Elate Inventory

Domino's India is one of the largest quick service restaurant operations in the country, with thousands of stores selling hundreds of thousands of pizzas a day and roughly 350 SKUs moving through a single store. At that volume, small inefficiencies in how stock is managed stop being rounding errors and start being real money.

And behind every pizza is a supply chain the customer never sees. Material moves through three parties: the commissary dispatches raw material, the store turns it into pizzas, and the store manager sits in between, forecasting need and asking the commissary for the right material at the right time. Inventory isn't one task in one place, it's a journey across all three.

The organisation set a new goal around cost saving, and my team was asked to find where the opportunity was. Rather than start from a screen or a module, we started from a person. We researched the problem from the point of view of a store manager first, then widened to cluster and regional managers the people collectively accountable for a store's revenue and profit.

This was deliberately open-ended. There was no brief beyond "find the opportunity," which is exactly the kind of ambiguity where the framing decides everything.

We went to the ground. Across the study we spent 50+ hours visiting 12 stores, shadowing store managers and staff through a full day to understand how the work actually happens not how the system assumes it happens.

We built a clear picture of the manager's real day (a persona, "Nitin," anchored it) and mapped the pain points across every part of store management: inventory, reporting, payments, order flow, staff. The recurring theme was that the back office ran on paper, memory, and Excel bridging the gaps the system left open ending counts written on physical sheets and re-typed, food-cost variance analysed in offline spreadsheets, KPIs shared to managers over WhatsApp several times a day.

We presented all of this to the CEO. Out of everything we found, inventory was chosen as the first problem to solve the food-cost opportunity was large and the findings were strong.

Inventory was sized by the business as a ~$9.5M annual problem spanning over-indenting (expiry wastage), under-indenting (stock-outs and cancellations), and hours of manual process per store per day with roughly ~$2.4M of it realistically addressable. That number wasn't the design team's to produce, but it framed everything that followed: it's the opportunity the solution was accountable to, and the reason inventory was chosen as the first problem to solve.

The root causes were structural: pen-and-paper delivery acceptance from commissary to store, a slow and error-prone day-end stock count, no tracking or enforcement of first-in-first-out anywhere, and master-data discrepancies between POS and SAP. Underneath the numbers sat three recurring themes: manual work done at odd hours (tiring, slow, error-prone), disconnected and non-assistive tools that forced managers to bridge gaps by hand and carry the cognitive load, and masters out of sync, where system data simply didn't match the store's reality.

Before committing, we weighed two solution directions honestly:

Guesstimate-based automation with buffers. Less to build, but it carried higher wastage and stock-out risk, had no industry precedent for untracked QSR inventory, and left the worst offenders untouched trays alone, which go untracked today, drive 2.5 to 3% losses, far higher than any other item.

Tech-based tracking and measurement. More to roll out and train for, but it meant less wastage and fewer stock-outs, hands-off indenting from real stock, and a path with proven industry precedent (large-format retailers like Reliance and More run on exactly this).

We chose tech-based tracking. It was the harder rollout, but the only one that addressed the losses at their source rather than papering over them with buffers and the tray-loss number made the case impossible to ignore.

Three tenets shaped the design. End-to-end tracking: every item is followed from commissary to store handover to storage to makeline nothing moves unseen. Hands-off indenting: the indent auto-generates from real stock data instead of a manager's guess. Incentivising compliance: high-compliance stores earn flexibility, while others follow more friction-based workflows until their data becomes trustworthy.

We ran multiple product and design sprints, going back and forth on cost, efficiency, and operational reality with the Ops team. The core principle that emerged was simple to state and hard to execute: reconcile inventory at every touchpoint, so the system always knew what was actually in the store rather than reconstructing it once a day from a tired manual count.

Day-end count became a fail-safe, not the source of truth.

