What counts as a resolved customer case?

"Resolution rate" is the number every customer-service AI reports and almost nobody defines. One tool counts a conversation as resolved when the AI sent a final message and the customer went quiet. Another counts it when the customer did not reopen the ticket within a day. A help desk counts the ticket closed when an agent closed it. Put those three numbers on one slide and you are comparing three different things.

This article is a measurement specification. It defines the events, the windows and the ledger you need so that "resolved" means the same thing in your business case, your vendor review and your quality audit. It is referenced by the business-case guide, which consumes these definitions rather than restating them. It does not describe any vendor's billing policy; if your contract charges per resolution, the contract's definition governs and should be compared against the one here.

Where this comes from. The specification comes out of four conversations Typewise held in 2026: a discovery conversation with an online retailer unhappy with how its incumbent tool counted resolutions, a discovery conversation with a travel company about its case logic, a demo a colleague ran for a retailer that compares reopen rates, and a pilot review with an online retailer running our agent. I was in three. Observations are anonymised and marked as reported; the definitions and the ledger are our recommendation, and the ledger numbers are invented.

Start from the case, not the message

The customer's unit is the case: the problem, from first contact to the point where nothing further is needed. Messages and tickets are how systems record it. A resolution is therefore an outcome at case level, and three things can go wrong between "message sent" and "case resolved":

• the customer comes back on the same problem (a reopen or repeat contact);
• a person had to finish part of the work (a partial handoff);
• the customer stopped replying because the answer was wrong and they gave up or went elsewhere (silence, which is not consent).

A specification handles all three explicitly.

The event definitions

Two choices need care.

Contact grouping versus case identity. A customer who sends five messages in an hour about one problem has made one contact about one case. Without grouping, the same problem becomes five tickets and the resolution rate is computed on inflated volume. The travel company's selection lead described their logic to me as grouping repeat contacts within an hour into one case and treating anything later as a separate case; the hour is a sensible counting rule, and that is all it should be. The grouping window is a counting rule, not a definition of the case: if the same customer comes back about the same still-open problem two days later, that is another contact on the same open case, not a new case and not a reopen. A reopen is only possible once the case had reached candidate resolution and the contact falls inside the repeat-contact window. If the same problem comes back after that window has passed, open a new case linked to the earlier one; the earlier resolution stands in its own period's ledger and the link is reported, so time never silently manufactures a fresh, unconnected case. Only a genuinely different problem starts a new case straight away. Keep the case identity persistent by customer and problem, document the contact-grouping window separately, and keep the full customer history visible regardless.

The repeat-contact window. Delivery questions are typically answered within days; a return or refund may take two weeks to prove itself; a subscription change may not show until the next invoice. Set the window per intent based on how long it takes for the answer to be tested by reality. A single global window is simpler and wrong for at least one of your intents.

Why silence is not resolution

A case where the customer stops replying has one of three explanations: the answer worked, the customer gave up, or the customer tried another channel. Tools that count silence as resolution report the first and hide the other two. Silent cases without a verified outcome belong in their own "unknown" state; they are neither resolved nor reopened until a check establishes which. Two checks expose the difference:

• Cross-channel reopens. Match contacts by customer and problem across chat, email, phone and messaging. A case "resolved" in chat and reopened by email the next day is a reopen.
• Outcome sampling. For a sample of silent cases, check what happened next: was the order delivered, was the return accepted, did the customer buy. The online retailer's founder described what he found when reviewing tickets his incumbent tool had marked resolved: the tool reported a resolution rate on the chats it handled, but customers in countries their return portal did not serve had been sent to that portal anyway. They did not argue; they stopped replying and tried another channel, and the dashboard called it success.

For pre-sales conversations, define the success event as the thing the customer was trying to do (an item added, an order completed) rather than the conversation ending.

Two bounds follow. Reopens observed on one channel are a lower bound on true reopens, because reopens on other channels are missed. A resolution rate that treats unverified silent cases as resolved is an upper bound on true resolution. Report both bounds when the data does not allow a point estimate.

