How to automate order fulfilment: the exceptions are the job

An order arrives, stock is available, a label is generated, the customer is notified. That path is straightforward to automate and it is not where the work is. The work is in the orders that do not follow it, which is a larger proportion than most people estimate before they measure it.

Partial availability, stock that is not where the system says, an address that will not deliver, a customer changing something after dispatch — these are the cases that determine whether fulfilment automation saves effort or creates a new category of problem that surfaces at the customer.

What we'll cover

• The happy path is not the problem
• Stock that is not where the system says
• Partial availability and splitting
• Building it with CodeWords
• Addresses that will not deliver
• Changes after the order
• Telling the customer
• Returns, which are the other half of fulfilment
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

The happy path is not the problem

Measure your exception rate before designing anything, by category, since it is the number that determines what to build.

Exceptions concentrate. A small number of products, destinations or order shapes produce most of them.

Each exception costs disproportionately — a person, a decision, often a customer contact.

Automating only the happy path leaves exactly the expensive work manual and makes it less visible, because it now arrives as a trickle rather than a queue.

Some exceptions should be prevented rather than handled, which is a merchandising or a data decision rather than a fulfilment one.

Handling one well is worth more than automating the straightforward path twice as fast.

Stock that is not where the system says

Counts drift through damage, theft, mispicks and returns processed incorrectly.

Overselling is the visible symptom, and it is the worst customer experience in ecommerce because it happens after their money was taken.

Reserve at order, not at dispatch, or two orders will claim the same unit.

Handle the multi-location case explicitly, since aggregate availability across warehouses is not the same as availability for one shipment.

Set a buffer on fast-moving items, which costs some sales and prevents the more expensive failure.

Reconcile continuously rather than at a periodic count, and treat a discrepancy as an alert rather than a correction to apply silently.

Partial availability and splitting

Decide the default deliberately: ship what is available, hold the whole order, or ask the customer.

The right answer varies by order, so the rule should consider value, the customer's history, and how long the missing item will take.

Splitting costs shipping and may cost margin, so the threshold where it stops making sense should be explicit.

Ask the customer for high-value orders, where the decision matters enough to be worth a message.

Never split silently. A customer receiving one of three items with no explanation contacts support immediately.

Track the second shipment to completion, since the most common failure here is a back-ordered item that quietly never ships.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so the store, the inventory system, the carriers and the customer notifications can meet in one workflow.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: the fulfilment rules, the exception handling, and who is told about what.
3. Authorize the connections — the store platform, the inventory or warehouse system, and the carrier accounts.
4. Describe the exceptions: partial availability, an address that fails validation, an order changed after placement, a high-value order.
5. Run it against last month's orders and check which would have taken each path.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Addresses that will not deliver

Validate at checkout, which is the only moment it is cheap to fix.

Suggest rather than silently correct, since an auto-corrected address that is wrong produces a lost parcel and a confused customer.

Know the destinations you cannot serve before taking the order, including the ones inside countries you do serve.

Handle the unit or apartment number, which is the most common cause of a failed delivery and the most commonly omitted field.

Check against the carrier's rules, since what is valid as an address and what a specific carrier will deliver to are different questions.

Catch the mismatch between billing and delivery countries, which matters for both fraud and duties.

Changes after the order

There is a window between order and dispatch where changes are cheap, and it is usually short.

Say how long it is, in the confirmation, which prevents most of the contacts.

Cancellation before dispatch should be automatic, since making somebody wait to cancel produces a refused delivery and a return instead.

Address changes need care — they are also a common fraud pattern, and a change to a different country especially so.

Adding items usually means a second order, which is easier than modifying the first and should be offered rather than debated.

After dispatch, be honest. Telling somebody it has gone and explaining the return route beats an attempt to intercept that usually fails.

Telling the customer

Confirm immediately, with what was ordered and when it is expected.

Say something when the expectation changes, which is the message that prevents the contact.

One notification per event, not per carrier scan, since a stream of tracking updates trains people to ignore all of them.

Give a date, not a status. "Out for delivery" is less useful than an arrival estimate.

Be first with bad news. A delay the customer discovers from a tracking page is worse than the same delay explained by you.

Make the tracking link work for somebody who is not logged in, which is where a surprising number of these flows break.

Returns, which are the other half of fulfilment

