Zendesk's July release added end-user presence detection so messaging teams can tell when someone has left a site or app, remove inactive sessions from queues, and follow up on abandoned conversations. The feature points at a blind spot in chatbot reporting: a conversation that never escalated may have ended because the visitor was satisfied, distracted, frustrated, or still waiting.
That distinction matters more as support workflows grow longer. Pylon's new agentic support platform describes background agents gathering context, investigating issues, and coordinating handoffs before a human responds. Each extra step can help the customer, but it also creates another place to leave.
Start with four numbers for the last seven days:
- Conversations with at least one visitor message.
- Conversations with a confirmed outcome or accepted handoff.
- Conversations with evidence that the visitor left while an intent was open.
- Conversations that ended without enough evidence to classify.
Keep the fourth number visible. If you silently count every unknown as resolved, your chatbot abandonment rate will look excellent while customers move to email, search, or a competitor.
Define Abandonment Before Calculating It
A useful definition is: a chatbot conversation is abandoned when the visitor leaves after stating an intent but before reaching a confirmed outcome, accepting a handoff, or explicitly ending the request.
Use this formula:
Chatbot abandonment rate = probable abandoned conversations / eligible conversations started × 100
An eligible conversation has at least one meaningful visitor message. Widget impressions, accidental opens, uptime checks, obvious spam, and internal tests do not belong in the denominator.
The numerator needs stronger rules than “no final message.” A customer who asks for opening hours, reads a correct answer, and closes the widget may be resolved without saying thanks. A customer who waits 40 seconds for a response and leaves has a much stronger abandonment signal.
Classify each eligible conversation into one of four terminal states:
| Terminal state | Required evidence | Reporting treatment |
|---|---|---|
| Confirmed outcome | Completed action, positive feedback, explicit confirmation, or verified downstream result | Resolved |
| Accepted handoff | Ticket created, live agent joined, callback captured, or another support channel accepted the case | Handed off |
| Probable abandonment | Open intent plus exit, timeout, or no return after a defined window | Abandoned |
| Unknown | Session ended without enough evidence to distinguish success from drop-off | Report separately |
This outcome contract should be shared by product, support, and analytics. Otherwise one dashboard will call a quiet exit “contained,” another will call it “resolved,” and the support inbox will record the same visitor as a new ticket.
The broader chatbot KPI reference covers resolution, containment, CSAT, and handoff. Abandonment is the diagnostic layer that stops those metrics from receiving credit for silence.
Instrument the Conversation, Not Just the Last Message
A transcript tells you what was said. It rarely tells you what the visitor was waiting for when they left. Add events for the conversation state, page state, and business outcome.
| Event | Minimum fields | What it answers |
|---|---|---|
conversation_started | conversation ID, timestamp, page, device, channel | Where did the intent begin? |
intent_opened | intent label, confidence, source message ID | What did the visitor need? |
response_started | reply ID, model, latency, intent | Did the bot begin responding in time? |
response_completed | reply ID, duration, source or fallback status | Did the visitor receive a complete answer? |
next_step_offered | action, handoff, form, or suggested reply ID | Was there a clear path forward? |
next_step_completed | result ID and completion type | Did the conversation produce an outcome? |
presence_changed | visible, hidden, disconnected, or inactive plus timestamp | Was the visitor still available? |
conversation_returned | previous conversation ID and elapsed time | Was the exit temporary? |
Browser visibility, a closed socket, and an idle timer are useful signals, but none proves frustration by itself. Mobile users switch apps. Laptop users leave tabs open. Networks disappear. Keep raw presence events separate from the rule that classifies a conversation.
Choose an inactivity window based on the stage. Thirty seconds may be long after a one-line FAQ answer, but short while a human agent is joining or an API action is running. Store the expected wait with the event so a later review can tell whether the system broke its own promise.
Also link chat outcomes to downstream channels when consent and identity allow it. If a visitor leaves the widget and submits the same question through a contact form ten minutes later, the chatbot did not resolve the request. Use a short attribution window and a privacy-safe identifier rather than trying to track people indefinitely.
A Worked Abandonment-Rate Calculation
Suppose a support chatbot records 1,000 eligible conversations in one week. Its first dashboard says:
- 620 reached a confirmed outcome.
- 140 entered an accepted human handoff.
- 80 had a clear open intent when the visitor left.
- 160 ended without a reliable outcome signal.
The observed abandonment rate is 80 / 1,000 = 8%. The worst-case rate is (80 + 160) / 1,000 = 24%. Reporting only 8% implies more certainty than the data supports, so the weekly review should show 8% observed abandonment, 16% unknown.
The team then adds completion events to its pricing links, captures accepted handoffs, and checks whether a visitor returns within 24 hours. Of the 160 unknown conversations, 100 now have evidence of a completed outcome, 20 are probable abandonment, and 40 remain unknown.
The revised result is 100 / 1,000 = 10% abandonment with 4% unknown. The rate increased even though measurement improved. That is a useful correction: the team now has 100 conversations it can diagnose instead of a flattering 8% built on missing events.
Do not compare the new 10% directly with the old 8% as if behavior worsened. Mark the instrumentation change on the chart and establish a new baseline.
Find the Turn Where Visitors Leave
An overall rate tells you that a problem exists. Segmenting by the last completed stage tells you where to work.
| Last completed stage | Strong diagnostic signal | First fix to test |
|---|---|---|
| Before first response | High latency or response never started | Reduce time to first useful text; add an honest wait state |
| After first answer | Exit follows fallback, long answer, or weak source match | Lead with the direct answer; improve the source or Q&A pair |
| During clarification | Repeated question or three-plus required turns | Ask only for information needed for the next decision |
| During form or action | Form opened but not submitted; tool started but not completed | Remove fields, preserve inputs, and return specific errors |
| During handoff | Visitor leaves after requesting a person | Show queue expectations and capture a callback route |
| After apparent resolution | Same intent returns through chat or another channel | Reclassify the first session and fix the incomplete answer |
Then split each stage by intent, landing page, device, language, model, and response-time band. A sitewide average can hide a checkout bot that performs well on desktop and fails on mobile, or a fast FAQ flow that masks a broken billing handoff.
Latency deserves its own banding. The chatbot speed guide explains why a marginally smarter answer can lose customers when every reply takes longer. Compare abandonment below two seconds, from two to five, from five to ten, and above ten. The curve will show whether speed is the primary defect or merely correlated with difficult intents.
Read the Last Two Turns as an Artifact
Metrics identify a stage; transcripts reveal the repair. Review a sample of abandoned and successful conversations with the same intent side by side.
Consider this fictional pricing exchange:
Visitor: Does the Team plan include SSO? Chatbot: Our plans are designed for organizations of different sizes. The Team plan includes collaboration features, workspace controls, analytics, and several integrations. Enterprise customers receive additional security and administration capabilities... [visitor leaves after 14 seconds]
The bot responded, so a basic uptime dashboard passes it. The intent stayed open because the answer never gave a yes or no. A better version makes the decision visible:
Visitor: Does the Team plan include SSO? Chatbot: No. SSO is available on the Enterprise plan, not Team. Would you like to compare the two plans or contact sales? [Compare plans] [Contact sales] Visitor selects: Compare plans [comparison page opens; outcome recorded]
The repair has three parts: a direct answer, a relevant next step, and a completion event. The button alone is not the fix; a precise answer earned the click.
For lead and support forms, inspect every required field at the same level. The lead-generation chatbot guide shows why progressive profiling beats collecting everything at once. Preserve already entered values after validation errors, and never make a visitor repeat details the conversation already contains.
Recover Without Turning Follow-Up Into Spam
Recovery should match the evidence and the cost of interruption.
While the visitor is present: surface the likely next step, shorten long replies, explain waits, and offer a visible human route. These changes prevent abandonment without sending anything later.
When presence becomes uncertain: pause typing indicators and queue capacity after a sensible grace period. Preserve the conversation so returning visitors can resume. Do not declare success merely because the session went inactive.
After a high-intent exit: follow up only when the visitor supplied a permitted contact route and the message provides value. A useful follow-up might contain the saved answer, ticket number, or one-click resume link. “You left something behind” is not useful support context.
After a failed handoff: acknowledge the missed expectation, keep the transcript attached, and give a concrete response window. The chatbot handoff guide covers the packet a human needs so the customer does not restart from zero.
Set frequency caps and stop recovery when the visitor completes the goal elsewhere, opts out, or indicates that the issue is closed. Measure recovered outcomes separately from clicks. A return that ends in the same failure is another diagnostic event, not a win.
Make Unknown Shrink Every Week
The most valuable improvement may be a smaller unknown bucket rather than a lower abandonment rate. Add outcome events to the highest-volume intents first, review the last two turns around each exit, and change one stage at a time. Keep the classification rules versioned so instrumentation changes do not masquerade as customer-experience changes.
A trustworthy chatbot abandonment rate tells you where an open customer intent disappeared and how certain you are about that judgment. Once that boundary is visible, the work becomes concrete: answer sooner, state the decision, reduce the next step, preserve context, or repair the handoff.
In Agentkit, conversation logs and analytics provide the review baseline, while suggested messages and lead-capture actions can shorten the path to a recorded next step.
No credit card required.
