How to automate SLA breach alerting against the right clock

An SLA is a contract, and a breach is a contractual event with consequences — a credit, a report, sometimes a right to terminate. That makes SLA alerting different from ordinary monitoring: the definition of "late" is written down somewhere, by lawyers, and your alerting has to agree with it.

Most implementations do not. They measure elapsed time from ticket creation, which is a different quantity from what the contract says, and the difference shows up when somebody disputes a credit.

What we'll cover

• The clock is not wall-clock time
• Response, update, and resolution
• Pause states, and who controls them
• Building it with CodeWords
• Alerting before the breach
• When a breach happens anyway
• Reporting to the customer
• Staffing against the pattern
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

The clock is not wall-clock time

Business hours are the usual basis, so a ticket raised at five on Friday with a four-hour response target is not late on Saturday morning.

Calendars differ per contract, per customer tier, and per region — and one global calculation is wrong for at least one of them.

Holidays count, and they differ by country. A calculation ignoring them alerts through a public holiday, which teaches people to ignore the alerts.

Some targets run around the clock and others do not, frequently within the same agreement, so there is no single rule to apply.

The timezone is the customer's or yours, depending on what the contract says, and assuming is how a dispute starts.

Read the deadline from your helpdesk where it computes one, rather than deriving your own. It already accounts for all of this and it is the figure you will be held to.

Response, update, and resolution

Three different obligations that get conflated into "the SLA".

First response — somebody replied. Usually the tightest target and the easiest to meet.

Subsequent updates — a promise to keep the customer informed at intervals, which is the one most often missed because nothing prompts it.

Resolution — the problem is fixed, with a much longer target and much more ambiguity about what counts.

They have different clocks and different consequences, and an alert that does not say which is at risk leaves the agent guessing.

Resolution is the contestable one. What counts as resolved — a workaround, a fix deployed, the customer agreeing — should be defined in the contract and frequently is not.

Alert per obligation, naming it, because the action differs: a response needs a reply now, an update needs a message, a resolution needs escalation.

Pause states, and who controls them

The mechanism that decides whether the numbers are honest.

A ticket waiting on the customer usually pauses the clock, which is reasonable and is where most disputes originate.

Who sets pending matters. If agents can pause freely, the metric measures agent behaviour rather than service quality.

Report time spent paused, per ticket, since a ticket paused for three weeks is a customer being ignored with a green SLA.

Watch for pause abuse — a pattern of pausing near a deadline is visible in the data and invisible in the summary.

Resume correctly. A customer reply should restart the clock immediately, and a delay in detecting it silently consumes the target.

Agree the rules once, write them down, and make the alerting follow them rather than reimplementing an interpretation.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so alerting can combine the helpdesk's own deadline with the contract tier from your CRM.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which tickets, which obligation, what threshold, and who is told.
3. Authorize the connections — the helpdesk, the CRM, and wherever alerts should go.
4. Describe the exceptions: a paused ticket, a customer with a non-standard agreement, a ticket with no applicable target.
5. Run it against last month's tickets and check its breach list matches what actually happened.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Alerting before the breach

The whole point, since a breach notification reports a failure that already cost you.

Alert at a proportion of the remaining time, not at a fixed offset, so a four-hour target and a five-day one both warn usefully.

Two thresholds. A nudge to the assignee at around three-quarters elapsed, and an escalation to a lead nearer the deadline.

Say what is needed and by when, in business hours, so the agent does not have to calculate it themselves.

Route to a person, not a channel, for the first alert — a channel message about somebody's ticket is addressed to nobody.

Handle the assignee who is away, since a nudge to somebody on holiday consumes the remaining time silently.

Do not alert on paused tickets, which is the most common source of noise and the fastest way to get the alerting muted.

When a breach happens anyway

Record it deliberately, with the cause, at the moment it happens rather than reconstructing at month end.

Notify somebody who can act, which for a contractual breach is usually an account owner rather than only the support lead.

Classify the cause: understaffed, waiting on engineering, an unusual request, or a target that is unrealistic. Those four have different remedies.

Do not quietly adjust the record. Editing a ticket to avoid a breach is a data integrity problem and, for a contract with credits attached, worse than that.

Report breaches weekly with causes, since the pattern is the useful part and a monthly count is not.

Feed it back into the target. A target breached routinely for structural reasons is a commercial conversation, not a support performance problem.

Reporting to the customer

Many contracts require it, on a schedule, and producing it by hand each month is exactly the work worth removing.

Report against the contract's definition, not your internal one, since those can differ and the contract is what was agreed.

