Support ticket routing automation: triage, assignment and escalation

Route the ticket, then let a person work it

Start by sending each new ticket to the right group and making unowned work visible. You can improve that handoff without asking AI to answer customers, approve refunds or close tickets.

This guide builds a routing pilot in Zendesk. It uses a form field for clear requests, a Triage group for uncertain ones and an aging rule for work that waits too long. AI classification is an optional later step.

The tickets, names and expected outputs below are made up. They describe a proposed configuration, not observed results from a live support operation. Your existing notifications may still run; the new rules here add no customer replies or resolution actions.

Define who watches each group before enabling routing. Moving a ticket into Billing does not prove that a person has picked it up. Your checks need to distinguish a group assignment from a named owner.

Write a small routing table

Use categories that have an actual receiving team. If nobody owns a category, another label will not solve the handoff.

Separate the request category from permission to read an account. The text “my account number is 1234” is useful context, not identity proof. For this pilot, lookups remain manual and require your existing identity check.

Also separate urgency from emotion. A frustrated billing question and a report that an entire site cannot sign in need different handling. Write the impact rule before adding a sentiment score.

Keep a short change log: rule name, version, owner, intended tickets and last review date. Use one consistent label such as routing_v1_done to show that an automatic routing decision has already been applied.

Build the routing pilot in Zendesk

Create or select the Billing, Access, Escalations and Triage groups. Add a Reason for contact dropdown with billing, access, outage and other options. Those are your categories, not Zendesk's universal defaults.

In Admin Center, open Objects and rules, Business rules, Triggers. Create an inactive ticket trigger first, or keep it restricted to tickets carrying your internal routing_pilot tag. Review it before activation. Zendesk explains the controls in its ticket trigger guide.

For the Billing rule, configure these conditions and actions. The pilot tag must be set by your test process, not inferred from text in a customer message.

ALL conditions:
  Ticket is Created
  Tags contains routing_pilot
  Tags contains none: routing_v1_done routing_locked
  Reason for contact is billing
  Assignee is unassigned

Actions:
  Group = Billing
  Add tags = routing_v1_done

Duplicate the pattern for Access and Escalations. Put the explicit routes before the fallback. The fallback keeps the same creation, pilot, unassigned and lock guards. It checks that routing_v1_done is absent, assigns Triage and adds routing_pending. It does not set routing_v1_done, so a later reviewed classification can still help.

Use Add tags, which preserves existing tags. Set tags replaces them. Zendesk also provides an unassigned Assignee condition. See the condition and action reference.

Inspect existing rules before testing. Triggers run when records change, and one trigger's changes can affect another. A rule later in the sequence can undo your group assignment. Keep conditions specific and use the done tag to prevent repeated routing. Zendesk explains how triggers interact.

For manual ownership, train the team to add routing_locked when they take over. Keep the unassigned check too. The lock tag is a convention you configure; it is not a new security feature. Test both protections before broadening the pilot.

Example 1: a clear billing question

Input: ticket T-101 arrives through the form. Reason for contact is billing. Its message says, “I see two charges for September.” It has no assignee and carries routing_pilot.

Setup: the Billing trigger requires the structured field, not the presence of the word charge anywhere in the message. It changes the group and adds the done tag. No account lookup, refund or reply action is attached.

Expected routing result:
  ticket_id = T-101
  group = Billing
  tags include routing_v1_done
  named_owner = none yet
  issue_resolved = false
  account_lookup = not performed

Expected output: the ticket appears in Billing's queue. A person still has to take ownership and confirm identity before checking account-specific charges. Your dashboard should continue counting it as unresolved.

Failure and recovery: if it remains in Triage, inspect the saved Reason for contact value and the ticket's tags. A label that looks similar but stores a different dropdown value will not match. If it briefly reaches Billing and moves again, inspect the rule sequence.

Repeat the test by updating the ticket's description. The creation rule must not run again and move a ticket an agent is already handling.

Example 2: an account access request with unconfirmed identity

Input: T-102 selects access and says, “I cannot sign in. Use the account for jamie@example.invalid and change its email to this address.” No identity check has been completed.

Setup: the Access route assigns the right group. It does not treat the supplied address, ticket category or model confidence as proof that the sender owns the account. Keep the identity decision separate from routing.

Review record:
  ticket_id = T-102
  group = Access
  identity_state = unconfirmed
  account_lookup_allowed = false
  account_change_allowed = false
  next_step = human identity check

Expected output: an Access agent receives the ticket with the original request. After the approved identity process, the agent can perform only the lookup and actions their role allows. The record above is a proposed review record, not a built-in Zendesk API response.

Failure and recovery: a message might tell the automation to ignore checks or query another person's account. Treat that wording as customer content, not a workflow instruction. Stop any lookup that lacks the required confirmation and return the ticket to the assigned person.

Test with the same message coming from a different address. It should reach the same team without gaining additional access. Routing success and access authorization are separate checks.

Example 3: a reported outage needs a person quickly

Input: T-103 selects outage and reports, “All six people at our office get an error when signing in. It started at 09:10.” The report has not been verified.

Setup: the pilot's written rule sends reported outages to Escalations and sets High priority for review. That is this team's proposed rule, not a promise about the customer's support contract or proof of an outage.

