Customer Escalation Checklist
A customer escalation process checklist: confirm the impact, name an owner, set update times, bring in engineering, close the loop and review what went wrong.
- Typical schedule per escalation
- The checklist 4 sections, 16 items
- Variables
{{customer}}{{ticket_id}} - Start from CI
Use this checklist when a customer issue goes beyond normal support: a key account is blocked, a customer threatens to cancel, a bug affects their business, or a complaint reaches management. It is for single-customer escalations. Outages that affect many customers belong in your incident process.
Who owns it
One named escalation owner runs the whole thing, usually a support lead or a customer success manager. Engineering, product or finance help with specific items, but the customer hears from one person. The owner decides when the escalation is closed, and confirms that decision with the customer.
Common pitfalls
- Nobody owns it. Escalations often bounce between support, engineering and sales. Name the owner in the first hour and tell the customer who it is.
- Promising a fix date you do not control. Promise update times instead: "next update by 15:00". Then keep them, even when the update is "still investigating".
- Losing context on the way to engineering. Pass on the steps to reproduce, the account ID, the impact and what has been tried. A link to a long ticket thread is not enough.
- Closing when the bug is fixed. The escalation ends when the customer confirms things work and the relationship is repaired. Ask them.
- Skipping the review. If escalations keep coming from the same cause, the review is where you find out.
If your helpdesk can call a webhook, start a run when a ticket is tagged as escalated. The audit trail then shows the response times and every promise made.
The checklist: Escalation: {{customer}} ({{ticket_id}})
First hour
-
Escalation owner named and recorded on ticket
{{ticket_id}} -
Impact confirmed: what is blocked, how many users, and any deadline on the customer's side
-
Issue reproduced or the evidence collected (screenshots, logs, account ID)
-
Checked that this is not part of a wider outage
If several customers are affected, switch to the incident process and link this ticket.
-
Customer contacted by the owner, with the next update time stated
Investigate
-
Engineering or product engaged with a complete summary: steps, impact, what was tried
-
Workaround found and offered to
{{customer}}optional -
Account manager or sales informed for key accounts optional
-
Every promised update sent on time, even without news
Resolve
-
Fix or decision delivered and explained to
{{customer}}in plain language -
Customer confirmed the issue is resolved for them
-
Goodwill gesture agreed with the approver, such as a credit optional
-
Ticket
{{ticket_id}}closed with a summary of cause and resolution
Review
-
Root cause recorded: product bug, documentation gap, process or expectation
-
Follow-up tasks created for the cause and linked to the ticket
-
Check-in with
{{customer}}scheduled one to two weeks later optional
Checklist as Markdown
Start this checklist from your pipeline
When a ticket gets the escalated tag in the helpdesk, POST /api/v1/runs with template "Escalation: {{customer}} ({{ticket_id}})" and the ticket ID.
curl -X POST https://runbook.metastic.ch/api/v1/runs \
-H "Authorization: Bearer $RUNBOOK_TOKEN" \
-H "Content-Type: application/json" \
-d '{"template": "Escalation: {{customer}} ({{ticket_id}})", "variables": {"customer": "…", "ticket_id": "…"}}'Frequently asked questions
What is a customer escalation process?
It is the agreed path for issues that normal support cannot resolve quickly or that carry business risk. A good process names a single owner, sets update times, defines how to bring in engineering or management, and ends with a review. Writing it down as a checklist means it works the same way every time.
When should a support ticket be escalated?
Common triggers are a blocked key account, a security or data concern, a bug that support cannot work around, a churn threat, or a ticket that has missed its response target. Define your triggers in writing so agents do not have to guess. When in doubt, escalate early.
How often should I update a customer during an escalation?
Agree an interval with the customer and stick to it. For a blocking issue, every few hours during business hours is common. An update without news is still an update, because silence is what turns an escalation into a cancellation.
Updated