The ledger: a worked, hypothetical month

Invented numbers to show how the events combine. The point is the structure, not the values. The ledger has two parts that must not be mixed: the cohorts, which split the month's cases by who handled them and sum to the total, and the outcomes, which split one cohort by what happened to it at a single observation cutoff (here: the end of the month plus the longest repeat-contact window) and sum to that cohort. Rates are always a numerator from the outcome rows over a denominator that is a named cohort.

The numbers are invented and do not add up to a benchmark; the point is the structure. Notice the two interval rates. Both are honest; they answer different questions. The first is what the business case needs (how much of all demand the AI finished). The second is what the quality review needs (how reliable the AI is where it acts). The conditional 85% is a third thing again: useful for diagnosing the verified cases, misleading if presented as the AI-handled success rate. A vendor dashboard that shows only a figure like the conditional one, on a denominator of conversations the AI touched, will look better than the first two and is not comparable to a help desk's number.

Also notice the comparison line. Reopen rates for AI-handled and human-handled cases are only comparable with the same window, the same grouping and a similar case mix. If the comparison shows AI-handled cases reopening at a materially higher rate than human-handled ones, treat that as a finding to act on through the fact and relevance edits described in what agents change in AI-written replies, not as a reason to change the definition. The retailer in the demo had run such a comparison and found reopen rates for AI-handled tickets noticeably higher than for human-only tickets; not all of the reopened tickets had been analysed yet and comparability was not established. Until it is, treat such a gap as a prompt to align windows and grouping and to trace causes, not as a result.

Partial handoffs are human work

One way a resolution rate flatters is by counting a case as AI-handled when a person did a step in the middle. Record the human minutes on partial handoffs and report them next to the resolution rate; a high "AI participation" figure with a high partial share is a different operation from one where the AI finishes cases alone. In the pilot review, the retailer's service director said a high share of conversations handled by the AI looked positive but the share that was only partially resolved was a bone of contention, and their engineering lead planned to review how many conversations the AI ran alone, how many agents replied to, and how much involvement was needed, before deciding anything. That is the right order. For how to design the partial step so it is at least visible, see handoff ownership.

Specification checklist

Before you compare any two resolution numbers, or put one in a business case, confirm:

• [ ] Unit is the case, identified by customer and problem and persistent until resolved; the contact-grouping window is documented separately and never closes a case; a further contact on an open case is not a reopen; the same problem after the window opens a new, linked case.
• [ ] One observation cutoff per ledger; cohorts sum to the total and outcomes sum to their cohort; every case is in exactly one final state.
• [ ] Candidate resolution requires a verified outcome and no pending work.
• [ ] AI-handled, assisted, partial handoff and fully human are distinct states.
• [ ] Repeat-contact window set per intent and documented.
• [ ] Reopens matched across channels, by customer and problem.
• [ ] Silence is not a resolution event; silent cases without a verified outcome are classified as unknown; audited cases move to resolved or known unresolved on evidence, the rest stay unknown and are not extrapolated.
• [ ] Two rates reported: of all cases and of AI-handled cases, with denominators shown, and with lower and upper bounds where channels are missing or unknown cases remain.
• [ ] Human reopen rate computed with identical rules for comparison.
• [ ] Human minutes on partial handoffs recorded.
• [ ] Business outcome tracked separately from resolution.
• [ ] Any contractual resolution definition compared against this one, differences listed.

Limits

The specification needs cross-channel customer matching, which some help desks do not provide; where it is missing, report that reopens are measured on one channel, treat the observed reopen rate as a lower bound and the inferred resolution rate as an upper bound. Repeat-contact windows are judgement calls; the goal is consistency over time, not a perfect value. And a resolved case is not a good outcome by definition; keep the business outcome in view.

Related reading

• Building a defensible business case for customer-service AI: where these definitions enter the money.
• First contact resolution: the essential customer success KPI: the human-side metric with its own rules for reopens and transfers.
• Top 10 metrics to track for AI-powered customer success: the wider measurement set.

FAQ