How to Measure AI Ticket Resolution Rate
Calculate AI ticket resolution with a declared case unit, denominator and confirmation rule. Separate Niwa answers, assisted replies and repeat contacts.
Measure AI ticket resolution rate by dividing cases resolved by AI under a defined evidence rule by the relevant case denominator, then multiplying by 100. State whether the denominator includes all eligible cases or only cases the assistant attempted. With Niwa, log what happened after a website answer or support email so you can separate a useful reply, a customer-confirmed result and work completed with human review.
A conversation ending is not proof that the problem was solved. Your calculation needs a consistent case unit, an outcome definition and a way to recognize the same problem when the customer returns.
Define a case before counting outcomes
Decide whether a case means one helpdesk ticket, one conversation or one customer problem. For a SaaS workflow, a problem-based case can keep a website chat and the later support email together. Use a stable identifier and retain the related channel records.
If one ticket contains two unrelated requests, define how your reporting treats them. You might retain the ticket as one unit and require both tasks to be complete, or create separate problem records. Either can be workable, but switching between them changes the rate without changing service quality.
The Niwa SaaS support guide describes the distinction between answering a question and completing a support task. Keep that distinction in your reporting unit. Do not count each message in a long conversation as a separate opportunity to resolve a case.
Declare the eligible population
Write the automation scope before reviewing the results. It might cover documented onboarding and feature questions, while account-ownership disputes and technical incidents remain with your team. Keep the excluded cases visible in a separate count.
Record how many eligible cases arrived and how many Niwa actually handled. The gap could reflect channel coverage, operating hours or a configuration problem. A high success rate among a tiny attempted group does not tell you how much of the overall support workload the workflow addresses.
Do not move failed attempted cases outside the denominator after seeing their outcomes. If a case fitted the declared scope at arrival, retain it under that rule. Explain genuine scope changes and use comparable periods when assessing progress.
Choose evidence for resolution
For a guidance task, customer confirmation that the steps worked is a useful evidence rule. For a supported account action, inspect the resulting application state and whether the required task was completed. A tool invocation or a ticket status change alone may not establish the customer's outcome.
Keep distinct labels for confirmed resolution, unconfirmed ending, human escalation, assisted completion and unresolved work. A person checking and authorizing a Niwa email reply makes that case assisted support, even if the reply ultimately solves the problem.
Intercom's reporting documentation distinguishes confirmed resolution from assumed resolution when a customer leaves without requesting more help or giving negative feedback. Use the vendor's actual definitions when reading its charts. Do not equate an assumed outcome with your own customer-confirmed measure.
Calculate both coverage and resolution
Use these three calculations with the same case definition and reporting period:
- AI coverage rate = eligible cases attempted by AI divided by all eligible cases, multiplied by 100.
- Customer-confirmed AI resolution across eligible cases = cases resolved by AI with customer confirmation divided by all eligible cases, multiplied by 100.
- Customer-confirmed resolution among AI-attempted cases = those confirmed AI resolutions divided by AI-attempted cases, multiplied by 100.
The first measures reach. The second measures the contribution to the eligible workload. The third measures the outcome among attempted cases. Present the underlying counts beside each percentage so readers can see which question it answers.
If you use verified task execution as another evidence category, label it explicitly. Do not quietly combine it with customer confirmation and continue calling the combined number a customer-confirmed rate.
Work through a hypothetical cohort
Suppose 500 eligible support cases arrive in a reporting period. AI handles 300; the remaining 200 go directly to your team. Of the 300 attempted cases, 150 customers confirm success, 90 conversations end without confirmation and 60 need human support.
Coverage is 300 divided by 500, or 60%. Customer-confirmed AI resolution across eligible cases is 150 divided by 500, or 30%. Among AI-attempted cases, it is 150 divided by 300, or 50%.
Combining the 150 confirmed and 90 unconfirmed endings gives 240 cases, but calling all 240 confirmed resolutions would misstate the evidence. Keep the 90 unknown outcomes separate unless later information establishes what happened.
These numbers demonstrate the calculations. They are not Niwa customer results, a recommended target or a universal benchmark. Your own scope and case evidence determine which rates are useful.
Reconcile customers returning with the same problem
Choose a review window that fits the task. In this example, use seven days after the initial outcome to look for repeat contact about the same issue. That is an illustrative reporting choice, not a mandatory industry standard.
Suppose 15 of the 150 initially confirmed cases return unresolved during that window. Keep the original confirmed count for transparency and also show the durable outcome after reconciliation: 135 out of 500 eligible cases, or 27%. Explain the reclassification rather than deleting the returning cases.
Allow the cohort's review window to finish before comparing it with an older cohort. Today's apparently resolved cases have had less time to return than cases from two weeks ago. Separate a new issue from a recurrence of the original problem using the case history and a person's review where needed.
Inspect cases alongside the dashboard
Review a sample of confirmed, unconfirmed, escalated and assisted cases. Inspect the source, answer, customer reaction and actual action result where relevant. Zendesk's conversation-log documentation illustrates case-level review for its AI agents. Use the equivalent records available in your support process.
A useful log includes case ID, request type, arrival time, entry channel, AI involvement, human involvement, outcome evidence and repeat-contact status. Keep personal data access limited to the people who need it. A summary report does not need to reproduce private conversations.
Niwa can answer from website knowledge and assist the owner through a connected support mailbox. The setup handbook explains those connections. Reconcile website answers and support email outcomes in your existing helpdesk, case log or reporting system.
Use the measure to choose a support change
Low coverage calls for a channel or scope review. Poor outcomes within a documented task call for source and workflow checks. A high repeat-contact count suggests the first answer may not have solved the underlying problem. Review staff correction time alongside the resolution numbers.
For an existing WordPress site, the standalone Niwa plugin is an available starting point. Niwa Business is USD 150 and includes a custom WordPress website or migration, hosting, maintenance and AI tools adapted to your business. Supported own-subscription connections have no extra Niwa AI usage fees or Niwa-imposed caps; provider terms and limits still apply, with separate API charges possible.
Discuss your reporting setup with Niwa using a redacted case sample and the outcome definition you want to track. Confirm the required connections, scope and billing terms. Agree on the counts and evidence before choosing a resolution target.