Reconciliation at every touchpoint was the principle. The modules are where it became real and where my role was design leadership rather than sole authorship. The screens were designed by two designers I mentored; my job was to set the core philosophy for how the interface should behave, make sure every use case was actually solved, and iterate and reiterate the interaction flows alongside them sometimes designing hands-on myself. The strategy set the direction; this was where the team turned it into something a busy person would complete rather than skip. The deliberate constraint throughout was lowest-cost mechanism first: a simple QR system over expensive hardware, and mobile interfaces tuned so the scan-and-reconcile loop cost seconds, not minutes.

1 · Delivery & stacking

This module covers two tasks that used to be one crush of work: taking the material delivery at night, and stacking it the next morning. A key early decision was to split them deliberately so the burden doesn't fall on a single person at the end of a shift, and the total time is spread across two calmer windows.

At night, receiving. The person taking delivery scans the QR on the challan (previously a manual, paper process) and tallies against the indent. Because it's the middle of the night, the flow is deliberately light: they tally at the box level only, not item by item. If there's a difference between what was indented and what actually arrived, it's recorded then and there not discovered days later during a count.

The next morning, stacking. A different person scans each item's QR on the stacking module, marks it received, and stacks it into cold storage. This is where item-level truth enters the system, at a time when someone can actually attend to it.

Most of the design work here went into the edge cases that are guaranteed to happen on a real floor: what if a QR is damaged or won't scan? The flow lets staff print a fresh QR and map it to the item, rather than dropping the item out of the system. Similar fallbacks were designed across the flow so a broken step never becomes an untracked item. The payoff: by the time everything reaches cold storage, anything missing, ruined, or stolen has already been recorded reconciliation has happened at the door, not at day-end.

2 · Consumption

Once the day starts, the priority shifts to recording consumption in real time tracking every item that moves out of cold storage to the makeline. During prep, each item taken out is scanned through the module on its way over.

The moment an item is scanned, the system starts its expiry countdown shelf life is pulled from the source, so no one has to remember it per SKU. This unlocks the two things that matter most operationally. First, it enforces FIFO in practice: if a staff member reaches for a newer packet while an older one nearing expiry is still available, the system flags it. Second, an expired item can never reach a customer the countdown makes expiry a hard signal, not a judgement call.

The interesting edge case was discard. If "expired" simply removed an item from the system, it would become an easy cover for waste or theft. So the design requires photo proof to discard a discard only goes through when an image of the item is uploaded. It's a small piece of friction placed exactly where it protects the integrity of the data.

3 · Ending count → Stock readjustment

A few deliberate decisions shaped this module. The first was a reframe in name: what stores called the "ending count" we renamed Stock readjustment because with inventory now tracked continuously, its job wasn't to count from scratch, it was to correct the small gaps between what the system believed and what was physically there.

The second was tying frequency to variance. When the new system rolls out, every store does a daily readjustment but as a store's variance drops, its need shrinks, and it earns a lower frequency (say three times a week, or once). Stores that stay above the variance threshold keep doing it daily which isn't a punishment so much as their current reality made lighter (they already count daily today, but on pen and paper, then re-key it into a system).

The third was keeping the input flexible. Staff can start scanning packets, or select and search the item in front of them whichever suits the item and the storage it sits in. And where variance appears, the flow doesn't just log a number: it asks why (over- or under-portioning, wastage), and any discard of expired stock requires photo proof the same data-integrity friction, placed wherever a number could otherwise be quietly fudged.

4 · Indent

Indenting already had an auto-indent before this but nobody trusted it, for two honest reasons: the reconciliation feeding it was unreliable, so its numbers were often wrong, and it lived in a system with poor UX. The concept wasn't broken; it was starved of good data and buried in a bad interface. Now that reconciliation was accurate, the auto-indent could finally be trustworthy but managers had already been burned, so the real design problem was rebuilding their trust, not just regenerating the number.

