Case study · Warehouse and retail operations · Aug to Oct 2026

Five files.
Now one WMS.

A plush toy brand sold through 8 stores of 3 retailers, and its stock lived in five files that never talked to each other. I connected warehouse, shipments, field visits and sell-out into one system on Google Sheets and Apps Script, as the operations lead, with AI writing the code.

Ferdy Febrian IskandarOperations and dataJakarta

2:00 walkthrough. Animated scenes use sample data; real-screen clips come from the live board with retailer names and values blurred.

16% → 28%of stock on store shelves, first measured 22 Aug, 27.7% on 8 Oct

8stores across 3 retailers, served from 1 warehouse

43active SKUs on one movement ledger

Rp0licence cost per month

The problem

Five files, five answers

XLSXSKU master.xlsx

Total stock

2,277

XLSXPO principal.xlsx

Incoming

+360

SHEETSStock HO

Total stock

2,239

SHEETSDaily sales

Total stock

1,979

XLSPartner sales.xls

Sold

The stock count on 14 August gave three different totals for the same warehouse. Every number was typed again by hand, deliveries to stores had no proof, field visits could not be checked, and partner reports arrived as PDF or Excel in a different shape each time. So the ask was simple: connect it all.

What I built

One flow, shelf to sell-out

1INBOUND

Every carton gets a slot

The principal's PO lands in X-IN. Each carton is scanned into a rack location, and anything not put away stays visible as overflow.

Warehouse condition page with stock at HO, storage and overflow totals — Warehouse condition: scans feed the location master.

2WAREHOUSE CONDITION

Every shelf, accounted for

A live map of racks, tables and stacks with fill levels. Quantity per rack has to match HO stock, and every count correction is logged with who, when and why.

Location map with rack slots and fill bars — Location map: slot, SKU, quantity against capacity.

3OUTBOUND

Pick, pack, prove it

Pickers scan the slot first, then the SKU. A delivery order cannot be issued when the store requires a PO number and none is entered.

Warehouse outbound page with picking, packing, staging, transit and delivered counts — Outbound: picking to delivered.

4SHIPMENTS

Closed only on receipt

Every shipment moves through five stages and only closes when the store confirms it arrived, so a stalled parcel shows up the same day.

Shipments at a glance with open, in warehouse, on the road and received — Shipments at a glance.

5FIELD OP APP

From the shelf, straight to the board

Store staff use a phone app that writes to the same ledger.

Check-in only inside 300 m of the store, with a selfie
Shelf counts become ledger rows, variances flagged
Shelf photos trigger a Google Chat alert
Check-out computes hours on site

Operational PIC work log with days worked, stores visited and selfies — Field work log, counted from the app.

6SELL-OUT

Every sale, one ledger

Partner sales reports in PDF or Excel are read into ledger rows, so sell-out per store and SKU is visible, including the SKUs that never sold.

SKU performance with core SKUs, never sold and share of units sold — SKU performance.

Inventory page showing 2,572 pieces owned and 28 percent on store shelves — 7 · The board: inventory, 28% on store shelves

Sales page with monthly units and best-selling SKUs — 7 · The board: sales by month and SKU

How I built it

Built by ops, powered by AI

I own the rules

The data model and the business rules that must never break are mine. A few of them:

No PO number, no delivery order.

A count correction is logged, never overwritten.

No check-in outside 300 m of the store.

AI writes the code

I describe the behaviour and the rule, AI writes the Apps Script, and every change gets a test that is first shown to fail before the fix goes in. I deploy and run production functions myself.

Built on what the team already uses

No new licence and no IT team. One movement ledger is the source for every number on the board.

Google SheetsApps ScriptGoogle ChatExcel scan station