Client name and identifying details have been altered to respect confidentiality. The engineering constraints and outcomes described are representative of work we undertake for organisations in this sector.
A growing retailer was running its sales across a website, fourteen physical stores and two marketplace integrations — but had no single view of orders or stock. The result was spreadsheet reconciliation, frequent oversells and decisions made on week-old data.
Orders arrived through five disconnected channels, each settled on its own cadence. Head office spent the better part of three days every month reconciling them in spreadsheets, and stock levels were only as accurate as the last manual update. Oversells — taking orders for items already gone — had become a regular customer-service headache, and there was no reliable way to see, in real time, which channels or stores were performing.
The business had evaluated off-the-shelf order-management products, but none handled their store-level fulfilment rules or their marketplace quirks without expensive customisation that still left gaps. They needed a system shaped to how they actually operated.
We designed a unified order hub that ingests every channel through a set of resilient, idempotent connectors, normalising orders into a single model. A central inventory service holds real-time reservations so that a sale in one channel immediately reduces available stock everywhere else. An event-driven backbone keeps the channels, warehouse and finance systems in sync without brittle point-to-point links.
On top of the hub we built an operations dashboard giving head office a live view of orders, fulfilment and stock by channel and store, plus automated end-of-day reconciliation that replaced the monthly spreadsheet grind. Stores were brought onto the platform in waves, so risk was contained and feedback incorporated as we went.
All fourteen stores and both marketplaces now flow through one system. Reconciliation that took days is continuous and automated, oversells have all but disappeared, and managers make calls on same-day data rather than last month's. The platform has since absorbed two new sales channels without rework.
If you sell through more than two channels, treat inventory as a shared service from day one. Most multi-channel pain isn't about the channels — it's about the absence of a single, authoritative stock truth. Build that first and everything else gets simpler.
A snapshot of how this work was delivered, for retail and omnichannel organisations evaluating a similar initiative.
Approximately fourteen weeks from discovery to phased go-live, delivered in fortnightly increments with business sign-off at each.
A lead architect, two backend engineers and one frontend engineer, with a client product owner embedded in the team throughout.
An event-driven order hub on Azure, using a strangler-fig migration that kept legacy channels running until each was safely retired.
A single source of truth for orders and real-time inventory, with reconciliation eliminated by design rather than by more staff.
If your channels each keep their own version of "the truth," you do not have an integration problem — you have a data-ownership problem. Solve ownership first with a clear hub and explicit events, and the integrations become straightforward plumbing. Trying to glue channels together after the fact almost always costs more and fails more often, because you are forever reconciling disagreements the architecture should never have allowed.