From One Site to Twelve: Scaling After the Pilot Works

The Problem With a Successful Pilot

A pilot that works is genuinely good news and it is also the least predictive evidence you will gather. The reason is uncomfortable: pilots are run at the best site, by the most motivated people, with unusual attention. Somebody wanted it to work, watched it daily, cleared the corridor, retrained the shift, and called the vendor the same hour something went wrong.

That person is the pilot’s most important component and they do not scale. At site seven the machine is unpacked by a supervisor who did not ask for it, has not been consulted, and is measured on something else entirely. Nothing about the technology changed. Everything about the conditions did.

So the question to ask after a successful pilot is not “did it work” but “which of the things that made it work will exist at the next eleven sites?” Write that list honestly before you order anything. If the answer is “the enthusiasm of one person,” you do not yet have a rollout plan — you have one good site.

Site Variance Is the Real Constraint

The single biggest surprise in multi-site rollouts is how different nominally identical buildings turn out to be. A hotel group with a standard prototype, a health system with a common design standard, a contractor servicing a portfolio of offices — all of them discover the same thing, and it is worth cataloguing the dimensions that actually vary:

• Floor surface and transitions. The same carpet specification installed six years apart behaves differently, and thresholds, expansion joints and slightly proud floor plates are where machines get stuck.
• Corridor width and clutter. Not designed width — actual width after carts, linen bins, spare furniture and seasonal storage have taken up residence.
• Lifts. Different vendors, different controller generations, different integration cost per building. This is usually the largest cost variance in a multi-floor rollout and it is site-specific.
• Wireless coverage. Every building has its own dead spots at robot height, and the network standard being identical on paper does not mean coverage is.
• Electrical capacity near the intended dock, which varies wildly in older buildings.
• Local labor market. Site one may have chronic vacancies while site five is fully staffed with long-tenured people, and the case for automation is genuinely weaker at site five.
• Unionised or represented workforces, where consultation obligations differ by site and by agreement.

The mistake is treating rollout as a procurement exercise — buy twelve, ship twelve — when it is a series of twelve small deployments sharing a platform decision. Budget for the variance rather than being surprised by it.

Survey Before You Commit the Fleet

Do not buy twelve machines and then survey twelve buildings. Survey first, in a deliberately cheap and standardised way, and let the survey decide the order and the count.

A workable site survey template covers: route length and the tasks in scope; floor surfaces and transitions; measured corridor width at the narrowest point at a busy hour; lift count, vendor and controller generation; wireless coverage at robot height along the route; electrical capacity at the proposed dock; current staffing level and vacancy history; who the on-site owner would be; and any consultation obligation.

Two things come out of that exercise and both are valuable. You get a ranked list, so the rollout starts where it will succeed rather than where the regional manager shouted loudest. And you get a disqualified list — sites where a machine is the wrong answer. A rollout plan that includes the courage to skip three buildings is more credible than one that claims all twelve are suitable, and it will hit its numbers.

Who Owns the Machine at Site Seven

This is where rollouts actually die, and it is an organisational question rather than a technical one.

At the pilot site, ownership was implicit. Across a portfolio it has to be explicit, and the decision is between two models. A local owner at each site — a named person per shift responsible for charging, loading, clearing faults and escalating — gives fast response and local accountability, at the cost of consistency and turnover exposure. A central owner with remote monitoring and a travelling technician gives consistency and better data, at the cost of response time and local buy-in.

Most portfolios end up hybrid: a named local owner for daily handling, a central function for monitoring, escalation and vendor management. What matters is that it is written down, that the named local owner appears in a job description rather than in a meeting, and that there is a defined answer to what happens when that person leaves. In a trade with high turnover, “we trained Maria” is not a sustainable operating model.

Two further items that get forgotten at scale: a training package that survives turnover, meaning a short documented procedure and a named trainer rather than the vendor’s one-off session; and a single escalation path so that site nine is not phoning a salesperson’s mobile at 6am.

A Rollout Sequence That Holds

The pattern we have seen work:

1. Survey the whole portfolio before ordering beyond the pilot. Rank and disqualify.
2. Choose site two to be hard, not easy. Counter-intuitive and important. Site two should be a difficult but representative building, because its purpose is to expose what the pilot hid. A second easy win teaches you nothing and gives false confidence you will pay for at site five.
3. Write the playbook from sites one and two. Dock siting rules, route design conventions, training script, escalation path, the first-thirty-days routine, and the measurement set. This document is the actual deliverable of the pilot phase.
4. Run a wave of three, applying the playbook, with the explicit goal of testing whether the playbook works without the original champion present.
5. Hold a genuine gate review. Set the criteria beforehand and be willing to stop. A rollout that never fails a gate review does not have a gate review.
6. Scale the remainder in waves, sized to what your support function can actually absorb — usually three to four sites at a time, not twelve.
7. Revisit the disqualified list annually. Buildings get refurbished, staffing changes, and platforms improve.

The gate review after wave one is the step most often skipped and the one that most reliably saves money. Its purpose is not to confirm the decision; it is to find out whether your organisation can do this without heroics.

Getting the Commercial Structure Right

A twelve-site rollout is a different commercial conversation from a single purchase, and there are terms worth asking for that no vendor volunteers.

Portfolio pricing tied to a schedule, not a commitment. You want volume pricing available across the rollout without committing to twelve units before you have surveyed twelve buildings. A master agreement with per-site releases does this.

Per-site service coverage confirmed by address. On-site response commitments in this industry are geography-conditioned and the contract rarely lists the geography. Get an appendix naming each site and the response tier that applies there. A four-hour commitment that covers your flagship and not your three regional buildings is a materially different product than you think you bought.

Re-mapping terms. Across a portfolio, some building will be refurbished every year. Establish who pays to re-map and how long it takes, in the contract, not in an email later.

A pause or exit right between waves. If the gate review fails, you want a contractual way to stop that does not cost you the remaining term on units you never deployed.

Consistent configuration, documented. Component substitution is live across this industry at the moment, and a fleet acquired over eighteen months can drift into two or three variants. Ask to be notified of changes to the sensing, drive and power stack, and ask what revalidation follows. Two variants means two sets of spares and two training documents, and you should know that before it happens rather than after.

Measuring a Rollout Rather Than a Robot

Pilot metrics do not scale. What to measure across a portfolio:

• Completed scheduled runs as a percentage of scheduled runs, by site. The variance between sites is more informative than the average — it tells you which buildings have a problem while the aggregate looks fine.
• Time to productive operation per site, from delivery to running unattended. This is your rollout velocity and it should fall as the playbook improves. If it does not, the playbook is not working.
• Support contacts per site per month, trended. A site whose contact rate does not decline after month two has an ownership problem, not a machine problem.
• The operational outcome you actually bought — labor hours removed, trips off the unit avoided, square footage per labor hour — measured per site against that site’s own baseline rather than against the portfolio average.

And one honest note to finish on. If the survey says four of your twelve buildings are poor candidates, the right rollout is eight sites, not twelve. We would rather sell eight machines that run well and get referenced internally than twelve where four sit idle and poison the programme. The second outcome costs us more than it costs you, and it is the more common one in this industry.