Before the second warehouse opens, decide which orders it gets.

Why this one is a diary

This note is written as the diary of an operations lead at a growing online brand, during the two weeks before a second warehouse goes live. The brand and the person are made up, a composite of conversations we've had with teams in this spot. The decisions are real ones, though, and they come up in nearly the same order every time.

The setup is common. The brand has shipped everything from one warehouse on the East Coast for years. Customers in the West wait longer, and shipping costs keep climbing, so they've signed with a 3PL on the other side of the country. The contract is done. The inventory transfer is booked. Go-live is in two weeks.

Everyone assumes the hard part is moving the stock. The diary suggests otherwise.

Monday: the rule that seemed obvious

We agreed the rule in five minutes: ship from whichever warehouse is closest to the customer. Then someone asked, "closest and has the stock?" Then someone else asked, "has all of it?"

The default rule is fine as a starting point. It just isn't a rule yet. It needs three more words: closest that can fill.

So the first decision was the fallback order. If the nearest building can't fill the whole order, try the other one. If neither can fill it alone, that's a different case, which is Wednesday's problem.

The second decision was where this rule lives. Today it's in the ops lead's head and a note in a shared doc. Their store platform supports some location rules, the 3PL has its own, and the brand's order management sits between them. Three systems could each decide where an order goes. The team picked one place to own the decision, so the other two simply follow it.

Wrote it down: one system decides the route. Everyone else reads it.

Wednesday: the order that lives in two buildings

A customer in Denver orders a jacket and two pairs of gloves. The jacket is only in the East. The gloves are only in the West. Now what?

There are three honest options. Split it into two boxes from two places, which costs more and means two deliveries and two tracking emails. Wait until one building has everything, which means a transfer and a slower order. Ship all from one, once stock moves, which can be the slowest of the three.

None is always right. The team wrote a small table instead of a single rule. Split when the order is above a value they chose, or when one item is the urgent one. Ship from the building with the expensive item when the rest is cheap and quick to transfer. Never split a set that's meant to arrive together, such as a gift box or a matched pair.

The bigger decision was what the customer sees. If an order might split, the confirmation email and the order page should say so plainly, with both tracking numbers in one place. Support should see it too, so "where's the rest of my order?" has a ready answer.

Decided: we tell the customer before they ask.

Friday: which count the store believes

Product page said "in stock, ships tomorrow." It was in stock. In the other building. Three days away.

With one warehouse, "in stock" meant one thing. With two, the storefront needs a decision. Does it show the total across both? Only the stock that can reach this customer quickly? Does the delivery promise on the page change by region?

The team chose to keep showing total availability, but to base the delivery promise on the building that would actually ship to that customer. That meant the storefront and the routing rule had to agree, so they made them read the same answer.

They also had to settle reservations. When an order comes in, stock is held in the building that will ship it, not in a shared pool. Otherwise two orders can claim the same last unit from two directions.

The last piece was transfers. Stock will drift toward the wrong coast. Someone has to watch the balance between buildings and decide when to move it, and the storefront has to know that stock in a truck is in neither building yet.

Note to self: the count isn't the promise. The route is the promise.

The following week: returns and the override

First returns question: does a return go back to the building it came from, the closest one, or wherever we want the stock?

They picked closest to the customer by default, with the ability to send certain items, like slow sellers, back to the main warehouse. Returned stock gets counted in the building that receives it, after inspection, not before.

Then the override. Someone will always need to ship an order from the "wrong" building: a VIP, a damaged item, a stock error. The team agreed who can override a route, made them pick a reason from a short list, and recorded it on the order. That way, if a lot of overrides appear, it's a sign the rules need changing, not a mystery.

Overrides are allowed. Silent overrides are not.

What went on the one page

By go-live, the diary had turned into a single page: default route, fallback, split table, what the customer is told, how stock is reserved and shown, returns, and who can override. Before switching anything on, they replayed a week of last year's orders against the page and looked at every order that would have split or switched buildings. A few rules changed that day. They also checked the support view: for each replayed order, could someone answering the phone see which building it shipped from, and why? If not, the route existed, but nobody could explain it.

This is the same shape of work we've done before. On Paddle8, shipping knowledge lived in spreadsheets of routes, and we turned those spreadsheets into a shipping API so the platform could use that knowledge. Routing rules for a second warehouse are that kind of knowledge too: valuable, usually informal, and much safer once software can read them.

If you're adding a location, fulfillment operations is where we connect the storefront, the warehouses and support so they tell the same story. Bring us a week of orders, and we'll replay them against your rules with you before the stock moves.