Restaurant operations where every order, sent-back dish and comp has an owner — from the kitchen to the check

Mi Retail is an operations center for restaurants, bars, cafés, quick-service chains and dark kitchens. It does not replace the POS or the kitchen display; it manages the human work that appears around them. Every order that must reach a table, every dish a guest sends back, every comp, refire, broken piece of equipment or supplier shortage becomes an Operational Work Item with an owner, a state, a due time and evidence. Each person sees what is theirs: the line sees tickets and refires, servers see plates to run and issues at their tables, the floor manager sees decisions waiting, and the owner sees only the exceptions. The domain work — orders, payments, recipes, food cost — runs in StoneOS apps or in the systems you already use.

No. Your POS stays the system of record for orders, checks, payments and tips, and your kitchen display keeps running the line. Mi Retail never charges a guest or prints a ticket. What it adds is the layer those systems were not built for: the work that has to happen when an order needs a person beyond the normal path. A returned dish, a comp that needs approval, an 86’d item that affects open tables or a cooler that stops holding temperature becomes a work item that travels between the kitchen, the floor and management until it is resolved. You keep your POS; Mi Retail takes over where the work leaves it and records who did what, and when.

When a guest sends a dish back, the server logs the return from the table with a photo and the guest’s reason, and that opens an exception work item linked to the original order. The kitchen receives the refire as a priority ticket tied to the same case, so the discarded plate and the new one never get separated. The floor manager sees the return in their queue, reviews the evidence, talks to the guest and approves the comp from the work item, with the reason recorded. The cashier then closes the check in the POS with the comp applied, and after service the head chef logs the waste against food cost. Every step has an owner, a state and a trace.

The order is entered in the POS as usual and reaches the kitchen display as a work item for the line. When the cooks bump it, the server who owns the table sees the plates ready to run; when they are delivered, the work item moves on, and the cashier sees the check ready to close when the table asks for it. Most orders flow through without anyone noticing Mi Retail at all, because the normal path is fast. The value appears when something breaks that path — a ticket sitting too long, a missing plate, a table waiting on a decision — because the work item already has an owner and a state, and the delay is visible instead of discovered by the guest.

A comp, void or discount above what a server may decide becomes an approval work item in the manager’s queue, with the table, the item, the photo and the reason attached. The manager approves or rejects it from the work item, and the decision is recorded with who made it and when. Only then is it applied in the POS, so every comp on the check has a matching decision behind it. Owners and area managers can review comps by reason, by dish and by manager, and a pattern — the same plate returned every Friday, one shift comping far more than the others — stops hiding inside the daily sales report.

When the kitchen runs out of an item, the 86 is recorded in the menu system and Mi Retail turns its consequences into work: the servers with open tables that ordered it get a follow-up to offer an alternative, and purchasing or the chef gets a request to restock before the next service. At a shift change, everything the outgoing team left open — a guest promised a callback, a refire still pending, a fryer waiting for a technician — is already a work item with a state and an owner. The incoming manager starts from Today and sees what is waiting, blocked or due, instead of reading a notebook in the middle of the rush.

Food cost is usually reviewed after the fact, from sales and inventory numbers that do not explain why a dish cost more than expected. Mi Retail keeps the reasons: every comp, returned plate, refire and discarded batch is a work item with its photo, its cause and who approved it. When the head chef or the owner reviews food cost, they start from those cases instead of guessing, and recurring problems — a recipe that keeps coming back, a station that wastes more, a supplier whose product spoils early — become findings with an owner and a follow-up. The numbers themselves live in the Food Cost and Waste apps of StoneOS or in your current system; Mi Retail makes sure someone acts on them.

Yes, when they have their own organization on Mi Retail. A short produce delivery, a wrong case of wine or a walk-in cooler that stops holding temperature can be sent as a derived work item that lands in the supplier’s or technician’s own intake queue. They assign it inside their own team, and you follow its state, due time and result without seeing their internal work; they, in turn, see only what you shared with them. When they close their part — a credit note, a replacement delivery, a repair report with photos — your work item is updated and can close. The exchange stops living in phone calls made from the back door during service.

Each role gets its own surface on the same operation. Cooks and servers work from My Work, which shows only the tickets, refires, plates and table issues that are theirs right now. The floor manager and the kitchen manager use Team Operations to see what is unassigned, late or blocked in their area and to reassign it in seconds. The general manager of a location looks at Operational Portfolio to see how service, returns and open issues are trending. The owner or the head of a group uses Executive Operations, which shows only what needs a decision at that level. Nobody has to dig through a feed of everything that happened to find what matters to them.

Yes, it is the same product at both ends. In a small café where the owner cooks, serves and closes the register, the experience collapses to one Today view with what is pending, what is waiting on a supplier and what must be solved before tomorrow’s opening, without teams or hierarchies that do not exist. In a group with many locations, a central kitchen or several brands running from shared dark kitchens, the same work items are split across stations, locations and area managers, and exceptions escalate to the right level. Area managers can compare locations side by side. What changes is how responsibilities are divided, not the way the work is represented.

The Food & Beverage edition of StoneOS brings apps for the domain work of a restaurant — Venues, Menus, Recipes, Tables, Reservations, Orders, POS, Kitchen Display, Bar Display, Tabs, Tips, Food Cost, Waste, and Delivery & Takeaway — on top of the Business Core apps every team uses, such as Chat, People, Calendar, Sheets and Drive. Those apps keep the depth of each domain: the POS takes the order, the kitchen display runs the line, Food Cost holds the numbers. Mi Retail is where the work they generate meets the people who must move it: a returned dish, a comp to approve or a waste spike lands as a work item in the right queue. If you keep your current POS, it stays the record.

Start with the one thing that keeps slipping during service — usually returns and comps, or shift handovers — instead of modeling the whole restaurant. Create a workspace for the floor and one for the kitchen, invite the managers and the people on shift, and let the next returned dish or equipment failure arrive as a work item with an owner and a due time. Within a couple of weeks you will see which dishes come back, where decisions wait and who carries the load. Then add purchasing and suppliers, connect the POS you already use and, when it makes sense, bring in the Food & Beverage edition apps from StoneOS. Mi Retail is free to start, so one location can try it before a whole group adopts it.