Site one went well. That is usually when someone asks the obvious question: can we do this everywhere?
Then you look at site two and it is not the same building. Different racking, different ceiling height, a different client mix, and quite possibly robots from a different supplier because it was kitted out two years later. The playbook from site one does not drop in cleanly, and the rollout that was supposed to take a quarter starts looking like three separate projects.
The short answer
- Sites are rarely identical, so copying a configuration does not work. What transfers is the process and the rules, not the layout.
- Standardise the decision logic, not the hardware. Trying to make every site run identical kit is slow, expensive, and usually loses to reality.
- Prove one zone per site rather than replicating wholesale. Each building earns its own baseline.
- Keep the same team across the first two rollouts. Rotating people out is where multi-site programmes lose their learning.
- Expect site two to be slower than you think and site three to be faster than site two.
Why does the second site rarely go as well as the first?
The second site usually underperforms the first because teams try to replicate a configuration rather than a method. Site one's setup was tuned to its layout, its client mix and its equipment. Site two has a different version of all three, so the settings that produced a good result in one building can produce a mediocre one in the next.
The instinct is understandable. Something worked, so copy it. But the thing that actually worked was the sequence you followed, measuring a baseline, proving one zone, adjusting, then widening. That sequence transfers. The specific task-allocation settings largely do not.
What actually transfers between sites?
What transfers is everything that is not physical: the rollout method, the priority rules, the measurement baseline, the exception-handling approach and the team that has done it before. What does not transfer is the layout, the equipment mix and the client profile.
Worth being concrete about the split:
Transfers well - The four-phase approach: evaluate, pilot, scale, measure. - Your definition of a good result, and the baseline metrics behind it. - Priority rules for what gets picked first when work competes. - The escalation path when something stalls, and who owns it. - The people. This is the most underrated item on the list.
Does not transfer - Zone layouts and travel paths. - Slotting logic, because the stock behaves differently. - Robot counts and mix. - Shift patterns and cut-off times.
If your rollout plan is a configuration file, you will rebuild it every time. If it is a method, each site gets faster.
How do you scale when the sites run different robots?
You scale across mismatched sites by standardising the layer that decides what work happens, rather than standardising the machines that do it. If each building's coordination is handled by equipment-specific software, then every site is its own island and your operating model is different in each one. If the decision layer is common, the buildings can differ underneath it.
This is the practical reality in contract logistics. Sites get automated at different times, for different clients, with whatever made sense that year. FloxMind coordinates mixed fleets from any vendor as one operation and supports 100+ robot models across deployments of 5 to 500+ robots, so a network that grew unevenly can still be run to one standard. The mechanics of where that layer sits are covered in what a warehouse orchestration layer is and on the technology page.
The point for a rollout is narrower than the general capability argument. It is that your operating model can be consistent even when your buildings are not, which is what makes a second and third site cheaper than the first.
Do you have to shut a site down to bring it into the rollout?
No. Adding coordination to a working site does not require a shutdown, because the layer sits on top of the warehouse management system you already run and connects to the robot controllers beneath it. There is no rip-and-replace and no new fixed infrastructure to install, and onboarding takes less than one week.
That matters more on site two than site one, because by then you are adding automation to a building that is already trading against live client commitments. The detail of phasing into a live operation is covered in brownfield warehouse automation.
How should you sequence a multi-site rollout?
Sequence by learning value, not by size. The instinct is to start with the biggest site because the return looks largest, but the biggest site is usually the most complex, and a hard first rollout teaches you less than a clean one.
A workable order:
- Pick a second site that is different enough to be a real test but not your hardest. If site two is nearly identical to site one you learn nothing about what transfers.
- Re-baseline from scratch. Picks per hour, labour hours, accuracy, exception rate. Do not assume site one's numbers apply. The set worth capturing is in which numbers to track once robots are running.
- Run one zone, not the building. Same discipline as the first pilot.
- Write down what differed. This becomes your rollout playbook, and it is worth more than the configuration.
- Only then commit to a network timetable. Two sites gives you a real estimate. One gives you a guess.
What does this typically deliver?
Across deployments, coordinating an existing fleet tends to produce throughput uplift of 20 to 40%, labour cost reduction of up to 70%, error reduction of up to 90%, and return on investment in 4 to 12 months, with 98%+ uptime across the operations coordinated. In one anonymous third-party logistics (3PL) e-commerce deployment using goods-to-person automation, picking throughput rose 40%.
Those are ranges rather than promises, and in a multi-site programme they will not be uniform. A site with heavy coordination losses will show a bigger gain than one that is already running tightly, which is another reason to baseline each building rather than assuming the network behaves as one.
The thing most rollouts get wrong
They treat site two as a copy exercise and staff it accordingly, often rotating the experienced people off after site one goes live. That is precisely backwards. The value built during the first rollout sits in the heads of the people who did it, and moving them on before the second site is stable is how organisations pay the learning cost twice.
Keep the team together for two sites. Let them write the playbook. Then scale the playbook rather than the people.
If you are planning a rollout across sites that are not identical, book a technical demo and we will look at what transfers and what does not across your network.