This omnichannel inventory case study starts with a complaint I hear constantly from retail owners: "we sold the same item twice and now I have to apologize to a customer." For an anonymized fashion brand selling across two marketplaces, Instagram, and three physical stores, this was not an occasional embarrassment. It was a weekly occurrence, and it was quietly costing them more in refunds, cancelled orders, and reputation damage than most of their marketing budget was earning them back.
The brand had grown fast, adding sales channels the way most Indonesian retailers do: a marketplace storefront here, an Instagram shop there, a couple of physical locations opened as the brand gained traction. Each channel tracked its own stock. Nobody had designed this as a system, it had simply accumulated, channel by channel, over two years.
By the time they came to us, the pattern was clear and painful: a dress sells out in Store A, but the online marketplace still shows it in stock because nobody updated that count in real time. A customer orders it online, the order gets confirmed, and then someone has to call the customer to say it is actually unavailable. Multiply this across hundreds of SKUs and multiple channels, and you get a business bleeding trust one cancellation at a time.
The Actual Cost of Disconnected Stock
Before proposing anything, we quantified what disconnected inventory was actually costing them, because "it's annoying" is not a business case and "it's costing us X per month" is.
- Cancelled orders. Roughly 8 to 12 percent of online orders in their busiest month required cancellation due to phantom stock, each one costing not just the lost sale but a refund processing cost and, more damagingly, a one-star review pattern forming on their marketplace accounts.
- Dead stock. Items sitting in one store's back room for months while another store or channel showed them as sold out and turned away demand. Capital sitting still instead of moving.
- Manual reconciliation labor. Two staff members spent a combined 15 hours a week manually cross-checking stock counts across spreadsheets and marketplace dashboards, work that produced no new revenue and was already stale by the time it was finished.
- Marketplace penalty risk. Repeated cancellations on major marketplaces trigger seller-rating penalties that reduce visibility in search results, compounding the original problem by suppressing future sales too.
None of this showed up as a single line item on their P&L. It was distributed across refunds, labor, and suppressed sales, which is exactly why it had gone unaddressed for two years. Nobody was looking at "inventory sync" as a cost center because it did not present itself as one.
Designing the Single Source of Truth
The fix was not a new POS system or a marketplace migration. It was establishing one inventory source of truth that every channel reads from and writes to, with allocation rules layered on top so channels do not simply compete for the same units in a race condition.
The architecture had three parts:
- Central inventory ledger. A single database holding real, physical stock counts per SKU per location, updated the moment a sale, return, or transfer happens anywhere in the business, whether that is a POS terminal in a physical store or a marketplace order webhook.
- Channel allocation rules. Not every unit gets shown everywhere. The business set allocation percentages per channel for fast-moving SKUs (for example, 40 percent of a hot item's central stock visible online, 60 percent held for the two highest-performing physical stores), so a single channel spike cannot silently starve the others.
- Real-time sync to channel-facing systems. Marketplace listings and the Instagram shop catalog pull live availability from the central ledger via API, instead of someone manually updating counts once a day. The lag between an item selling and every other channel knowing about it dropped from hours to seconds.
This is the same underlying discipline as choosing a POS system: what matters after the demo, applied at the inventory layer instead of the checkout layer: the tool matters less than whether it is the single place truth lives, with everything else reading from it rather than maintaining its own parallel version of reality.
What Changed After Sixty Days
The business measured results over two months post-launch, comparing against the same period the prior year adjusted for seasonal demand.
| Metric | Before | After 60 Days |
|---|---|---|
| Order cancellation rate | 8-12% | Under 2% |
| Manual reconciliation labor | ~15 hrs/week | Under 2 hrs/week |
| Dead stock value (est.) | Rp 180M sitting idle | Rp 60M, actively redistributing |
| Marketplace seller rating | Declining | Recovering |
The cancellation rate drop alone justified the project. But the more durable win was the freed-up labor: the two staff previously doing manual reconciliation moved into demand forecasting and channel-specific merchandising, work that actually grows revenue instead of just preventing embarrassment.
What This Case Study Generalizes To
The specific technology mattered less than the principle: every business selling across more than one channel eventually hits this wall, and the businesses that survive it are the ones that stop treating each channel's stock count as its own island. If you are running two marketplaces and a physical store today with separate stock tracking, you are almost certainly living some version of this brand's before-numbers, whether or not you have measured it yet.
The build itself does not have to be enormous. Most of the cost is in getting the allocation rules right for your specific sales pattern, not the technical plumbing, which for most SMEs is a matter of weeks, not months, once the central ledger design is settled.
If this pattern feels familiar and you want a second opinion on where your channels are actually leaking, partner with ervandra.com to look at the real numbers before committing to a rebuild.
The Practical Takeaway
If you are selling on more than one channel with separate stock counts, you are not managing inventory, you are managing a coordination problem between systems that do not talk to each other. Build the single source of truth first, layer allocation rules on top, and the cancellations, dead stock, and manual reconciliation labor drop together, because they were always the same root cause wearing different costumes.