The moment a business sells through more than one channel, it acquires a problem that looks like a technology problem and is really a decision problem: several systems each hold a retail stock figure, each is internally consistent, and none of them agrees.
Pick one source of truth for retail stock
There must be exactly one system that owns stock. Every other system reads from it and none of them decide independently.
Which one depends on where goods physically move. If everything ships from one warehouse, the warehouse system should own it. If most sales are in-store, the till system probably should. What matters far more than the choice is that it is made explicitly and then respected, including when it is inconvenient.
The failure mode is a compromise where each system owns stock “for its own channel”. That is not a source of truth, it is four of them, and reconciling four is not a solvable problem.
Allocation is the part that gets skipped
Knowing you have twelve units is not enough. Some are reserved against an order that has not shipped. Others sit in a customer’s basket. A few are in transit between locations. The rest are damaged and awaiting write-off.
A system that reports twelve available when four are already committed will oversell, and overselling online is more damaging than showing out of stock, because it converts a lost sale into a disappointed customer and a refund.
Model reserved stock explicitly. Then decide how long a basket holds a reservation. That figure is a commercial decision, not a technical one, and someone in the business should own it.
Latency, and what to do about it
Real-time stock across every channel sounds like the goal and is often the wrong target. Marketplaces impose their own update frequencies, and pushing every movement instantly to every channel creates load and rate-limit problems for very little gain.
The practical approach is a buffer. Hold back a small quantity from online channels so that the last few units are not sold simultaneously in three places. It is inelegant and it works, and it is what most experienced operations end up doing.
Reserve genuine real-time updating for the few products where it matters: high value, low quantity, or heavily promoted lines.
Returns break the model
Stock systems assume goods flow outwards. Returns flow the other way and rarely get the same attention.
A returned item is not immediately sellable. It needs inspecting, possibly repackaging, and sometimes writing off. If a return automatically increments available stock on receipt, you will sell something that is sitting in a box waiting to be checked.
Give returns their own state between received and available, and make someone responsible for moving items out of it.
Reconcile against reality, regularly
However good the integration, physical stock and system stock drift. Breakage, theft, miscounts, items put back in the wrong place.
Rolling cycle counts, a small section counted frequently, beat an annual full stocktake. They find discrepancies while the cause is still identifiable, and they do not require closing.
Track the size of the discrepancy over time as a measure of process health. A number that is getting worse tells you something specific is wrong upstream.
What to build first
One system owning stock, everything else reading it, a buffer on online channels, a proper state for returns, and a weekly count of a rotating subset.
That is unglamorous and it removes most overselling. The clever optimisations are worth having afterwards, not instead.
This is the shape of most of our retail and CPG work, and it usually sits at the intersection of system integration and the point-of-sale hardware feeding it.
Further reading: GS1 standards define how product and location identifiers are structured, which is what makes retail stock reconcilable across channels rather than only inside one system.
In short
Pick one system to own stock. Then make every other system read from it.
Model reserved stock separately. Otherwise you will oversell, and a refund costs more than a lost sale.
Hold a small buffer back from online channels. It is inelegant. However, it works, and most experienced operations end up doing it.
Finally, count a rotating subset every week. Small counts find problems while somebody can still explain them.
Related reading
- Manufacturing: getting shop-floor data into the office without a rewrite — Shop floor data usually lives on paper and in one person’s head. Getting it into the office rarely needs a new system, just one reliable capture point.
- Financial services: audit trails as a design requirement, not a feature — Audit trails added late are just logs. Designed in, they answer who changed what, when, and what the value was before. What that actually requires.
- Redesign or rebuild? How to tell which one you actually need — A redesign changes how a site looks; a rebuild changes how it works. How to tell whether you need a redesign or rebuild before the budget is set.