The most consequential moment in an AI-supported service journey may be the moment the AI stops.
A customer has explained a problem, perhaps twice. A system has gathered details, offered a suggestion or started a transaction. The next step may belong to a human adviser, a back-office team or another system. If the context or responsibility does not travel with that step, a fast opening becomes a slow service experience.
Five developments in September 2026 make this a useful leadership question rather than a theoretical one. A telecoms provider is introducing AI voice support for selected calls. Another is using AI within a refund workflow. A contact-centre vendor has announced live translation for voice conversations. University researchers have challenged the assumption that more human-like AI always produces a better experience. Workforce research points to a gap between AI deployment and redesign of the jobs around it.
These are different kinds of evidence: company announcements, product plans, academic findings and a survey. None establishes a universal return on investment. Taken together, they suggest that the next useful unit of design is not the bot. It is the complete service journey, including the boundary where a machine's work becomes someone else's responsibility.
Five signals worth watching
1. Voice AI is moving into a narrower, measurable service journey. On 24 September, Virgin Media O2 announced an AI voice agent for selected broadband fault calls. It says the initial scope is a small proportion of call volume, that customers can still speak to a person, and that teams will monitor calls and customer feedback. This is an operator's announcement of a gradual launch, not independent evidence that the service has improved. The interesting design choice is the bounded entry point and explicit human option.
2. AI is entering the work behind the conversation. In a 22 September announcement about Telstra's use of Agentforce, Salesforce described an interim-service workflow that validates eligibility, calculates refund amounts, monitors restoration of a fixed service and applies the refund while updating records. Salesforce says the workflow supports more than 1,000 contact-centre representatives. Those are vendor-reported details, not an independent outcome study. They nevertheless show why service design must extend beyond the chat or call: the consequential event is an accurate change in the underlying systems.
3. Language access is becoming part of the live agent workflow. Zendesk announced real-time, two-way voice translation on 10 September. Its announcement says agents can switch translation on or off and administrators can choose whether original or translated audio is retained. The company said availability would begin in October through a closed early-access programme for eligible customers, so this is not a claim of general availability or proven service outcomes. It does, however, put routing, consent, accuracy and recording policy into the same operational conversation.
4. A more human-like interface is not always the kinder one. On 2 September, a University of Queensland researcher summarised studies of customer responses after service failures. In some situations, participants using text chat rather than voice reported greater relief; in separate work, accurate recognition of a customer's emotion improved responses to an artificial service agent. The author does not argue that text is always better than voice. The lesson for leaders is to test the interaction against the emotional state and task, rather than assume conversational realism is a universal measure of quality.
5. Workforce design is lagging technology ambition. Protiviti's 2026 AI Pulse Survey, volume five, reports that 13% of chief human resources officers strongly agree their organisations are ready for role redesign, compared with 36% of IT leaders. The figures describe respondents' perceptions, not an audit of actual readiness. The gap is a warning: if more difficult cases flow to human teams while their roles, tools and training remain unchanged, a deployment can shift work without improving service.
The handoff is a product feature
Handoff is often treated as a fallback. A customer asks for a person, the AI cannot answer, or a confidence threshold is crossed, and the interaction is transferred. That is too narrow. In a functioning service operation, a handoff is a designed exchange of context, authority and ownership.
Context means the next worker knows what the customer asked, what the AI said, what was checked, and which facts remain uncertain. Authority means the recipient knows what action they can safely take. Ownership means somebody is accountable for the issue until it is resolved, even when work crosses teams or channels.
Consider a broadband fault. The AI may confirm an outage and offer troubleshooting. A human adviser may need to decide whether the case warrants an engineer, a credit or additional support for a vulnerable customer. If the adviser receives only a transcript, they still have to reconstruct the customer's situation. If they receive a confident but incorrect summary, the risk is worse: a false premise can move quietly into the next decision.
The right handoff package is therefore not simply "conversation history". It is a structured record: the customer's stated goal; verified account and service facts; actions already attempted; the source and time of each relevant system check; any uncertainty; and the reason for escalation. The adviser should be able to inspect and correct it. Sensitive information should be restricted to the people and systems that need it.
For higher-risk decisions, the handoff also needs a visible approval boundary. A system can calculate a proposed refund or draft an exception. It should be clear who authorises the final action, which rules were applied and what will appear in the customer's record. These are product requirements, not compliance notes to add after launch.
Choose the boundary by consequence, not by technology
An AI interface can be excellent at answering a standard question and still be unsuitable for making a discretionary decision. The decision to automate should follow the cost of being wrong and the ease of putting things right.
A low-risk journey might involve explaining an existing order status from a verified source. An intermediate case might let AI collect evidence and recommend a next step while a person approves an account change. A high-impact case might involve financial hardship, disputed charges, bereavement, accessibility needs or the possibility of interrupted essential service. In those cases, the system may help prepare the work, but the route to a trained person must be straightforward.
Not every escalation begins with a model reporting low confidence. Customers know things the system cannot see. They may need an exception, distrust a previous answer or simply want someone to hear a sensitive issue. An effective design accepts the customer's request to switch channels or speak to a person without treating it as failure.
The Virgin Media O2 announcement is useful here because it describes a narrow launch and an available human route. Leaders should still ask what that route feels like in practice. Is it discoverable? Does the adviser know what happened? Does the customer have to repeat information? A stated escalation policy is not the same as a successful escalation experience.
Likewise, the Telstra example shows the appeal of connecting AI to fulfilment. It also points to the control questions any such system must answer: Which data source determines eligibility? What happens if restoration status changes after a refund is calculated? How is a failed update detected, reconciled and explained to the customer? The published announcement does not settle those questions for other organisations. Each implementation must.
Measure resolved journeys, not contained conversations
Containment can tell a team whether a customer stayed within an automated channel. It cannot, on its own, tell them whether the customer got what they needed.
An interaction may count as contained because the customer abandoned it. A customer may receive a correct explanation but still need to call again because an account change did not happen. A transfer may be the right outcome when a complex issue reaches a specialist promptly with its context intact.
A more useful scorecard follows the journey across systems and people. Measure:
- Verified resolution: whether the underlying issue was resolved, not merely whether an answer was delivered.
- Repeat contact: whether the same issue returns after an apparently successful interaction.
- Handoff quality: how often context is complete, accurate and usable on arrival.
- Time to safe resolution: the elapsed time to an appropriate outcome, including any rework.
- Customer effort and access: repetition, failed routing, difficulty reaching a person and the experience of customers using other languages or accessibility support.
- Frontline load: case complexity, after-call work, decision burden and escalation volume, not only the number of calls handled.
Break these measures down by journey type. A routine status enquiry, a billing dispute and a sensitive complaint should not be judged by one threshold. Also inspect a sample of failed and apparently successful cases. A high-level dashboard can hide errors that only emerge in the account record or in the next conversation.
This is why a translation feature requires more than a demonstration of fluency. A leader needs to understand whether a translated promise matches the actual policy, whether the customer understood the proposed action and what record an adviser can review if the translation is disputed. Zendesk's announced controls around audio retention are a reminder that the operational record is part of the product.
Redesign the human job at the same time
When automation takes routine interactions, the remaining human work changes shape. Advisers may handle fewer simple questions and more exceptions, emotional conversations and cross-team decisions. A staffing plan based only on lower volume misses the harder part of the work.
Supervisors need new ways to spot when an AI summary is misleading, when a customer is being cycled between channels, and when an apparently resolved case has generated a repeat contact. Quality teams need access to the complete journey, with appropriate privacy controls, rather than evaluating only a call recording or chat transcript.
Frontline staff should help define the transfer rules before they are asked to absorb the exceptions. Ask them which cases require judgement, which system checks they repeat, and which notes would actually help at the start of a transferred interaction. Train them to challenge AI-produced summaries, not to regard them as verified evidence.
The workforce question is not limited to training people to use a new tool. It includes decision rights, job design, escalation capacity, quality assurance and feedback into the product team. The Protiviti survey reflects an executive perception gap on role redesign; a service leader can test the issue locally by looking at what the workday now contains and whether people have the authority and support to do that work well.
The University of Queensland account of customer-service research adds another caution. A slick voice interaction can feel impressive in a demonstration while being the wrong medium for a frustrated customer. Include customers and advisers in testing, and test stressful, ambiguous cases as well as straightforward ones.
A practical 30-day starting point
You do not need to redesign every channel at once. Pick a single journey with real volume, a clear outcome and a known escalation path. A broadband fault, a delayed order or a simple service credit may be suitable; the choice depends on your operation.
In the first week, map the journey from first contact to verified outcome. Include the systems that hold the truth, the people who approve exceptions, and the moments at which the customer must repeat themselves. Gather examples of failed transfers, not just average handling times.
In the second week, specify the handoff contract. Write down which fields an AI system may collect, which facts must be checked against a system of record, how uncertainty is represented, who receives the case, and what constitutes a successful completion. Decide how customers can request human help at any point.
In the third week, test the journey with advisers and a small set of realistic cases. Include an incorrect account match, unavailable data, a change in eligibility, a frustrated customer and a request to switch language or channel. Observe whether the human recipient can see and challenge what the AI has done.
In the fourth week, review verified outcomes, repeat contacts and frontline load alongside speed and containment. If the journey is better for customers and manageable for staff, expand carefully. If not, change the boundary, not just the prompt.
For a broader assessment before launch, the site's contact-centre AI readiness guide covers the surrounding data, workflow and governance questions. For leaders choosing where to apply AI in live service operations, the customer experience AI page is the primary next step.
Better service is the outcome
The current wave of announcements makes it easy to ask how many interactions AI can handle. That question matters operationally, but it is incomplete.
The more important question is whether the organisation can carry a customer problem from first contact to an accurate, humane and accountable resolution. AI can gather context, translate speech, guide an adviser and execute bounded steps. People can exercise judgement, manage exceptions and take responsibility for the outcome. The design challenge is to make those contributions work together without making the customer coordinate them.
Start with one journey. Give the transfer point as much attention as the AI response. Then judge the result by what happened to the customer's problem, not just what happened inside the bot.