Containment Rate vs Deflection Rate: How SaaS Teams Measure Both

A practical measurement guide for separating bot-only conversations from verified self-service resolutions, with event fields, a worked SaaS example, and safe operating targets.

By PankajNovember 11, 2026chatbot metricscontainment rateticket deflectionsaas support

Decagon’s example starts with 10,000 support contact attempts: 6,500 resolved through self-service produces a 65% deflection rate. For a SaaS team, that result means something different from the percentage of chatbot conversations that ended without a human. Tracking containment rate vs deflection rate separately helps teams see both automation coverage and customer outcomes.

Containment rate counts eligible chatbot conversations that end without a human handoff. Deflection rate counts eligible support requests resolved through self-service, often across a broader request population. A conversation can be contained but unresolved, so teams should report both rates with their denominator, resolution evidence, repeat-contact window, and a separate handoff-success measure.

Containment rate vs deflection rate: formulas and definitions

Use containment to measure the conversation path and deflection to measure resolved support demand. Neither metric should treat a bot reply, customer silence, or automatic ticket closure as proof that a request was solved.

Metric	Formula	What it describes
Containment rate	Eligible chatbot conversations ending without a human handoff ÷ eligible chatbot conversations × 100	Whether the conversation stayed with the bot
Verified deflection rate	Eligible support contact attempts resolved through self-service ÷ all eligible support contact attempts × 100	Whether a support request was resolved without human support

Define the denominator before comparing periods. A chatbot-only containment denominator includes conversations that entered the bot, while a deflection denominator can include eligible attempts through chat, help-center search, email, or phone. Count repeat attempts consistently, and exclude tests, spam, and duplicate logging events under a documented rule.

Keep four outcomes distinct in reports: a bot response means a message was sent; a contained conversation ended without agent handoff; a probable resolution has no linked repeat contact during the follow-up window; and a verified resolution has customer confirmation or evidence that the requested outcome occurred. Teams comparing support channels can use a framework such as knowledge base versus AI support agent case deflection to define which self-service surfaces belong in their population.

A worked example—and the events to track

Consider a month with 10,000 eligible support contact attempts, following the scale of Decagon’s published example. Suppose 8,000 entered the chatbot, 7,200 ended without a human handoff, and 6,500 of those requests were verified as resolved through self-service. The remaining 700 contained chats had no confirmed outcome. The other 2,000 attempts came through other channels or went directly to a person.

The results are 90% containment (7,200 ÷ 8,000) and 65% verified deflection (6,500 ÷ 10,000). The 700 silent or unresolved bot conversations count toward containment under this definition, but not verified deflection. This makes the difference explicit instead of using a verified-only numerator for one metric and silently applying it to the other.

A lightweight support-data setup can capture the distinction with events such as conversation_started, bot_reply_sent, handoff_requested, handoff_started, resolution_confirmed, and repeat_contact. Attach fields including conversation_id, contact_attempt_id, customer_id, issue_id, channel, handoff_reason, resolution_status, and timestamps. Link later contacts to the original issue_id where possible; count a related contact within 72 hours as a repeat, not as evidence that the earlier bot session succeeded.

Decagon describes a 24–72-hour no-ticket window as a scalable behavioral proxy, while warning that it can overstate deflection when customers return through an untagged channel. AeroChat likewise points out that abandonment can inflate containment. A 72-hour window is a workable default for a small SaaS team, but label a no-repeat result probable, not verified, unless the customer confirms success or a validated action demonstrates it.

A practical target, quality checks, and Zealoop

There is no defensible universal containment percentage for every SaaS team: a bot handling password resets has a different issue mix from one handling complex integrations. A useful first-month operating target is 100% successful routing for conversations that request a human and 100% outcome tagging for measured conversations. Then improve verified deflection against the team’s own baseline without worsening repeat contact, customer feedback, or escalation access.

A weekly review can focus on these checks:

Report containment and verified deflection separately, with their denominators and exclusions.
Review bot-only conversations with no confirmed outcome, especially abandoned chats and auto-closed tickets.
Compare 72-hour repeat contact and CSAT for bot-resolved requests with the team’s baseline.
Audit failed guarded actions and requests where the bot had relevant documentation but still gave an incorrect answer.
Test that a direct request for a person reaches an agent and record handoff_success separately from handoff_requested.

These checks fit Zealoop’s role as an agent that answers from company documentation, looks up customer data, and performs guarded actions. For measurement, a successful action should be recorded only after its result is validated; an attempted account change is not resolution evidence. Teams using Zealoop’s Free plan, which includes 50 conversations per month and 3 knowledge sources, can log every conversation but should avoid treating a small, uneven sample as a stable benchmark. The RAG chatbot versus AI support agent comparison can help teams distinguish answer-only self-service from workflows that include account actions and escalation.

FAQ

How should a small SaaS team capture a 72-hour repeat contact?

Store the original contact’s customer or account identifier, issue category, and timestamp. When another conversation arrives within 72 hours, match it to the same issue where possible and set repeat_contact=true on the original outcome. If the channel or identity cannot be matched reliably, report that limitation rather than assuming no repeat occurred.

What should happen when a customer asks for a human?

The chatbot should stop trying to contain that conversation and route the request through the team’s defined escalation path. Log both handoff_requested and handoff_success; the second event confirms that the customer actually reached the intended queue or agent. A handoff request without a successful route is not a successful escalation.

Should an AI chatbot’s action attempt count as a resolution?

No. The system should record a resolution only after confirming the requested state change or outcome. For example, a billing-plan update should count after the account reflects the new plan, not when the bot submits the update. Failed or unauthorized actions should be tagged separately and routed to a person when needed.

Sources

All articles on the blog