TICKET MANAGEMENT
Score yesterday's SLA-breach predictions and publish accuracy to Notion
Each morning, compares the prior day's forecast against which tickets actually breached, computes precision and recall in Postgres.
How it runs
The automated pipeline, trigger to output.
- TriggerDaily each morning
- ActionRead prior-day predictionsPostgres
- ActionConfirm actual breaches in ZendeskZendesk
- LogicCompute precision, recall, false alarms
- ActionStore accuracy metricsPostgres
- OutputPublish scorecard to NotionNotion
What it does
This workflow keeps the forecaster honest. Every morning it pulls yesterday's stored predictions, checks which of those tickets actually breached SLA, and computes how well the model did: how many flagged tickets really breached, how many breaches it missed, and the trend over time. It writes a dated scorecard to a Notion page so the team can see whether the forecast is trustworthy and tighten the threshold when it drifts.
When to use it
Use this alongside any of the breach-forecast workflows. Without measuring accuracy you can't tell whether the alerts are worth acting on, and a noisy or blind forecaster quietly loses the team's trust.
How it works
- 1A daily morning schedule fires the run.
- 2Read yesterday's prediction set and outcomes from Postgres.
- 3Query Zendesk to confirm which of those tickets actually breached their SLA.
- 4Compute precision, recall, and false-alarm rate, then store the results back in Postgres.
- 5Render a dated accuracy scorecard with the running trend.
- 6Publish the scorecard to the Notion dashboard page.
Set it up
What you configure once, before turning it on.
- 1Connect PostgresAny Postgres URL — query, write, migrate.
- 2Connect ZendeskTickets, queues, knowledge base.
- 3Connect NotionPages, databases, comments.
- 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.