A user writes in with a problem. The agent handling it can't resolve it and passes it to tier two. There they ask for information that was already in the first conversation, and the user repeats it. Two days later the case comes back to tier one because, looked at calmly, it was simple. Nobody missed a response time, no indicator turned red, and the operation still spent three times the effort it needed to while the user explained the problem twice.
Escalation design is one of the least discussed decisions when standing up an outsourced operation, and one of the most decisive for its real cost. It usually gets settled with a line in the contract — "complex cases move to second tier" — and that line means nothing operationally. Complex for whom, by what criterion, carrying what information, and with what route back.
A tier is not a rank
The most common mistake is treating tiers as ranks: tier two knows more, earns more and decides over tier one. Organised that way, escalating becomes an act of surrender, so the team avoids it until the case has already gone bad, or uses it as an escape hatch to avoid thinking.
A tier is something else: a set of cases that get resolved with the same tools, the same access rights and roughly the same handling time. Tier one takes what can be closed in one interaction with the knowledge and permissions it already has. Tier two takes what requires a permission tier one doesn't hold, a tool it can't reach, or an investigation that doesn't fit inside a conversation.
Defined that way, the criterion stops being subjective. The question isn't "is this hard?" but "do I have the access, the data and the time to resolve it?". If the answer is yes, it doesn't escalate, however uncomfortable. If it's no, it escalates immediately, however simple it looks.
If the escalation criterion is perceived difficulty, every agent will have their own, and the operation won't be measurable.
Every hop has a price
An escalation isn't free. It costs the agent's time to document, the specialist's time to get up to speed, the user's time waiting and, almost always, one extra follow-up interaction. A case that passes through two pairs of hands consumes considerably more than twice the effort of one closed on first contact.
There's a practical consequence. Raising the share of cases resolved at first contact is usually worth more than speeding up tier two. And that share rarely rises by hiring more experienced people. It rises by granting permissions. Most avoidable escalations happen because the agent knew exactly what to do and didn't have the button to do it.
Reviewing tier one's access list is generally the highest-return exercise at the start of an operation. Restrictions surface that were set years ago out of caution, with no threshold and no condition attached, and that today only generate internal traffic.
Functional and hierarchical aren't the same
Two things often get mixed under one word, and they're worth separating.
Functional escalation moves the case toward whoever has the technical ability to solve it: tier one to tier two, tier two to a specialist, specialist to the client's own team. It's horizontal in authority and vertical in knowledge.
Hierarchical escalation moves the case toward whoever has the authority to decide outside the rule: approve an exception, authorise a credit, accept a risk. It doesn't require more technical knowledge, it requires a mandate.
Blending them produces two familiar symptoms. One, supervisors handling technical cases they can't solve, because the team escalates "upward" by habit. Two, technical cases stuck for days waiting on a decision nobody is empowered to make. Both routes should exist, be written separately, and have different triggers.
What travels with the case
The quality of an escalation is decided by what gets sent, not by how fast it gets sent. A minimum package prevents most of the rework:
- What the user asked for, in their words, not interpreted.
- What was attempted and what each attempt returned.
- The identity checks already done, so nobody repeats them.
- The reason for escalating under the agreed criterion: missing access, missing tool, investigation needed or authorisation needed.
- What was promised to the user, and by when.
That last point is the one most often skipped and the one that does the most damage. Tier two works without knowing what expectation is still open, and the user gets an answer that doesn't match what they were told. This is natural material for the knowledge base: the escalation package format should be defined before day one, not negotiated case by case.
The route back
Almost every design describes how a case goes up. Very few describe what happens afterwards.
When tier two resolves something, the solution stays in tier two. The same query arrives the following week, escalates again and gets solved from scratch again. Escalation without a knowledge loop turns the second tier into a repetition factory.
The loop is built with two simple rules. First: whoever resolves an escalated case writes down the procedure if the case can recur, even in three lines. Second: someone reviews the most frequent escalation reasons on a regular cadence and decides which ones move down to tier one, with whatever permission or article is missing. Without that second step, the split between tiers freezes on launch day and never improves.
There's also the case sent back because it shouldn't have escalated. Sending it back is fine, as long as the return explains what was missing and isn't logged as an individual failure. If returning becomes a reprimand, the team stops escalating when it should.
What to measure
Four indicators describe a tier model well, and none of them works alone:
- Escalation rate, broken down by reason. The aggregate says nothing; the breakdown is what lets you act.
- Return rate: escalated cases that tier two sends back. If it's high, the criterion isn't clear or training is missing.
- Re-escalation: cases that go up more than once. Usually a sign the tier boundaries are drawn wrong.
- Queue time in tier two, measured separately from total handling time. That's where the delay invisible to the user accumulates.
All four belong in the report from the start, alongside the rest of what gets agreed in the first month of an operation. Adding them later forces you to discuss trends with no history behind them.
How smartBPO works it
We define tiers by access, tooling and time, not by seniority, and we write the criterion as a single sentence a new agent can apply without asking. We keep the functional route separate from the hierarchical one, each with its own triggers. We standardise the package that travels with a case before launch, and we review escalation reasons with the client in the recurring meeting, so anything that only needed a permission moves down to tier one. We track returns and re-escalations, not just the aggregate rate. The goal isn't a fast second tier: it's that most cases never need to reach it.