The Alarm That Needed A Login
Our helpdesk was built for organizations where plenty of staff have no company login. Then the one alert that matters was wired to a login — so the tickets nobody had picked up were the tickets nobody was told about.
A service-level agreement is not really a promise about time. It is a promise that somebody will find out. The deadline is only the trigger; the whole mechanism is the moment a human being is told that something has gone past it, and if that moment does not arrive then the agreement is a number in a database with a date beside it. We had the number, the date, and a defect that meant on some tickets nobody was ever told — and they were, with a kind of precision, the worst tickets to pick.
A design decision made years earlier
Our helpdesk lets a ticket be assigned two ways at once: to an employee, and to a login. That looks like duplication until you notice why it exists. In most of the organizations we work with, a large share of the people who actually do the work do not have a company login. A storekeeper, a technician, a driver, somebody on a site three hours from head office. They exist in the system as employees — they have a manager, a department, a record — and they have never signed in to anything.
So a ticket can be genuinely owned by a real person who cannot receive an in-app notification. That is not a gap in the design; it is the design. It is what lets a supervisor route a job to the person who will do it rather than to whoever happens to hold an account.
Two things a system can mean by "assigned"
One is accountability — whose job is this. The other is addressability — where do I send things. Most systems collapse them, and then quietly require everybody to be addressable in order to be accountable. Keeping them apart is right, and it creates an obligation: every mechanism that acts on an assignment now has to handle the case where accountability exists and addressability does not.
The obligation we did not meet
The breach alarm looked up who owned the ticket and sent them a warning, then escalated to that person's manager. Both steps resolved through a login. So the alarm worked perfectly for exactly the population the dual assignment exists to make optional.
Three breached tickets, one sweep
The third row is the one that turns this from an oversight into a real defect. A ticket that has breached its deadline is very often a ticket nobody picked up — that is a large part of why it breached. It had no owner, so the alarm had no owner to notify, so nothing was sent about the single ticket in the queue that most needed somebody to look at it. The failure was concentrated exactly where the harm was.
And note that nothing here was hidden. The ticket was visible in the queue the whole time. Anybody looking at the right screen would have seen it. That is the ordinary consolation offered when an alert fails, and it is worth being honest about what it is worth: an alert exists precisely for the times nobody is looking at the screen. If the answer to a missed notification is that the data was on a dashboard, the notification was never doing anything.
What it does now
The alarm resolves an audience rather than a person. It tries the assignee, then that assignee's manager — looked up from the employee record, so an agent with no login of their own still escalates to somebody who has one. If neither of those produces a recipient, it falls back to the department queue the ticket has been sitting in all along.
The fallback is a fallback and not an extra recipient, deliberately. Copying a whole department every time a named agent runs late is how an alert becomes noise, and how it then becomes a filter rule that somebody sets up in month two. The queue is told only when the assignment chain produced nobody — which is the unassigned ticket, which is the case that was silent.
The honest remainder
A breached ticket with no assignee, no manager and no department still has nobody to tell, because there genuinely is nobody. What changed is that the system now says so out loud — the sweep reports how many it could not deliver, instead of finishing quietly — and it keeps trying, so the alert fires the day somebody is assigned or the day a user joins that department.
The general shape, which is not about helpdesks
Any system that supports people without accounts will eventually build a notification for them, and the notification will be written by somebody who has an account and is thinking about people who have accounts. The test is not whether the feature works. It is whether the feature works for the population the feature was built to serve, which is a different question and is almost never the one that gets asked.
- Can a person be responsible for something in this system without being able to log into it? If not, ask what happens to your frontline staff. If so, ask the next question.
- Who is told when a deadline is missed on a ticket nobody has claimed? Not "can I see it on a dashboard" — who is told.
- What does the system do when it has nobody to notify? The three possible answers are: tell you, do nothing, or record that it notified somebody. The third one is the dangerous one, and it has its own post.
Ours are yes, the department queue, and it tells you — since August 2026. The three-row table above is from our own test suite. We are publishing the version of this story where we were wrong for a year, because the alternative is publishing a claim about alerting with nothing behind it, and this industry has enough of those.
