AI in customer support: calculating the cost of one resolved request

To calculate AI customer support costs, divide the full costs for the chosen period by the number of customer problems actually resolved. Include model and tool usage, human work, monitoring and corrections. Do not count a repeat contact about the same unresolved problem as a new success. Before comparing an AI pilot with existing service, define resolution and quality conditions identically for both workflows.

A cheap answer can become expensive service if the customer writes again or a staff member must restore incorrectly changed data. Human involvement does not itself mean the pilot has failed. It may be an intended part of the process whose cost and outcome need honest accounting.

Calculating AI costs starts by defining a resolved request

For this calculation, a request is a customer problem with a traceable identity. One conversation may contain several questions, while one question may continue across email, chat and telephone. Choose the unit before the pilot; otherwise ticket-splitting rules may accidentally produce the most favourable result.

For example, a delivery question is resolved when the customer receives correct information applicable to their situation or the required action actually takes place. An automatic conversation-closed status does not establish that. Agree how resolution will be verified: through a system outcome, customer confirmation or a justified manual sample.

Define an observation period for reopening. Its length should fit the problem: delivery tracking and a recurring billing fault may reveal failure at different times. No universal number of days suits every support process. Report recently closed cases whose observation period has not ended separately.

Retain the number and age of unresolved cases in the comparison too. If costly problems remain queued outside the calculation, the cost per closed case may look attractive at the expense of poorer service.

Accounting for repeat contact in AI support

Link repeat communication to the original problem where there is sufficient justification. Do not merge every contact from one customer: they may have a new, independent question. Record a reason, such as an unanswered question, incorrect instruction, new information or a genuinely different problem.

If an AI answer caused additional work, the correction time belongs to the original case. Track human handover through to the final outcome too. One successful handover is not another resolved problem.

An incorrect answer and repeat contact are not synonyms. A customer may never return even after receiving a wrong answer. Quality sampling is therefore needed alongside contact statistics. Preserve the checking method and selection limitations rather than treating a small sample as certainty about every conversation.

Link personal data within the business's defined access and retention boundaries. A cost report usually does not need the customer's full correspondence. Use separate access arrangements for detailed error investigation.

The AI customer support cost basket

Model calls are only one cost item. Show tool and retrieval costs, platform fees, staff involvement, knowledge-content maintenance and technical monitoring separately. For human labour, use the business's agreed hourly-cost calculation consistently across both workflows.

Show development and implementation expenditure separately from ongoing operation. If you allocate it across periods or requests, state the assumption. With a small pilot volume, that allocation can change the metric substantially. Do not replace an assumption with a guaranteed-return claim.

The practical formula is straightforward:

Cost per resolved request = attributable total costs / number of resolved requests.

Alongside it, describe quality and the cases covered. If no requests have been resolved, the metric cannot be calculated. A zero denominator does not mean free service.

A worked example comparing two support workflows

All figures below are invented to demonstrate the calculation, not client results, a quotation or a market benchmark. Both workflows assume 200 comparable incoming cases, of which 180 meet identical resolution criteria within the observation period. The remaining 20 must still appear in the report.

Amounts are rounded to cents. The table deliberately excludes the initial implementation investment; show it separately in a real assessment. The difference in the example is small and does not establish that implementation pays off.

Check that the same working minutes have not been counted in both service and correction. Repeat communication is not a separate outcome here: its costs are allocated to the relevant work items. If the AI workflow had fewer valid resolutions in practice, the denominator and comparison would change.

Compare similar problems and languages

A set of simple opening-hours questions cannot fairly be compared with complex complaints. Group cases by problem type and distinguish where AI answers independently, where it prepares a draft and where it immediately hands work to a person.

Check languages separately where data volume permits. An overall average can hide adequate answers in one language and frequent corrections in another. With a small sample, report insufficient data rather than a precise forecast of apparent savings.

Seasonality and shift workloads also affect comparability. Record which cases were selected for the pilot and which were excluded. Judge both workflows by the same final quality requirement. Speed cannot compensate for unauthorised data disclosure or an incorrect confirmation of a customer action.

When an AI pilot is not economically justified

A pilot can produce many answers without resolving enough problems. If staff spend as long reviewing each answer as they previously spent writing it, any potential benefit must be found in actual data. It cannot be inferred from the number of generated messages.

An unstable knowledge base is another obstacle. Frequent product and process changes may require more maintenance work than expected. This is a cost and process issue, not a reason to lower review requirements.

The decision may be to narrow the pilot to one problem group or keep AI in a staff-assistant role. Before expansion, define an acceptable error level, handover procedure and cost boundary. The business chooses these according to risk, not a universal AI-efficiency metric.

What adoption statistics do not tell you about AI costs

In the CSP survey for 2025, 12.2% of covered enterprises used AI. The survey covers enterprises with at least 10 people employed in specified sectors, not every Latvian microbusiness. Eurostat's enterprise AI-use data provide wider adoption context. Neither source establishes savings for a particular support pilot.

For answer correctness, see measuring RAG system quality. A full investment decision needs an automation return calculation. Cost per resolved question is a separate operating metric to use in that decision.

Frequently asked questions about AI support economics

Is an automatically closed conversation a resolved request?

Only if it meets the business's shared outcome and quality criteria. Closed status alone does not prove that.

Does human handover mean AI has failed?

No. Safe handover may be the intended outcome for a complex case. The calculation must include all work through to resolution.

Is a lower cost metric enough to justify implementation?

Quality, unresolved cases, risk and implementation investment also need assessment. A cheaper but worse service is not an equivalent comparison.

For an AI support pilot assessment, prepare request volumes, current handling time and quality criteria. The starting question is which customer problem the business can resolve safely and at what total cost.