Define the triggers
Write down when an agent should escalate, so it is not a judgment call each time.
- The problem needs access or skills the agent doesn't have, such as a bug
- The request is above the agent's limit, such as a large refund
- The customer has asked for a manager
- The ticket is about to break, or has broken, a response or resolution target
- Legal, security or privacy is involved
Name the owners
For each trigger, say who takes it and how to reach them. A named person or rotation beats “engineering”. Keep the list short and review it when people change roles.
Write a good handoff note
The receiver should be able to act without asking the customer anything again.
- What the customer is trying to do and what happened
- What you have already tried
- Steps to reproduce, with links, order numbers or account details
- What you need back, and by when
- What you told the customer to expect
Keep the customer informed
Tell the customer that the ticket has moved and when they'll hear next. The agent who owns the relationship stays the contact unless you decide otherwise, so the customer isn't passed around.
Alert people without overloading them
Use an alert for the cases that need a person quickly, such as an urgent ticket or one that is about to be late, and keep other escalations in the queue. If everything alerts, nothing does.
Review the escalations
Once a month, look at what was escalated and why. Repeated causes point to a missing macro, article, permission or product fix. The goal is fewer escalations of the same kind over time.