Integrating warehouse systems with your online store

Customers judge an online store by what happens after they click “buy”. Whether their order ships on time depends on something they never see: the connection between the store and the warehouse. If the warehouse management system receives orders late, incomplete or not at all, nothing else in the operation can compensate. A warehouse that cannot see orders in time cannot ship them in time.

Integration between ecommerce platforms and warehouse systems is often treated as a technical detail, handed to developers late in a project. It deserves more attention than that. This guide explains how to define, test and run the connection so that orders flow reliably, stock stays accurate and problems are caught before customers notice them.

What has to flow, and in which direction

At its simplest, the integration carries four types of message. Each must be defined clearly, because ambiguity in any one of them shows up later as lost orders, wrong stock or confused customers.

• Orders, from the store to the warehouse: what to pick, pack and ship, to whom and by which service.
• Stock levels, from the warehouse to the store: what is available to sell, by product and location.
• Shipments, from the warehouse to the store: what was dispatched, when, with which carrier and tracking number.
• Returns, in both directions: what the customer is sending back, and what the warehouse received and in what condition.

In many businesses an ERP or order management system sits between the store and the warehouse, which adds a step to each flow but also a useful point of control. Whatever the architecture, draw it on one page, showing every system and every message, and agree it with everyone involved before any development starts.

Step 1: Define the data

For each message, agree the content field by field. This sounds tedious, and it is the step most often rushed. It is also where most integration problems begin.

Take orders as an example. Which identifier will both systems use for an order? How are product codes matched between the store’s catalogue and the warehouse’s item master? How are bundles, gift wrapping, personalisation and gift messages represented? How are delivery services mapped to carriers? What happens to address lines that exceed the warehouse system’s field lengths? Each answer should be written down.

Stock needs equal care. Agree whether the warehouse sends total stock or available stock, net of orders already allocated. Decide how often updates are sent: on every movement, every few minutes or in periodic batches. Decide how stock that is damaged, quarantined or awaiting inspection is treated. A mismatch here is a common cause of overselling.

Step 2: Test with real orders

Integration testing often uses a handful of simple orders: one item, standard delivery, paid by card. Those orders almost always work. Problems hide in the exceptions, and the exceptions are where customers get hurt.

Build a test set from real orders, drawn from your own history, that covers the awkward cases. Then add the scenarios your business has not yet encountered but plausibly will.

1. Orders with many lines, mixed delivery methods and items from different locations.
2. Partial shipments, where some items ship now and others later.
3. Cancellations before and after the warehouse has started picking.
4. Address changes after the order has been sent to the warehouse.
5. Out-of-stock situations discovered during picking.
6. Bundles, kits, personalised items and gift options.
7. Orders with very long names, addresses or non-Latin characters.
8. International orders requiring customs information.
9. Returns of part of an order, and returns of items in unsellable condition.

For each scenario, check the result in every system: the store, any ERP in between, the warehouse system and, where relevant, the carrier. Confirm that the customer receives the right messages and that finance sees the right transactions. Involve warehouse staff in testing, because they will spot practical problems developers miss.

Step 3: Monitor the connection

Integrations fail. Networks drop, systems are updated, certificates expire, a new product is created with a code the warehouse does not recognise. The question is not whether a message will fail, but whether anyone will know when it does.

The worst failures are silent. An order that never reaches the warehouse looks, to the store, like an order that is being processed normally. The customer finds out first, days later, when it has not arrived. Every integration needs monitoring that makes failures visible quickly.

• Alerts on every failed or rejected message, sent to a named person or team.
• A daily reconciliation comparing orders placed with orders received by the warehouse.
• Alerts when expected messages stop arriving, such as no stock updates for an hour.
• A dashboard of orders by status, highlighting any older than expected at each stage.
• A simple process for correcting and resending failed messages.

Agree response times for each type of alert. An order failure during peak trading needs attention within minutes. A delayed stock update overnight may wait until the morning.

Review the monitoring itself every quarter. Alerts that fire constantly for harmless reasons train people to ignore them, which is almost as dangerous as having none. Tune thresholds so that every alert is worth acting on, and remove ones that no longer serve a purpose.

Step 4: Plan go-live and peak

Go live at a quiet time, with extra support in place in the warehouse and the technical team. Run the new integration alongside careful manual checks for the first days, reconciling every order. Agree in advance what you will do if something goes wrong, including how to fall back to the previous process.

Before your first peak, test the integration at realistic volumes. A connection that handles normal days comfortably may queue or time out when order volumes triple. Load testing with the warehouse system provider is far cheaper than discovering the limit on the busiest day of the year.

Owning the integration after go-live

Once live, integrations are often left without a clear owner. The ecommerce team assumes IT is watching; IT assumes the warehouse provider is; the warehouse provider assumes the store will report problems. Name one person accountable for the integration’s health, with access to monitoring, a direct line to each system’s support team and authority to escalate.

That person should also own change. Any change to either system, such as a new delivery service, product type or platform upgrade, should be checked against the message specification and tested before release.

We used to find out about failed orders from customer complaints. Now an alert reaches the right person within minutes, and most issues are fixed before anyone outside the team knows.

Operations manager, online homeware client

Your next step

Whether you are planning a new integration or living with an existing one, start by drawing the flows on one page and checking that a message specification exists for each. Then run a daily reconciliation of orders placed against orders received by the warehouse for two weeks. If the numbers do not match, you have found where to start.

Source: Intelliversal analysis.

Frequently asked questions

Should stock updates be real time?

Stock should update quickly enough to prevent overselling at your order volumes. For many businesses, updates every few minutes are sufficient; high-volume sellers or those with scarce stock may need event-based updates on every movement.

Who should own the warehouse integration?

One named person, usually in operations or IT, who has access to monitoring, contacts at each system provider and authority to escalate issues and approve changes.

How do we know if orders are being lost?

Reconcile orders placed in the store with orders received by the warehouse every day, and set alerts for any failed or rejected message.

Explore Digital supply chain and fulfilment integration