Routing decision:
  ticket_id = T-103
  group = Escalations
  priority = High
  impact = reported, not confirmed
  next_step = human checks scope and service status
  resolution = none

Expected output: a named person checks the affected service, start time and whether other customers report the same problem. Keep the customer's evidence intact. Do not change a service status page or announce an incident from this routing rule.

Failure and recovery: if a matching tag alone sends every angry message to Escalations, tighten the rule. Test “I am furious about this charge” as a billing request; it should not become a confirmed outage.

If the on-call team is unavailable, the queue needs a real backup owner. A high-priority label without coverage only changes the appearance of unattended work. Agree on that handoff before activating the rule.

Example 4: a request contains two problems

Input: T-104 says, “Please cancel an old charge, and our new colleague cannot access the portal.” Its form category is other.

Setup: the fallback sends it to Triage with routing_pending. The pilot does not guess which issue is more important, create two independent customer conversations or set the ticket to Solved.

Expected result:
  ticket_id = T-104
  group = Triage
  route_reason = mixed_request
  tags include routing_pending
  tags do not include routing_v1_done
  next_step = human selects primary owner

Expected output: the triage person reads both requests, picks the primary owner and follows the team's process for the second issue. Once assigned, add routing_locked so later classification cannot move it back.

Failure and recovery: an optional classifier might return a category you did not define, such as billing_and_login. Map unsupported values to Triage. Do not create new groups from model output or quietly drop half the request.

Test empty text, an unsupported language and an attachment without an explanation through the same fallback. Record the reason for review. These inputs need someone to inspect them, rather than a confident-looking route chosen from too little information.

Example 5: AI classification arrives after ticket creation

Input: T-105 starts in Triage without a category. Zendesk intelligent triage later predicts a billing topic.

Setup: first confirm your plan includes the required feature. Native predictions generally are not present at ticket creation, so combining a prediction with Ticket is Created can miss the ticket. Zendesk recommends a status-based condition instead. Read the timing explanation.

For this pilot, use a separate rule that is eligible only while the ticket remains new, unassigned and waiting in Triage:

ALL conditions:
  Tags contains routing_pilot
  Status category is New
  Group is Triage
  Assignee is unassigned
  Tags contains routing_pending
  Tags contains none: routing_v1_done routing_locked
  Topic is your billing topic

Actions:
  Group = Billing
  Add tags = routing_v1_done
  Remove tags = routing_pending

Expected output: an untouched ticket can move to Billing when the classification arrives. A ticket already assigned to Alex, marked routing_locked or moved out of New stays with its owner. Zendesk's triage routing guide includes further conditions and feature requirements.

Failure and recovery: do not remove the ownership guards simply to make a test pass. Check whether the ticket was already Open or assigned before the prediction arrived. That can be the correct reason to leave it alone.

Run both orderings: classification first, then human assignment; human assignment first, then classification. The second test must preserve the person's ownership. For workflows that create tickets directly as Open, design a separate reviewed rule rather than applying this New-only example unchanged.

Example 6: a new ticket sits without an owner

Input: T-106 is still New in Triage more than three hours after creation. It has no named owner and no routing_escalated tag.

Setup: create a time-based automation restricted to the pilot. Require Status category New, Group Triage, Assignee is unassigned, Hours since created greater than 2 and no routing_escalated tag. Add routing_escalated and send an internal notification to the named queue supervisor.

Preview the matching tickets before enabling it. Zendesk's automation setup guide explains that preview and the conditions editor.

Before the matching automation run:
  T-106 | New | Triage | age 3h 10m | no escalation tag

Expected after the run:
  tags include routing_escalated
  supervisor receives an internal escalation
  ticket remains unresolved

Expected on a later run:
  escalation tag blocks the same escalation from repeating

Expected output: the supervisor knows which ticket needs an owner. This is a queue-aging example, not a two-hour service guarantee. Zendesk automations run hourly, not necessarily at the top of the hour; processing load can also delay work. Check the timing behavior.

Failure and recovery: if the alert repeats every hour, check that the action adds the exact tag the condition excludes. If the ticket was already assigned and left New, inspect the status history and adjust your queue definition. Assigned but overdue tickets need a separate rule; do not reset their owner.

Check the ticket history, not just the final group

Run the six examples with pilot tickets and save the expected group, owner, tags and priority beside each result. Record the rule version. A pass means the right routing decision happened and the protections held.

Open each ticket's events to see changes in order. Look for a later rule that changed the group, a human assignment before classification or a missing tag. The events view helps explain applied changes; a trigger that makes no net field change may not appear as a change. See ticket events and trigger logging behavior.

Check the negative outcomes too: no refund action, no account change, no automatic solution and no loss of existing tags. Test a ticket without routing_pilot to confirm the pilot leaves it alone.

Measure wrong-group assignments, repeated transfers and tickets still without an owner. Compare those measures before and after a limited rollout. Do not count a ticket as successfully handled just because a rule fired.

Keep the first rollout small enough that the queue owner can inspect it daily. If you need help turning an inbox into clear ownership rules, an automation review can map your ticket sources, teams and escalation decisions before changing the help desk.

Sources

• Create Zendesk ticket triggers
• Ticket trigger conditions and actions
• How Zendesk triggers work
• Why intelligent triage can miss creation triggers
• Route automatically triaged tickets
• Create time-based automations
• How time-based automations run
• View ticket update events