TICKET MANAGEMENT
Predict SLA misses from ticket history and escalate to PagerDuty
Hourly, scores open tickets against a historical breach model stored in Postgres and pages an on-call lead through PagerDuty when the predicted miss probability crosses…
How it runs
The automated pipeline, trigger to output.
- TriggerEvery hour
- ActionFetch open ticketsZendesk
- ActionLook up historical handle timesPostgres
- LogicScore breach probability within 4h
- LogicFilter above risk threshold
- OutputOpen PagerDuty incident for on-callPagerDuty
What it does
This workflow uses your own resolution history to estimate breach risk instead of relying only on the raw SLA clock. It pulls open tickets, joins each against a Postgres table of historical handle times by queue, priority, and tag, then computes a probability that the ticket will miss SLA in the next four hours. Tickets above the risk threshold trigger a PagerDuty incident so a lead can intervene before the breach lands.
When to use it
Use this when simple time-remaining math under-predicts breaches because some ticket types reliably run long. The model captures that pattern and warns you early on the tickets that statistically blow up.
How it works
- 1An hourly schedule starts the run.
- 2Fetch all open tickets from Zendesk with their queue, priority, and tags.
- 3Query Postgres for historical median and tail handle times matching each ticket's attributes.
- 4Compute predicted finish time and the probability it lands after the SLA deadline within 4 hours.
- 5Filter to tickets above the configured risk threshold.
- 6Open a PagerDuty incident summarizing the at-risk set and assigning the support on-call.
Set it up
What you configure once, before turning it on.
- 1Connect ZendeskTickets, queues, knowledge base.
- 2Connect PostgresAny Postgres URL — query, write, migrate.
- 3Connect PagerDutyIncidents, on-call, escalations.
- 4Set each agent's modelWe leave models unset so you pick the tier — fast + cheap, or top-quality.
- 5Tune it to your dataEdit the prompts, filters, and field mappings so it matches how your team works.
- 6Test, then turn it onRun once against a sample, confirm the output, then enable the trigger.
More Ticket Management workflows
Intercom Known-Issue Auto-Responder
When a new Intercom conversation matches a known active incident, it attaches the conversation to that incident's parent ticket and sends the customer the current status reply.
Weekly reopen-by-agent coaching digest
Aggregates each agent's solved-then-reopened tickets for the week, identifies the most common reopen reason per agent, and emails a private coaching digest to the support manager.
Deduplicate Discord bug reports against existing Linear issues
Before creating anything, searches Linear for issues matching a new Discord bug report; if a duplicate exists it comments and links the report there, otherwise it opens a fresh…
Enrich Discord bug reports with Sentry errors before filing in Linear
Takes a Discord bug report, has an LLM pull out likely error signatures, searches Sentry for matching events.
Front-to-Linear Recurring Bug Linker
When a Front ticket is tagged as a bug, it searches Linear for an existing matching issue and either links the ticket to that parent issue or opens a new tracked one.
Front Duplicate Conversation Clusterer
When a new Front conversation arrives, it semantically compares the report against open conversations.
Run it inside a business
This workflow drops into a full company template. Import the org, and this is one of the playbooks its agents run.
Run this workflow in your colony.
14-day trial. No DevOps. No Sales call. Provisioned in under a minute.