When the Chatbot Speaks, But the Service Doesn’t
Why multilingual AI is an omni-channel architecture question, not a translation feature
September, 2026
In 2001, when I first launched the small digital agency that later became Lava Digital / Wolf Interactive, I had what felt like a bold idea.
Make our own website multilingual.
The internet was still young enough that this felt exciting. A small business in Australia could look a little more global. Digital was not just a brochure. It was becoming a communication layer that could travel across geography, market and language.
In practice, it was also a little mad.
Money was tight. Every update meant a translation specialist, duplicated content and more patience than the project budget warranted.
It was thoughtful. It was expensive. It was clunky.
It did not last.
Looking back, the ambition was right. The operating model was not ready.
That is why the current multilingual AI moment is so interesting. AI has changed the cost curve. A capability that once required translation providers, duplicated content and a lot of patience can now appear inside a chatbot almost instantly.
But the operating model question has not disappeared.
It has moved further into the service.
The Shift
AI can make the conversation multilingual before the service is.
A customer can ask a question in Vietnamese, Arabic, Mandarin, Cantonese or Punjabi and receive a fluent answer in return. A live chat can translate both sides of the exchange. A contact centre agent can receive an English summary of a multilingual conversation. A knowledge base can be searched in one language and answered in another.
Useful for simple queries, certainly.
For low-risk interactions - opening hours, appointment times, order status - it genuinely helps.
The problem starts when leaders mistake the conversation for the service.
Modern service rarely happens in one neat interaction. It moves across websites, portals, forms, documents, payments, records, call centres and human escalation.
The chatbot may speak.
The service may not.
That is the Channel Cliff: the drop-off between translated guidance and service completion.
The customer gets a fluent answer, then hits an English-only form. The AI conversation ends neatly, but the portal still asks for a declaration the customer cannot confidently understand. The chatbot explains a process in-language, but the escalation lands with an agent who receives a compressed English summary and very little context.
The conversation gets better.
The service layer underneath does not move.
The Real Tension
The risk is not the conversation.
It is what happens when the conversation ends.
A multilingual chatbot can explain how to apply for hardship support. That does not mean the hardship application can be completed in-language.
An assistant can describe an insurance claim process. That does not mean the policy wording, evidence requirements, dispute pathway or case record can travel with the same clarity.
A council, utility or insurer may offer multilingual guidance at the front door while the path to completion stays stubbornly English-first.
That is the point where a service quietly stops working and no one logs it.
This is also where dashboards can become a little too comforting. Chatbot volumes are up, language selections are visible, and the containment metrics look clean on a slide.
Lovely.
But containment is not completion.
A closed conversation is not the same thing as a resolved service.
Some organisations look at low interpreter requests and assume the need is low. It may not be. People may be getting by with children, relatives, carers, bilingual neighbours or community workers. Others may be leaving before the organisation ever records a failure.
There is a difference between a community that does not need language support and a community that has stopped asking for it.
The Ripple Insight
The first failure is not translation quality.
It is assuming the translated conversation means the service has been translated too.
That is the part leaders need to look for.
Not the demo. Not the vendor slide.
The drop-off.
The moment English reappears. The moment context thins out. The moment the customer is left guessing or waiting on an agent who received a summary, not the conversation.
In private enterprise, it shows up later: abandoned applications, unresolved complaints, and repeat contact that gets treated as a channel problem rather than a language one.
In public and regulated services, the stakes are different: hardship, housing, consent, claims, care, safety, schooling and eligibility.
And then there is the shadow workforce that rarely appears on a dashboard.
A teenager helping a parent navigate a portal.
A grandchild explaining an aged-care form.
A community worker explaining the same bill for the third time that week, while appearing on nobody’s operating model.
That may keep the household moving.
It should not become the service model.
When a service quietly depends on a fourteen-year-old to interpret a legal obligation, that is not digital-first.
It is an unmanaged operating risk.
The user of the portal may not be the person carrying the consequence.
The task is not interface translation. It is making sure the person affected can understand, act, challenge and finish.
The Move
Most teams start with the language question:
what languages do our customers speak?
It is a fair question. It is just not enough.
The more useful question is:
what did customers who speak those languages actually complete?
Map the multilingual journey by service completion, not language availability.
Start with one important journey - hardship, eligibility, dispute or essential service interruption.
Follow it from the first in-language interaction to the final outcome. Where does English reappear? Where does the handoff lose context? Where does the record need to show what was said, understood and acted on?
Not every interaction needs the same level of design.
Checking an appointment time is not the same as agreeing to a payment arrangement. Asking where to upload a document is not the same as consenting to care, disputing a decision or accepting a legal obligation.
AI translation is useful where the consequence is low and the error is recoverable.
It needs more care where the journey involves money, access, safety, consent, dispute or essential support.
The advantage will not go to the organisation that speaks the most languages.
It will go to the one that can explain, resolve and audit in them.
The organisations that get this right will know exactly where the multilingual experience stops.
Because the future of multilingual AI will not be decided by how many languages appear in a dropdown.
It will be decided by whether customers can complete the service the chatbot helped them start.
Executive note for leaders
Before approving multilingual AI in a service channel, ask:
what can the customer actually complete?
Look past the language dropdown, chatbot demo or translated first response.
Follow the journey to the form, portal, handoff, record, payment, escalation and final outcome. Find where English reappears, where context disappears, and where someone else quietly has to finish the task.
A fluent conversation proves the front door can speak.
Service progress proves the organisation can explain, resolve and audit in the customer’s language right through to completion.
Subscribe
You can subscribe for free. Every edition is delivered directly to your inbox and published here on Substack.
If a piece raises a question, surfaces a pattern, or helps you think more clearly about a decision, I’d value the conversation.
Thanks for reading,
Stuart Gonsal MAICD
With occasional help from Springsteen, my Border Collie, who reminds me that clarity comes from movement 🐾.
Connect
LinkedIn – Follow for practical leadership in the AI era. ↗
Disclaimer
Everything shared in The Ripple Effect reflects my personal views and does not reflect those of my current or past employers, clients or partners. Any examples are illustrative, drawn from publicly known patterns or anonymised experience.