Tiered Support

Handling requests in the order they arrive looks fair. The problem is that requests come in wildly different sizes. Someone who can't find the password reset takes three minutes; a report that documents fail to save under one specific condition means digging through logs and takes half a day. Put both in one queue and one request at the front holds up the twenty behind it.

So two conscientious people can produce a strange customer experience. A question that would take three minutes leaves a customer waiting four hours while the agent is deep in a report that's hard to reproduce. Neither request is being deprioritized; they are simply blocking each other in arrival order.

There was a second problem alongside it. If every agent has to handle every request, it takes months before a new hire can answer anything alone, because the structure requires learning to read server logs in order to be qualified to answer a password question. Tiered support solves both with the same move: it splits the queue by difficulty and splits the range of knowledge each queue demands along with it.

Deciding the dividing rule takes longer than the dividing. It runs in five steps.

1. Write the rule that separates the two as a list. Anything resolved with a help article or a prepared reply is first line; anything needing a look at an individual account's records or a hunt for a cause is second. Left to instinct, people judge it differently, so list twenty or so request types and mark which side each belongs to.
2. Everything arrives at the first line. Open a support ticket — one request tracked with a number, an owner, and a status — and decide whether prepared replies and help articles can finish it on the spot. In a well-run team, 70 to 80 percent close here.
3. Hand it up when the conditions are met. Decide in advance what has to travel with it: steps to reproduce, the account identifier, the time the problem occurred, and what the customer already tried. Without those, the second line has to ask the customer again.
4. The second line finds the cause. If it looks like a product defect it goes to engineering, and that route and the threshold for using it are set out separately as an escalation path.
5. Push work back down. Once a month, group what went to the second line by type; anything recurring gets a help article and a reply template so the first line can handle it. Skip this step and the structure gets top-heavy over time.

Target times get set per queue as well. The first line holds first response time under two hours while the second line holds resolution time within three business days. Apply one standard to both queues and one of them always misses while the other has too much slack.

Three conditions make the structure worth its overhead: more than thirty requests a day, a wide spread in difficulty across request types, and at least three agents. With all three present, splitting the queue alone cuts waiting time by more than half, without anyone being added to the team.

At around ten requests a day, the management overhead costs more than it returns. One person handling everything and spending extra time on the hard ones is faster. A product where most requests need investigation gains little from splitting either. If only 20 percent close on the first line, the problem is staffing one queue rather than running two. For customers on large contracts, a dedicated owner beats tiers, because an answer from someone who already knows the account is worth more than a shorter wait.

There are four limits. First, every handoff costs something. Customers repeat themselves or an answer slips a day, so reducing the number handed up is a standing goal. Second, an agent who only ever works the first line answers the same questions forever; something has to hand them harder types one at a time. Third, a dividing rule left alone sends everything upward. Products change, so the rule gets revised quarterly, and the share handed up is the number that says when it has gone stale. Fourth, splitting the queue is only a way of handling requests that arrive. Ticket deflection — stopping them from arriving at all — is the more fundamental side, and the two get run together.

"This should have closed on the first line and it came up to us. Let's revisit the rule."

Read it as a signal that the rule no longer matches the actual requests.

"When you hand something up, include the reproduction steps and the account identifier."

Missing information makes the customer explain twice.

"At our volume, tiering would actually be slower."

At a small scale the structure doesn't earn its keep.

Pagedeck's customer success team takes around sixty requests a day, with two people on the first line and one on the second. About three quarters close on the first line.

One of Sofia's monthly jobs is reading through the list and pulling out recurring types. Last month eleven requests came up to the second line about documents not being visible, all caused by the same permission misconfiguration. She wrote a help article laying out the sequence to check and added it to the first line's reply set. This month two requests of that type reached the second line.

The most common mistake is reading the tiers as ranks of people. First and second sound sequential, and the second line does the harder work, so it looks like the senior seat. But this divides requests by difficulty, not jobs by seniority. The first line handles most of the volume and shapes more of what customers think of the company than anything else does. Once it reads as a rank, first-line agents treat the role as a waypoint and the quality of that seat drops.

The other belief is that handing something up makes it faster. It goes to someone who knows more, so of course it does. But the handoff itself takes time. Packaging the information, and the second line reading it and rebuilding the context, costs half a day. Habitually passing up what could have closed below makes the customer's answer arrive later. The fastest handling is handling that finishes in the first queue, which makes the share handed up a number worth managing.