Rolling a Bot Out to a Second Country: A Checklist

The first bot got built with everyone watching. Requirements argued over line by line, the knowledge base assembled document by document, someone senior reading every single answer before launch. The second one? Different reception entirely. It looks like a copy job. A duplicate with the language swapped. And that assumption is exactly where second-market rollouts fall apart.

A second market is not a translation project. It is a second product that happens to share parts with the first. The knowledge base diverges, the phrasing diverges, the opening hours diverge, the escalation path diverges - but rarely at the same moment, which is why the drift goes unnoticed until customers start complaining.

I’ve seen enough failed second rollouts to know the shape of them. Either the answers are factually correct but delivered in a register nobody local actually uses, or the tone lands perfectly while wrapping policies that do not apply in that country. This is written for teams already running one working bot who are about to duplicate it, a stage that comes up often across our digital transformation posts.

Decide What Is Shared and What Is Local Before You Copy Anything

Draw the line once, in writing, before you duplicate a single document. Retrofitting the split after both markets are live is the expensive version of this task, because by then nobody remembers which answers were deliberately localised and which just drifted.

Shared covers product descriptions, how the thing works, technical specifications, brand voice guardrails and scope limits - the list of questions the bot must refuse to answer. Local covers pricing and payment methods, delivery timelines, returns and warranty wording, legal notices, contact routes and holiday calendars.

The category people forget sits between the two: content that looks universal but is not. Shipping promises and support hours get embedded inside FAQ answers that otherwise read as pure product information. One rule catches most of them - if a sentence contains a number, a date, a currency or a promise, treat it as local until someone proves otherwise.

Scale changes the answer here. A small team can maintain one master source set with market-specific overrides and keep it in their heads. An operation with separate country P&Ls should give each market its own knowledge base and sync the shared core deliberately, on a schedule, rather than hoping edits propagate correctly. Hope is not a sync mechanism. The mechanics of adding a second language to an existing bot are worth reading alongside this split, because the configuration decisions follow from it.

Translated Sources Versus Locally Written Ones

Translation works fine for factual, stable material: specifications, step-by-step instructions, product definitions. That content answers the same question regardless of who asks it, so a good translator produces a good result and you move on.

Where it falls over is when the local customer asks a different question rather than the same question in another language. Here is the trap in concrete form. Your FAQ was built around the questions your first market asks. Then it got translated word for word. The new bot now holds excellent answers to questions nobody in that country types.

So split the work. Translate the reference material, then write the FAQ and the guided conversation flows locally, from real inbound tickets in that market. Getting the local question list is cheaper than teams assume - pull the last few months of support emails and chat transcripts from that country, cluster them by intent, write against the clusters. Boring work, but it takes an afternoon, not a quarter.

Local Phrasing of the Same Question

Same intent, different vocabulary. Customers in the new market name your product, the process and the problem differently - sometimes reaching for the English term, sometimes a local one, sometimes a competitor’s brand name used generically. All three need to resolve to the same answer.

Regional variation inside a single language matters more than most teams expect, and formality conventions differ sharply. Some markets treat formal address as basic courtesy. Others read the exact same wording as cold and bureaucratic. That call belongs to someone who lives there, not to whoever signed off on market one.

For voicebots, this is a recognition problem as much as a wording problem. Speech recognition degrades first on place names, street names, product names and anything spelled out letter by letter - and those are precisely the details a support conversation turns on. Test with people who speak the language daily in that country. Not with a bilingual colleague from head office who already knows what the bot is hoping to hear.

Opening Hours, Holidays and the Handoff Gap

The bot runs continuously. The humans behind it do not. The mismatch surfaces first on public holidays the head office does not observe, when the escalation queue quietly stops moving and nobody notices for a day.

Build the local holiday calendar before launch, including regional holidays that vary within a single country, and decide explicitly what the bot says when it cannot reach anyone. There is time zone drift to plan for too: a support team covering two markets loses the comfortable overlap that made the first rollout feel effortless.

Handoff to a person is general practice worth planning for. The part teams underprepare is the message given when handoff is not available right now. A clear “we will reply by X” beats a promise that goes unanswered overnight.

Then the question most teams skip entirely: who answers when the escalation target does not speak the customer’s language? Three realistic answers. Staff the market locally. Route to a shared team working in a bridge language and say so upfront. Or restrict the bot’s scope in that market to what it can fully resolve alone. Which of the three you can afford usually comes down to how the rollout is resourced, and our implementation packages set out what that support looks like in practice.

The Pre-Launch Checklist

Go/no-go items before the second market goes live. Anything unticked is a decision you are deferring onto customers.

• Local knowledge base loaded and reviewed by a native speaker who works with customers, not only by a translator.
• FAQ and guided conversation paths written from local ticket data, not translated from the first market.
• Bot name, tone and scope configured separately for the new market in the admin panel.
• Holiday and opening-hours calendar set for the new country, including regional variations.
• Escalation route defined in writing, with a named language for the receiving team and a stated response time.
• Twenty to thirty real local questions tested end to end, including misspellings, dialect wording and, for voice, accented speech and local place names.
• Shared-versus-local content split documented, so the next update does not silently overwrite market-specific answers.
• A named owner in the new market who reads conversations weekly through the first month.

After Launch: Reading the New Market’s Conversations

The opening weeks in a second market produce the most useful material you will ever collect about how local customers phrase things. Treat conversation review as scheduled work with a name against it, not as firefighting when something goes visibly wrong.

Two things deserve attention. First, questions the bot answers confidently but incorrectly for that market - these are the dangerous ones, because confidence hides them from casual review. Second, questions the first market never asked at all, which tell you where the local FAQ still has holes.

Feed those gaps into the local knowledge base rather than patching the shared core. Edit the core to fix a local problem and you drag the first market’s answers out of alignment, usually without anyone connecting the two events. Weeks later, someone in market one asks why an answer changed. Nobody knows.

Reviewing transcripts and measuring outcomes is a discipline your team runs, using whatever analytics tooling the business already has. The bot side of it is simply keeping sources current. Set a review cadence, and set a rule for promoting a local answer into the shared core once both markets need it.

Treat the Second Market as a Rehearsal for the Third

The real return on a disciplined second rollout is the template it leaves behind. Markets three and four should cost a fraction of the effort, because the hard thinking has already been done and written down. That compounding rarely shows up in the business case.

Not running a bot yet? Then the useful starting point is to build the first one properly, with the shared-versus-local split in mind from day one, so that market two becomes a duplication rather than a rebuild. If you would rather scope that split with someone first, talk to us about a pilot. Registering gives you a free first voicebot, which is a low-risk way to test the approach before you commit a second market to it.