Customer escalation analysis: why escalated requests are rising

Short answer

To find out why escalated requests are rising, split the rise along four dimensions: topic (which problem is being escalated), channel (bot, chat, call), time (which week, which hour) and routing (who handed the conversation to whom). A rise usually comes from one of four causes: a new problem has appeared, the first line lacks knowledge or authority, a routing rule has changed, or customer expectations have risen.

Each cause has a different fix. Looking at the total number of escalations and deciding "we need more second-line staff" often treats the result rather than the problem.

What an escalation is and how to recognise it

An escalation is when a request is handed to a more authorised person or team because the first line (a bot or a first-line agent) could not resolve it. In a conversation it can be recognised three ways: a handover record in the system (bot to agent, agent to supervisor), the customer's explicit demand ("I want to speak to a manager"), and the agent's sentence ("I'm passing this to a specialist"). The first is the most reliable but not every system has it.

Cause 1: a new problem

A new product, a price change, a technical outage or a new rule brings customers with questions the first line has no answer for. Sign: the rise is concentrated in one or two topics and starts on a specific date. Fix: give the first line an answer or authority, and fix the problem itself.

Cause 2: a first-line knowledge or authority gap

The topic is not new, but the first line cannot resolve it: the answer is missing from the knowledge base or outdated, or the agent lacks authority to decide (for example, a small refund). Sign: the same topic is always escalated, and the second line closes it with a standard answer. Fix: add the answer to the knowledge base or widen the authority.

Cause 3: a routing change

The bot's handover rule changed, a new channel was connected or the shift schedule changed. Sign: the rise is even across all topics and tied to one date, channel or hour. Here the problem is the rule, not the customer. How bot handover rules are built is explained in chatbot escalation rules.

Cause 4: rising customer expectations

Customers no longer accept an answer they used to accept: a competitor offers faster service, a campaign promised more, or a public event raised sensitivity. Sign: the share of explicit demands such as "I want to speak to a manager" rises while the topics stay the same. Fix: revisit the answer standard or service level.

Analysis along four dimensions

1. 1TopicThe topic split of escalated conversations and its change from the last period. A rise in one topic points to cause 1 or 2.
2. 2ChannelBot-to-agent and agent-to-supervisor handovers separately. A rise in one channel points to cause 3.
3. 3TimeBy day and hour. A rise at certain hours points to shifts or routing.
4. 4Who to whomWhich shift or group hands over. This is for seeing the process, not for individual evaluation.

Escalation share, not count

When total enquiries rise, escalations rise too. The real indicator is the escalation share: escalated conversations as a proportion of all conversations, separately by topic. A high share is normal for some topics (legal requests always go to a specialist, for example). What matters is the change.

Illustrative example

This is an illustrative example. In an online store, bot-to-agent handovers rise noticeably over two weeks. The topic split shows the rise is mainly in "refund status" and starts on the date the store switched to a new payment provider. The bot still quotes the old provider's timeframe, while customers write that the money has not arrived.

Causes 1 (a new problem) and 2 (outdated bot knowledge) are combined. The bot's answer is updated and the payment team gets a list of delayed refunds. Over the following weeks the escalation share for that topic is tracked.

A weekly escalation review

Review escalations every week in a short 30-minute meeting with the support lead and the knowledge base owner. The agenda is fixed: the two fastest-growing topics, the typical answer the second line gives on them, whether that answer can be handed to the first line or the bot, and the results of last week's decisions. Every meeting should produce at least one change: a new knowledge base answer, wider authority or a corrected handover rule. The change's effect is checked in next week's escalation share.

Escalation is not bad

Cutting escalation entirely should not be the goal. In some cases a correct, timely handover is the best outcome: a complex complaint, a legal issue, an angry customer. The problem is handing over what the bot or first line could resolve, or failing to hand over what should be. So track two indicators together: the escalation share and the share of conversations left unresolved without escalation.

Typical mistakes

• Looking at the total count and adding second-line staff.
• Explaining the rise as agent weakness without looking at the process.
• Tightening the bot's escalation rule just to cut handovers — the customer gets trapped.
• Not reading the conversations the second line resolves.

Limits

• If a handover is not recorded in the system, AI only estimates it from sentences in the conversation.
• An escalation where the customer switches to the phone or comes in person may not appear in the conversation.
• Share changes can be random at small numbers.

Escalation analysis in Vexvon

In Vexvon it is recorded who handled the conversation — the bot or an employee — and the panel shows the bot vs staff split. The company sets up fields such as "escalation reason" and "topic" itself; the panel's AI assistant gives them with channel and time cross-tabs and period comparisons. Bot replies are built from the knowledge base, so a first-line knowledge gap is fixed there directly. More: analytics and the knowledge base.

Next step

Split the last two weeks' escalated conversations by topic and read 15 from the fastest-growing one: which of the four causes shows up? For the root cause method, see complaint root cause analysis; we can build the analysis together in a demo.

Further reading on this topic: customer journey pain points, support knowledge gap analysis.