Winning a contract is the good news. The go-live date that comes with it is the part that keeps an operations director awake.
For a third-party logistics (3PL) operator, onboarding a new client has always been a scramble: racking, labour, systems, a wave of new stock-keeping units (SKUs) and a service commitment you signed before you saw a single order. When the warehouse is already automated, that scramble changes shape. It does not get harder, but it does move. Less of the work is physical and more of it is configuration, and the risk shifts from "can we handle the volume" to "can we handle the volume without damaging the clients already in the building".
This is a guide to the second version of the problem: bringing a new client live on a floor that already runs robots.
The short answer
On a manual floor, capacity for a new client is mostly people and space: hire pickers, allocate racking, train the team. On an automated floor, capacity is a coordination question, because the constraint is how the robots are told to divide their time rather than how many bodies you can put on a shift.
That has one genuinely good consequence and one genuinely uncomfortable one.
The good one is speed. You are not waiting on a hiring pipeline to be ready for a volume step. The fleet is already there and already working, so the change is to its instructions.
The uncomfortable one is that the instructions are shared. Every client on an automated floor is drawing from the same pool of machines, so a new client does not arrive alongside your existing operation, it arrives inside it. If nothing changes in how work is allocated, the new volume competes with the old on a first-come basis, and first-come is not the same thing as your contractual priorities.
Four things, in roughly this order of effort:
Only the second of those involves anyone moving anything.
In most cases, yes, and it is worth checking properly before assuming otherwise, because the instinct in contract logistics is to size hardware to the contract that justified it.
The reason you usually can is that most automated floors are not running at their machine limit. They are running at their coordination limit. Robots sit idle while another part of the floor is saturated, work is released in batches that stop matching reality within the hour, and a stalled task waits for a supervisor to notice it. That lost capacity is generally larger than the capacity a new client needs.
Coordinating an existing mixed fleet rather than adding to it tends to produce throughput uplift of 20 to 40%, which for most single-client onboardings is more headroom than the contract requires. A coordination layer also deploys on subscription rather than capital expenditure, so it does not need to be justified against one client's contract term.
There are exceptions, and they are worth naming honestly. A client bringing a genuinely different handling requirement, pallets where you previously ran totes, or cold chain where you ran ambient, is an equipment question and no amount of coordination will substitute. The test is whether the new work is a different volume or a different kind of work.
Test the order profile rather than the order count. A client shipping the same number of units through completely different basket shapes will find a different bottleneck to the one you planned for.
Four tests earn their time:
By deciding the priority rules deliberately and in advance, rather than discovering them.
The failure pattern is consistent. A new client goes live, the team watches the new client's numbers closely because that is where the attention is, and existing service levels drift a few percent. Nobody notices for a month, because a few percent is inside the noise until a monthly report lands.
Three things prevent it. Set allocation priorities to match what your contracts actually commit to, which means someone has to read them. Keep the pre-go-live baseline visible on the same dashboard as the new client's performance, so a drift shows up as a comparison rather than a complaint. And give the new client a deliberate ramp rather than a full cutover where the contract allows, so the floor learns the new pattern at a volume you can still absorb.
Our piece on sharing one robot fleet across several clients goes further into how allocation by client priority works, and which operational measures are worth tracking once robots are running.
Assume it is, in one direction or the other, and configure for both.
Forecasts in new business are optimistic by construction, and the honest version of onboarding assumes the first quarter will not match the pitch. An automated floor handles that better than a manual one if the fleet is shared, because work simply reallocates: if the new client ships half of what was projected, the robots spend that time on someone else rather than standing still.
The same logic covers the harder case. Contracts end, and if you configured the floor around one client, their notice period becomes an asset problem. If the fleet was never committed to them, the work moves to whoever is in the building next quarter. That is the difference between a fixed cost and a variable one, which matters in a business where the client list turns over.
Coordinating a mixed fleet across clients tends to produce throughput uplift of 20 to 40%, error reduction of up to 90%, labour cost reduction of up to 70% and return on investment in 4 to 12 months. In one anonymous 3PL e-commerce deployment using goods-to-person automation, picking throughput rose 40%. These are ranges rather than promises, and where a site lands depends mostly on how much coordination loss it is carrying before anything changes.
A coordination layer sits between your WMS and the robot controllers, works across 100+ robot models from different suppliers, and needs no in-house robotics team to run. If you want to see how it would handle your next go-live, book a technical demo and bring a real order file with you.