Online order, warehouse and courier: which system owns which data

A customer ordered through the website, and an hour later emailed to say they would rather have it delivered to the office, not home. Whoever read the email corrected the address in the shop. The courier label had been printed half an hour earlier with the old address, and the parcel went where the customer was not.

Nobody made a mistake there. The address existed in two places and was changed in only one. That is the heart of every problem between an online shop, a warehouse and a courier: the same data lives in several programs, and people carry it across by hand.

Every piece of data has one owner

Before connecting anything, decide which system is in charge of which data. In charge means the data is changed only there, and every other system receives it from there. It usually looks like this:

• The order and customer details: the shop, or whichever program processes orders. An address change goes there and nowhere else.
• Stock and price: the warehouse program. The shop shows them but does not change them.
• The shipment and its status: the courier. The business sends the shipment details and gets back a tracking number and delivery status.
• The invoice: the invoicing program.

Once this is written down, half of the conversation about integration is done. What remains is which route the data takes from its owner to the rest, and when.

Stock on the website is a promise

When the shop shows an item as in stock, that is a promise to the customer. If website stock is updated by hand, once a day or “when someone gets round to it”, goods that may already be gone are sold in between.

So stock should flow one way, from the warehouse to the shop, and be reduced or reserved as soon as the order arrives, not only once it is packed. Otherwise two orders arrive for the last unit, and both are confirmed.

The same goes for price. A discount entered only on the website, and not in the program that issues invoices, means the customer sees one price on the invoice and paid another. Someone then fixes it with a credit note and a new invoice, and the customer remembers having to call. If the warehouse program owns the price, the discount goes in there, with a start and end date, and the website only displays it.

Exceptions decide whether the automation works

An ordinary order that arrives, gets packed and leaves is easy to automate. The work is in the exceptions, and those are what need listing before anything is connected:

• Cancellation after packing. Who stops the parcel, and how do the goods from the unpacked box become available on the website again?
• A change of address or phone number. Until when is it possible, and who checks whether the label has already been printed?
• Partial delivery. One item is out of stock. Does the whole order wait, or does what is available go out, and what is the customer told?
• Payment method. Cash on delivery and payment in advance mean different conditions for dispatch. The system has to know which applies.
• Returns. Goods come back, and with them the question of money. A return should be tied to the order and the shipment, not to an email in someone’s inbox. We covered the deadlines that start running then in every complaint has a deadline.

If an exception has no answer, integration will not invent one. It will just deliver it faster to the point where it gets stuck.

Where the order gets retyped today

Take one ordinary order from last week and follow its path: the shop, the warehouse or invoicing program, the courier’s app, the message to the customer. Wherever someone typed the same data again, put a mark.

Integration starts where the marks cluster. Most often that is passing the order to the warehouse, because that data is retyped for every single order, and a mistake copied there goes straight into the parcel. How a warehouse catches that kind of mistake while the goods are still on the packing table is covered in where warehouse mistakes are really made.

Before connecting anything, also check with your courier whether and how they accept shipments from another program, and how they report delivery status back. The answer decides whether labels are printed from your system or from theirs.

When this is in good enough shape

The sign that the flow is sorted is not a nice screen but quiet. Nobody rings the warehouse to ask whether the parcel went out, nobody types a tracking number into a message to the customer, and nobody corrects an address in two places.

A list of data owners and exceptions is the best way into designing a system that carries an order from the website to the customer. Our system design and build service includes moving your existing data across, so you work with a full database from day one. Tell us which programs you use today.