TICKET MANAGEMENT
Escalate Near-SLA-Breach Tickets by Revenue Weight
When a Zendesk ticket approaches its SLA deadline, checks the account's ARR from a Postgres CRM mirror and routes only the high-revenue ones to PagerDuty while logging the rest.
How it runs
The automated pipeline, trigger to output.
- TriggerZendesk SLA-warning webhook firesZendesk
- ActionLook up account ARR in Postgres CRM mirrorPostgres
- LogicGate on ARR threshold and time-to-breach
- ActionHigh impact: create PagerDuty incident with ARR payloadPagerDuty
- OutputLow impact: write event to Postgres escalation logPostgres
What it does
Not every SLA breach deserves a page. This workflow listens for Zendesk SLA-warning events, looks up the affected account's ARR in a Postgres CRM mirror, and applies a revenue gate: tickets tied to high-ARR accounts trigger a PagerDuty incident, while lower-impact ones are recorded to a tracking table for normal handling.
When to use it
Use it when SLA-breach alerting is noisy and on-call engineers are paged for low-stakes tickets. Best for teams with a synced Postgres copy of CRM data who want escalation severity to track affected revenue rather than treating every deadline equally.
How it works
- 1A Zendesk SLA-warning webhook fires as a ticket nears its deadline.
- 2The ticket's organization is matched to an account row in Postgres and its ARR read.
- 3A gate compares ARR against a high-impact threshold and the remaining time to breach.
- 4Above threshold: a PagerDuty incident is created with the ARR and time-to-breach in the payload.
- 5Below threshold: the event is written to a Postgres escalation-log table for later review.
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
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.
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.
Escalate repeat reopens to a Linear bug
Detects when the same underlying issue reopens across multiple tickets, uses an AI agent to cluster them by root cause.
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.