How a five-location specialty retailer replaced spreadsheet restocking with a private operating system.
A POS plus an expensive third-party analytics platform still left the operator guessing. Ember Labs connected reporting, purchasing, transfers, and inventory decisions into a single operating layer - built in 6-8 weeks and tuned against the business's real numbers.
Client identity withheld at their request. Operating data verified. Deployment ongoing.
Five-location specialty retailer
- Stack at start
- POS + paid analytics add-on
- Build window
- 6–8 weeks
- Reports live
- ~20
- Status
- Deployed · expanding
Real receipts.
Not a fairy tale.
Numbers below reflect this operator's outcomes within roughly the first 60 days post-launch and the first year of run. Each business is different; we won't promise the top of any range before we know your numbers.
Reports without answers.
The operator wasn't short on data — they were short on the connective tissue between data and decisions. Every week's restock plan was rebuilt by hand, and every month's inventory bill quietly grew.
- 01
Basic POS reports, no real analysis
The point-of-sale offered sales and item exports, but every meaningful answer — what to reorder, what was dying on the shelf, what to move between stores — had to be built by hand from raw rows.
- 02
An $8K–$9K analytics add-on that didn't close the gap
An upgrade to the POS vendor's analytics platform — roughly double the cost of the POS itself — refreshed every two hours and shipped with prebuilt reports, but no practical support for building correct restocking logic.
- 03
One person held the reporting knowledge
Custom reports lived in one team member's head. Variables like restock days and days-of-cover were configured incorrectly, so reorder recommendations were unreliable from the start.
- 04
Trends, dead stock, and transfers were invisible
Without dependable views of fast movers, slow movers, dead stock, transfer opportunities, or pricing competitiveness, decisions defaulted to memory, daily shelf photos, and phone calls between locations.
- 05
Panic ordering and a cash-flow squeeze
Out-of-stocks triggered emergency reorders. Emergency reorders overfilled shelves and back rooms. Inventory nearly doubled. Clearance and blowout cycles followed, and one underperforming category was eventually liquidated at a loss of roughly $100K to free up working capital.
A POS plus a paid analytics add-on is still two tools — neither one tells you what to do next.
- • POS exports refreshed in batches; analytics platform updated every two hours.
- • Prebuilt reports, but no practical support for building correct restocking logic.
- • Restock-day and days-of-cover variables were misconfigured; recommendations were unreliable.
- • Reporting knowledge concentrated in a single team member.
- • Decisions reinforced by daily shelf photos and inter-store phone calls.
- • One dashboard with roughly twenty operational reports, kept current against the live POS.
- • Lead-time-aware restocking with correct days-of-cover, per SKU and per store.
- • Transfer, dead-stock, pricing, and new-item velocity workflows running on the same data.
- • A managed agent inside the dashboard that answers operating questions in plain language.
- • The third-party analytics platform retired; spreadsheet-driven payroll work eliminated.
One dashboard.
Twenty reports. One managed agent.
Built in 6–8 weeks against the operator's own POS data. The agent runs inside the dashboard, trained on the operation, and answers questions in the same place the team already works.
Restocking & purchasing
- Lead-time-aware restocking with correct days-of-cover variables
- Stock-out alerts on every SKU × location
- New-item velocity monitoring with early-warning thresholds
- Vendor purchase-order drafting tied to live demand signals
Inventory health
- Trend analysis across categories, locations, and time windows
- Dead-stock identification with clearance / BOGO / blowout playbooks
- Slow-mover advice with pricing and merchandising suggestions
- Pricing reanalysis against profit and category benchmarks
Multi-location operations
- Transfer reports that move inventory to where it actually sells
- Items frequently purchased together for cross-merchandising
- Employee performance reports without manual spreadsheet work
- A managed agent inside the dashboard for ad-hoc questions in plain language
Inventory normalized.
Cash flow restored.
Within roughly 60 days of launch, the operator's working capital position looked materially different — and the weekly operating rhythm stopped revolving around spreadsheets.
- Inventory normalized from roughly $389K back down to roughly $190K within about 60 days.
- Credit lines used to absorb the inventory swell were paid down as stock turned through.
- Back-room overflow at every location cleared as transfers and clearance plays ran on schedule.
- Transfers between stores became a routine, queued task rather than a phone-tree exercise.
- Reorder recommendations stabilized; panic ordering dropped out of the weekly rhythm.
- The $8K–$9K/year third-party analytics platform was retired without a gap in reporting.
- Roughly $115K in office and admin payroll tied to spreadsheet rebuilding and order-guessing was eliminated.
From dashboard to operating layer.
The roadmap moves the operation from reporting to action. Each capability ships once it can be verified against the business's real numbers, with humans reviewing exceptions.
- 01Item creation in the POS
The system drafts new items from vendor catalogs and receiving documents, then queues them for review.
- 02Purchase orders, end-to-end
POs are generated against live demand and lead times, then emailed to vendors with the right line items and quantities attached.
- 03Transfers as work, not meetings
Inter-store transfers are created automatically and dispatched as tasks to the right employees at the right locations.
- 04An operating layer, not just reports
Each capability moves the operation toward increasingly autonomous retail operations, with humans reviewing exceptions instead of typing the same numbers twice.
Direction of travel: increasingly autonomous retail operations, with humans approving exceptions instead of typing the same numbers twice. The standard is observable, audited progress against the operation's real numbers — not headline automation percentages.
