The first thing that breaks when a store starts selling into a second or third country is not the website, the logistics, or the payments — it is the phone. The store that ran fine with one support line and one team suddenly has German customers reaching Czech-speaking agents, Polish callers listening to a menu in the wrong language, and evening calls from a market one timezone over ringing into an office that closed an hour ago. None of this announces itself as a routing problem. It shows up as "customers keep hanging up" and "support says the calls are weird lately."
What breaks when a store grows into its second and third country
The uncomfortable part is that every store already has a routing policy. If nothing was configured, the policy is "every call rings the same place, in whatever order the phone system defaults to" — which is still a decision, just one nobody made on purpose. Growth into new markets does not create the routing question; it makes the cost of the accidental answer visible. The fix starts with saying the policy out loud.
The four dimensions a store's routing actually has
Routing for a multi-market store comes down to four dimensions: country, language, call type, and hours. Most setups that feel chaotic are chaotic because one of the four was never made explicit.
Country is the outermost layer. A caller dialing the store's German number and a caller dialing its Polish number have told you something before anyone answers, and the routing should honor it — different storefronts usually mean different catalogs, prices, couriers, and return rules, so the answering team needs the matching context.
Language sits close to country but is not the same thing. Markets overlap: a store selling into Czech and Slovak markets may serve both with one language queue, while a single market can need two. Routing by language usually means either separate lines per storefront or a short menu choice, and the honest rule is that the menu should be one layer deep. Every additional layer sheds callers.
Call type is the dimension stores borrow from their helpdesk. An order question, a delivery escalation, and a payment dispute want different teams and different priorities, and often arrive with different urgency. Where written channels sort this with tags and views, the phone sorts it with queues — or fails to sort it at all.
Hours are the dimension everyone remembers last. A store selling across even neighboring countries is selling across staggered business days: holidays differ, lunch peaks differ, and an hour of timezone offset moves the evening rush. Routing by hours means deciding, in advance, where a call goes when the primary team is off — not discovering at each holiday that nobody decided.
Failover is order retention, not a technical footnote
Failover answers one question: where does the call go when the place it should ring cannot take it. For a store, this is not an infrastructure detail — a ring that dies unanswered during checkout hours is, qualitatively, an abandoned order walking away. The caller with a payment problem or a stock question is often at the exact moment of deciding whether to buy, and the difference between "someone picked up" and "it rang out" is the difference between a rescue and a silent loss the analytics will never attribute to the phone.
Technically, failover lives at the routing level: when the primary destination does not answer or cannot be reached, the call continues to a second destination — another queue, another office, an on-duty phone — rather than dying where it stood. Providers that run their own routing typically maintain parallel carrier paths of matching quality underneath this, so a failure higher up the chain has somewhere equivalent to land.
Worth a caveat, though: failover preserves the contact, not the full experience. The fallback destination answers the call; it does not automatically know the German catalog or have refund authority. A failover chain is also not free to lengthen — each additional hop keeps the customer listening to ringing, and callers rarely wait through a third. In most cases the honest design is one good fallback that can take a message competently and trigger a follow-up, with expectations set accordingly — order retention means keeping the conversation alive, not pretending the substitute team is the primary one.
Rules, not lines: the fix is policy, not more phone numbers
The instinctive response to routing pain is to buy more numbers — a line per country, then a line per team, then a line per season. Numbers multiply; clarity does not. Ten lines with no policy behave exactly like one line with no policy, only louder, because now the accidents happen in parallel.
The durable fix is a small set of explicit rules that use the four dimensions: which number was dialed decides the market context, a menu or a language line decides the queue, the call type decides the team, and the clock decides the fallback. Written down, a store's entire routing policy usually fits on one page. That page is the deliverable — the phone system is just where it gets enforced.
The rules are the store's to define; enforcing them across carriers, numbers, and a PBX is voice-engineering work that ops teams rarely want to own. Managed voice providers exist for exactly that division of labor — VoipTower, for one, operates numbers and call routing for online retail as a managed layer, with the store keeping the policy and the provider keeping it running; the shape of that setup is described under e-commerce voice infrastructure and in more depth on the call routing service page.
A worked example: one store, three markets
Take a deliberately invented store — a mid-size home-and-garden retailer based in Prague, selling through three storefronts: Czech domestic, Germany, and Poland. The profile is hypothetical; the routing decisions are the real content.
The store publishes one local number per storefront. Rule one: the dialed number sets the market — German-storefront callers land in a German-language queue staffed by the two agents who know the German catalog and courier setup; the Polish line works the same way. Rule two: within each market queue, a single-layer menu splits "existing order" from "everything else," because delivery escalations are the store's loudest call type and deserve the shorter path. Rule three: after local closing, each market's line forwards to the Czech office for the overlap hour, then to a voicemail that promises — and gets — a next-morning callback in the caller's language.
Now the backfire, because one of these rules is a trap in its plausible form. The tempting version of rule one is to route by the caller's own number: German mobile prefix, German queue. It looks right and demos well. In practice it misroutes precisely the callers most likely to need help — the Polish customer who ordered from the German storefront while working in Berlin, the expat with a foreign SIM, the traveler calling about a delivery to a holiday address. Caller-ID geography tells you where the phone is from; it says nothing about which storefront the order lives in. The reliable signal is the number the customer dialed, because customers call the number printed on the storefront they bought from. Routing on the dialed line survives every edge case that caller-ID routing trips over — and the stores that learn this usually learn it from an angry bilingual customer, not from documentation.
The example is small on purpose. Three markets, three lines, one menu layer, one fallback path — and every one of the four dimensions is decided somewhere visible.
Questions to settle before you configure anything
Which storefront's callers wait longest today, and would we know? If hold behavior differs by market, the routing is already misallocated; gut feel usually lags the queue by a season.
Can every market's caller reach a human in their language during that market's business hours — and what exactly happens in the first minute after those hours end? Walk the path as a caller, once per market. The dead spots announce themselves.
Which call type do we most regret missing? The answer decides which queue gets the shortest path and the strongest fallback. For most stores it is the delivery escalation or the payment problem, not the general question.
Where does a call land when the primary queue cannot take it, and what can that destination actually do? A fallback that can only sympathize needs a different script — and a different promise to the caller — than one that can act.
Who can change a routing rule, and how fast, when a courier strike or a holiday reshuffles a market's traffic for a week? Policy that takes a project to change is policy the store will route around by hand.
Where to start
Write the current routing down as it actually behaves — every number, every destination, every after-hours dead end — and hold it against the four dimensions. The gaps will be obvious on paper in a way they never are in the queue, and the one-page policy that comes out of the exercise is the specification for whatever comes next, whether that is an afternoon of PBX configuration or a conversation with a provider. The phone is usually the last channel a growing store designs on purpose. The stores that do it early get something quieter than a feature: calls that simply land where they should, in the right language, at hours someone answers.