The Alarm That Needed A Login
Our helpdesk is built for organizations where plenty of staff have no company login, so the one alert that matters cannot depend on one. Wire it to a login and the tickets nobody has picked up are the tickets nobody is 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. Any helpdesk can store the number and the date. The harder part is making sure somebody is told on every ticket — including, with a kind of precision, the worst tickets to miss.
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 that design creates
The obvious breach alarm looks up who owns the ticket and sends them a warning, then escalates to that person's manager. Built the obvious way, both steps resolve through a login — so the alarm works perfectly for exactly the population the dual assignment exists to make optional.
Three breached tickets, one login-bound alarm
The third row is the one that turns this from an oversight into a real failure. 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 has no owner, so a login-bound alarm has no owner to notify, so nothing is sent about the single ticket in the queue that most needs somebody to look at it. The failure is concentrated exactly where the harm is.
And note that nothing here is hidden. The ticket is visible in the queue the whole time. Anybody looking at the right screen would see 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 AWRA’s alarm does
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 a login-bound alarm leaves 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. The system 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 — The Send That Delivered Nothing, on a push notification to an audience with no registered devices that was written to the log as a success.
Ours are yes, the department queue, and it tells you. The three tickets in the table above are cases our test suite runs against the alarm, and all three reach somebody. A claim about alerting is only worth the test behind it, and this industry has enough claims with nothing behind them.
