Support Escalation Policy: Levels, Triggers and a Template
How to write a support escalation policy: levels, triggers, who owns what, a handoff note format, time limits and a review routine, with a template to copy.
In this article
A customer writes that money left their account but the order never appeared. The agent who picked it up doesn't have access to payment logs, so she messages a colleague in the team chat, then waits. Two hours later the customer writes again, and a second agent starts from zero. Nobody did anything wrong. There was simply no written rule for what happens when a problem is bigger than the person holding it.
A support escalation policy is that rule. This article walks through its parts and ends with a template you can copy and adapt.
What a support escalation policy is
It is a short document that answers four things: when a case moves up, to whom, how it is passed on, and how long each person has before it moves again. It is not the same as an SLA. An SLA is the promise you make to the customer. The escalation policy is your internal route for keeping that promise when the first person can't.
Note the two directions people mean by "escalation". A functional escalation hands the case to someone with different skills or access (billing, engineering). A hierarchical escalation brings in someone with more authority (a team lead, a manager). Your policy should name both.
Levels: keep them few
Three levels are enough for most teams. More than that and cases bounce around.
| Level | Who | Typical cases |
|---|---|---|
| 1 | Frontline agents | Questions, how-to, simple account problems, anything with a canned answer |
| 2 | Specialists or a team lead | Billing disputes, bugs that need reproducing, upset customers, exceptions to policy |
| 3 | Engineering, finance or a manager | Confirmed defects, money movement, outages, legal or security complaints |
Small team? Level 2 can be one named person per week. It doesn't need to be a separate department.
Triggers: when a case moves up
Write triggers as conditions someone can check, not as feelings. Four kinds cover most situations:
- Skill or access: the agent can't solve it with what they have, such as a payment lookup or a code change.
- Time: the case is approaching its deadline or has passed it.
- Impact: several customers report the same thing, or one customer is blocked from paying or logging in.
- Customer signal: the customer asks for a manager, mentions a complaint to a regulator, or has written three times without progress.
In Hodhod, the time trigger can be automated. Auto-escalation on tickets reacts to "overdue", "idle for a while" or "waiting on the customer", and can raise priority, reassign to a team, add a follower, label the ticket or add a note. It previews which tickets a rule would have caught before you switch it on.
Who owns what
The most common failure is the case that is "escalated" but owned by nobody. Settle two rules:
- One owner at a time. When a case moves to level 2, the level 2 person owns the customer relationship until it is solved or handed on again.
- The first agent stays informed, not responsible. They follow the ticket and can see the outcome, but they stop chasing it.
Who speaks to the customer? Decide this too. A common choice is that level 1 sends one short message saying the case has moved to a specialist and when to expect news, and after that the new owner writes. In Hodhod you assign the ticket to a team or person, add the original agent as a follower, and keep internal discussion in private notes so the customer doesn't see it.
The handoff note
Most of the lost time is in the handoff. If the next person has to re-ask the customer, the escalation made things slower. Require this note on every handoff:
Handoff note
Customer / ticket number:
Problem in one sentence:
What the customer expects:
What I already checked or tried:
What I'm asking you to do:
Priority and why:
Deadline (customer-facing and internal):
What the customer has been told:
The line "what the customer has been told" matters most. It stops the next person from contradicting a promise they didn't know existed.
Time limits
Give each level a limit for acting on the case, not for solving it. Here is an example for an urgent case, counted in working hours:
| Step | Limit |
|---|---|
| Level 1 replies to the customer | 15 minutes |
| Level 1 hands off if it can't be solved | 30 minutes after the case arrived |
| Level 2 takes ownership and replies | 1 hour after the handoff |
| Level 2 hands off to level 3 or resolves | 2 hours after taking it |
| Level 3 gives a status update | same working day |
Add them up and an urgent case reaches level 3 within 3.5 hours at the latest, with the customer hearing from a person at least at minutes 15 and 90. These numbers are only a starting point. Take them from what your team can do today, as with an SLA, and tighten them later. For lower priorities, scale the limits up. How you set priorities in the first place is covered in ticket triage and priority.
Engineering escalations
When the cause is a defect, don't forward ten separate tickets to developers. Link the tickets to one issue so engineering sees a single problem with a count of affected customers. In Hodhod this is the issue tracking feature, and an issue can be sent to Jira. When engineering fixes it, you can message the linked conversations in one go.
Copyable template
ESCALATION POLICY (team name, version, date)
Levels
L1: [names/team] - handles: [list]
L2: [names/team] - handles: [list]
L3: [names/team] - handles: [list]
Escalate when (any one is enough)
- Needs access or skill the current level doesn't have
- Ticket is within [X] of its deadline or past it
- [N] or more customers report the same problem
- Customer is blocked from paying or logging in
- Customer asks for a manager or mentions a formal complaint
Ownership
- One owner at a time; the owner talks to the customer
- Previous owner follows the ticket but stops chasing it
- Internal discussion goes in private notes only
Handoff note (required)
Problem / expectation / checked so far / request / priority /
deadline / what the customer was told
Time limits (working hours)
L1 reply: [ ] L1 handoff: [ ]
L2 take-over: [ ] L2 handoff or resolve: [ ]
L3 status update: [ ]
Out of hours
Who is on call for urgent cases and how they are reached: [ ]
Review
Monthly: read every escalated case that missed a limit.
Quarterly: change levels, triggers or limits if the same cause repeats.
Reviewing the policy
A policy nobody reviews becomes decoration. Once a month, take the escalated cases that missed a time limit and ask what they have in common: one shift, one topic, a missing access right, a handoff note with empty fields. Also look at the opposite problem. If level 1 escalates more than half of what it receives, the issue is probably training or missing canned replies, not the policy. Check the volume of escalations against your support KPIs rather than judging by feel.
Hodhod's quality review can help here: a reviewer scoring a sample of conversations can include "escalated at the right time" as a criterion.
To run escalation rules and handoffs on your own team, request a free demo. For tickets with priorities, deadlines and auto-escalation, see ticketing.
Frequently asked questions
How many escalation levels should a small team have?
Two or three. With a team of three people, level 1 is everyone, level 2 is whoever is on the rota that week, and level 3 is the founder or the developer. Adding more levels only adds more handoffs.
What is the difference between escalation and a handoff?
A handoff is any transfer of a case between people. An escalation is a handoff triggered by a rule because the case needs more skill, access or authority. A transfer because of a shift change is a handoff but not an escalation.
Should the customer be told about an escalation?
Yes, briefly. Say that a specialist now has the case and when they can expect news. Don't describe your internal levels, and don't ask the customer to repeat what they already wrote.
Can escalations be automated?
Partly. Time-based triggers such as overdue or idle tickets can be automated with auto-escalation rules. Triggers that depend on judgement, like an upset customer, still need an agent to decide.
Who decides when a case goes to engineering?
Set that in the policy: usually level 2, after reproducing the problem and checking whether other customers are affected. Level 1 shouldn't send raw reports directly to developers.
