Back to blog
Diary

Thursday: Settle It Once and Name the Exception

5 min read
Settle it once, name the exception. A default recorded once, with its exception named, is never asked twice.

From the operations desk

The minutes went on defaults nobody had recorded yet

This Thursday's traffic was quoting and expectation-setting rather than exceptions; defects and delivery failures were a small fraction of it. The expensive minutes went on answers the desk had already given somewhere in the same threads. Underneath a heavy intake of first quotes to new prospects sat established accounts settling how their orders would be handled from now on: how goods are packed, what an order must arrive with, what happens to an optional extra.

Price the packing choice, warn once, then write the default down

A footwear reseller shipping into Europe asked what happens to a pair if the retail box is not kept. The desk put three named packing standards on the table for his future orders — keep the original retail box, replace it with a carton, or bag only — and he chose the bag straight away, with his own exception attached: he would name the orders needing a box. Before writing anything down the desk added the risk he had not been told about, that a material of that kind has to be folded for bag-only packing and may crease. Only then was the choice recorded as the account default. He asked for the box and the bag priced against each other afterwards, and was asked a second time whether bag packing was really what he wanted before the order moved.

The exception was used on the first order. The invoice went out at the bag price, he asked for the original retail box on that one order, and it was reissued the same afternoon, before anything had been packed or handed over. He restated the default as he asked for the change: bags for the rest. Ask your partner by which stage of your account's flow an exception has to be named if it is to be acted on, and have that stage recorded next to the default itself rather than learned at the invoice; order change and cancellation cut-offs sets out what can still be changed at each stage.

An intake line only works when it names the fields

The order-intake standard is one sentence: send the products you want, plus the recipient — full name, telephone number, the complete street address and the postcode — and an invoice follows. That Thursday it went out from memory into one thread in the morning, then again into that same thread in the evening once the quote came back, retyped under the quote it belonged to rather than referred back to. A prospect's thread beside it got the same sentence built from scratch.

The short form is where it broke. A first-orders prospect was asked for recipient details with none of the fields named and came back asking which details were wanted; the field-level version closed it in one message and the address arrived minutes later. Those are the fields a checkout has to capture before an order is worth passing on, so collect them upstream rather than by hand — reaching the recipient is part of delivery sets out why the telephone number and the house number are part of delivery rather than paperwork.

An add-on nobody wrote down gets guessed at

An optional extra shows the gap most plainly. One seller was selling a gift bag as a line that carried no shipping requirement, so it did not reach the feed the warehouse picks from, and the desk's own technical side said that could not be fixed for the time being. Workarounds were offered while the fault stayed open: he names the orders that need a bag, or a bag goes into every order.

He took the per-order route, because he wanted a bag included only where his customer had ordered one, and making the line carry a shipping requirement would have added a delivery charge for that customer. He notified the first one by chat message and asked for it to be checked, and the next morning the bag still did not show against that order.

The fault sat with the order feed on the fulfilment side, which is why the ask came back as naming each affected order in advance.

Ask which defaults your account already carries

Ask your fulfilment partner to read back the defaults recorded against your account: the packing standard, the fields their intake needs before an order can be invoiced, and the handling of any optional extra your storefront treats as a line with nothing to ship. Name each exception yourself and ask where it is recorded, because an exception that is not on the order is not visible to whoever packs it. Then ask the question that turns the read-back into something you can rely on — which artefact each line of it sits in, the order form, a field on the order, or the sheet both sides work from.