Routing & Automation
Part of Choosing customer support software
Defining support workflows before comparing tools
Create a concise support workflow brief covering intake, ownership, handovers, required data and completion before comparing software.
Define the support workflow before comparing software: how a request arrives, who owns it, what information is needed, what happens while it waits and what counts as finished. Capture the result in a short brief that vendors can answer. It need not prescribe every screen or automation rule.
Start with a few types of work
Group recent enquiries by the action they require, not only by channel. A delivery question, an account-access problem and a complaint may all arrive by email, yet each needs different information and follow-up. Strip personal details from examples used in a planning workshop.
For each issue type, record the entry point, the team that takes it, the information needed for a useful first response, and who remains accountable if another team contributes. Include work outside the support platform. A workflow that ends at ‘escalate’ still needs a recipient and someone responsible for updating the customer.
Describe the path from arrival to completion
A compact worksheet can expose gaps:
| Stage | Question for the team |
|---|---|
| Intake | Which contacts become support work, and what minimum details are needed? |
| Triage | Who identifies the issue type and any urgent exception? |
| Ownership | Who gives the next response, and how is unowned work noticed? |
| Waiting | What is the team waiting for, and who checks that work resumes? |
| Handover | What context goes to a specialist, and who communicates with the customer? |
| Completion | What evidence shows the requested action is done? |
Use the team’s own language. If ‘pending’ means waiting for the customer in one team and waiting for a supplier in another, define each meaning separately. The brief should state what each situation means for ownership and follow-up; detailed ticket-status design can wait.
Specify the information and authority needed
List fields that change a decision. For an illustrative damaged-delivery enquiry, an agent might need an order reference, the affected item and a description of the damage.
The organisation’s policy determines whether a refund, replacement or specialist review is available. Mark what the customer can supply, what must come from an internal system and what needs verification before an agent acts.
Zendesk documents standard and custom ticket fields used in forms and workflows. Freshdesk documents ticket fields, including custom ticket fields. These examples show why the brief should name required data and why a comparison must use the proposed edition; neither provider’s default form is assumed to match your process.
Record authority as carefully as data. Who may promise a replacement, change an account, view a restricted case or close an issue? If a specialist advises but the original agent remains responsible for the customer reply, say so. Permissions and handover controls can then be compared against agreed responsibility.
Setting Up Automation Rules on Ticket Creation
- Rule ConfigurationUse conditions and actions to automate workflows based on ticket creation.
- Rule ExecutionChoose between first-match or all-match execution; order affects rule application.
Turn the workflow into comparison questions
For each stage, ask a vendor to show the relevant capability in the proposed plan and identify any manual step. Separate the required outcome from a preferred implementation. ‘A supervisor can find an unowned urgent enquiry’ is a requirement; a particular dashboard or rule is one possible way to meet it.
Freshdesk documents ticket-creation rules that use conditions and actions. It also explains how rule order and the choice between first-match and all-match execution affect which rules run. Document decisions and exceptions before configuring automation.
Finish with a brief that names the issue types, owners, required data, exceptions and completion conditions, plus questions the team has yet to resolve. That brief gives every vendor the same work to answer.
