Articles
Order fulfilment automation: what to automate first
Order fulfilment automation should start with the address, not the label printer: the order of work, the costliest failure, and what stays human.
- fulfilment
- automation
- logistics
Order fulfilment automation usually begins at the label printer, because that is the visible part: a parcel appears, a label comes out, the queue moves. The work runs the other way — address, order, stock, manifest, paperwork — and each step is worth automating only once the one before it holds. Done out of order, the same failure just reaches the customer sooner.
Where does fulfilment automation actually start?
At the address, because every later step depends on it. Aclean address is not a text box: it is a wilaya and a commune chosen from lists, a landmark written in words a driver can follow, and a phone somebody answers. Free text pushes the decision to the doorstep, where the driver holds the parcel and cannot ask a question.
The test is blunt: could a driver who has never delivered here find the door from the record alone? If the answer depends on calling, the record is incomplete.
Why is the parcel that cannot be delivered the most expensive failure?
Because it is paid for several times and produces nothing. Stock leaves the shelf, the courier charges for the trip out, the return costs the trip back, and the goods come back in a condition somebody must assess. None of those costs appears in an order count.
The cause is usually not a refusal. It is an address nobody could find or a phone that rings out: a customer who moved, a digit missing, a landmark only the writer understood. Each is cheap to prevent at ordering.
So the first automation worth building is not dispatch but validation at entry: lists instead of free text, a required landmark, a backup number, and a rule that refuses an order the courier cannot reach.
What must be true before a courier sees the order?
Three things: the order is confirmed, the stock is reserved, and the address passed the test above.
Confirmation means somebody has reached the customer and the customer still wants the goods; without it you are shipping hope. Reservation holds the units to the order when it is confirmed, not when it is picked, or the next order for the same item is picked against stock already promised. And the address test runs before the manifest exists, because once the parcel is in a bag the only repair left is at the door.
| Step | What automation does | The precondition |
|---|---|---|
| Address | Lists, required landmark, backup number | A driver can find the door |
| Order | Records the confirmation | The customer still wants it |
| Stock | Holds the units to the order | The count is trusted |
| Manifest | Generates the handover document | Every parcel has your reference |
| Settlement | Matches the batch to an amount | The courier reports per parcel |
That sequence is the order of cost: a broken confirmation costs a delivery, a broken address costs that and the stock.
What has to stay a human decision?
Everything where a rule would have to guess, and everything where someone's money moves without a record behind it.
That means the substitution offered when an item is short, the cancellation of a confirmed order, how many attempts are worth paying for, a discount at the door, a delivery to an address the record contradicts, and whether a customer who refused twice deserves another try. These are not failures of automation; they are points where a decision lands on a person, and a rule that chooses for you will choose wrong often enough to cost more than the time it saves.
What it needs is a record: who decided, what, and why. An override with no reason is indistinguishable from a mistake.
How does the loop close after delivery?
With a reconciliation that ends in an amount, not a status.
Four links: the manifest you handed over, the status of each parcel on it, the settlement paid against a batch, and the returns that never became sales. A courier reporting "delivered" with no amount leaves the loop open; a lump-sum settlement with no batch detail leaves it open from the other side. The parcel reference joins them, so you generate and print it. Where a manifest is exchanged as a document rather than read as a PDF, UBL 2.1 defines a despatch advice for it.
Returns belong in the loop with a reason attached: "address not found", "refused at the door" and "damaged in transit" point at three different fixes.
When does automation stop helping?
When the bottleneck moves to packing. Order automation compresses the time between an order and a manifest, which is the part that was rarely slow. If the constraint is a person putting items into boxes, or a shelf layout that makes the picker walk, a faster manifest only builds a queue at the packing table.
The signal is a measurement, not an opinion: how long a confirmed order waits before packing, and how long it waits after. When the second wait is the longer one, the next improvement is physical — a pick list ordered by shelf, an extra pair of hands at the peak — and the software will keep reporting success while the queue grows.
In what order do you do this?
- Take the last month of orders and list the ones that failed, with a reason for each: that list is the specification.
- Fix the address fields first: wilaya and commune as lists, landmark required, backup phone offered.
- Move confirmation before dispatch, with a state dispatch can read, and reserve stock at confirmation so the shelf and the promise agree.
- Generate your own parcel reference and print the manifest yourself.
- Agree the statuses in writing, including what counts as an attempt and what a settlement line contains.
- Reconcile on a fixed day for a full cycle, then automate the paperwork the reconciliation proved stable.
- Measure the wait before packing before buying anything else.
Where this goes wrong
- The label printer comes first. The visible win, automating the step that already worked.
- The status list is invented at the courier's convenience. "Delivered" and "delivered and paid" are different facts.
- A failed delivery is retried by a rule. Without a person deciding, the next attempt repeats the first mistake at full price.
- The courier produces the manifest from a spreadsheet you emailed, so the identifier is theirs and cannot be queried next year.
What this does not cover
It does not choose a courier or say what a delivery should cost; that depends on zones, volume and risk. Nor does it design a warehouse beyond the packing note. And it assumes the volume justifies a system: at low volume, a good order form and a weekly reconciliation are enough.
We build fulfilment as a chain — a validated address, a confirmed order, a held reservation, a manifest you own, and a settlement that closes the loop — and automate each link only once the one before it holds.
Services in this article
Articles
Related articles.
Cash on delivery is an operations problem, not a payment option
Cash on delivery is a cash-handling operation with a delivery step attached. What to record, how to reconcile, and where the money quietly goes missing.
- ecommerce
- delivery
- logistics
Work out delivery cost before you set a price
Delivery is priced per parcel you hand over, but it is paid per order that arrives. How to build a cost per delivered order before you set a price.
- delivery
- pricing
- ecommerce
Invoice exception handling: where automation succeeds or fails
Invoice exception handling automation decides whether the pipeline survives: who owns each exception, what the system records, and what is not approved alone.
- invoice-automation
- exceptions
- operations
Start a project
Have something to build?
One short brief is enough. You get a written scope and a fixed quote before anything starts.
