The FBA Inbound Order That Can't Exist Yet

Most of a 44-minute call with our 3PL went on one question: why the order they wanted couldn’t exist yet.
I build SKU.io. I also run an online store on it, and part of what we sell goes to Amazon FBA through a 3PL, so on this call I was the customer. Before anything moves I want to know the units are really on the shelf, because building boxes for a shipment that turns out short is a day thrown away. That check, as the 3PL sees it, needs an order. I asked whether anything else in their system could hold or pick stock. “There’s really not right now.” Could they verify stock before an order existed? “When the order is in the system, it tells the warehouse where the product is so they can go and pick it.”
Fair enough. The trouble is Amazon, which won’t say which of its warehouses gets what until it has the box configuration, meaning what is in each box and what each box weighs. I put it to them as “they do not consider it an order until we provide box configs.” After that, one planned shipment can come back as several, each to a different address. The example I gave them was a single order of 10 items that is really three orders, of three, four and three items, going to three Amazon warehouses. Their ops lead: “Right. Three different addresses.” So the order they wanted on day one is three orders I can’t write until the boxes exist, and the boxes don’t get built until there’s an order.

The usual way out is a placeholder: one order, no real ship-to, put on client hold so nobody ships it, cancelled once the real ones are in. I suggested it myself. Then their ops lead explained the cancel.
“Once we cancel it, any orders that are in back order are going to released … it’s going to be allocated.”
I should have seen that coming, because our own software had the same flaw until June. Verifying an FBA plan in SKU.io used to create a warehouse transfer nobody meant to ship, purely to hold the stock while Amazon decided where it was going, and the real transfers were cut from it after the split. We pulled it out on June 21 and put the hold on the plan’s own lines instead. It moves onto each shipment when Amazon splits the plan and drops if the plan is aborted. It also won’t hold part of a plan. If one line is short the verify fails, and someone has to go count.
None of that reaches inside the 3PL’s system. Their placeholder still has nowhere to put the units except an order, and the gap between cancelling it and typing in the three real ones is when back orders take them.
What I asked for was a hold. These SKUs, this many, set aside, no address, nobody ships. “An inventory hold order. And this is like common.” They don’t have one. I don’t blame their ops lead for that. They didn’t pick the software either.
The rest of the call went on other things. They don’t lock an order once picking starts, and someone on my side had been editing quantities mid-pick, which I wrote about separately in the order nobody was supposed to change. Our counts had drifted from theirs too. “I synced it two months ago and now we’re way out of sync again.” That one is mine. They said some shipments were “taking months before they go out.” My data said we turned around box labels inside a day once we had them, and that the waiting was unanswered follow-ups on both sides. We didn’t settle it.
At one point I said part of me would love to just estimate the box weights and dimensions and send them. Their ops lead: “I wouldn’t let anybody do that.” Then, “Scary.” I’d half agreed before they said it, because guessed boxes have caused problems for us before. Amazon places the shipment off those numbers. So the boxes get packed and weighed first, 50 pounds max each, and everything waits on that.
If your 3PL wants an order you can’t write yet, bring the shipment to a demo.