Every evening at around 8 PM, the owner of a retail chain in Tangerang would receive five phone calls, one from each branch. Each branch supervisor would read out the day's numbers: sales, notable stock-outs, anything unusual. The owner scribbled notes, and by 9 PM he had a picture of his business that was already wrong, because it was assembled from memory, in a hurry, by tired people.
This is a retail inventory visibility case study, but I want to be upfront about the punchline: the fix was not sophisticated software. The chain did not buy an ERP, did not hire a data scientist, and spent less than many companies spend on a single glossy brochure redesign. The fix was agreeing on one source of truth and making every stock number get entered exactly once. The dashboard came after, and it was the easy part.
The details are anonymized, and some numbers are rounded, but the shape of the story is one I have now seen repeat across retail, distribution, and F&B.
The starting point: three versions of the truth
The chain sold household goods across five branches, roughly 2,800 active SKUs, with a central warehouse feeding the branches weekly. On paper they had an inventory process. In practice they had three:
- The POS records, which captured sales but not damaged goods, internal usage, or the informal borrowing between branches that happened whenever one ran out.
- The branch spreadsheets, maintained differently by each supervisor. One used colors, one used a second hidden sheet, one kept half the data in a notebook.
- The evening phone calls, which is where decisions actually got made.
The same carton of goods could be counted differently in all three places. Reconciliation happened monthly, took the admin team about four days, and mostly produced arguments.
The costs were real but diffuse, which is why the situation had survived for years:
| Symptom | Estimated cost |
|---|---|
| Dead stock discovered at year-end (expired, obsolete, forgotten in back rooms) | ~Rp180 million written off in the previous year |
| Emergency restocking (urgent transport for items another branch had plenty of) | Rp3 to 5 million per month |
| Admin time on reconciliation and the nightly call ritual | ~6 person-days per month |
| Stock-outs of fast movers while slow movers piled up | Unmeasured, but the owner's biggest complaint |
If your business recognizes several of these symptoms, you may be past the point spreadsheets can serve you. I wrote a diagnostic for exactly that in 7 Signs Your Business Has Outgrown Spreadsheets.
The wrong fix they almost bought
Before we met, the chain had been quoted around Rp400 million for a full ERP implementation, covering inventory, accounting, HR, and procurement, on an eight-month timeline.
I have nothing against ERPs. But the diagnosis was wrong. Their problem was not missing features. It was that stock data was born in three places and never reconciled. An ERP fed by the same chaotic inputs would have produced the same chaos with better fonts, and the failed implementation would have poisoned the team against the next attempt for years.
The actual requirement fit in one sentence: every stock movement entered once, at the point it happens, into one shared system, visible to head office the same day.
What we actually did
The project took about ten weeks, in three deliberate stages.
Stage 1: agree on the single source of truth (weeks 1 to 3)
This stage involved no software at all. We got the owner, the warehouse head, and all five branch supervisors in one room and settled the questions that had been fought through phone calls for years. Who counts what, when. What counts as damaged versus sellable. How inter-branch transfers get recorded, by the sender or the receiver. What a stock-out means precisely.
The output was a two-page rulebook. Boring to produce, and the single most valuable artifact of the whole project. Every later technical decision was just an implementation of this document.
Stage 2: one entry point per movement (weeks 3 to 7)
We built a simple web app, mobile-friendly, because branch staff worked from phones, with exactly four functions: receive stock, record adjustment (damage, correction), record transfer, and daily spot count for a rotating subset of SKUs. Sales continued to flow from the existing POS automatically.
The design rule was ruthless: entering a movement had to be faster than the old way of noting it for the evening call. Under fifteen seconds per entry. If it were slower, staff would rightly abandon it under pressure, and the "three versions of truth" problem would return wearing new clothes.
The old branch spreadsheets were retired on a hard date, not run in parallel indefinitely. Parallel running feels safe but it means double entry, and double entry is precisely the disease.
Stage 3: the dashboard (weeks 7 to 10)
Only then did we build what the owner had originally asked for: a dashboard showing live stock by branch, fast movers versus slow movers, items below reorder threshold, and stock aging, meaning how long items had been sitting. The nightly phone calls stopped in the first week. The morning coffee habit changed instead: the owner opened the dashboard at 8 AM and called only the branches with anomalies.
Total cost, including the workshops: under Rp120 million, less than a third of the ERP quote.
The results after six months
- Dead stock down roughly 30%. The aging view made slow stock visible in weeks instead of at the year-end count. The chain started running clearance promos while goods were still sellable.
- Emergency transport costs down by more than half, because supervisors could see other branches' stock before reordering from the warehouse.
- Reconciliation dropped from four days to roughly half a day per month, mostly spot-check verification.
- The unmeasurable one: the management meeting changed. Discussions started from a shared screen instead of competing recollections. Arguments about what the numbers were became decisions about what to do.
Not everything went smoothly. One branch's compliance was poor for the first month, and the fix was social, not technical: the owner made the dashboard the only accepted source in meetings, so a supervisor whose numbers were missing had to explain the gap publicly. Compliance followed within weeks.
The takeaway
The lesson of this retail inventory visibility case study is that visibility is not a software feature you purchase. It is a discipline you agree on, then automate. The sequence matters: rules first, single point of entry second, dashboard last. Most failed inventory projects I have reviewed ran that sequence backwards, buying the dashboard first and hoping discipline would follow.
If your evenings involve phone calls that reconstruct what your own business did today, start with the two-page rulebook. It costs a meeting. And if you want an experienced partner to pressure-test the diagnosis before you sign any six-figure software quote, that is precisely the kind of engagement I take on through my partnership work. The cheapest project is the wrong one you did not buy.