Sumo: turning a restaurant's chaos into a system that runs itself

I owned product strategy and rollout for Sumo — a smart-restaurant platform built for environments where volume is brutal and margins are thin: university canteens, factory cafeterias, and a national telco's inventory floor. My mandate was end-to-end: define the wedge, sequence enterprise deployments, and own the metrics that proved the system worked on a real lunch line — not in a demo kitchen. The job wasn't to ship another POS. It was to stop money leaking at every seam.

High-volume kitchens ran on disconnected parts: a POS here, a manual weigh station there, cameras nobody watched, inventory reconciled on paper at close. Billing errors, waste, theft, and queues out the door were treated as the cost of doing business. At thousands of meals a day, a 2% error rate isn't a rounding error — it's a budget line. Leadership knew they were losing money; they couldn't see where. Floor staff knew the systems were wrong; they kept paper backups because they didn't trust the screen.

I scoped Sumo as a single nervous system — POS, CC cameras, digital weigh machines, and conveyor belts wired into one AI-watched platform. The wedge wasn't "more integrations." It was one workflow simple enough that a busy line cook would actually use it. Each deployment site had to become proof for the next. I sized the prize before we expanded features: fewer billing errors, less waste, faster throughput. Every spec tied back to a number the ops team already cared about.

IoT in the real world is brutal — a scale that drifts, a camera that drops, a belt that jams at lunch rush. Every stakeholder lobbied for their feature; I held the line on reliability before breadth. The war wasn't the hardware demo. It was making the system trustworthy enough that staff abandoned their paper backup. We ran site-by-site rollouts, fixed drift and downtime at each location, and refused to expand until daily active use on the floor was real — not signed off in a conference room.

We deployed across 3 large universities, 2 manufacturing organizations, and the biggest telco inventory floor in the market — 17 enterprise sites total. Once staff trusted the system, the numbers followed: ~40,000 meals/day processed at peak, billing and queue errors down ~90%, food waste down ~25%. The metric I watched closest was adoption — speed followed trust, not the other way around.

I'd still start with one site, one rush hour, one workflow — and make that perfect before the roadmap meeting. Enterprise buyers want breadth; floor staff want something that works when the queue is out the door. I'd also instrument distrust earlier: how often did staff reach for paper? That signal predicted success better than any pilot survey.