Deflection Rate Formula: Calculate Resolved Support Requests

In a cohort of 100 eligible SaaS support requests, 30 confirmed self-service resolutions produce a 30% deflection rate—not 45% just because five other customers left before getting an answer. The deflection rate formula helps support teams report what customers actually resolved, rather than how many automated conversations simply ended.

Deflection rate = (qualifying self-service resolutions ÷ total eligible support requests) × 100. Count an eligible request as deflected only when the customer’s issue was resolved without human support. Keep requests that escalated in the denominator, and do not treat abandonment or an unconfirmed chat ending as a resolution.

Deflection rate formula

Deflection rate = (qualifying self-service resolutions ÷ total eligible support requests) × 100. The numerator is the number of eligible requests resolved through self-service or AI without a human taking over. The denominator is every request in the defined cohort, including those that escalated or remained unresolved. Multiplying by 100 converts the result to a percentage.

For example, if 120 of 300 eligible requests meet the team’s self-service resolution rule, the calculation is (120 ÷ 300) × 100 = 40%. The arithmetic is straightforward; the important work is deciding what counts as an eligible request and what evidence establishes that it was resolved. Decagon and Helply both describe a self-service-resolution formula, though teams still need to specify the operational rules behind their own measurement.

A qualifying resolution needs more than a closed session or a missing ticket. Stronger evidence includes a customer confirming that the answer helped or a completed task that demonstrates the issue was addressed. If a team instead uses a behavioral proxy—such as no related human contact during a follow-up window—it should label the metric as proxy-based, since silence does not prove that the customer found a solution.

Keep the numerator and denominator on the same unit. If the report counts eligible support requests, each numerator event must represent one of those requests. Mixing help-center page views in the denominator with tickets in the numerator creates a percentage that cannot reliably describe either support demand or customer outcomes.

A worked deflection rate example

A small SaaS company groups 100 eligible customer support requests into a weekly cohort. Its documentation and AI agent resolve 30 requests without human help. The basic result is 30 ÷ 100 × 100 = 30%.

The other 70 requests still matter to the calculation. Ten receive useful automated troubleshooting but are escalated to a person, five end without evidence of resolution, and 55 require human handling from the start. None belongs in the self-service-resolution numerator, but all remain in the denominator.

The five abandoned requests cannot be added to the 30 confirmed resolutions. Doing so would yield 35%, not 45%, and would still incorrectly treat customers who left without a solution as successful outcomes. Nor should the ten escalations be described as interactions that ended without a human taking over: they required human handling.

This example counts requests, not messages or individual chat sessions. If the same customer sends three messages about one issue, those messages do not automatically become three requests. If the customer returns later about the same unresolved issue, the team should apply its repeat-contact rule rather than counting the original interaction as a lasting success.

Choose a numerator and denominator that reflect real outcomes

A deflection percentage is useful only when its numerator and denominator describe the same customer population and counting unit. For SaaS support, the denominator should represent eligible attempts to get help; the numerator should include only requests that were actually handled without a person under a clearly stated resolution rule.

Define eligible support requests

Set eligibility before examining the results. A team might include customer-initiated questions about product setup, billing, or account use, while excluding spam, internal tests, and sales inquiries. If the analysis covers only issues suitable for self-service, report that scope and its request count. The resulting rate describes that cohort, not all customer demand.

Do not remove difficult requests after an AI agent fails or escalates. Those are outcomes in the eligible cohort. Excluding them after the fact would shrink the denominator precisely when automation did not complete the work, making the reported rate look better without showing that more customers received a resolution.

Choose a unit and include the relevant channels

A team can count contact attempts, support requests, or customer journeys, but those units answer different questions. One request may involve several messages or channels; one customer journey may include multiple issues. Choose a unit that fits the report and apply it consistently. Do not label a count of conversations as a count of requests unless the relationship between them is defined.

Include channels that match the question. A chatbot-only rate can use eligible chatbot interactions. An overall self-service rate may include help-center and AI-agent requests, provided the team can identify which sessions represent help-seeking and apply a consistent outcome rule. A page view alone does not establish that a visitor sought support or resolved an issue.

Product usage counts may also use a different unit from a support metric. Zealoop defines a conversation as one thread with one visitor, regardless of how many messages it contains. That makes a thread count useful for understanding the plan’s conversation volume, but it does not automatically mean each thread equals one support request: a thread can contain more than one question, and a request can continue across channels. Keep the two measurements distinct when building a deflection report.

Require evidence, then account for later contact

A session that closes after an AI answer is not automatically a resolution. The customer may have abandoned the attempt, switched to email, or returned later. Keep abandoned and unknown outcomes out of a confirmed-resolution numerator. If the report uses “no later contact” as a proxy, identify the follow-up window and acknowledge that the proxy measures observed repeat contact, not direct confirmation.

