Tickets that land on the wrong desk cost you hours before anyone even starts. Here is how to route each one to the right owner, with proof attached, in under a minute.
See the pattern in action, tap through the tabs below:
The bottleneck: every request lands in one shared queue. A senior engineer reads each one, guesses the owner, and forwards it. Tickets bounce two or three times, and the urgent ones age while people argue about whose they are.
The outcome: each ticket reaches the right owner in under a minute, with the evidence attached, and anything uncertain goes to a human instead of a guess.
# routing-policy.yaml
# One intake, four owners. Each rule names the evidence that triggers it.
intake:
sources: [pagerduty, jira, slack_requests]
dedupe_window_minutes: 30
router:
process: hierarchical # manager agent assigns, specialists execute
min_confidence: 0.75 # below this, a human triages
roles:
- name: sre_owner
handles: [latency, saturation, failed_deploy]
evidence: [dashboard_link, recent_deploys]
- name: security_owner
handles: [suspicious_login, cve_alert, secrets_leak]
evidence: [alert_id, affected_asset]
- name: platform_owner
handles: [ci_flake, cluster_quota, base_image]
evidence: [pipeline_run_url]
- name: data_owner
handles: [pipeline_lag, schema_change]
evidence: [job_id]
fallback:
owner: on_call_human
sla_minutes: 10
audit:
log_every_decision: true # who, why, confidence, rule matched
> router replay --ticket OPS-4821 [09:02:11] intake "p95 latency up on checkout after 08:55 deploy" [09:02:12] classify category=failed_deploy confidence=0.91 [09:02:12] rule sre_owner matches failed_deploy [09:02:13] evidence dashboard_link OK, recent_deploys OK [09:02:13] assign OPS-4821 -> sre_owner (rationale logged) [09:02:14] notify #sre-oncall with summary + rollback link > router replay --ticket OPS-4822 [09:07:40] intake "weird login from new country for svc account" [09:07:41] classify category=suspicious_login confidence=0.68 [09:07:41] gate confidence below 0.75, human triage [09:07:42] assign OPS-4822 -> on_call_human (sla 10m)
1. Export 200 recent tickets and label the true owner by hand.
2. Write one rule per owner with the evidence it needs.
3. Run the router in shadow mode for a week and compare it to the humans.
4. Raise the confidence bar until misroutes hit zero, then go live.
Why wrong-desk tickets are so expensive
Ask any on-call engineer about their worst week and routing shows up fast. A latency alert goes to security. A suspicious login goes to platform. Each hop adds a handoff, a Slack thread, and a few minutes of confusion.
The cost is not just the delay. It is the senior person who becomes a human switchboard, reading every request just to decide who should read it. That is the most expensive routing engine you could build.
The outcome: automated task routing with a paper trail
The goal is simple. Every new request is classified, matched to an owner, and delivered with the evidence that owner needs. If the system is unsure, it says so and hands the ticket to a person.
- Classify: read the title, body, and attached alert, then pick one category.
- Match: look up the owner role that handles that category.
- Verify: check that the required evidence (dashboard link, alert ID, run URL) is present.
- Deliver: post to the owner's channel with a two-line summary and the next action.
- Log: record the rule, the confidence score, and the reason.
Where most routing automations fail
The common mistake is routing on keywords. "Login" appears in a password reset and in a credential stuffing attack, and those need very different owners. Routing on category plus required evidence is far more reliable, because a ticket missing its evidence gets bounced back to the requester instead of to a teammate.
The second mistake is forcing a decision. A router that must always pick an owner will pick wrong about one time in ten, and nobody will trust it after the first bad page. A confidence floor with a human fallback is what keeps trust intact.
How it's built
Tools are the easy part here. The pattern is a manager agent that assigns work and a handful of specialist roles, each with a narrow job and a short list of tools. Frameworks such as CrewAI's hierarchical process model exactly this shape, and you can wire the same logic in a workflow engine if you prefer a visual builder.
Keep the roles boring
Each role should read like a job description: what it handles, what evidence it needs, and who it escalates to. If you cannot describe a role in one sentence, split it.
Run in shadow mode first
For the first week, let the router make decisions but do not act on them. Compare its picks with what your humans actually did. The gap tells you which rules need tighter evidence requirements before you let it touch real pages. This mirrors the discipline in Google's incident management guidance, where clear roles beat heroics.
Measure three numbers
- Misroute rate (tickets reassigned by a human within an hour)
- Time to first owner touch
- Share of tickets sent to the human fallback
A healthy router starts with a high fallback share and shrinks it as the rules improve. If the fallback share drops to zero on day one, the confidence bar is too low.
FAQ
How is automated task routing different from a ticket rule in Jira?
Static rules match fields and keywords. An agent-based router reads the free text and the attached evidence, so it can handle messy requests, while still falling back to a human when it is unsure.
Will it replace our on-call engineers?
No. It replaces the manual sorting step. People still own the decisions, and the audit log shows exactly why each ticket went where it did.
How long does a pilot take?
A scoped pilot for one queue usually takes a week or two: a few days to label tickets and write rules, then a week of shadow mode.
If you want this routing workflow built for your own team, the hands-on labs in the DevOps Boot Camp are a good place to start, and you can browse everything on the courses page.
