Three orders, three outcomes

Three orders, one desk log

The three cases below are taken from the same working notes, in the same season, from buyers with comparable budgets and comparable destinations. They are not selected for drama. They are selected because each one turns on a single decision that the buyer described explicitly, which makes the lesson traceable rather than retrospective.

Case one is an order where nothing went wrong and the process still needed a decision. Case two is an order where a visible defect arrived and the buyer handled the timing well. Case three is an order where a partial delivery was handled by waiting, which is the mistake the other two avoid in different ways.

Before the cases, one note about what they are not. Three orders cannot support a claim about how often anything happens. They support a claim about what a decision costs, which is a different kind of statement and the only kind three cases can carry.

Case one: the order that stalled at the warehouse

The background: four items from two stores, arriving at the warehouse across eleven days, with the last item landing after the buyer had stopped checking. The buyer assumed the order was ready to ship and waited for a measurement that had already been taken on the items that had arrived.

What the buyer did: nothing, for nine days. The assumption was that a partial arrival would trigger a message, and no message came, because nothing was wrong. The warehouse had done its part and was waiting for a consolidation instruction.

The result: the parcel was eventually built and shipped nine days later than it could have been, with no error anywhere in the chain. The measurement existed, the items were in stock, and the only missing input was an instruction that nobody had asked for.

The lesson: the warehouse acts on requests and does not infer them. A multi-store order has a moment at which the buyer has to say the build can proceed, and waiting for a message that will not arrive is indistinguishable from an idle order.

There is a second lesson underneath that one, and it is about attention rather than about instructions. The buyer stopped checking on day eleven because the order felt finished once three of four items had arrived. The status had not changed, the items had not moved, and the only thing that had changed was the buyer’s expectation. An order is not finished when it stops being interesting; it is finished when it is on a plane.

Case two: the order with a visible defect

The background: a single jacket, arriving with a print that sat visibly off-centre in the warehouse photograph. The buyer saw the frame on the day it was posted rather than at the end of the week.

What the buyer did: asked for one more frame of the same area with a ruler in it, and asked for the flat chest measurement at the same time. Both came back the same day. The measurement matched the tally rows for that model, so the fit was not in question, and the print defect was confirmed in the second frame.

The result: the item was rejected at the warehouse rather than after postage, and the return went down the path that applies before the parcel is built. The buyer spent one message and one day, and avoided paying to move an item that was going to be returned.

The lesson: the warehouse step is the cheapest place in the whole process to discover a defect. The same discovery after delivery costs postage in at least one direction, and it usually costs the handling window as well, because the window starts before the defect is seen.

Case three: the partial delivery that waited

The background: three items ordered, two received, one still with the seller after the warehouse had already measured what had arrived. The buyer decided to wait for the third item before making any decision at all, on the theory that a complete picture would make the decision easier.

What the buyer did: nothing, again, and this time with a reason. The third item arrived eight days later, by which point the two measured items had been sitting for most of the handling window and the defect on one of them had not been raised.

The result: the defect was raised late, the window closed while the correspondence was still going, and the send-back paths were no longer available. The item was kept and moved on locally, which is the outcome the return model produces once the window has expired.

The lesson: a partial delivery is a reason to decide about the part that arrived, not a reason to defer all decisions. The two questions, whether to keep what is here and whether to wait for the rest, are independent and can be answered separately.

The patterns the three cases share

Read together, the cases share two patterns. The first is that the expensive decisions were timing decisions, not quality decisions. Case one lost nine days to a missing instruction, case three lost a window to a deferred one, and neither involved a defective item until it was too late to matter.

The second is that each case had a cheap action available on the day the problem first became visible. In case one it was a message; in case two it was a second photograph request; in case three it was a decision about the items already in hand. None of the cheap actions required information the buyer did not have.

The third pattern is quieter: none of the three buyers lacked information. All three had the measurement, the photograph and the status. What varied was whether the information was acted on before the next deadline moved.

1. The warehouse acts on instructions, not on inferences.
2. The cheapest place to find a defect is before the parcel is built.
3. A partial delivery splits into two independent decisions, and only one of them benefits from waiting.
4. Every one of the three cases had a same-day action that would have changed the outcome.

A short list for the next order

The reusable part of a case review is the checklist it leaves behind. The four lines below are the ones the three cases produce between them, ordered by how early they can be run.

1. When the last item of a multi-store order lands, send the build instruction rather than waiting for a message.
2. Read the warehouse photograph the day it appears, and name what it does not settle.
3. If anything is wrong with an item that has already arrived, raise it before the last item lands.
4. Write the window end date somewhere visible, because in all three cases the deadline moved while attention was elsewhere.

The data point behind this note

Three-order review drawn from the handling-window model in KB-2026-05 (three return paths split after the desk found a single figure hid the case where keeping an item is cheaper, plus the window-closure check added in the same batch).

◇KB-2026-05· 2026-09-30 Batch ledger · Challenge a figure

Notes in the same cluster

Related entries and gauges

• How do you handle an order where only part of it arrived?
• What does each order status mean in plain words?
• Return path bench

  What each path costs from where you are standing now.