Match later contacts across channels where identity and issue context allow. If the team cannot confidently link a later email to the original chat, classify the outcome as uncertain rather than assuming no repeat occurred. Keep the original eligible request in the denominator and determine its final classification according to the team’s written follow-up rule.

Basic deflection rate vs. a repeat-contact-adjusted rate

A basic rate can overstate success if it credits every self-service interaction that does not immediately create a ticket. A customer might leave without solving the problem and return by email the next day. The initial session looked contained, but the support need persisted.

One stricter option is a repeat-contact-adjusted rate:

> Repeat-contact-adjusted deflection rate = (apparent self-service resolutions − linked repeat contacts about the same issue) ÷ eligible support requests × 100

Suppose 120 of 500 eligible requests initially appear to be resolved through self-service, but 25 customers contact support again about the same issue during the chosen follow-up window. The basic rate is 120 ÷ 500 × 100 = 24%. Under this subtraction method, the adjusted rate is (120 − 25) ÷ 500 × 100 = 19%.

This is one possible stricter calculation, not a universal standard. A team could instead count only apparent resolutions that have no linked repeat contact during its defined window. In either approach, the result depends on reliable contact matching and a clear definition of “same issue.” Report the rule with the percentage rather than presenting an adjusted figure as self-explanatory.

Helply describes a 48-hour repeat-contact adjustment as one approach. That is a specific measurement choice, not a rule that fits every SaaS product. A customer may need longer to discover that an integration fix failed, while a password-reset issue may become clear much sooner. Choose a window suited to the issue mix and use it consistently for comparable cohorts.

Keep escalation separate from repeat contact. If an AI agent provides useful guidance and then hands the request to a person, that request may have benefited from automation, but it was not resolved entirely through self-service. Excluding it from the self-service numerator preserves the distinction between assistance and autonomous resolution.

Deflection rate vs. containment rate vs. resolution rate

Deflection, containment, and resolution describe different outcomes. Deflection concerns whether eligible support was resolved without human handling; containment describes whether an interaction stayed in an automated channel; resolution asks whether the customer’s issue was solved, regardless of who solved it.

An AI agent may contain an interaction without resolving it. For example, it could give an incomplete answer about a failed payment, after which the customer leaves the chat. The session did not transfer to a person, but if the payment still fails, the issue remains unresolved. Counting that interaction as a deflection would confuse the channel outcome with the customer outcome.

The reverse can happen as well. An agent may gather relevant details and provide useful troubleshooting, then escalate a billing problem so a person can investigate it. That request was neither contained nor fully deflected, but a human may ultimately resolve it. Reporting the three measures separately makes the contribution of automation clearer without crediting it for a human resolution.

For AI support, pair deflection and containment with resolution and customer satisfaction (CSAT). A rising containment rate alongside falling resolution or CSAT is a warning that customers may be leaving automated interactions without getting help. A high deflection rate is meaningful only when its outcome definition reflects successful self-service rather than the absence of a transfer.

What is a good deflection rate?

There is no single deflection rate that establishes success for every SaaS team. Channel mix, product complexity, issue mix, eligibility rules, and the definition of resolution all affect the percentage. A useful benchmark is therefore a comparable cohort measured with the same rules, not a headline number from a different company or method.

Start with a baseline for a stable group—for example, eligible billing questions handled through in-app support—and compare subsequent cohorts with the same scope and follow-up rule. Suppose that group records 24 confirmed self-service resolutions from 100 eligible requests in one period, then 30 from 120 in the next. The rate changes from 24% to 25%. The second period has six more self-service resolutions, but its rate is only one percentage point higher; both the counts and rates help explain the change.

Next, examine whether the mix changed. If the second cohort contains more straightforward password-reset requests and fewer complex integration failures, an overall increase may reflect easier demand rather than better answers. Compare issue categories or channels separately where the volume supports a meaningful comparison, and keep the combined rate for the overall picture.

The trend is more actionable when paired with repeat contacts, escalations, resolution, and CSAT. If the percentage rises while repeat contacts also rise or customer satisfaction falls, inspect the affected topics before declaring success. Set an internal improvement goal only after establishing a consistent baseline and deciding which customer outcomes the team intends to improve.

How to measure deflection rate consistently

A trend is interpretable only when its cohort, event timestamps, follow-up window, and attribution rules stay stable. Write those rules down before comparing periods so a change in the percentage does not simply reflect a new counting method.

