Scaling Scan & Go to 9 Countries: The Operating Playbook Behind a 12-Month Rollout

Twelve months. Nine countries. One mobile checkout product going from a single-country pilot into the daily routine of millions of grocery shoppers across MENA. The headline metric — 60% faster checkout — is the part that lands on slides. The part that decides whether the rollout actually sticks is everything underneath it.

I led the multi-country expansion of Scan & Go at Carrefour (Majid Al Futtaim Retail). What follows is the operating playbook we used: how we picked countries, what the platform had to do before we could scale it, and the blast-radius rules that kept a production rollout from torpedoing peak-hour sales.

The unlock isn't the app. It's the launch unit.

A scan-and-go app on its own is a feature. A scan-and-go rollout is a fully-formed launch unit: app + payments rails + store-ops change + loss-prevention controls + customer comms + support runbooks + measurement. If any one of those is missing in a country, the feature underperforms and the post-mortem points at "the app" — when in reality the gap was somewhere upstream.

Our first job, before any country-2 conversation, was to define the launch unit. Concretely: what does it take to turn this on in a new country in eight weeks without paging the central team every day for three months after?

Country selection is a portfolio decision, not a popularity contest.

Every country team wants to be next. The instinct is to sequence by whoever shouts loudest or whoever has the warmest CEO relationship. That instinct is wrong.

The criteria that actually mattered for us:

• Payments readiness. The local payments rail and the card-present rules in-country drive 70% of the integration work. A country that needs a new acquirer, a new tokenisation scheme, or local-only wallets is a different project, not a copy-paste.
• Store-ops maturity. Hypermarkets with stable shrink baselines and reliable store-manager tooling absorb a new checkout mode much faster than stores still firefighting on the basics.
• Volume + behaviour fit. High basket size + frequent mid-week shop = scan & go is a daily-use product. Low basket size + weekend-only big shops = scan & go is a curiosity.
• Country team capacity. We never launched into a country whose ops team was already past their commitment line. The rollout looks like a software project; it lands like an operational one.

Score every candidate country on those four. Sequence by score, not by executive enthusiasm. The countries that scored low aren't "no" — they are "later, after we fix X." That distinction protects relationships and protects velocity.

Build the boring layer first.

The technical part that mattered most for scaling was the part that is the least exciting to demo: a configuration layer between the app and the country. Currency, tax rules, payment methods, receipt format, loyalty integration, refund flow, support phone number, language bundle, age-restricted item rules — all of it, country-scoped, hot- swappable, and validated before the build ships.

Without that layer, every new country becomes a fork. With it, the same binary serves N countries and the launch unit becomes "fill in the config, run the validation suite, schedule the soft launch." That is what compresses a 12-month rollout into the schedule it actually ran.

If you take only one thing from this post: in any multi-country product, the configuration layer is the product. The UI is just the latest skin on top.

The 60% checkout-speed number — what it actually measures.

"60% faster checkout" is a useful headline because it's true and it compresses a real experience improvement into a single number. It is also one of the most easily misread metrics in retail tech, because what gets compared depends entirely on where you start the clock.

We measured it as: time from the moment a customer reaches the front of any queue (manned, self-checkout, or the scan-and-go egress lane) to the moment they have a paid receipt. Pre-scan and bag-pack time was already done by the customer in scan-and-go, so the comparison isolates the queueing + tendering portion that the customer experiences as "checkout."

Two takeaways for anyone running this kind of measurement:

• Pick a customer-experienced definition of the metric and stick to it. Don't let it drift between countries.
• Pair it with a baseline metric that is harder to game. We tracked NPS for the scan-and-go journey alongside the speed number and landed at 61 NPS — the speed only counts if the experience landed.

The blast-radius rules that kept peak hours safe.

A scan-and-go bug at 6pm Friday in a hypermarket is not a software outage. It's a queue at the egress lane that turns into a customer service incident, a loss-prevention incident, and a CSAT incident simultaneously. Three rules made this manageable across nine countries:

1. Soft launch in low-traffic hours, always. Tuesday mid-morning, never Friday evening. Surfaces problems in the forgiving window where the store team has spare capacity to react.
2. Per-store kill switch, not just per-country. Configuration-level toggle that the country ops lead can flip in under a minute. Used rarely, but the existence of the switch is what lets ops sleep.
3. Real shadowing before real launch. Ops staff watched the first hundred transactions in person at the egress lane in every new store. The data they brought back into the rollout calls was higher signal than any dashboard.

What I'd do differently.

Two honest mistakes worth naming:

We under-invested in support tooling early. The first country shipped, support tickets came in, and the agents had to chase information across three tools to resolve a single transaction dispute. We caught up by the third country, but the right move was to treat the support console as part of the launch unit from day one, not as a fast-follow.

We over-trusted the central rollout calendar. The plan said "country 6 launches in week 32." Reality said "country 6 wants to launch in week 32 but their payments switch upgrade is in week 30 and that buffer is too thin." When you compress a calendar across nine countries, the schedule becomes brittle in ways the Gantt chart hides. We started shipping with a two-week air-gap between dependent milestones from country 4 onward and the rollout smoothed out immediately.

The bottom line.

Scaling a frontline retail product across nine countries in twelve months is not a software-engineering achievement. The software is necessary and not sufficient. What did the work was: an explicit launch unit, a portfolio approach to country sequencing, a configuration-first platform, customer-experienced metrics, blast- radius discipline, and a willingness to build the boring layer first. Done well, the rollout looks effortless from the outside. That is the tell that a lot of unglamorous work went in early.

If you are running a multi-country rollout and want a second pair of eyes, send me a note. I'm easier to find before country 2 than after country 6.