A service team saves time with AI. Advisers write fewer notes, customers receive faster answers and supervisors can review more conversations. Yet the monthly operating cost barely changes.
That does not necessarily mean the technology has failed. It means the business case may have confused three different things: faster tasks, usable capacity and financial value.
Time saved is an input to the calculation, not the conclusion. Its value depends on where it appears, whether the operation can use it and what extra work the AI creates elsewhere.
This distinction is becoming harder to ignore. On 5 October, Computerworld examined the gap between AI productivity and enterprise returns, drawing on research and interviews with McKinsey and Gartner analysts. The issue is broader than contact centres, but customer service provides a concrete place to investigate it: a customer brings a problem, resources are consumed and an outcome eventually follows.
For a leader deciding whether to expand an AI service deployment, the useful question is not simply how many conversations it handles. It is what an appropriately resolved case costs, and whether that cost buys a better service.
Five signals behind the economics question
These are five actionable themes in current research, not a measured ranking of market popularity. The publication dates differ, and the findings should not be treated as directly comparable.
1. Individual productivity is outpacing enterprise financial impact. McKinsey's survey published on 25 August 2026 reports that 80% of respondents say AI improved their individual productivity, while 37% attribute at least some enterprise EBIT impact to AI. These are respondent reports, not audited financial results. They nevertheless reinforce why a business case needs a mechanism connecting task improvements to organisational value.
2. Faster production can move work into verification. DORA's 10 March 2026 analysis examined 1,110 open-ended responses from Google software engineers collected in the third quarter of 2025. It describes time saved in generation being reallocated to auditing, review and integration. This is qualitative evidence from a specific engineering population, not a contact-centre productivity estimate. The relevant question for service leaders is whether their own AI workflow reduces total work or transfers it.
3. AI cost visibility is not the same as value attribution. The State of Tokenomics release candidate published on 23 September 2026 draws on 472 responses across 11 industries. It identifies proving value, fragmented spending visibility and measurement as prominent challenges. Its sample is weighted towards technology and software. The findings are directional survey evidence, not a universal estimate of AI profitability.
4. Accountability is becoming part of economic management. KPMG's 24 September announcement of its Q3 Global AI Pulse Survey says only 12% of surveyed organisations consistently assess AI value against cost, rising to 48% among those reporting established returns. The survey covered 2,131 senior leaders across 20 countries. The association does not establish causation, but it makes ownership of the value calculation a practical leadership question.
5. Training and deployment are not sufficient substitutes for redesigning work. Deloitte's 2026 State of AI report distinguishes surface-level use, process redesign and deeper transformation. Its survey summary reports that workforce education remains a more common response than re-architecting roles and workflows. That is a reminder to specify how the service operation will actually absorb the capability, rather than assume access to a tool changes the operating model.
Together, these signals support a narrower funding discipline: measure a complete unit of service, account for the costs around it and explain what will happen to any released capacity.
Choose the unit before measuring the saving
A conversation is not necessarily a case. One billing dispute can generate a chat, two calls, an email and a back-office adjustment. Treating those as independent units can make each interaction look efficient while the overall journey becomes expensive.
Define the unit around the customer's problem. For example: a disputed bill corrected or explained under the applicable policy; a fault resolved or assigned to an appropriate remediation process; an order enquiry answered accurately with no unnecessary repeat contact.
Some outcomes cannot be completed immediately. A complaint may need investigation or a fault may require an engineer. Measure meaningful progress and final resolution separately rather than labelling a transfer as a completed case.
The FinOps Foundation's unit-economics guidance distinguishes resource-efficiency measures, such as cost per token, from business measures, such as cost per case resolved. Both have a purpose. Token metrics help explain the technology bill; a business unit helps explain what the organisation received for it.
A practical starting measure is:
Cost per appropriately resolved case = attributable operating cost for the defined journey / cases meeting the agreed resolution standard.
The resolution standard matters as much as the numerator. If abandonment is counted as success, or an incorrect account change is treated as completion, a low unit cost becomes misleading. Specify the evidence needed to call the case resolved and the period during which repeat contact or correction will be reviewed.
Avoid pretending the measure is universally comparable. A routine status enquiry and a vulnerable customer's complex complaint have different work content and acceptable service requirements.
Include the work that the demonstration leaves out
The visible AI charge is only one part of the service cost.
Count model use, tool calls, retrieval and infrastructure where they can be attributed. Include relevant platform fees and licences. Then account for human review, escalation, corrections, quality assurance and the operating effort required to keep policies and integrations current.
Separate recurring costs from implementation and change costs. A pilot may carry unusually high setup costs; a production operation may carry commitments not present in the pilot. Show both the marginal cost of another case and the fuller cost of maintaining the service.
Document shared-cost allocations. An arbitrary allocation can make a promising use case look uneconomic or conceal a poor one. The estimate need not be perfect at the beginning, but its assumptions must be visible and stable enough to support a decision.
Consider an illustrative workflow that drafts a service-credit recommendation. The AI prepares the calculation quickly. A reviewer must still inspect the contract and incident record. A failed update may require rework. If those steps are excluded, the apparent saving describes only the drafting stage.
This is where DORA's verification finding is useful as a question, not as a transferable percentage. Observe the work in your own operation. Does the adviser spend less time overall? Does a supervisor now investigate more doubtful summaries? Has the back-office queue grown?
The answer may still favour AI. A better recommendation could prevent errors or improve consistency even without a large labour saving. But the business case should name that benefit instead of hiding extra work.
Turn released minutes into usable capacity
A saved minute is not automatically a minute the business can redeploy.
Savings may be dispersed across shifts, concentrated in low-demand periods or dependent on specialists who remain necessary for other work. If handling time falls but staffing cannot change and demand is unchanged, the immediate cash saving may be small.
That does not make the capacity worthless. It might reduce waiting, allow advisers to complete overdue follow-up, improve quality or absorb growth without adding as much resource. Those are legitimate operational benefits. They should be described and measured as such.
Distinguish four claims: reduced effort, increased capacity, avoided future expenditure and lower current expenditure. They are not interchangeable. A modelled reduction in handling time supports an effort claim; it does not, on its own, support a headcount or payroll claim.
Work with service operations and workforce planning to identify when the gain can be used. Examine arrival patterns, skill requirements, occupancy, shift coverage and exceptional cases. Check whether the remaining work becomes more complex.
Do not count the same capacity twice. If released time is used to improve quality, it cannot simultaneously be booked in full as a cash saving. Likewise, avoided recruitment needs an explicit demand assumption and a comparison with what would otherwise have been required.
The decision is partly about service ambition. Leaders may choose to retain resource and deliver better support. The business case should make that choice visible, not classify it as a failure to capture value.
Compare comparable cases and protect service quality
A before-and-after comparison can be distorted by seasonality, incident volume, staffing, policy changes or the mix of customer problems.
Begin with a narrow journey and a credible baseline. Where practical and appropriate, compare similar groups or use a staged rollout. If a controlled comparison is not feasible, explain the limits rather than attribute every improvement to AI.
Track cost alongside quality and customer outcomes. Useful companions include resolution accuracy, repeat contact, complaint severity, time to resolution and customer effort. Review accessibility and language needs rather than assume an average represents everyone.
Also distinguish fixed improvements from changes in demand. Better self-service may make it easier to ask a question, increasing usage while reducing friction. Higher total spending could therefore coexist with lower cost per resolved case and better service.
Conversely, a cheaper interaction may generate more repeat contacts. The interaction price falls, but the cost of resolving the problem rises.
Set explicit quality constraints. A model or workflow change that reduces cost but produces an unacceptable error rate is not an improvement. The site's AI agent evaluation article addresses release evidence; the economic question here is different: whether a sufficiently reliable service deserves more investment.
Keep non-financial outcomes visible without inventing their monetary value. Faster access to help, more consistent decisions and reduced risk can matter. Where a financial conversion is uncertain, report the operational measure and the uncertainty separately.
Make cost controls part of service design
AI costs can vary with context length, retries, model choice, connected tools and the number of steps needed to complete a task. An average can conceal a small set of unusually expensive journeys.
Attribute usage to the use case and case type, with appropriate privacy controls. Look at the distribution of costs, not only the mean. Investigate whether costly cases are legitimately complex or caught in ineffective loops.
Use spending limits, retry limits and alerts, but design what happens when a boundary is reached. A cap that ends an interaction without a recovery route protects a budget while abandoning the customer.
Consider cheaper models or simpler deterministic steps where they meet the requirement. Do not assume a model router pays for itself: routing introduces its own engineering, operating and quality costs. Compare the complete configuration, including human work, before changing it.
Ask suppliers for usage data granular enough to reconcile charges with workloads. The September Tokenomics survey's emphasis on attribution is useful because a total bill cannot explain which journey drove it.
Give a named owner responsibility for the unit-cost definition and another clear responsibility for service quality. Finance, technology and operations should agree the assumptions together. A dashboard maintained by one team is not shared accountability unless it informs actual decisions.
A 30-day plan before expanding
Week one: define the case and baseline. Select one meaningful journey. Agree what counts as resolution, how repeat contact is identified and which costs belong in the calculation. Record current service performance and the limits of the available data.
Week two: instrument the complete workflow. Capture attributable AI usage, review effort, escalation and rework. Separate setup expenditure from recurring operation. Test whether cost records can be reconciled with the provider bill.
Week three: establish the capacity mechanism. Ask operations what happens to released effort. Is it absorbed by demand, used for better follow-up, converted into avoided recruitment or reflected in a staffing change? Put the assumptions in writing.
Week four: make a bounded funding decision. Review unit cost, quality, customer outcomes and the proposed use of capacity together. Expand only where the evidence supports it. Narrow or stop a use case that consumes more resource than its benefit justifies.
For broader questions about applying AI in service operations, the primary next step is the customer experience AI page. The objective is not to automate every interaction. It is to choose service changes that remain useful when their full operating consequences are visible.
Fund the outcome, not the activity
AI can improve a task without changing the economics of the service. It can also improve the service without immediately reducing expenditure.
Neither result should be forced into an exaggerated savings claim. Leaders need to know which benefit is real, which is modelled and what operational change is required to capture it.
Start with a defined customer problem and a defensible unit of resolution. Include the work around the AI, explain what happens to capacity and hold service quality constant enough to interpret the result.
That turns an attractive demonstration into an investment decision. The question is no longer whether the system produces answers cheaply. It is whether the organisation can resolve the right problems at an acceptable cost, with a service its customers can trust.