How to build SLA breach alerts

What matters here

• Read the target from the contract. A premium customer and a free trial on the same clock means one of them is wrong.
• Warn at half and at eighty percent of the target. An alert at the breach only reports what already happened.
• Pause the clock only while the customer owes you a reply. A pause for internal reasons hides the delay you most need to see.
• Send the warning to a person by name, not to a channel. A warning everybody sees is a warning nobody owns.
• Count near misses as well as breaches. They show where the next breach comes from.

Who this is for

You run support operations. The help desk tracks SLA targets, but the warnings are a red badge in a view somebody has to open, and breaches are found in the weekly report.

How it works in practice

What has to happen between a ticket starting its clock and either being answered in time or escalated.

1. 1

   Each ticket gets a target from the customer's contract

   First response and resolution targets by support tier and priority, read from the account rather than a default.

2. 2

   The clock runs on the right hours

   Business hours or around the clock, in the customer's time zone, as the contract says.

3. 3

   The clock pauses only while the customer owes a reply

   Waiting on the customer pauses it. Waiting on engineering, a partner or another team does not.

4. 4

   A warning goes to the assignee before the target

   At half the target time with no reply, and again at eighty percent, with a link straight to the ticket.

5. 5

   A near breach on a key account reaches more people

   The team lead, and the account owner when the account is in renewal or already escalated.

6. 6

   Every breach and near miss is recorded

   With the tier, the queue and the reason, so the weekly review talks about causes rather than counts.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   First, find where the targets really live

   A clock is only as good as the target it counts down to.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Zendesk, Salesforce, Slack
   and Snowflake, or whatever we run in those seats. Before you plan
   anything, tell me which of them are already authenticated in the
   workspace.
   
   From Zendesk I need the Ticket model with status, priority, assignee,
   group and the SLA policy fields, plus the SLA policies themselves.
   From Salesforce I need Account and Contract with support tier, response
   targets if they are stored, renewal date, time zone and account owner.
   
   Tell me where each customer's targets actually come from today. If the
   help desk applies one policy to everybody while contracts say
   otherwise, that is the first thing to fix.

2. 2

   Set the target and the clock per ticket

   One number for everybody is wrong for nearly everybody.

   Headless skills build-workflow

   Copy

   Use build-workflow. When a ticket is created or its priority changes,
   set its first response and resolution targets from a table of
   support tier and priority. Read the tier from the account, not the
   ticket form.
   
   Run the clock on the hours the contract gives: business hours in the
   customer's time zone, or around the clock for the top tier.
   
   Pause the clock only while the ticket is waiting on the customer.
   Waiting on engineering, a partner or another internal team does not
   pause it. Record every pause with who set it and why.

3. 3

   Warn while there is still time

   An alert with time left is one somebody can act on.

   Headless skills tray-patterns

   Copy

   Use tray-patterns. Check open tickets every five minutes against their
   targets.
   
     At half the target with no public reply: message the assignee in
     Slack, with the ticket link, the customer and the time left.
     At eighty percent: message the assignee and their team lead.
     On an unassigned ticket: message the queue lead, since nobody else
     will see it.
     On a top-tier account, or one in renewal or already escalated: tell
     the account owner as well.
   
   Send each warning once per point, not every five minutes. When the
   ticket gets a reply, update the warning message to say it was saved.

   Updating the warning when the ticket is saved is what keeps people reading them. A channel full of stale red alerts gets muted within a week.

4. 4

   Record every breach and near miss

   The weekly review should argue causes, not counts.

   Copy

   Land every warning, save and breach in Snowflake with the tier, the
   queue, the assignee, the time of day, and whether the clock was paused.
   
   Report weekly: attainment by tier and queue, breaches by cause, near
   misses saved after the eighty percent warning, and time spent paused
   by reason.
   
   If most breaches happen on tickets that sat unassigned, the fix is
   routing, not the alert. If most happen at one time of day, it is
   staffing.

5. 5

   Validate, then hand the targets to support ops

   Because targets change every time a contract does.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production. Run it in report-only mode for a week first, so the
   warning points are set from real ticket timings.
   
   Then open the same workflow in Tray Build so support operations can
   change the targets table, the warning points and who gets told in the
   visual canvas.

What it connects to

The help desk runs the clock, the CRM sets the target, and the warning goes where people already work.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Further reading

Background on the same subject, for the case rather than the build.

• Solving the challenges of modern customer support with automation

Related guides