One Business, Different Countries: Why One Answering Config Fails
A team configures an agent for their home market, it works well, and then they launch it in a second country. Suddenly the same system produces complaints that make no sense: people call during "closed" hours, ask for pa
A team configures an agent for their home market, it works well, and then they launch it in a second country. Suddenly the same system produces complaints that make no sense: people call during "closed" hours, ask for payment methods that are not offered, and get routed to a person who is asleep.
Nothing is broken. The configuration was built for one market and copied to another.
What is actually local
Five things differ by country in ways that affect a phone agent, and all five are easy to miss:
1. Working hours and weekends. The working week is not Friday-to-Monday everywhere. A configuration that assumes a SaturdayβSunday weekend will misroute calls in a large part of the world, and the failure looks like "the agent is down on Sundays" rather than "the weekend is different here".
2. Public holidays. Even within one country, regional holidays matter. An agent that greets with "we're open today" on a national holiday damages trust faster than being closed.
3. Language, and the version of it. Answering in the right language is table stakes. Answering in the right variant is the difference between sounding professional and sounding foreign β and a customer who hears the wrong variant often switches to English, which defeats the purpose.
4. Payment and cancellation expectations. "Pay on arrival", "invoice", "direct debit", "cash on delivery" β availability varies. So does the cancellation norm: a 24-hour policy that is standard in one market reads as unreasonable in another.
5. What "escalate to a human" means to the customer. In some markets, reaching a person is expected and any friction is unacceptable. In others, a callback within an hour is completely normal. The same escalation design is either generous or insulting depending on where the caller is.
What should stay global
The temptation, once you have noticed the differences, is to localise everything. That is worse β it produces five systems nobody can maintain.
Keep these global:
- The knowledge about your product. Facts do not vary by geography unless they genuinely do.
- The brand voice. How you speak should not fragment; what you promise can.
- The escalation logic. How a judgement reaches a human should be consistent, even if the destination changes.
- The quality bar. The same coverage and the same refusal rules everywhere.
Localise inputs β hours, holidays, language, payment methods, callback expectations β and keep behaviour constant.
The routing question most people miss
If you operate in several countries, which agent answers a call?
Three models, and each has a cost:
- One agent, language-detected. Simplest to maintain, hardest to tune. It must speak every language well, and it must know which policies apply to whom.
- One agent per country. Cleanest behaviour, most maintenance. You now have N knowledge bases, and they drift.
- One agent, country-routed. A front door that identifies the market and hands off to a country-specific agent. More moving parts, but it keeps each agent narrow.
The second and third have the same trap: the knowledge bases diverge. If your German agent says the return window is 14 days and your French one says 30, that is not localisation, that is an inconsistency that will be found.
The holiday problem, specifically
A concrete example of how this goes wrong.
An agent is configured with opening hours and no holiday calendar. On a public holiday the office is closed but the agent says "we're open 9 to 5" and books an appointment for that day. The customer arrives at a locked door.
The fix is not clever. It is a calendar that someone actually maintains, and a rule: when the calendar is uncertain, the agent should say it will confirm rather than assert.
That rule is worth more than the calendar, because calendars drift.
A per-market checklist
Before enabling a country, confirm:
- Working days and hours, including the local definition of a weekend
- Public and regional holidays for the next twelve months
- Which language variant, and whether code-switching is expected
- Payment methods offered, and cancellation terms
- Whether a callback is acceptable, and within what window
- Which number customers will see, and whether it looks local
- Who receives an escalation, and in which time zone
Seven items. Most of them are not technical, and all of them are cheap to fix before launch and expensive after.
The honest part
Going international with an agent is mostly not an AI problem. It is an operations problem: knowing your own hours, your own policies, and who is on call.
The teams that do this well treat each market as a small launch β a checklist, a test call, a read of the first week's transcripts. The teams that do it badly change the country setting and assume the rest follows.
The customer, of course, only notices the second kind.
Disclosure: I work on RingBot, an Agent-as-a-Service platform where numbers can be provisioned in most countries, language handling is configurable per agent, and routing can be country-aware. None of that replaces knowing your own local hours and policies.
Related: transfer is five features, when to hand off, the handoff brief, identity checks.
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.