Nobody Knows Who to Call, So They Call Everyone

Pull up an incident from last quarter that took a long time to resolve and look at what happened in the first twenty minutes. There is a decent chance you will find three tickets. One from the unit, one from a manager who was told about it, and one from a second unit hitting the same thing. Two of them got assigned to different queues. One got closed as a duplicate of a ticket that was itself a duplicate.

None of that delay was technical. All of it was people not knowing who to call, and doing the sensible thing under uncertainty, which is to call everybody.

Broadcast is a rational response

I want to start by defending the behaviour, because service desk managers tend to describe it as a discipline problem and it is not.

If you do not know which of four groups owns a problem, and the cost of guessing wrong is a two-hour delay while your ticket sits in the wrong queue, then contacting all four is the correct strategy. It is faster in expectation, it is lower variance, and the cost is borne by somebody else. A person doing this is not being inconsiderate. They are being rational about an information problem your organization created.

Telling them to stop does not change the calculation. It just adds guilt to a decision they will make anyway, and it teaches them not to mention that they also called the other group, which makes the duplication harder to see rather than less common.

The only thing that changes the behaviour is making the correct route cheaper to find than the broadcast. That is a documentation problem wearing an operations costume.

Routing knowledge decays faster than anything else you have

Here is what makes this harder than it looks. Most content in a hospital decays slowly. A clinical protocol can be right for years. A tip sheet survives until the next upgrade.

Routing knowledge — who owns what, who is on call for it, which queue it goes to, who to escalate to after hours — is coupled to the org chart, and the org chart moves constantly. A team gets absorbed. A managed service takes over a function. Somebody's remit quietly expands. A vendor contract changes and a category that used to be handled internally now goes to a portal.

None of those events triggers a documentation update, because none of them feels like a documentation event. They feel like personnel and contracting events. And so the escalation matrix, which was accurate on the day it was published, degrades continuously from that day forward, and nobody notices until somebody follows it into a dead end.

I have seen escalation documents that were structurally correct and functionally useless: the categories were right, the process was right, and roughly a third of the named individuals no longer worked there. Users had learned this and stopped consulting it. Which means the organization had an escalation document with a readership of zero, being maintained by nobody, and a live escalation practice that existed entirely in the heads of people who had been there a while.

The matrix is the wrong artifact

The standard response is a better matrix — a table with categories down one side and teams across the top, published somewhere central.

I have come to think the table is the wrong shape for the problem, for the same reason that a folder tree is the wrong shape for finding documents. The table is organized by how the organization is structured. The person with the problem does not have a category. They have a symptom, in their own words, and the translation from symptom to category is the entire difficulty. Handing them a table indexed by category asks them to do the hard part before they can use it.

What they need is to describe the problem the way they would describe it to a colleague and be told where it goes. That is a retrieval question, not a table lookup, and it is the same vocabulary-mismatch problem that makes intranet search fail — the nurse says the badge reader is dead, the matrix says Physical Access Control Systems.

There is a second thing the table cannot do, which is tell you it is out of date. A retrieval layer over routing content can at least surface when the answer it is giving was last verified, and can flag the routes nobody has confirmed in a year. Solution Compass treats a verification date as a first-class property for exactly this reason, and routing content is where it pays off fastest, because it is the content class where staleness is both most likely and least visible.

Make the decay visible

If you do nothing else with this, do the following, because it takes an afternoon and it is unusually revealing.

Take your escalation documentation, whatever form it is in, and extract every named person and every named team. Check each one against your current directory. Count how many resolve to a person who still holds that responsibility.

Everybody expects a few. The number is always worse than expected, and the value of the exercise is less the number than the reaction in the room when it is read out.

Then do the second half, which is the harder one. Take the last fifty tickets that were reassigned at least once and look at where they landed versus where they started. That is your real routing map, and it will not match your documented one. The gaps between them are not random — they cluster around the categories that changed ownership most recently, which tells you exactly which parts of the document to fix first.

Two things that hold up

The routes that stay accurate in the organizations I have seen do it are the ones with two properties.

They name a function, not a person, with the person resolved at read time. "The interface on-call analyst" survives turnover; a named individual does not. This requires the underlying roster to be maintained somewhere, but a roster is maintained anyway for scheduling, which means you are pointing at a system of record rather than maintaining a second copy that drifts.

And they have an owner whose job includes noticing when they change. Not a committee. One person per domain who is on the distribution for reorganizations and contract changes, and who understands that updating the route is part of the change rather than an administrative afterthought. This is a small amount of somebody's time and it is the single highest-return content ownership assignment I know of, because routing content is consulted under pressure, by people who have no alternative, at the moment when being wrong costs the most.

Go and look at those three tickets from last quarter. Somewhere in the notes there is a line where an analyst wrote "not us, reassigning." Find out how many minutes that cost, and then find out whether the document that would have prevented it still names someone who works there.