Operating Model · Escalation Design
What breaks first when support scales, and in what order.
In a European scale-up I ended up responsible for 1,850 agents across four countries. What didn't scale wasn't the technology. It was the distance between the moment a problem appeared and the moment it reached someone who could decide on it.
At two hundred agents, I could walk the floor and hear what had broken the same week it broke. At eighteen hundred, across four markets, the same kind of problem took six weeks to reach me. In the meantime it had been reworded three times by three layers of management, each with a reason to soften it before passing it on.
That distance is not an operational detail. It is the exact order in which a support organization stops working as it grows, and most GMs only find out after the third piece has already broken.
The order it breaks in
It doesn't all break at once. It breaks in sequence, and the sequence is almost always the same.
- First, visibility. The leader loses the ability to observe the floor directly. Nobody decides this; it simply happens once headcount passes what one person can still perceive first-hand.
- Second, speed. Information keeps moving up, just slower at every layer it crosses. A problem that used to take a day to reach you now takes forty.
- Third, accuracy. Every layer that touches the problem reshapes it. Usually not to deceive, but to protect: edges get sanded off, the parts that would make the reporter look bad get quietly dropped. What arrives at the top is no longer the original problem. It's a version edited more than once.
- Fourth, ownership. Once nobody is quite sure who should have caught it first, nobody feels responsible for fixing it. The problem sits there, bounced between functions, until it's too big to ignore.
By then it costs ten times as much to fix, and the customer heard about it before you did.
Why it breaks in this order, not at random
Every handoff between management layers is a point where information gets rewritten, not just passed along. It's the same reason a game of telephone always distorts in the same direction: whoever reports a problem has an incentive, often unconscious, to make it look smaller than it is, because reporting it intact means admitting it happened on their watch.
The more layers a piece of information crosses, the more that distortion compounds. This isn't a story about dishonest people. It's organizational math: every handoff adds noise, and the noise always runs the same direction, downward in severity.
What I built to stop it
I stopped waiting for the problem to climb the hierarchy on its own. I redesigned the path.
Inside every department outside CX, one named SPOC, a single point of collection for anything touching the customer experience in that function. Those SPOCs worked with the regional programme manager, who reported directly to me.
The result: two handoffs from the department where a problem originated to my desk. The same person owned each handoff, instead of a relay of different layers each with a reason to reword it.
Uncomfortable for whoever sat in the middle. Their version was no longer the only version that reached me.
It meant finding out about problems while they still cost little, not once they had already become a crisis with the customer copied in.
The number that matters in your organization, today
I'm not asking how many agents you have or how many markets you cover. I'm asking something simpler and more uncomfortable: how many handoffs are there, today, between whoever sees a problem first and whoever has the authority to decide on it?
If you can't answer with an exact number, that's the first thing to map. Before technology, before AI, before any dashboard. No tool fixes an organizational distance. Only someone who redesigns the path does.