In most online stores, an order's journey to the customer is automated only as far as the moment it's paid for. Then a person takes over: opens the carrier's portal, retypes the delivery address, picks a service, prints a label, sticks it on, and copies the tracking number back into the system so it can be sent to the customer. At ten orders a day that's an annoyance. At a hundred it's a full-time job doing nothing a machine couldn't do.
Fulfilment is the last stretch where time can be saved without the customer feeling it negatively — and the first place where they spot a mistake immediately, because they see it on their own parcel.
What can be automated in fulfilment
The process has four steps that build on each other, and each has a different difficulty and a different payback.
1. Choosing the carrier and service. In most stores the customer decides at checkout, but not always — for larger consignments, international orders or cash on delivery, a rule on the merchant's side decides. Those rules can be written down and evaluated by the system: weight, dimensions, destination country, payment method, and whether it goes to an address or a pickup point.
2. Creating the shipment and label. This is the part most people picture when they hear "shipping automation". The system sends the data to the carrier's API, gets back a tracking number and a label to print. It saves retyping and, more importantly, removes address typos.
3. The handover manifest. At the end of the day the carrier needs a summary of consignments. Most carriers expose this in their API, so it can be generated automatically rather than by clicking through a portal.
4. Tracking status back. This is the step that gets skipped most often — and paradoxically delivers the biggest saving. If shipment status (collected, in transit, delivered, failed attempt, returned) flows back into the system automatically, the reason for anyone to look something up by hand disappears.
Where the effect is largest
| Step | Time saved | Errors avoided |
|---|---|---|
| Rule-based carrier selection | small | medium — wrongly chosen services disappear |
| Creating the shipment and label | large | large — address typos disappear |
| Handover manifest | medium | small |
| Tracking status back | large (in support) | large — the customer doesn't have to ask |
It's worth noticing where the saving lands. The first three rows save warehouse time. The last one saves customer support time — and that's the department that never asks for shipping automation, because it doesn't see it as its own remit.
What needs to be ready
Shipping automation isn't an isolated integration — it needs clean inputs from the preceding steps.
- A validated delivery address. If the customer types an address as free text with no checks, the carrier's API will reject it or, worse, accept it with an error in it. Validating at checkout is cheaper than a delivery complaint.
- Real product weights and dimensions. Without them you can't pick a service or calculate a shipping price. This tends to be the biggest obstacle, because catalogues often lack these values or have them estimated.
- A clear order status. The system has to know when an order is ready to ship — otherwise it creates a shipment for goods that aren't in stock. We cover this in our article on automating order processing, and inventory management follows on from it.
- Rules for exceptions. Fragile goods, oversized items, timed delivery, destinations outside the EU. These cases should go to a person, not into the automated flow.
What happens when the carrier's API goes down
This question rarely appears in a brief and almost always appears in production. Carrier interfaces aren't available one hundred per cent of the time, and outages arrive at the worst possible moment — in the seasonal peak, when order volumes are highest.
The fix isn't complicated, but it has to be planned in advance:
- A queue instead of a direct call. The request to create a shipment goes into a queue and the system retries it. Nothing is lost during an outage; it's just processed later.
- Visible state. The warehouse has to see which orders are waiting for a label and why — not just that "nothing is happening".
- A manual fallback. For critical consignments there must be a way to create the shipment in the carrier's portal and enter the number back into the system.
- An alert. Somebody has to learn that the queue is growing before the customer does. We go into this in more depth in our article on monitoring and fallback scenarios.
One carrier, or several?
With a single carrier the integration is straightforward. With several, the question becomes whether to connect each one individually or go through an aggregator that offers one interface for multiple carriers at once.
Direct integration gives full control and access to all of that carrier's services, but every additional carrier is another integration to maintain. An aggregator simplifies the start and adding further carriers, but introduces a dependency on a third party and usually doesn't expose every carrier-specific service.
The decision depends on how many carriers you genuinely need and how heavily you use their specific services. We discussed the same reasoning about depending on an intermediary layer in our piece on connecting ERP, CRM and an online store.
Summary
Shipping automation pays off earlier than most companies assume — not because of label printing, but because of the status flow back, which takes load off customer support. It presupposes a validated address, real weights and dimensions, and a clear order status. And from day one you should assume that the carrier's API will, at some point, stop answering.
The scope of a project like this depends mainly on the number of carriers, the state of your product data, and whether fulfilment is handled in the store or in a warehouse system. If you're weighing up a specific setup, we'll go through it in a no-obligation consultation.