Home · Solutions · Operations & quality
Solution · Operations & qualityThe wholesale order is computed from sales, not from memory after a fourteen-hour shift
Supplier orders driven by sales
A robot reads the till sales, converts them into usage by your rules and assembles order proposals for each supplier: with minimums, pack sizes and cut-off times. The chef corrects and approves on a phone; the sending happens by itself, each order in its supplier’s format.
Executive summary
Supplier orders are made late at night, from memory and a glance into the fridge; the result is shortages mid-service, surpluses for the bin, and purchasing that depends on the form of one tired person.
The robot computes proposals from actual sales and usage rules, respects each supplier’s minimums and cut-offs; the chef approves on a phone, and the sending and delivery checks happen by themselves.
Mid-service shortages and binned surpluses fall visibly, the late-night dictating disappears, and the owner sees purchases set against sales for the first time, week by week.
till sales (export or API); usage rules and minimums; orders by email or supplier portals; delivery checks in Microsoft Teams
Business problem
Purchasing from memory, at midnight
In hospitality, supplier orders are a daily decision about real money: too much means waste and the bin, too little means “sorry, we’ve run out” in the middle of Friday service. Despite those stakes, the process looks the same in most small places: late at night, after close, somebody tired dictates or clicks through orders from memory, propped up by a glance into the fridge.
Memory after fourteen hours of work is a poor storekeeper. It forgets the Wednesday group of eighteen, the Monday rocket still on the shelf, the salmon moving faster than usual this week. And every supplier has its own rules: one takes orders until 10 p.m. for the day after tomorrow, another sells in five-kilo multiples, a third only through a portal that logs you out after five minutes.
Shortages and surpluses are not the only cost. There is dependence: the whole of purchasing lives in one person’s head, and that person’s holiday or illness means a week of improvisation. And there is ignorance: nobody sets purchase costs against the week’s sales, so food cost is computed once a month, from invoices, when it is too late to react.
Deliveries close the picture: they arrive in the morning, mid-prep, and rarely does anyone check them line by line against the order. Shortages surface in service, price mistakes in the invoice, and claims do not exist, because there is nothing to compare against.
How it works today
Below is what the work looks like before anything is automated.
- PersonOrders dictated after close, from memory and a glance into the fridge
- Risk of errorMemory knows nothing of Wednesday’s bookings or the salmon’s pace
- PersonEvery supplier has different cut-offs, minimums and channels; the chef’s head keeps them
- WaitingShortages surface mid-service; surpluses on Monday by the bin
- Risk of errorDeliveries accepted without comparison to the order; no claims, for there is nothing to compare
- Risk of errorFood cost computed once a month from invoices, when reaction is too late
Why the current process costs more than it appears
The bill that never shows up in a budget.
- A binned surplus is a wholesale purchase carried to the bin; in hospitality that starts at a few percent of turnover.
- A shortage in service costs twice: the lost dish, and the guest who remembers “they ran out”.
- Purchasing in one head is operational risk: that head’s holiday stops the process.
- A delivery unchecked against the order is an invitation to shortages and quiet price rises.
Cost of inaction
The first row is a cautious model of ingredient losses from over-ordering and poor rotation; hospitality audits often show more. You will see your own number after a month of setting purchases against sales.
The third row counts the hour of work, not its hour of day; the cost of decisions taken daily at 11:15 p.m. by a tired person fits in no spreadsheet, but every owner knows it.
A model organisation with realistic proportions – the numbers exist so you can run the same maths on your own data; they are not a client result.
A restaurant with a café: 70 covers, six days a week, three main suppliers and two supplementary, a till with a sales export, Microsoft 365.
Orders dictated in the evening by the chef; around 75 orders a month; weekly service shortages, a Monday bin for surpluses.
Deliveries accepted on the run, uncompared; food cost known once a month.
The chef’s holiday means a week of purchasing improvisation.
Every evening the robot reads the till sales, converts them into usage by the rules (menu items into key purchase lines), factors in declared stock from a quick check, bookings and the day of week, and assembles proposals per supplier with minimums and cut-offs; the chef corrects on a phone and approves; sending goes by email or portal, and at delivery a checklist compares lines against the order.
In the modelled case ingredient losses halve, service shortages become rare, and the late-night dictating hour disappears. Model numbers, not the restaurant’s records.
Proposed solution
We start with your usage rules: we do not build full recipe costing, but a practical translation of sales into the key purchase lines, the ones that really lose money: proteins, dairy, fresh vegetables, bread. Add each supplier’s minimums, pack sizes, cut-offs and channels, and a calendar of events: group bookings, day-of-week seasonality.
Every evening the robot computes the proposals: the till says what sold, the rules say how much of what that used, and a quick declared stock check (two minutes with a phone at the fridge, critical lines only) closes the arithmetic. The chef receives ready lists per supplier; corrects what he sees fit, and approves. Sending happens by itself, each order in its recipient’s format, before the cut-off.
At delivery, the receiver ticks a checklist on a phone: what came, what is missing, what changed price. Differences immediately become an emailed claim to the supplier, not a discovery in service. The owner sees purchases set against sales weekly: a first live approximation of food cost, not a month after the fact.
UiPath Orchestrator: the evening schedule, the order queue, retries and an audit trail; UiPath Integration Service connectors for Microsoft Teams and Outlook 365
Usage rules for the key lines, proposals per supplier with minimums and cut-offs, phone approval, sending in the recipient’s format, delivery checklists and the weekly purchases-to-sales summary
Till sales via export or API; orders by email or supplier portals; lists and reports in Microsoft Teams
How the automated process works
- AutomationEvery evening the robot reads the till sales and converts them into usage by the rules
- PersonThe quick declared stock: two minutes with a phone at the fridge, critical lines only
- AutomationProposals per supplier: with minimums, pack sizes and the cut-off time
- PersonThe chef corrects and approves on a phone; the decision remains his
- AutomationSending happens by itself, each order in its supplier’s format, before the cut-off
- PersonAt delivery a checklist; differences immediately become a claim
Human-in-the-loop model
Automation handles
- Converting sales into usage and the order proposals per supplier
- Sending on each supplier’s cut-offs and formats, plus delivery checklists
- The weekly purchases-to-sales summary
People decide
- The usage rules, the menu and the purchasing decisions; a proposal is a proposal
- Approving every order and adjusting for special events
- Choosing suppliers, negotiating prices and deciding claims
Before and after
Systems and integrations
The stack is short on purpose: one engine, one execution layer, one place where a person decides.
Inputs
- till sales (export or API)
- usage rules and supplier minimums
- declared stock of critical lines
- bookings and the events calendar
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- approved orders sent to suppliers
- delivery checklists with differences
- the weekly purchases-to-sales summary in Microsoft Teams
Human touchpoints: order approvals on a phone; delivery checklists; the weekly summary; a rules review at menu changes
Technologies used
the evening schedule, the order queue, retries, a record of every order
Aapprovals, email sending, checklists, reports
Ausage rules, supplier minimums and the order history
Athe sales source; popular tills and POS systems have exports
Bsending where a supplier requires a portal; scope depends on the portal
BIllustrative economic model
Numbers you can check against your own data.
The model does not promise zero waste, because hospitality is living matter; it assumes a halving through arithmetic instead of memory. Volumes and percentages belong to the scenario; your own numbers go into the calculator alongside.
Run the maths on your data
An illustrative estimate based on your inputs. It models freed capacity, not promised savings.
Business benefits
- Orders are computed from sales; memory stops being the storekeeper
- Service shortages and the Monday bin become exceptions
- Supplier cut-offs, minimums and formats watch themselves
- Deliveries are compared with orders; differences go straight back to the supplier
- The owner sees purchases against sales weekly, not once a month
The management view
- Purchasing stops depending on one head and its form at 11:15 p.m.
- The history of orders, deliveries and differences builds your position with suppliers
- A second venue is a set of rules to copy, not a second tired head
Board-level KPIs
ingredient losses to purchases · service shortages weekly · time spent on orders daily · delivery-to-order differences · the approximate weekly food cost
Security and governance
The automation has exactly the permissions it needs. Not one more.
- The robot works on operational data: sales, lines, quantities, purchase prices; no guest personal data
- Every order has a record: proposal, corrections, approval, sending, delivery
- Usage rules and minimums are versioned; the kitchen changes them, not the automat
- Purchase prices and margins are seen by the owner and those he designates
- Data stays in your Microsoft 365 tenant; the robots run in the EU region of UiPath Automation Cloud
Why now
Ingredient prices are high and volatile; every kilo in the bin costs more than ever.
Hospitality margins forgive nothing: two points of food cost is often the difference between profit and topping up.
Kitchen staff are scarce; a chef’s hour at midnight is a resource that must not be spent on dictating.
Relevant executive roles
Sees purchases against sales weekly and stops financing the bin
Finishes work when the kitchen closes, not after three calls to wholesalers
Ticks a phone checklist instead of trusting that “everything came”
Common questions and objections
The rules concern purchase lines, not dishes: salmon, butter and rocket stay while dishes change. A new dish is one correction in the rules, and the proposal still passes through the chef’s hands, and he sees next week’s menu better than any system.
Part of the market works that way, and it does not block the process: the robot still prepares computed lists, and a human makes the call, reading from a ready list in two minutes instead of dictating from memory in fifteen. Where a supplier has email or a portal, that call disappears too.
And there is none in this process: the declared stock is two minutes at the fridge, critical lines only, often a dozen items. The rest is computed from sales. This is not a warehouse system; it is arithmetic that takes the most expensive decisions off memory.
When this is not the right solution
- A venue with one supplier and a five-item menu: a sheet of paper and routine suffice
- No sales export from the till at all: first a till with data, then computing from it
- Expecting full recipe costing and gram-level stock: this is practical arithmetic, not an ERP
A question for the next management meeting
How much did we spend last month on ingredients that ended in the bin, and who made those decisions at 11:15 p.m.?
Implementation approach
Scope without ambiguity, before anything is signed.
We deliver
- Usage rules for the key lines and a profile of every supplier
- Evening order proposals with phone approval
- Sending in the suppliers’ formats and cut-offs
- Delivery checklists with automatic claims for differences
- The weekly purchases-to-sales summary and two weeks of parallel running
We need from you
- The till’s sales export and the supplier list with their rules
- Two hours with the chef to write down the key lines’ usage rules
- The team’s agreement to the two-minute declared stock and the delivery checklist
Stages
Discovery
Suppliers, cut-offs, minimums, channels; the scale of shortages and the bin
Rules
Key lines, usage factors, the events calendar
Build
Sales reading, proposals, approvals, sending, checklists
Parallel run
Two weeks: proposals beside the dictating, results compared
Go-live
Orders move to the process; a rules review after a month
A quick win. Effort depends on the till and the suppliers’ channels: a till export and email orders are the shortest path; supplier portals join step by step.
Friday, 7:40 p.m.: “we’re out of salmon”. Monday, 9:10 a.m.: rocket into the bin. Both decisions were made on Tuesday at 11:15 p.m., from memory.
Send us a week’s sales export and your supplier list. We return a draft of usage rules for your key lines and the arithmetic of the losses that mere computing stops.
Count the week’s shortages and surplusesThe neighbouring process usually has the same problem
Attendance in a notebook, meal charges from attendance, parents’ bills by hand. Every month.
See the solution Finance & accountingCost invoices to the accountant without the binderOn the fifth the accountant asks about missing invoices. The inbox hunt begins.
See the solution Management & planningThe owner’s morning report in one messageYesterday’s takings, today’s staffing, overdue payments. One message instead of three systems.
See the solutionIndustries where we deploy this most oftenSmall business & services