The Promise Nothing Was Watching
A support agreement usually makes two promises: we will get back to you, and we will fix it. Plenty of helpdesks measure both, report on both, and 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 a half-wired helpdesk looks like
Both promises can be entirely 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. A report counts first-response breaches, accurately.
And the scheduled job that raises an alarm looks only at the resolution deadline. Not because of a condition that evaluates wrongly — because the first-response deadline is not in the query, and never was.
One ticket, five hours of silence
Read the last two rows together, because their combination is the specific failure. The system is not ignorant. It knows, it is willing to tell anybody who asks, and it counts the misses up afterwards for a report — and it never once volunteers the information while somebody could still act 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 notices
Because nothing is broken. Every test passes, because every test is about the mechanism that exists. 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 AWRA’s sweep does
The sweep raises both. A ticket that has passed its first-response target with no reply to the requester 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 failure.
One rule is deliberate: 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 the rule worth checking first in any helpdesk you evaluate.
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; yes; and a reply the requester can see. The ticket in the table above is a case our test suite runs against the sweep, and it raises an alert — because a claim about alerting is only worth the test behind it.
