Metrics and terms
Handovers are events here, not a percentage
When a visitor asks for a person, the assistant offers a form and stores what they wrote. Those enquiries are listed for you. What does not exist is a rate: nothing divides them by anything, and the division most people would do by hand is less straightforward than it looks.
not measured here
No escalation rate is computed. Enquiries taken by the handover form are stored and listed per assistant, so the events are recorded, but nothing divides them by conversations or messages and no such figure appears on the insights page. Offers that a visitor declined are not recorded at all.
What it means
An escalation rate is the share of contacts that moved from an automated layer to a person. Read one way it is a cost number, telling you how much human work the automation still generates. Read the other way it is a design number, telling you whether the route to a person is available and used. Those two readings pull in opposite directions and most reporting confuses them, which is how a team ends up celebrating a falling escalation rate that was caused by burying the handover. Underneath both readings sits a definitional question with no standard answer: whether an escalation means a completed handover, an offer of one, or any moment a visitor wanted a person and did not get one.
How it is actually calculated
What this product records
When a visitor asks for a person, the assistant offers a form taking a name, an email and a message. Completed enquiries are stored and listed per assistant.
So the numerator of a strict escalation rate exists as a list you can count. What does not exist is any record of an offer that was declined, which means the softer definitions of escalation cannot be built from this data at all.
The division you can do by hand, and its caveats
Count the stored enquiries for a period and divide by the conversation figure on the insights page. That is the closest thing available and it needs three warnings attached.
First, the windows have to match, and the conversations tile covers the last thirty days. Second, one visitor can send an enquiry and also have three conversations, so the numerator and the denominator are not counting the same kind of thing. Third, the result tells you nothing about availability, because a visitor who wanted a person and never found the form is invisible in both terms.
Reading it by topic instead of in total
The total is a workload number. The interesting version is per topic, which is a design number: a topic generating more handovers than expected is either genuinely too complex to automate or failing for a fixable reason, and reading the enquiries tells you which.
Nothing groups enquiries by topic for you. Doing it by hand for a month is unglamorous and it is where the actual finding usually is.
How the number gets moved without anything improving
How handovers fall while frustration rises
Offer the person later. Move the handover from the first reply to the third, add a qualifying question before the form, or word it as a last resort, and the count falls immediately. Every visitor who wanted a person and gave up before reaching the form is now invisible, and they were the ones with the hardest problems.
Make the form longer. Each additional field loses people, so completed enquiries fall while the need that produced them does not. This one is usually done for good reasons, which is why it is worth naming.
Read a falling count in the right direction. It can mean the material improved, and it can equally mean the exit got harder to find. The two are distinguishable only by looking at whether the offer still appears where it used to.
What to look at instead, or alongside
- The raw enquiry count over time, which is honest workload information and needs no denominator.
- The enquiries grouped by topic by hand, which is the version that tells you what to automate differently.
- The unanswered questions list read alongside it, since a topic with many refusals and no handovers is the worst combination on the board.
- A check that the handover offer still appears where you think it does, after any change to the fallback wording.
Questions
- Is a fallback an escalation?
- No. A fallback is the assistant declining to answer, and it produces no enquiry on its own. Whether a refusal turns into a handover depends on how the fallback message is worded and on whether the visitor then asks for a person. Counting refusals as escalations would inflate the number several times over.
- Should we aim for a lower escalation count?
- Only if you know why it fell. As a target it is an instruction to make the route to a person harder to find, and teams hit targets. If you want a target, set it on a topic where you have just published material, and check the enquiries for that topic specifically.
- Can we tell how many visitors wanted a person and did not ask?
- No, and no product in this category can. It is the population that matters most and leaves the least evidence. The nearest proxy is reading conversations that ended abruptly after an unsatisfying answer, by hand.
Keep reading
- Conversation volume: what a conversation count can tell youHow many people opened the widget and said something. A useful denominator, a poor headline, and a number that moves with your marketing.
- Containment rate: why this product does not compute oneContainment counts conversations that ended without a person. A widget cannot see whether one did, so no containment figure exists here.
- First response time has no meaning without a queueThis metric measures how long somebody waited for a human to pick up. There is no queue in a widget, and no first response time is computed.
- Every metric and termWhat each one means, and which of them this product actually computes.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.