Most fulfillment conversations end with somebody sharing a dashboard. It shows orders, inventory, maybe a shipment status column, and it feels like the deliverable. It is not the deliverable. A dashboard is a view, and a view can be changed, re-pointed or switched off by whoever owns the underlying system.
What you actually signed up for is three documents. If they do not exist as documents, the service has no interface, and every disagreement later becomes a negotiation about memory.
Document one: a dated rule sheet for the channel you ship into
This is the one that sounds like paperwork and behaves like engineering. The rule sheet says: for channel X, item class Y, here is what must be true before the parcel leaves our building, and here is the date the rule was read from the source.
The reason the date is the load-bearing part is that these rules move. Amazon's bagging requirements, expiration-date presentation, carton envelope and case-pack caps are all published by Amazon and all subject to change without notice to you. A rule sheet without dates is a claim about the present that will silently become false.
A shape that works:
| rule_code | channel | applies_to | expected | source_seen |
|---|---|---|---|---|
| suffocation_warning | amazon-fba | bag opening >= 5in | prescribed warning printed, film >= 1.5 mil | 2026-10-01 |
| expiration_format | amazon-fba | shelf-life items | MM-DD-YYYY or MM-YYYY, 36pt+, unit and box | 2026-10-01 |
| carton_envelope | amazon-fba | standard box | 36.00 x 25.00 x 25.00 in, 50.00 lb | 2026-10-01 |
| preexisting_barcode | amazon-fba | inbound carton | prior carrier barcode removed or rendered unscannable | 2026-10-01 |
Two properties make this a document rather than a wiki page. Closing a rule never changes what an old shipment was judged against, because the version is dated. And every row names a source, so when the platform changes the requirement, the fix is one row, not an archaeology project.
We keep our prep rules in exactly this shape, and the reason is not tidiness. It is that an operator answering "why was this treated differently from last month" needs a version, not a recollection.
Document two: an exception log with an owner and a disposition
Anything that did not go as planned should exist as a row with four fields filled in: what triggered it, what the decision was, who owns the next action, and what it cost.
The field people skip is the owner, and it is the only one that determines whether the exception closes. "Held pending documentation" with no name attached is a status, not a work item. Compare:
2026-10-07 hold carton 88213 rule: expiration_format
owner: <named person> next: request re-code from supplier
cost: null close: null
2026-10-07 hold carton 88213 rule: expiration_format
owner: nobody next: waiting
cost: unknown close: unknown
The second one is what most provider relationships actually look like, and it is why sellers discover a problem three weeks late rather than three days late.
A useful property to ask for: the log must be exportable and readable after you stop being a customer. If the only copy lives in a dashboard you lose access to on termination, the log is a feature of the vendor's product rather than a record of your operation.
Document three: named responsibilities
Three questions, answered in writing, with a party named for each:
Who is importer of record on a direct-to-consumer parcel? For a parcel leaving a Chinese warehouse addressed to a consumer in Germany, the party accountable at the border is often the recipient. Whoever arranged the shipment should be explicit about who is named and why, because that is the difference between a tax line and a customer service incident.
Who pays a preparation defect fee when the defect was created on the provider's side? A rule sheet with no cost owner is advice. The answer does not have to be generous, it has to exist.
Who holds the evidence, and for how long? If a carton is reworked, the only surviving proof of what arrived is what was captured before the rework. Ask where those files live and whether you can get them.
What deliberately is not in these documents
Rates and transit promises, for one. We do not publish either, and no rule above depends on them. A quoted per-parcel number and a delivery window are both forecasts, and forecasts do not belong in the same artifact as a dated rule that determines whether a shipment is compliant.
The other thing that does not belong is a service-level number nobody can recompute. If a provider states a percentage, ask which denominator and which window, and ask to see the same query run on last month's data. A metric you cannot reproduce is decoration.
How to read all three in ten minutes
Ask for one closed exception from last quarter and follow it. The rule sheet should tell you which version applied on that date. The log should tell you who owned it and how long it stayed open. Named responsibilities should tell you who paid and who still has the photographs.
If those three line up, the dashboard is a convenience. If they do not, the dashboard is the whole product, and you are buying someone else's memory of your business.
FulfillNexa by SBT (fulfillnexa.com) runs inbound, storage and outbound across three warehouses in China, with 3,000 square meters in Shenzhen, 13,000 in Suzhou and 8,000 in Dongguan, and the three documents above are the shape we think a fulfillment relationship should be auditable through. We do not publish rates or transit commitments, and none of the above depends on either.
Top comments (0)