Escalation reasons to a supervisor: reference table with criterion, trigger and what gets written down

Escalating is not "handing off the chat because I don't know what to do." Escalating is a decision made with criteria: there is a defined reason, a verifiable trigger, a written record, and an accountable person on the other side. When any of those four pieces is missing, the handoff turns into a back-and-forth: the customer repeats everything, the supervisor improvises, and later nobody knows why it was resolved the way it was. This page is a reference table for building that circuit in a team that handles WhatsApp. It is not a list of tips: it is material to check off, adapt to your operation, and hang next to the monitor.

The main table has 16 reasons grouped by family. For each one you will find the criteria (why that case is not closed by the person handling it), the trigger (the concrete and observable signal that activates the escalation, not a hunch), what must be written in the system before transferring, and what is done when the supervisor is not available at that moment. Then come the decision matrix by level, the handoff checklist, and the mistakes that make an escalation fall apart.

How to read the table

Each row is a reason. The criteria answers "why doesn't the agent resolve this?" and serves to discuss team design, not minute-to-minute work. The trigger is what is used minute-to-minute: if the agent can point to the phrase, event, or number that activated the escalation, the escalation is done right. If they can't, they are escalating out of fatigue or fear, which are the two reasons that generate the most noise in a shared inbox.

The column "what is written" is the most ignored and the one most missed after fifteen days. Everything the supervisor needs to pick up without asking the customer again must be loaded before the transfer: case summary, what has already been tried, the verified contact detail, and the reason in a tag. If the supervisor has to open the history and read forty messages to understand, the escalation did not save time: it moved it elsewhere.

The last column assumes the obvious: there isn't always a supervisor watching the screen. A small team doesn't have live supervision at 22:00. That's why each reason comes with its plan B. Plan B is never "leave the customer waiting without saying anything"; it is always one of three things: acknowledgment with a deadline, redirect to another channel, or closure with a record to pick up on the next shift.

Decision matrix by level: who resolves what

Before defining reasons, it's worth defining levels. A team where everyone escalates to the same person ends up with a supervisor acting as an agent and an inbox that doesn't move forward. The following matrix organizes decisions by level: what gets resolved at the position, what gets consulted with the coworker next to you, what goes to the supervisor, and what only the owner or management can decide. It's not a structure of roles: it's a structure of authorizations.

The handoff checklist: what gets completed before pressing the button

An escalation without a record is a forwarded message. These eight items are completed before transferring the conversation, in the order they appear. If any of them can't be completed, it's not that the escalation is wrong: it's that information is missing and the supervisor will have to ask for it anyway.

• Categorized reason: the number and name from this table, not a free-form description.
• Three-line summary: what the customer wants, what happened, and what's missing.
• Case status: what was resolved, what was promised, and what's still pending.
• Verified data: name, order number, shift, account, or the corresponding identifier.
• Evidence: screenshot, direct quote, or ticket number, when the reason requires it.
• Deadline the customer has already heard: if a time was promised, that time travels with the case.
• Tag on the contact: just one, with the reason, so escalations can be counted later.
• Owner on the other side: who it's transferred to and during what hours they take over.

What to do when no supervisor is available

Availability cannot be an assumption. If the escalation circuit only works from 9:00 to 18:00, then from 18:00 to 9:00 the business has no escalation: it has an inbox that fills up. There are three options and it's best to choose one per reason, not one general option.

• Acknowledgment with a deadline: the customer is told that the case has an owner and is given a specific window. The deadline is defined by the business and must be achievable; promising a deadline that can't be met is worse than not promising one.
• Redirect to another channel: when the case requires data that can't be requested via chat, the alternative channel is offered and the redirect is logged. The case isn't closed, it's moved.
• Closure with a log for the next shift: the case is left tagged and prioritized, and the customer is told it will be picked up first thing. The log must include what was told to the customer, so the next shift doesn't contradict the message.

What doesn't work is silence. A customer who has already escalated and doesn't even receive an acknowledgment comes back more hostile, and reason #1 in this table activates on its own. The acknowledgment doesn't solve the problem: it buys the time to solve it properly.

Common mistakes that bring down escalation

These are the patterns that appear over and over when a team builds its circuit for the first time. None of them is fixed with a tool: they're fixed with written definitions and with someone who reviews escalations once a week.

• Escalating without a categorized reason: the supervisor receives "look at this chat" and has to rebuild the case from scratch.
• Escalating everything: if 40% of conversations end up with the supervisor, the bottleneck isn't volume, it's the lack of authorizations at level 1.
• Escalating nothing: the agent handles cases that aren't theirs, promises what they can't, and the problem shows up bigger later.
• Not logging the deadline the customer already heard: the supervisor responds with a different time and the customer notices the lack of coordination.
• Using two tags for the same reason: later you can't count how many escalations there were per cause.
• Transferring without notifying the customer: the customer writes, gets no response, and thinks they were abandoned.
• Escalating via internal chat without leaving a trace in the system: the case exists only in the memory of two people.
• Not reviewing closed escalations: without that review, you can't detect which reasons repeat and which policy should be changed.

How to measure whether escalation is working

You don't need a complicated dashboard. Five numbers that can be pulled from the inbox itself are enough to know whether the circuit is improving or getting worse month over month. The important thing is to always measure them with the same criteria and not change the definition halfway through.

Label and summary template for the handoff

The record doesn't have to be a long form. A label and a three-line summary are enough, as long as the three lines answer the same things: what the customer wants, what was done, and what's missing. Here's an example structure, to adapt:

• Label: escalated-supervisor.
• Reason: number and name from the table (for example, 5 · third contact about the same topic).
• Customer: name and order, shift, or account number.
• Wants: in one sentence, in the customer's words.
• Was done: what was answered, what was promised, and on what date.
• Missing: the concrete action the supervisor has to carry out.
• Timeframe told to the customer: the window that was already committed to.

This format has a practical advantage: it can be copied and pasted into any shared inbox system, including a spreadsheet, without depending on an integration. If the team uses templates and labels inside Wando, the summary can be left as an internal note on the contact so the supervisor sees it when opening the conversation.

Questions worth answering before publishing the circuit

• Who is the supervisor in each time slot and who replaces them?
• What is the authorization limit for each level, in numbers?
• Which reasons can be resolved without a supervisor and which never can?
• Where is the escalation logged and who reviews it?
• What is the customer told when the case is referred and within what time frame?
• How often are the most frequent reasons reviewed to change the policy?

If any of these questions goes unanswered, the process will still work, but at the expense of the judgment of whoever is handling it. And when that person takes vacation, the escalation falls apart. The table is there so that this doesn't depend on a single person.