Two Promises, and Why One Marker Was a Bug
A support contract makes two promises — we will answer by then, we will fix it by then — and they need two alarms. Giving them one shared "already notified" flag would have meant the first breach permanently silenced the second.
Where a support agreement carries a penalty, the deliverable is not the support. It is the evidence about the support, and evidence has a property that operational data does not: it has to survive somebody disagreeing with it.
Two promises
A ticket category holds two targets. One is how quickly a human will respond. The other is how quickly the thing will be fixed. They are set independently, they expire independently, and they mean different things to a customer.
The first response is a promise about attention. The resolution is a promise about outcome. A desk can honour either and miss the other, and customers care about the first one more than most agreements reflect.
First response
- Measured in minutes or hours
- Entirely within the desk's control
- Breached silently and early
- The one customers actually feel
Resolution
- Measured in hours or days
- Often depends on somebody else
- Breached loudly and late
- The one written into the contract
The arrangement that was worst
For a period, this product computed the first-response deadline, stored it, exposed a working check for whether it had been breached, and counted those breaches in a published report — while the job that raises alarms filtered on the resolution deadline only.
So the report told you afterwards how many first responses you had missed, and nothing told you while you could still make one. As the code comment on the fix puts it, that is the least useful arrangement of those parts: all of the measurement, none of the intervention.
Every component of the alarm existed. They had simply never been connected to each other, and the report made the absence look like a feature.
The design question inside the fix
Raising the alarm was the easy half. The interesting half was a column.
Every alert needs a marker recording that it has been sent, or it fires every time the job runs and people build mail rules to hide it. The obvious implementation is one marker per ticket: we have told them about this ticket.
That would have been a bug, and a quiet one. First response comes due long before resolution. A ticket that breaches its first-response target gets an alert, the marker is set — and when the resolution deadline passes hours later, the ticket is already marked as notified, so the second and more consequential alarm never fires.
One marker means the cheaper promise silences the dearer one, permanently, for exactly the tickets that are going worst.
One marker versus two, across the four outcomes
| What happens | One shared marker | Two markers |
|---|---|---|
| First response breached, alert fires | Yes | Yes |
| Resolution later breached, alert fires | No | Yes |
| Resolution breached first, alert fires | Yes | Yes |
| Both breaches evidenced separately | No | Yes |
Built and maintained Configurable by you, not maintained by us Not built
Row two is the whole argument. It is also the row that would never appear in testing, because it needs a ticket that breaches both deadlines hours apart.
And the marker only gets set if somebody was told
There is a second rule here that came out of an earlier defect and is worth stating, because it is the part most systems get wrong.
Both alarm methods return the number of people they actually notified, and the marker is written only when that number is not zero. A ticket assigned to nobody, in no department, cannot notify anybody — and rather than being marked handled, it stays unmarked and is retried. The alert fires the day somebody is assigned or joins the department.
The previous behaviour stamped the marker unconditionally, so a breach nobody heard about was recorded as handled and could never be raised again. A column called notified at that is set when nobody was notified is worse than no column, because it is evidence of an alert that did not happen — and evidence is exactly what a penalty clause turns on.
What AWRA OpsHub does today
- Two independent deadlines per ticket category — first response and resolution — each stored on the ticket and each with its own breach check.
- A separate notified marker per deadline, so neither can silence the other.
- Alarm methods that return how many people were reached, with the marker written only when that is non-zero, so an unreachable breach is retried rather than buried.
- A recipient chain of assignee, then their manager through the employee record, then the department as a fallback.
- A per-category clock — elapsed wall-clock or the organisation's working hours.
- An internal note that deliberately does not satisfy the first-response promise.
What it does not do
- Any alert before a deadline. Everything fires on or after breach.
- A pause on the resolution clock for anything other than waiting on the requester.
- Any SLA evidence pack or customer-facing performance statement generated from the data.
- Per-customer or per-contract SLA targets — targets are set on the ticket category.
- Any penalty or credit calculation.
Not ours, by choice
- Targets live on the category, not on the customer. Where different customers have contractually different targets, that has to be modelled as different categories, and it is worth saying so before a contract is signed on the assumption of per-customer terms.
- Ageing buckets stay on calendar days by design even where the SLA clock is on working hours. The two are answering different questions and making them agree would break the ageing.
- Nothing here is South African. Johannesburg is here because contractual support terms with penalties are ordinary practice there, which makes the evidence rather than the operation the thing being bought.
Two, for desks where the SLA is contractual rather than aspirational
The clocks and the evidence exist. These are the two things a penalty clause turns out to need that a normal desk does not.
Targets per customer or contract
Today the target lives on the ticket category, so different terms for different customers means duplicating categories. A target resolved from the customer's agreement, falling back to the category, is the shape — and it is what stops a category list turning into a contract list.
An evidence pack per period
Tickets, targets, actual times, breaches, and the pause history that explains them — produced as a document for a specific customer and period. This is the artefact a penalty conversation is actually held over, and assembling it by hand from a report is where the disputes come from.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. If you are signing a support agreement with penalties, raise the first item before the contract rather than after.
Talk to us about contractual SLAsFour questions about SLA evidence
How many deadlines does a ticket have?
A good answer sounds like
Two, and they alert separately.
What it actually means
One is a simplification that will show up as an unexplained silence on your worst tickets.
Can one alert suppress the other?
A good answer sounds like
No — separate markers.
What it actually means
The question this page exists for. It is invisible until a ticket breaches both, hours apart.
What is recorded when an alert reaches nobody?
A good answer sounds like
Nothing — it is retried.
What it actually means
A marker set on a failed send is a false record, and in a penalty dispute it is a false record you produced.
Are targets per customer or per category?
A good answer sounds like
Per customer, ideally.
What it actually means
Ours is per category. That is workable and it means one contract change can mean a new category.
Our position
If your support agreement has money attached to it, model each contractual tier as its own ticket category, put those categories on the working-hours clock, and check the pause history before you accept any breach figure — yours or a supplier's. The two-marker design means the numbers you produce will be complete; what they will not be, yet, is a document you can hand to a customer.
Ask what happens when both deadlines pass
It is a specific question with a specific answer, and it finds a design decision most vendors have made implicitly rather than deliberately.
Talk about support agreementsFrequently asked questions
Does an internal note count as a first response?
No, deliberately. The first-response timestamp is set only when the comment is not internal, so an agent discussing a ticket with a colleague cannot accidentally satisfy a promise made to the requester. This is the single most common way a helpdesk SLA is gamed and the product does not have the hole.
What pauses the resolution clock?
Waiting on the requester. On resume the ticket gets back exactly the budget it had at the pause, measured on its own clock, rather than having a span of wall-clock time refunded — which is what an earlier version did, and it produced deadlines at eleven at night on a working-hours category.
Can I report on first-response performance?
Yes, and you could before anything alerted on it — which was the problem. The report and the alarm now read the same deadline, so the number you report and the number you were warned about cannot diverge.
