Narrative 15: Blueprint - Automate, guide, and transform your support processes

Narrative 15: Blueprint - Automate, guide, and transform your support processes

Behind the scenes of a successful ticketing system: BTS Series 

Narrative 15: Blueprint - Automate, guide, and transform your support processes

Even organizations that deliver quality products and services can face low customer satisfaction when their processes for addressing issues are poorly defined. This problem often stems from communication gaps, inadequate training, or failing to involve the right stakeholders at the required stages. The problems may range from minor procedural errors to major organizational oversights, and the impact extends beyond customers; employees also face significant difficulties when structured processes are not correctly followed.
Using a Blueprint in Zoho Desk drives consistent, high-quality customer service by making support processes transparent and repeatable at scale, regardless of team size or industry. It enables teams to easily spot bottlenecks, monitor SLA compliance, and refine workflows for maximum efficiency. Whether for onboarding, escalations, or compliance management, Blueprint helps businesses accelerate case resolution, deliver timely experiences, and onboard new agents faster with clear, actionable guidance on every ticket.

Components of a Blueprint

In Zoho Desk Blueprints, "stages" represent distinct steps or milestones in a business process, while "transitions" define the movement and conditions required to progress from one stage to another. 

Stages

Stages are the specific checkpoints or states that a support ticket or record passes through in a process, such as "Assigned," "In Progress," "Awaiting Response," or "Closed." Each stage captures the ticket's status at a given point in time and provides visibility into the process's progress.

Transitions 

Transitions are the actions, criteria, and intermediate checkpoints required to move a ticket from one stage to another. A transition can enforce checks, require specific actions, or mandate that fields be completed before advancing to the next stage. Transitions can also be configured to trigger automations, send notifications, or assign ticket owners.

​
A transition typically includes:
  • The criteria for when the transition is allowed
  • The actions to perform during the transition (updating fields, completing checklists, sending messages)
  • Transition ownership (who can act)
  • Automated actions are triggered upon execution
​
Common transitions: These transitions can be accessed from multiple stages, such as a "Cancel Ticket" action available at any point in the process.
Parallel transitions: Multiple transitions can be configured to run in parallel, allowing a ticket to move through multiple paths simultaneously.

Highlights

Enabling Strict Mode ensures that agents strictly follow ticket processes. When activated, all other actions in the ticket interface are disabled, allowing agents to perform ticket-related actions exclusively through the transition bar.

Admins can now selectively set which actions and fields are required during a transition. The introduction of the Configure Mandatory option enhances this capability to provide greater control and flexibility in customizing Blueprints for various groups of agents and refining specific aspects of the support process.

Admins can now effortlessly prioritize and reorder transitions with a simple drag-and-drop feature. This allows them to easily arrange the sequence of transitions in a Blueprint to determine how they are presented to agents. In the past, this process required agents to delete and re-add transitions in the desired order, which was time-consuming and labor-intensive.

The number of Points and Transitions permitted in a blueprint dictates the complexity of the internal processes you can design for your team. We have increased the number of pointers and transitions to allow you to incorporate greater complexity into your support operations as needed. 

When developing a Blueprint, you may find the need to rename a State or modify its Status Type after it has already been linked to the blueprint. This was not an option previously, but we've now made it possible. You can now change the Status Type and rename states associated with a blueprint. 

Key Features

  1. Design sequential ticket workflows with defined states and transitions.  
  2. Assign transition ownership to agents or departments.  
  3. Control ticket progression by restricting actions until necessary steps are completed.  
  4. Automate notifications, field updates, task assignments, and custom functions during and after transitions.  
  5. Use a Blueprints dashboard to track the number of tickets in each stage, SLA violations, bottlenecks, and overall process efficiency.  
Idea

Commonly automated business processes

  1. Quote management
  2. Task management
  3. Library book lending
  4. Hospital management
  5. Converting leads to customers
  6. Order cycles
  7. Support request handling and escalations
  8. Recruitment
  9. Deal follow-up

Takeaway

Creating a Blueprint involves specifying the states (ticket statuses), transitions (actions to move between states), and, if needed, criteria to apply the Blueprint only to specific tickets. It provides structured guidance to agents and makes help desk operations more efficient and consistent across teams.


Please stay tuned for more in the Desk behind-the-scenes series.


Regards,

 

Kavya Rao

The Zoho Desk Team