Skip to content
CosmosCLIChangelog
Context EnginePricingDocsBlog
CustomersCareersStatus PageTrust CenterSecurity
Talk to SalesSign in
Book demo

Support

Intelligent ticket dispatcher

Classify new issues by type, component, and severity, assign the right owner, and notify them before manual triage begins.

supportroutingtriagelinearjiradispatcherautomationclassificationslackassignment

[ workflow / support ]

Intelligent ticket dispatcher

New tickets from Linear, Jira, or support are classified by type, component, and severity. Cosmos matches the result against routing rules, assigns owner, priority, and SLA tier, then notifies the assignee in Slack. Tickets without a route go to a human triager instead of disappearing.

10 nodes

08 edges

Trigger[trigger]
New ticket created

Linear / Jira / GitHub Issues

System step[parse]
Parse ticket

Title, description, fields

AI Agent step[classify]
Classify type + component + severity

Bug / component / P0–P3

AI Agent step[enrich]
Enrich with related tickets

Similar issues, recent incidents

System step[lookup]
Look up routing table

Type × component × severity

Decision

Routing rule matched?

Known classification

No
Human-in-the-loop[triage]
Escalate to triage owner

Unrouted label + context

YES
System step[assign]
Assign ticket

Assignee + priority + SLA

Output / Result[notify]
Notify assignee via Slack

P0/P1 pages on-call channel

Bypass (already solved)[log]
Log routing decision

Audit log entry

Workflow prompt

Paste this into Augment to reproduce the workflow end-to-end.

Build a Cosmos workflow that classifies and routes every new ticket to the right owner before a human reads it.

Trigger: a new ticket is created in Linear, Jira, GitHub Issues, or a connected support desk.

Steps:
1. Parse the ticket. Extract: title, description, reporter, attachments, labels already applied, linked tickets or PRs, and any structured fields (component, version, environment) filled in by the reporter.
2. Classify the ticket. Determine:
   a. **Type**: bug, feature request, question/support, incident, chore/task, or security report.
   b. **Component area**: from a configured list (e.g. authentication, billing, API, data pipeline, frontend, infrastructure, security). Use the description text, labels, and any stack traces or error messages to infer the component if not explicitly set.
   c. **Severity**: P0 (production down / data loss), P1 (major feature broken), P2 (degraded but workaround exists), P3 (cosmetic / minor).
3. Enrich the ticket. Search for related open tickets, recent incidents, and similar closed issues to surface patterns. Add this context as a comment on the ticket.
4. Look up the routing table. Match the type + component + severity combination against the configured routing rules. The routing table maps combinations to: team queue, individual assignee, or escalation path.
5. Decision: "Routing rule matched?".
   - If no match found, route to the configured triage owner (a human) and add an "unrouted" label with a note explaining what classification was applied and why no rule matched.
   - If matched, continue.
6. Assign the ticket. Set the assignee (team or individual), apply the correct priority, set the SLA tier based on severity and support plan, and apply the relevant component label.
7. Notify the assignee via Slack: ticket title, type, severity, one-sentence summary, and a direct link. For P0 and P1 tickets, page the on-call channel.
8. Log the routing decision (ticket id, classification, routing rule applied, assignee, latency) to the dispatcher audit log.

Constraints:
- Never silently discard an unmatched ticket: always escalate to the triage owner with context.
- P0 incidents must page the on-call channel; do not route them only to a Slack DM.
- Keep the routing table in a configuration file (not hardcoded) so it can be updated without a code deploy.
← All Workflows