Include the breaches, with what happened, rather than only a percentage — a report that shows only a headline number invites the question you should have answered.

Be consistent month to month. A changed methodology looks like a changed result, and explaining it is harder than being consistent.

State the exclusions — planned maintenance, customer-caused delays — clearly, since those are what a dispute will focus on.

Have the numbers ready before the review, so the meeting is a discussion rather than a reconciliation.

Staffing against the pattern

Most breaches are predictable, which makes them a scheduling problem rather than an alerting one.

Report breaches and near-misses by hour and weekday. The pattern is usually stark — a particular afternoon, the hour after a regional handover, Monday mornings.

Look at near-misses, not only breaches. Tickets answered with minutes to spare are the same staffing problem, and there are far more of them.

Correlate with volume. A queue that reliably exceeds capacity at the same time each week is a rota question, and no amount of nudging fixes it.

Watch the handover boundary. Tickets arriving just before a region finishes are the ones most likely to sit, and the pattern shows up immediately once somebody looks.

Give the data to whoever sets the rota, not to the support lead alone, since the fix is usually cover rather than urgency.

Re-check quarterly. Volume patterns shift with seasonality and with the customer base, and a rota set a year ago is fitted to a different shape.

Making it survive

Read the helpdesk's computed deadline rather than deriving one, so your alerting and your reporting cannot diverge.

Make it idempotent, keyed on the ticket and the threshold, so a ticket alerts once per obligation rather than repeatedly.

Handle the ticket with no applicable target, which is common and should be reported rather than treated as instantly breaching.

Re-check when the priority changes, since the target changes with it and a reprioritised ticket may already be late.

Report the outcome. Alerts sent, breaches recorded, and tickets excluded with the reason.

Limits worth knowing about

Your helpdesk's calendar configuration is the source of truth, and a mismatch between it and the contract is a problem no alerting can fix.

Priority changes mid-ticket alter the target, and how your tool handles that varies.

Multi-party obligations — where a third party's response time is inside your own commitment — are rarely modelled and are where real breaches originate.

Credits and penalties are contractual, and calculating them is a finance and legal matter rather than something to automate quietly.

This is not contract advice. What your agreements require, exclude, and entitle customers to is a question for whoever advises you.

What to build first

A pre-breach alert using the helpdesk's own deadline, at around three-quarters of the remaining business-hours time, sent to the assigned agent, naming which obligation is at risk and skipping paused tickets. It catches the ticket while there is still time, and using the helpdesk's figure means your alerting cannot disagree with your reporting.

Two habits make the difference. Use the computed deadline rather than ticket age, since business hours and per-tier calendars make those very different numbers. And exclude paused tickets from the first version, because alerting on them is the fastest route to the whole thing being muted.

Frequently asked questions

Why does my SLA alerting disagree with the helpdesk?

Because it is measuring elapsed time rather than the contractual clock. Business hours, per-tier calendars, holidays, and pause states all apply, and the helpdesk's computed deadline already accounts for them.

Which obligation should the alert name?

Whichever is at risk — first response, an update, or resolution. They have different clocks and different actions, and an alert that does not say which leaves the agent working it out.

Should paused tickets alert?

No. It is the most common source of noise and the fastest way to get the alerting muted. Report time spent paused separately, though, since a ticket paused for weeks is a customer being ignored with a healthy-looking SLA.

When should the alert fire?

At a proportion of the remaining time rather than a fixed offset, so both a four-hour and a five-day target warn usefully. Two thresholds work well: a nudge to the agent, then an escalation.

What should happen when a breach occurs?

Record it with the cause at the time, notify somebody who can act commercially as well as operationally, and classify why. Never quietly adjust the record — for a contract with credits attached that is considerably worse than the breach.

What causes most real breaches?

Waiting on a third party whose response time sits inside your own commitment, which is rarely modelled anywhere. After that: understaffing at predictable times, and targets that were never realistic.

Does this cover our contractual obligations?

No. What your agreements require, exclude, and entitle customers to — and how credits are calculated — is a question for whoever advises you. The alerting should follow the contract, not define it.

Most of our breaches look random — are they?

Rarely. Report breaches and near-misses by hour and weekday and the pattern is usually stark: a particular afternoon, the hour after a handover, Monday mornings. That makes it a rota question rather than an urgency one.

Why track near-misses?

Because a ticket answered with minutes to spare is the same staffing problem as one that breached, and there are many more of them. Breaches alone are too rare a signal to plan a rota from.

Related reading

• Automated ticket routing
• Connecting Zendesk to Slack
• Freshdesk and CodeWords