Returns are built last and are a large share of the work in most categories. Automating them well affects the outbound side too, because the reasons are a defect report.

Make initiating a return self-service, since the manual version costs a support contact for something that needs no judgement.

Ask why, in structured categories rather than free text, because the reason is the valuable part and free text does not aggregate.

Distinguish the reasons that matter: wrong item sent, damaged, not as described, changed mind. The first three are your problem and the fourth is not.

Send the label automatically where your policy allows, and state the refund timing honestly since that is the most common follow-up question.

Restock deliberately. An item returned to stock without inspection is an oversell waiting to happen and occasionally a second complaint.

Report reasons by product, weekly, to whoever chooses and describes them — a product with a high "not as described" rate is a listing problem that costs shipping twice on every order.

Making it survive

Make everything idempotent on the order, since duplicate labels and duplicate shipments are expensive mistakes.

Never dispatch twice. Check state immediately before acting.

Handle carrier API failures by queuing and retrying rather than failing the order.

Reconcile daily: orders placed, fulfilled, and outstanding, with anything stuck flagged by age.

Report the outcome: orders processed, exceptions by category, and the age of the oldest unfulfilled order.

Limits worth knowing about

Carrier APIs differ substantially in reliability and in what their tracking statuses mean.

Cut-off times are real and an order arriving after one is a day later regardless of what the automation does.

International shipping adds customs, duties and documentation, which are a different problem rather than an extra field.

Inventory accuracy has a ceiling set by your physical processes, and no software improves a warehouse's counting.

Peak periods break assumptions, particularly carrier capacity and delivery estimates, which is worth planning for rather than discovering.

What to build first

The exception report: every order that did not follow the happy path, by category, with an age. It changes nothing operationally and it tells you which exception is actually costing you — which is almost never the one people assume, and which determines everything else worth building.

Two habits make the difference. Reserve stock at the point of order rather than at dispatch, since overselling is the worst failure in this whole system and it is a straightforward one to prevent. And never split an order silently, because a customer receiving part of their order with no explanation will contact you, and that contact costs more than the message you did not send.

Frequently asked questions

What should I automate first in fulfilment?

Not the happy path. Measure the exception rate by category first — the exceptions are where the cost is, they concentrate in a small number of products and destinations, and each one costs a person's time and usually a customer contact.

How do I prevent overselling?

Reserve stock at the point of order rather than at dispatch, handle multi-location availability explicitly, and keep a buffer on fast-moving items. Overselling is the worst failure in ecommerce because it happens after payment.

Should a partial order be split or held?

It depends on value, the customer, and how long the missing item will take. Decide the rule deliberately, ask the customer for high-value orders, and never split silently — that guarantees a support contact.

What is the most common cause of failed deliveries?

A missing unit or apartment number. Validate addresses at checkout, suggest corrections rather than applying them silently, and check against the carrier's rules as well as general address validity.

How should order changes be handled?

State the change window in the confirmation, make pre-dispatch cancellation automatic, treat address changes carefully since they are a fraud pattern, and offer a second order rather than modifying the first.

How many shipping notifications should a customer get?

One per meaningful event, not one per carrier scan. Give an arrival date rather than a status, and be first with bad news — a delay discovered on a tracking page is worse than the same delay explained by you.

What happens if stock counts drift?

They always do, through damage, mispicks and returns processed incorrectly. Reconcile continuously and treat a discrepancy as an alert rather than a correction applied silently, since the silent version hides the cause.

Can automation fix inventory accuracy?

No. Accuracy has a ceiling set by your physical processes, and software can surface discrepancies faster but cannot improve how a warehouse counts.

Should returns be part of fulfilment automation?

Yes, and they are usually built last. Self-service initiation removes a support contact for something needing no judgement, and the structured return reasons are the most useful defect report in the business.

What do return reasons tell me?

Which problems are yours. Wrong item, damaged and not as described are operational or listing failures; changed mind is not. A product with a high "not as described" rate is costing shipping twice on every order.

Why does peak season break fulfilment automation?

Because it breaks the assumptions underneath it — carrier capacity, delivery estimates and cut-off times all change, and rules tuned in a normal month quietly produce promises you cannot keep.

Related reading

• Automating Shopify orders to Google Sheets
• Automating refund processing
• Automating abandoned cart emails