1. Fix the cohort and unit. Specify whether the report counts requests, contact attempts, or customer journeys. Name included channels, issue types, and customer groups. Apply exclusions such as spam and internal tests consistently, and keep eligible requests in the denominator when they escalate.
2. Set the cohort date. Group requests by when the customer first sought help, not by when a ticket was eventually resolved. Use a consistent timezone and reporting cutoff. A cohort that has not completed its follow-up period should be marked pending rather than treated as confirmed deflection.
3. Choose an observation window. Define how long the team will look for a related return contact. Apply the same period across comparable cohorts and explain why it fits the issues being measured. Do not mix outcomes from a mature cohort with unresolved outcomes from a newer one.
4. Match contacts across channels. Link chat, email, and other support contacts using customer identity and issue context where possible. Count a related return according to the stated repeat-contact rule. Keep unmatched or anonymous sessions visible as unknown rather than assuming that the customer did not return.
5. Separate observed facts from proxies. Report customer-confirmed resolutions and verified task outcomes separately from outcomes inferred from no later contact. Include the cohort size and counts of escalations, abandoned requests, and pending outcomes so a percentage does not conceal the evidence behind it.
6. Avoid unsupported attribution. A change after introducing an AI agent does not by itself prove that the agent caused the change. Product releases, seasonality, and support-channel shifts can alter demand. Compare like-for-like cohorts and describe the result as a trend unless the analysis can isolate the cause.

For teams evaluating an agent, operational plan limits should not be mistaken for outcome definitions. Zealoop’s Free plan includes 50 conversations per month and 3 knowledge sources; its Scale plan is $299 per month and includes 6,000 conversations per month. A conversation is one thread with one visitor regardless of message count, so those plan totals describe threads, not confirmed deflections. The pricing page lists these plan details; a separate support report still needs its own eligible-request and resolution rules.

Improve deflection without worsening customer experience

A useful deflection improvement helps the customer get a correct answer or complete an appropriate task without unnecessary friction. For SaaS teams, that requires accurate product guidance, appropriate use of customer data, a controlled route for consequential actions, and a clear way to reach a person when automation cannot finish the request.

• Ground answers in maintained documentation. Keep setup instructions, billing terms, and troubleshooting procedures current and specific. When an answer is wrong or incomplete, update the source material and test the affected question rather than trying to raise the metric by discouraging escalation. Zealoop’s site describes a 20-minute quickstart and a Free plan that provides a documentation-answering agent, so a team can assess a real documentation-grounded workflow rather than a time-limited demo.
• Use customer data only with an appropriate identity check. Documentation can answer general questions, but order history and account-specific requests need reliable customer context. Zealoop requires a signed identity from the customer’s server for order-history lookups and actions. That requirement is more precise than simply saying a customer is “verified”: it identifies the server-signed identity as the basis for those operations.
• Keep consequential actions guarded. Completing a task can be more useful than giving instructions, but the action should remain under customer control. Zealoop runs a refund or address-change action only after the customer confirms it. This makes the confirmation step part of the support outcome: an action is not complete merely because the AI described what it could do.
• Treat escalation as a valid outcome. Some requests need a person because the issue is complex, the information is insufficient, or the customer wants human help. Count those requests as escalated rather than deflected, and review whether the AI provided useful context before handoff. An honest escalation is preferable to a misleadingly high deflection figure built from unresolved interactions.

Report the resulting rate alongside resolution, repeat contacts, escalation, and CSAT. If deflection rises while customer outcomes worsen, inspect the specific queries and task flows that changed. The objective is not to keep every customer in an automated channel; it is to resolve suitable requests safely and leave a reliable route to human support for the rest.

FAQ

Can a Zealoop conversation count as one support request?

It can if the team’s reporting definition establishes that relationship for the cohort being measured. Zealoop defines a conversation as one thread with one visitor, regardless of how many messages it contains. A thread may include multiple questions, so teams should avoid treating every product conversation as exactly one resolved support request without checking how their own request unit is defined.

When should a SaaS team move an issue from AI to a human?

Escalate when the issue needs investigation the automated workflow cannot perform, when required customer context is unavailable, or when the customer asks for a person. For example, a documentation answer may explain a billing policy, while an account-specific dispute may require human review. Escalation should remain an accepted outcome, not a failure hidden by the deflection metric.

Can an AI agent perform an account action without customer confirmation?

The answer depends on how the product guards that action. Zealoop’s stated behavior is that a refund or address-change action runs only after the customer confirms it; order-history lookups and actions also require a signed identity from the customer’s server. Teams should distinguish an answer about an action from a completed, authorized change when measuring resolution.

What does a support team’s AI conversation allowance measure?

It measures conversation volume according to the plan’s definition, not the number of issues resolved. For Zealoop, one conversation is one thread with one visitor regardless of message count. To calculate deflection, a team must separately identify eligible support requests and determine which ones were resolved through self-service under its stated outcome rule.

Sources

• www.featurebase.app/blog/deflection-rate
• helply.com/blog/what-is-the-deflection-rate
• decagon.ai/glossary/deflection-rate
• www.zealoop.com/
• www.zealoop.com/pricing