optivento

where a 2% cost change
moves profit 29%

Restaurants run on margins thin enough that small waste is existential. The data to prevent it already exists, in a POS, a supplier invoice, a paper prep list. It is just never in front of the person at the moment they decide. That gap is the product.

try the prototype see the research
my role
Research & product strategyProduct architectureInteraction design & UI
research
12 in-depth chef interviewsAcross restaurant types
users
Head chefs & kitchen managersOwner-operators
status
Graduate capstone, not shippedSept 2023 to May 2024
The Optivento dashboard on a tablet, showing live inventory levels, shipment tracking and account status.

READ THIS FIRST. Optivento is a self-directed graduate project. It was never launched, so there are no production metrics on this page. What follows is what the research established and what I designed from it. The figures further down are industry benchmarks and modelled projections, and each one says which.

the leverage is absurd,
and nobody can reach it

A 2% saving is made of a hundred small decisions taken at 6am.

Take a restaurant doing $1M in sales on a 3.5% profit margin, roughly $35,000 of profit. Cut non-labour costs by 2% and profit rises by about 29%, near $20,000 straight to the bottom line.

That is the entire business case, and it is why inventory software exists at all. The reason it keeps failing is not that operators don't understand the maths. It is that the saving is made of a hundred small decisions taken at 6am by someone with flour on their hands, and none of those moments have the numbers attached.

the margin arithmetic $1,000,000 annual sales 3.5% margin ≈ $35,000 profit −2% non-labour cost ≈ $20,000 recovered +29% profit same sales, same staff Industry benchmark figures, not measured by me. The design question is why this leverage stays out of reach.

Industry benchmark arithmetic. The point isn't the numbers, it's that the leverage sits in ordinary daily decisions, not in a strategy meeting.

twelve chefs, and one answer
that kept coming back

I interviewed twelve chefs across different cuisines and restaurant sizes about how they actually manage inventory, prep and recipes. I expected to hear that the software was bad. What I heard was that the software was irrelevant, because the work happens somewhere it can't see.

“There is a need for a structure. I think this place will benefit more from an organisational structure.”
Lexie · sous chef
“Whether it's a special event, a busy lunch rush, or a regular workday, this initial planning phase is crucial to ensure everything runs smoothly.”
Sanya · head chef
A professional restaurant kitchen during service, where the interviews took place.

Interviews ran in kitchens rather than over calls, which is how the paper became visible.

effects Waste & over-ordering ordering to feel safe Inconsistent pricing cost drifts, menu doesn't Handover loss longer shifts, repeat work No visibility till month end problems found too late Operational inefficiency the decision has no data attached root causes Work strategy lives on paper prep lists, stock counts, handovers Communication is verbal WhatsApp, shift talk, memory Neither cause is a technology gap. Both are a record-keeping gap, which is why adding another dashboard doesn't close it.

Problem tree, redrawn from the interview affinity map. Two root causes, four effects, one core failure — and the useful insight is that both roots are about where the record lives, not about analytics.

the obvious product was a
dashboard. that's the one that fails.

an analytics dashboard for the owner

Charts of cost, waste and margin, refreshed daily. It demos beautifully and it changes nothing, because the person looking at it is not the person deciding how much cabbage to order on Thursday. Every chef I spoke to had access to reports they never opened.

Rejected: wrong person, wrong moment

digitise the prep list

Replace paper with an app and let structure follow. Closer to the real behaviour, but it makes the kitchen pay a data-entry tax up front for a benefit that arrives weeks later. Nothing survives a lunch rush if it costs time during one.

Rejected: cost now, value later

attach the number to the moment

Let the system track stock on its own wherever it can. The till already knows what has been sold, the camera can read a delivery note, the supplier already sends an invoice. Then show the cost only at the moments the kitchen is already deciding something: placing an order, pricing a dish, changing a recipe. The staff never enter data for its own sake, because every time they do, they get an answer back straight away.

built

data → insight → action,
inside one workflow

Three principles held the architecture together, and each one exists to stop the product becoming another reporting layer.

capture without asking

POS integration draws inventory down as dishes sell; the device camera reads barcodes and delivery notes. The kitchen's manual logging burden had to fall, not rise, or nothing else mattered.

cost propagates through the recipe

When an ingredient price moves, every dish containing it re-costs immediately, so a margin problem shows up as a menu item rather than as a month-end surprise.

every insight ends in an action

A low-stock signal becomes a pre-filled reorder; a cost spike becomes a suggested price. Insight without an adjacent action is just another notification.

Two tablet screens: an auto-generated reorder list with quantities, and the POS integration setup flow.

Reordering is generated from consumption rather than composed by hand. The chef edits a proposal instead of building a list.

Menu manager: editing a dish and seeing its ingredient cost update.
Sales reporting alongside inventory reordering.

Left: changing a recipe shows the margin consequence in the same screen. Right: sales and stock read together, because separately neither answers what to order.

Using the device camera to scan stock into inventory.

Camera capture designed for one hand, in motion, in a kitchen: large targets, immediate confirmation, no keyboard.

What this would be worth, if it were built.

8–12%

projected reduction in food waste

15–20%

projected improvement in inventory accuracy

~30%

projected reduction in manual logging time

MODELLED, NOT MEASURED. Projections from published industry benchmarks for comparable inventory systems, applied to the workflows observed in the twelve interviews. No version of Optivento has run in a live kitchen, and I would not present these as results.

what this project
does not prove

nobody used it during service

Twelve interviews establish the problem well. They do not establish that this solution survives a Friday night, which is the only test that counts in a kitchen.

passive capture is an assumption

The whole architecture rests on stock drawing down accurately from POS and camera input. In practice that degrades — substitutions, comps, staff meals — and I have not designed the recovery path for when the count goes wrong.

I scoped it too wide

Inventory, pricing, sales reporting, menu management and forecasting is four products. If I restarted, I would build only the reorder loop and earn the rest.

the project I learned
the most from

It never shipped, and working out why taught me more than the parts that went well. I would cut the scope to the reorder loop, run the research toward a live service test rather than another set of interviews, and earn every feature after that one. Happy to talk through the whole of it.

back to the research see more work