Internal escalation taxonomy in WhatsApp: table by role and target time

An escalation is any conversation that leaves the person who was handling it and moves to someone else with more information, more authority, or more tools. Most teams have escalations, but they don't have a taxonomy: things get forwarded through internal WhatsApp, by email, by word of mouth, or they simply don't get forwarded at all and the customer is left waiting. This table organizes the reasons, defines which role each one corresponds to, what must always be attached, and how long the customer can wait depending on severity. It's designed for you to copy it, adapt it to your operation, and paste it into the team's internal channel.

Before the table, a note on method: the target times are not promises to the customer. They are internal agreements between areas. The customer sees a single number, the first response time; what's measured internally is how long each hop takes. If hop one takes two hours and hop two takes a day, the customer got a quick response and an extremely slow solution, and that feels worse than having waited from the start.

How to read the table

• Reason: the short label used to classify the case. It has to be the same word the whole team uses, not synonyms.
• Responsible role: who resolves it, not who receives it. There can be a role that receives and another that resolves; the one that matters for the target time is the one that resolves.
• Minimum information: what must be attached when forwarding. If it's missing, the case comes back and a whole day is lost.
• Target time: from when it's forwarded until there's a response with content for the customer, not an acknowledgment of receipt.
• Severity: high, medium, or low. It defines whether the target time is measured in minutes, hours, or business days.

Reference table: reasons, role, minimum information, and target time

The three severities, in concrete terms

Severity is not defined by the customer's anger but by the impact. A very angry customer asking about stock is low severity: it is resolved with information. A calm customer reporting they were charged twice is high severity: there is money involved and a legal deadline running.

• High: there is money, legal risk, reputational risk or the operation is halted. Whatever is being done is interrupted to handle it.
• Medium: there is a broken promise or an exception that requires authorization, but the business keeps running. It is handled the same day.
• Low: it is information the customer needs but it is not urgent. It is handled within 48 business hours.

What to always attach, regardless of the reason

The number one cause of escalations that take twice as long is handoff without context. The person receiving it has to ask the customer again the same thing the customer already answered, and that burns the relationship. These five pieces of data go in every handoff, always:

1. 1Customer name and phone number exactly as it appears in the conversation.
2. 2Three-line summary: what happened, what the customer asked for, what has been answered so far.
3. 3The screenshot or the link to the full conversation, not an oral summary.
4. 4What is expected from the role receiving it: a decision, an authorization, a piece of data or a concrete action.
5. 5By when it is needed, according to the severity in the table.

What a well-done escalation looks like and what a badly done one looks like

Frequent mistakes when building this taxonomy

• Using synonyms for the same reason. If one agent writes "refund" and another "return", the statistics are useless and nobody knows how many cases there are of each type.
• Defining the role by person instead of by function. When that person goes on vacation, the escalation falls apart. The role has to exist even if the person occupying it changes.
• Setting target times that nobody can meet. A systematically missed deadline teaches the team to ignore the entire table.
• Not defining what happens outside business hours. If it isn't written down, everyone improvises and the customer receives contradictory answers.
• Confusing severity with the urgency of the person escalating. Severity is defined by the impact on the business and on the customer, not by the desire to get the case off one's plate.
• Not measuring. A table that isn't audited becomes outdated within a month and stops reflecting the real operation.

How to audit the circuit once a month

The audit is simple and doesn't need special tools. A sample of escalated conversations from the month is taken, classified with the table and compared against the target times. That's enough to know whether the taxonomy works or has become decorative.

1. 1Choose a sample of between twenty and thirty escalated conversations from the month, mixing reasons.
2. 2Classify each one with the reason from the table. If a reason appears that isn't in the table, note it down: it's a gap in the taxonomy.
3. 3Measure the real time between the escalation and the response with content to the customer. Don't count the acknowledgment of receipt.
4. 4Mark the cases where minimum information was missing. Those are the ones that almost always took the longest.
5. 5Count how many cases returned to the original agent unresolved. If it exceeds one in five, the problem is the definition of roles, not the people.
6. 6Update the table with the new reasons and review the times that are always missed: either the deadline is wrong or there aren't enough people in that role.

A useful piece of data for this audit is the real time at which messages arrive, not the time they were uploaded to the system. If you measure with the upload date you'll see a false distribution, because history imports pile everything into the same moment. Always use the timestamp of the original message.

Escalation and support with AI suggestions

When the first response is given by a system with AI suggestions, escalation changes in form but not in substance. AI can suggest the classification of the reason and the routing, but the decision to escalate and to whom remains human. What does improve is the record: each case is tagged with the reason from the first message, and the monthly audit is done on data instead of on memory. Tools like Wando, which suggest responses and approve them with one click, serve exactly that purpose: the team doesn't write from scratch, but still decides what gets routed and what gets answered on the spot. If you want to see how the inbox with suggestions works, you can try it free for 14 days, no card required, and check the current plans at wando.online/pricing.

Questions worth answering before publishing the table

• Who covers each role when that person is away? If there's no answer, the role isn't defined.
• What happens to cases that come in outside business hours? Do they pile up or is there an on-call shift?
• Does the customer get a notice when their case is routed, or do they wait without knowing someone else is looking at it?
• Are target times measured in business hours or calendar hours? It has to be written down and be the same for all reasons.
• Who updates the table when a new reason appears? If there's no owner, it goes out of date on its own.

An honest closing note on the limits of this table

This taxonomy doesn't solve the underlying problem of a team that can't keep up: it organizes the disorder, it doesn't eliminate it. If most cases are high severity and the target time is missed every week, the table will clearly show that there aren't enough people, and that's useful information even if it isn't the information you want to see. The times are a starting point and vary by industry, team size and business hours. What doesn't vary is the logic: every reason has an owner, every owner needs minimum information and every severity has a deadline that can be measured.