Nobody decides that engineers should do support. It happens one message at a time. A ticket looks odd, L1 isn’t sure, and someone pings the developer who built the feature. The developer answers, because it takes ten minutes and the customer is waiting. Then it happens again on Thursday.<\/p>\n\n\n\n
Within a few months the escalation path is a person, not a process. That person’s roadmap work slips, and nobody can say exactly when it started.<\/p>\n\n\n\n
This is a guide to fixing it: a support escalation model that keeps engineers for the problems only engineers can solve.<\/p>\n\n\n\n
The cost of an escalation is not ten minutes. It is the context switch on both sides, plus the steady pressure it puts on the team. Google’s SRE book<\/a> aims to keep operational work below half of each SRE’s time, and warns against letting a team slide into becoming an ops team. Product engineers who answer tickets have no such guardrail. Nobody measures how much of their week goes on support, so nobody notices when it grows.<\/p>\n\n\n\n It also hides the real problem. When the developer who built a feature is the fastest route to an answer, the knowledge never leaves their head. The docs stay thin, L1 never learns, and the next customer with the same issue lands in the same chat thread.<\/p>\n\n\n\n A tiered support model works when every tier has a clear job and a clear limit. Vague tiers, such as “basic” and “advanced”, only move the argument about who owns what.<\/p>\n\n\n\n L1<\/strong> handles anything with a known answer: how-to questions, account and billing issues, documented errors. Its limit is the knowledge base. If the answer isn’t there, L1 escalates, and a clean escalation is a good result.<\/p>\n\n\n\n L2<\/strong> reproduces and diagnoses. These people can read logs, use the admin tools, test on a staging environment and recognise a known bug from its symptoms. They can’t change the code. Most of the real work in a support escalation process happens here, and it is where many companies under-invest.<\/p>\n\n\n\n L3<\/strong> is engineering. It receives only what L2 has confirmed as a defect, an infrastructure fault, or a data problem that needs a code or config change.<\/p>\n\n\n\n The test is simple. L1 changes nothing in the product. L2 changes configuration and customer data within agreed limits. L3 changes code.<\/p>\n\n\n\n Engineers resent escalations for one main reason: they arrive without the information needed to act. “Customer says export is broken” costs half an hour of back-and-forth before anyone opens a log.<\/p>\n\n\n\n Set a minimum standard. An escalation to engineering should carry:<\/p>\n\n\n\n In practice a good one reads like this: “Export fails for one Pro-plan account since 09:40 UTC. Reproduced on staging with files over 50 MB. Request ID attached. One customer affected; exporting in batches works as a workaround.” An engineer can start on that in the first minute.<\/p>\n\n\n\n Escalations missing any of these go straight back to L2. It sounds strict. After a few weeks it saves everyone time, and L2 learns what a good handover looks like.<\/p>\n\n\n\n Add severity levels next. Four is enough, each with a response time that engineering has actually agreed to. If anyone can mark a ticket “critical”, everything becomes critical.<\/p>\n\n\n\n Even with good criteria, escalations need a single entry point. A shared channel where anyone can tag anyone brings the old problem straight back.<\/p>\n\n\n\n The usual fix is a rotating support-duty engineer: one person per week or sprint who takes escalations from L2, with their feature work scoped down to match. Everyone else stays out of the queue. Larger organisations often create a standing escalation engineer<\/a> role for this once ticket volume justifies it. The same logic applies one step earlier. A customer support engineer<\/a> at L2 who can read code and logs will resolve many issues before they reach L3.<\/p>\n\n\n\n The model only holds if L1 and L2 are properly staffed: trained on your product, equipped with the right tools, and available outside engineering hours. Many teams build this in-house at first, then find it hard to maintain as the product and the user base grow.<\/p>\n\n\n\nDefine tiers by what each one is allowed to change<\/h2>\n\n\n\n
Write the escalation criteria down<\/h2>\n\n\n\n
\n
Give engineering one door<\/h2>\n\n\n\n
Decide who staffs L1 and L2<\/h2>\n\n\n\n