Design for roll-out from day one

The pilot went well. Users in the first market adopted the platform, the numbers looked good and the steering committee agreed to roll it out. A year later, it is still running in one market.

This is one of the most common problems we hear from regional headquarters. It is rarely about technology. It is about decisions made in the first few weeks, when the only market anyone was thinking about was the pilot.

Why roll-outs stall

Three causes come up again and again.

• The pilot is built around one market’s process. Rules, screens and data structures quietly assume how the first distributor works. The second market works differently, and every difference becomes a change request.
• Configuration lives in code. Prices, approval steps, dealer lists and email templates are written into the application. Adding a market means a release, not a setting.
• Nobody owns onboarding. The project team that built the pilot moves on. Taking the next market live is treated as a small follow-up, not as work that needs its own plan, people and budget.

None of these is visible during the pilot. All of them become expensive in the second market.

Four design choices that change the outcome

In the platforms we build and run for regional headquarters, from distributor commerce to warranty and certification, four choices make the difference.

1. Separate regional standards from market configuration

Decide early what must be the same everywhere and what each market may vary. On a regional commerce platform we run, there is one platform instance, and each distributor gets its own store with its own catalogue, prices, payment and delivery set-up. Shared capabilities, such as VIN-based parts search, are built once and used by every store.

The same principle applies to smaller systems. On a dealer certification engine, the list of dealers and signatories is master data that the regional HQ updates itself, not something a developer changes in code.

2. Keep the application independent of the environment

For a warranty platform now being built as an MVP for its first market, the application is deliberately separated from the infrastructure. The next region can bring its own cloud environment, network and data-residency set-up, while the application components carry over unchanged.

3. Treat onboarding as a product

The second market should be easier than the first, and that only happens if onboarding is designed: a checklist of what each market must provide, data templates, a training pack, a test plan and a clear owner. When a market goes live, the playbook gets better.

Templates help here too. For a family of regional brand websites, the second site starts from the same CMS, infrastructure and security components as the first, so only the brand-specific features are new work.

4. Plan how it will be run before it goes live

A platform that is about to serve ten markets needs monitoring, support, upgrades and a budget for them. If running costs are an afterthought, every new market adds load to a team that was never sized for it. We agree the operating model, and how support effort will be shared across markets, before the first go-live.

Measure adoption, not just delivery

A roll-out is not finished when the system is live in a market. It is finished when the people in that market use it. Track adoption per market, such as active users, transactions and requests still handled by email, and treat a market that has gone live but is not using the platform as an open issue.

Where to start

If you already have a pilot running, the most useful exercise is an honest review of the three causes above: which rules are hard-coded, what each new market would need to change, and who owns the next go-live. It usually takes a short working session to see how much of the second market’s cost can still be avoided.

If your platform has stalled after the pilot, tell us about it.