Behind is recoverable. Off the system isn't.

A couple of weeks ago our service desk fell four days behind on escalations. Nothing dramatic caused it. Power cuts on the team's side knocked out a day or two of work, and the queue quietly built while nobody was looking at it. By the time we caught it, priority-one escalations were still sitting unactioned.

The person running the desk did what most capable people do under pressure. She stepped away from the system and started working straight off the raw alerts. That was our old way of working, and it is worth pausing on what it actually looks like. Raw alerts are the unfiltered feed from the field: every issue landing in one inbox, in no order, with no age on it, no severity, and no record of what has already been handled. Before we built the system, someone sat in that feed all day and worked whatever looked loudest. I understand the instinct to go back completely. It is familiar, it feels like rolling up your sleeves, and when you are drowning, the tool that is supposed to help you feels like overhead. Grabbing the nearest fire feels like progress.

But here is the problem, and it took a phone call to talk it through properly. A field operation like this produces escalations continuously. The system is a moving train. Going back to the old way of working is not a pause or a shortcut; it is jumping off. Jump off to fight fires by hand and the train does not stop. New escalations keep arriving, and now they are not being logged, aged or triaged either. You are not catching up. You are converting a four-day backlog into a permanent state, because the queue grows faster than you can hand-fight it.

Stay on the train, though, and being behind is just being behind. The alerts clear as the escalation tickets get worked through the inbox, in order, oldest and most serious first. It is uncomfortable for a few days and then it is over.

Behind is recoverable. Off is not.

So we turned it into a protocol on a five-minute call. When something delays the desk, a power cut, an absence, whatever, we do not silently drop back to manual. We get on a short call and set a plan. And the plan is allowed to be brutal: skip that day's follow-ups entirely if we need to. Follow-ups are the known. They are logged, they have dates, they will keep for a day. The escalations sitting unread in the inbox are the unknown, and the unknown is where the account-losing problem is hiding. Triage the unknown before the known, every time.

Two things I would offer any owner running a field or route operation off the back of this.

First, the failure was not the power cut. Delays are weather; they happen. The failure mode was the silent switch back to manual, because that decision gets made alone, under stress, by whoever is drowning, and it is the one move you cannot recover from. Make "we are behind" a trigger for a five-minute conversation instead of a quiet workaround.

Second, notice what your systems are for on the bad days, not the good ones. Any process works when you are on top of it. The test is whether it gives you a way back when you are not. Ours did, but only once we agreed to stay on it.

The protocol worked verbally. The next step is writing it into the standards document, because verbal agreements survive until the next bad week. Written ones survive the one after that.