TL;DR:
Define three or four severity levels by customer impact, so the question becomes "which level?" rather than "does this feel bad?".
Escalate when a trigger is met, and include the same facts every time so engineering can start at once.
Tell the customer what happens next and keep the ticket as the single place for updates.
A customer writes in that something is wrong, and you cannot fix it from the support side. Do you message engineering now, tonight, or next week? On a small team there is often no rule, so the decision depends on who is nervous. Escalation rules turn that into a short check you run in a minute.
When you need written rules
Write them when support and engineering are different people and engineers are interrupted by messages that vary wildly in clarity. The goal is fewer interruptions for engineers, faster help for customers and no one guessing.
What to set up
A list of severity levels with plain definitions, based on customer impact.
A named person or channel for each level, and how quickly you expect a response.
A template for the handoff message so every escalation has the same facts.
An agreement on how the customer is updated, usually by support, from one ticket.
Step by step
Define severity by impact: Ask who is affected and what they cannot do. Words like "serious" are not definitions.
Add a trigger for each level: A trigger is something you can check: several customers report it, or money is wrong, or nobody can sign in.
Try the obvious fixes first: Rule out user error, a known issue or a quick workaround from your help articles before escalating.
Reproduce it if you can: A problem you can make happen is far easier to fix than one you cannot.
Send the handoff with the standard facts: Use the template, link the ticket, and name the severity.
Tell the customer and set the next update: Say it has been passed to the people who can fix it and when they will hear next.
Close the loop: When engineering answers, update the ticket and the customer, then note whether a help article or tag should change.
Worked example: when a ticket goes to engineering
The levels and the product are invented. A small team agrees on these:
Level | Meaning | Example trigger | Who and how fast |
|---|---|---|---|
S1 | Many customers cannot do the core task, or data or money is wrong | Checkout fails for several customers, or a customer is charged twice | Engineer on call, message at once |
S2 | One customer blocked, or a core feature partly broken | One customer cannot sign in after a reset | Engineering channel, same day |
S3 | Annoying but there is a workaround | Wrong label on a button | Bug list, reviewed weekly |
A customer writes: "I can't complete my order. The page just spins." You check the help article on payment errors, which does not apply. You try the same steps on a test account and the page spins for you too. You search the last hour of tickets and find two more customers with the same symptom.
Now apply the table. The core task (ordering) fails for you, and for at least three people in total. That meets the S1 trigger. You message the on-call engineer immediately using the template:
Severity: S1
What is wrong: order page spins and never completes
How many: 3 customers in the last hour, plus reproduced on a test account
Steps to reproduce: add any item, go to checkout, select Pay
Expected: confirmation page. Actual: spinner, no confirmation
Environment: web, tested in two browsers
Ticket links: #101, #104, #107 (made-up numbers)
What support has done: ruled out card errors, told customers we are on it
Next update to customers: in 30 minutesThe engineer can start working without asking a single question. If the page had only spun for one customer, and not for you, the same check would give S2: same-day message in the engineering channel, with the facts in the same template.
What to include every time
Severity and impact: how bad, how many people.
Steps to reproduce: what to click, in order.
Expected and actual results.
Environment: browser or device, version if known, account type.
Evidence: ticket links, screenshots, error text, times.
What you have already tried, so no one repeats it.
Review the rules after the first month. Look at the escalations that engineering sent back with questions and add whatever was missing to the template. Look at the S1 tickets and ask whether each really met the trigger. The rules improve by being corrected against real cases.
On a very small team the same person may be both support and engineering. The rules still help: they make you stop and write down severity, steps and expected result before you start, which is exactly the information you will want when you return to the problem tomorrow.
Mistakes to avoid
Escalating on feeling. Use the trigger. If it is not met, record the ticket and revisit.
Forwarding the customer's email alone. Engineers need steps and results, not the customer's frustration.
Everything is S1. If every message is critical, none is. Keep S1 rare and defined.
Going silent. The customer still needs an update when there is no news.
Not closing the loop. The fix teaches you which help article or tag to add.
Doing it faster
Save the handoff template as a snippet so it takes seconds to fill in. If you want a second pair of eyes while you describe the steps, DuckyHelper can see your screen and talk it through out loud, but always check the facts yourself before an escalation goes out.
Frequently asked questions
How many severity levels should a small team have?
Three or four. More levels create arguments about which one applies and add little.
Can support change the severity later?
Yes. State the reason in the ticket, such as "more customers affected than first thought", so everyone can follow the change.
Get started
