On time in the warehouse, late on Amazon
A client calls, worried. Their late shipment rate on a marketplace has jumped, and they risk losing selling privileges. You check: every one of those orders left your warehouse on the day it was placed. The problem is further along. The tracking numbers either never reached the marketplace, or arrived the next day, or arrived with a carrier name the marketplace did not recognise.
Nobody noticed because each system reported success at its own step. Your WMS sent the dispatch update. The client's order management tool received it. Somewhere between that tool and the marketplace, it stopped.
Why confirmations get lost
The dispatch confirmation travels through several connections owned by different parties. Each one has its own way of failing, and none of them tells the warehouse.
| Point of failure | What goes wrong |
|---|---|
| WMS to client platform | Connector token expired, update rejected |
| Carrier name mapping | Carrier code not in the marketplace's list, so tracking is not valid |
| Split shipments | Only the first parcel's tracking is sent |
| Order management tool to marketplace | Batch sync runs late or fails |
| Order number mismatch | Marketplace order reference not carried through |
The warehouse is rarely at fault, but the client sees the warehouse as the source of dispatch data and asks you first.
What the gap costs
For the client, marketplace metrics that affect their account health, buy box and in some cases their right to sell, as well as customers who cannot track their parcel. For you, a client relationship that suffers from a problem you did not cause but cannot prove you did not cause.
It also wastes your team's time. Investigating a batch of 'late' orders by hand means looking up each one in three systems.
End customers feel it too. A parcel with no tracking on the marketplace generates a 'where is my order' message to the seller, even though the parcel is already moving, and some of those turn into claims that the item never arrived.
The fix clients sometimes reach for is to take marketplace orders away from you and send them to a fulfilment service they think is more reliable. Losing volume over a data problem is the worst outcome of all.
The confirmation check we build
- A record of every dispatch from your WMS: order, parcels, carrier, service, tracking numbers and dispatch time.
- A check of each channel's view of the same order, through the marketplace or platform APIs where the client authorises access, or through their order management tool.
- Mismatch detection: missing tracking, missing parcels, carrier codes not recognised, late updates.
- Automatic correction where permitted: resending tracking, mapping carrier names to the codes each marketplace accepts.
- Alerts to the client and your team for anything that cannot be corrected, with the order list and the point of failure.
- A daily report per client showing dispatch time in your WMS against confirmation time in each channel, which is the evidence when metrics are questioned.
What you end up with
Confirmations that are checked, not assumed. Carrier code problems fixed once, rather than rediscovered per order. And a daily record that shows exactly when each order left you and when the marketplace heard about it.
Signs this is affecting your clients
- Clients report late shipment metrics for orders you shipped on time.
- Split shipments show only one tracking number to customers.
- Carrier names appear as 'other' on marketplace orders.
- Connector failures are discovered by clients, not by you.
- Investigating a late shipment complaint means checking three systems.