A checklist for the message you send the warehouse

The warehouse message read as a work order

A warehouse message is a work order, not a conversation. It arrives in a queue with a hundred others and it gets acted on by someone who has the parcel in front of them and a limited amount of time. Everything below is written to make that person able to act without asking you anything back, because a question back costs days rather than minutes.

The checklist is long because a request has several independent parts: what to do, which parcel, when to do it, what evidence to leave behind, and what to do if something is missing. Most messages cover the first part and leave the rest implicit, and the implicit parts are exactly the ones that generate follow-up questions.

Read the list as a pre-send pass rather than as a form. The version that matters is the one you can run in two minutes on a phone, before the parcel has been sealed and while a change is still possible.

What and which: the parcel identity block

The first group settles identity. A request naming the wrong parcel is worse than no request, because it gets carried out. Every line here exists because a request without it can be applied to the wrong item or questioned instead of executed.

1. Order number, written in full rather than shortened.
2. Item or line reference, exactly as it appears in the order rather than as you remember it.
3. Declared size and colourway, so a substitution cannot be mistaken for the right item.
4. Quantity, spelled out as a number, because a request about one of three identical items is a different request.
5. The warehouse storage reference if one was issued, since it is what the shelf label says.
6. The date the item was received, which tells the reader whether they are looking at a parcel or a record.

What to do: the action block

The second group is the action itself. Requests fail here most often, because the action is stated as an outcome rather than as a step. Removing a shoe box is an outcome; discarding the retail box, keeping the shoes, and photographing the shoes after removal is a step sequence someone can follow.

Where an action changes the parcel, say what should happen to the material that comes off it. A box that is removed and left in the bag re-enters the parcel, and the measurement does not change. That single omission is the most common reason a sensible request produces no result.

1. The action, written as the first instruction in the message rather than after the explanation.
2. What to remove and what to keep, named separately, so the parcel does not lose the item along with the packaging.
3. Where the removed material goes, because material left in the bag is material still in the parcel.
4. Whether the item should be re-bagged, re-boxed or left loose inside the outer carton.
5. Whether the outer carton should stay the same or be reduced, since those produce different measurements.
6. Whether fragile components need protection added, which is the one case where volume legitimately increases.

Evidence: what to leave behind

The third group is the part people skip, and it is the part that decides whether the request can be verified later. A request that changes a parcel and leaves no record is a request you cannot check, and a weight dispute without a record is an argument rather than a claim.

The desk keeps one rule for this group: every action should produce at least one artefact that carries a date and a number. A photograph without a weight is weak evidence, and a weight without a date cannot be matched to a quote.

1. A photograph of the sealed carton on the scale, showing the reading.
2. The recorded dimensions after the change, in centimetres, rather than a statement that the parcel is smaller.
3. The weight before the change, so the effect of the request can be measured rather than assumed.
4. The weight after the change, taken the same way, on the same scale.
5. A photograph of anything that was removed, kept with the parcel record rather than discarded.
6. A note of who carried the request out, which matters only if the result is disputed and nothing else can settle it.

Timing, fallbacks and the second-order questions

The fourth group covers when and what if. Timing matters because requests arrive at different stages: before consolidation, during consolidation, and after the parcel has been measured. A request that does not say which stage it applies to can be carried out at the wrong one, at which point it is either impossible or pointless.

Fallbacks matter because the answer to a request is sometimes no. A box that cannot be removed without damaging the item, a carton that cannot be reduced without exposing a corner, a measurement that cannot be taken because the item is already wrapped. Saying in advance what to do in those cases converts a stall into a decision.

1. The stage the request applies to: before the parcel is built, or before it is measured.
2. A date after which the request should be abandoned rather than carried out late.
3. A fallback for each action that could be refused, written as an alternative rather than a complaint.
4. A statement of which single line matters most, so a partial execution still produces something useful.
5. Whether the parcel should be held for a reply, or shipped if the reply does not arrive.
6. The channel you will be watching for the answer, so the reply does not sit unseen.

The lines people most often leave out

Across the four groups, a small number of omissions account for most of the follow-up traffic. They are worth naming because each one is invisible when you write the message and obvious when you read the reply.

1. Where the removed material goes, which is the single most common reason a packing request changes nothing.
2. The weight before the change, without which the effect cannot be quantified.
3. The stage the request applies to, which decides whether it is possible at all.
4. The fallback, which decides whether a refusal stalls the parcel or resolves it.
5. Which line matters most, which decides what happens when only part of the request can be carried out.
6. The channel for the reply, which decides whether you see the answer before the parcel moves.

Sending it as one message

The reason to send everything in one message is not politeness. A message that arrives complete is executed in one pass, and a message that arrives in three parts is executed in three, with the parcel possibly measured between them. Sequencing is the hidden cost of a partial request.

The practical format that carries all twenty-four lines without becoming unreadable is a short numbered list, one instruction per line, with the evidence request placed at the end so it is not lost in the middle. Read it once as if you were the person holding the parcel, and strike anything that could be read two ways.

Then keep a copy. The message is the specification, the reply is the record, and the pair together is what makes a later question about the parcel answerable.

The data point behind this note

Message lines derived from the packing-request test in KB-2026-04 (9 footwear parcels and 5 soft-goods parcels weighed before and after a request; shoebox removal moved the chargeable figure on 7 of 9, and the vacuum-bag request moved 0 of 5).

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

Notes in the same cluster

Related entries and gauges

• How do you ask the warehouse a question that gets a useful answer?
• How much does dropping retail packaging actually save?
• Packing and declaration bench

  Turn a vague instruction into a list of requests that move a number.