The core decision was to move indenting onto the phone and make it about accepting and tracking, not data entry. We designed the full lifecycle of a delivery as clear states on the way, arrived, accepting, and so on so a store manager can glance at an incoming indent, add or remove items before accepting, and track deliveries from their phone rather than a clunky desktop tool. The auto-indent is generated for them; their job shrinks to a quick review.

Two guardrails protect the data and, over time, the trust. If a manager edits the indent, the flow gently asks them to double-check because the generated indent is usually right, and most edits are habit rather than need. And edits route to cluster-manager approval, so overrides are visible rather than silent. The intent was to let managers lean on the system a little more each cycle, until checking-and-accepting replaces re-doing.

5 · Live inventory (reporting & health)

This module is the payoff of tracking everything: the idea was to bring inventory reporting upfront to make the live state of a store something you can see and act on, rather than reconstruct from POS, SAP, spreadsheets, and WhatsApp after the fact.

The real challenge here wasn't the dashboard it was finding the bridge between how Ops consume data today and what we wanted them to see. Push too far toward an idealised view and it becomes a report nobody reads; stay too close to the old habits and nothing improves. Most of the thinking went into meeting Ops where they already were and moving them forward from there, rather than imposing a "better" model they'd quietly ignore.

On top of the live view, we introduced a global Domino's store-health score rolling a store's inventory health into a single legible number that made performance comparable and gave the whole system a shared metric to move. We were also exploring smart actionables using GenAI to turn the live data into specific next steps rather than leaving managers to interpret raw numbers as a forward direction for where this reporting layer goes next.

All the tracking and reconciliation in the world only works if people keep doing it under real shift pressure, and that, not the interfaces, was the genuine design risk. So the last piece of the system isn't a screen for a task; it's the behavioural layer meant to make the reconciliation actually stick.

The core idea was a gamification model that worked on two levels at once: an individual layer, where staff earn points for doing inventory tasks well, weighted by quality and care, not quantity, and a store layer, where each person's performance rolls up into a shared store score. Individual effort and collective standing reinforce each other: you play for your own progress and for the store's, so peer accountability is built into the model rather than bolted on as a personal points gimmick. To shape it, we went beyond our own walls, connecting with Ops and with people at other companies who'd run similar programmes, and arrived at a construct with the usual guard rails around it (role calibrated ceilings, quality weighting, fallbacks for when people ignore or game it).

Honestly, this is the piece that advanced the least. It never reached its final stage, the core reconciliation flows took priority, so it stayed largely at the construct level rather than being designed out to the depth of the rest. I'm including it as what it is: a well reasoned model, validated against how similar systems work elsewhere, and the clear next piece of work rather than a finished one.

The design wasn't only screens and flows, it was meant to be a behavioural system built to survive contact with a busy kitchen.

The work was completed through to a finished, test-ready design, with an on-ground store pilot planned to validate it. Before that test could run, an organisational reprioritisation paused the project.

So this is not a shipped-and-measured result, and I won't present it as one. What it is: a fully researched, fully designed systems solution to a ~$9.5M problem, taken from open-ended cost mandate to test-ready over about eighteen months. The value here is the reasoning problem-finding from the ground up, weighing solution directions honestly, lowest-cost systems design, and a behavioural model to make it stick.

Inventory was where I really felt how many masters a design answers to inside a real operational business. Ops constraints, cost, staff behaviour under shift pressure, and a promise of a better customer experience weren't separate considerations to balance politely they collectively drove every decision, from the shape of the system architecture all the way down to a single CTA. A choice that looked right at the interface could be wrong for cost; a flow that was efficient on paper fell apart against how a tired person actually behaves at night. Everything was connected to everything.

The other thing I carry from it is the sheer reiterative nature of the work. There was no clean line from problem to solution it was cycle after cycle of sizing, sketching, pressure-testing against ops reality, and reworking, at every level at once. Learning to hold that much complexity and keep iterating without losing the thread is the real skill this project built in me, and it's the one I lean on most in anything ambiguous now.