Technical support

Where the written criterion says. The common failure is leaving the boundary implicit, and the result is a ticket that shuttles back and forth while the customer waits. We define the escalation criterion during transition, with concrete examples on both sides of the line.

Escalation goes to your engineering, not to a second line of ours that does not know the product. Where it makes sense for us to have that second line, we say so, and it is a separate decision with a separate cost.

By written criterion rather than individual judgement, because what one person considers hard another resolves in two minutes. The criterion should be observable: case type, time already spent, and whether a documented procedure exists. Without it, first line escalates too much or too little, and both are expensive.

With easy, unpenalised escalation. A team assessed on first-contact resolution and penalised for escalating holds on to cases it should pass, and the user waits longer than they would have if the case had gone up immediately. The indicator should reward resolution rather than retention.

And with feedback flowing back. Every case resolved in second line that could have been resolved in first generates a knowledge base entry and, if the pattern repeats, training. Without that feedback, second line handles the same cases indefinitely and first line never improves.

All the difference, which is why attrition is more expensive in technical support than in general service. Someone who has known the product for a year resolves cases a new person escalates, and the difference between them is not technical competence but accumulated context.

The design consequence is that retention should be budgeted as investment. Continuing training, written progression and conditions that reduce departures cost less than the cycle of recruiting, training and replacing, and the calculation uses numbers any operation already has.

The other consequence is that documentation stops being optional. Knowledge living only in two people's heads is a risk that grows silently, and an operation that writes as it resolves converts that risk into an asset with no visible additional effort.

Enough to diagnose and nothing beyond, which in practice means read access over logs and configuration and write access only where the procedure requires it. Granting broader access because it is simpler to configure is the error that appears in every audit and that nobody ever actually decided.

Where diagnosis requires production data access, the access is named, logged and time-limited, and the exception is anticipated in the design rather than opened at two in the morning by someone who needs to resolve an incident. An architecture that does not anticipate the emergency exists only on paper.