The Promise Nothing Was Watching
A support agreement usually makes two promises: we will get back to you, and we will fix it. We measured both, reported on both, and had an alarm on only one — the one that matters least to the person waiting.
The two halves of a support promise are not equally important to the person on the other end, and the ranking is not the one vendors assume. "We will resolve this within two working days" is the commitment that gets negotiated. "Somebody will get back to you within an hour" is the one that decides whether the customer spends the afternoon wondering if their message arrived. Silence is the actual complaint. Resolution time is what the complaint gets written up as afterwards.
That gap widens with distance. A customer who can walk into your office has an alternative to waiting; they can appear at the counter. A customer three time zones and an ocean away has exactly one signal that their problem is being dealt with, and it is the first reply. Everything else is inference.
What we had built
Both promises were real. A ticket category carries a first-response target and a resolution target; a ticket raised under it stores both deadlines; the system knows at any moment whether either has been missed, and answers correctly. There is a report that counts first-response breaches, and it has been counting them accurately the whole time.
The scheduled job that raises an alarm looked only at the resolution deadline. Not because of a condition that evaluated wrongly — because the first-response deadline was not in the query. It had never been.
One ticket, five hours of silence
Read the last two rows together, because their combination is the specific failure. The system was not ignorant. It knew, it was willing to tell anybody who asked, and it counted the misses up afterwards for a report — and it never once volunteered the information while somebody could still have acted on it. Of all the possible arrangements of those parts, that is close to the least useful. It produces an accurate monthly figure for a thing that could have been prevented daily.
Why nobody noticed for a year
Because nothing was broken. Every test passed, because every test was about the mechanism that existed. There is no failing case to find when the defect is that a second case was never written — absence does not throw. This is the argument for auditing a module against what it PROMISES rather than against what it does: a promise you never implemented has no failing behaviour to catch you out.
What it does now
The sweep raises both. A ticket that has passed its first-response target with no reply to the requester now alerts the same audience as a resolution breach — the assignee, their manager, or the department queue if neither is reachable. The two deadlines are tracked with separate markers, which matters more than it sounds: a ticket routinely misses the first and still meets the second, and the reverse happens too. One shared marker would mean whichever breach came first silenced the other, which is a quieter version of the same defect.
One thing deliberately left alone: an internal note between colleagues does not count as a first response. Only a reply the requester can actually see stops that clock. This is the single most common way a first-response metric gets gamed — a system where any comment satisfies the promise will report excellent response times and leave customers in silence — and it is worth saying that we got this one right the first time, since most of this post is about the ones we did not.
The general question, and it is a good one to ask a vendor
Most software has more measurements than alarms, and the ratio is rarely deliberate. A measurement gets added because somebody wanted a number on a screen; an alarm gets added because somebody was burned. So the measurements accumulate quietly and the alarms arrive one incident at a time, and there is a permanent gap between what a system knows and what it will tell you unprompted.
- Which of your promises produce an alert, and which only produce a report? Ask for the list. The distinction is usually visible to the vendor and invisible in the interface.
- Does a first-response breach alert anybody, or does it only appear in a summary? Worth asking in exactly those words, because both answers involve the word "yes" if you ask it loosely.
- What counts as a response? If an internal note satisfies the promise, the number will be excellent and will mean nothing.
Ours are: both promises alert, since August 2026 and not before; yes; and a reply the requester can see. The table above is a case from our own test suite rather than a hypothetical, and the reason the honest answer includes a date is that a claim about your alerting is only worth the day it started being true.
