Forward-Deployed Engineering · Restaurants · Demand planning and kitchen prep
Case study: tomorrow's demand, this morning's prep sheet, today's supplier order
Illustrative engagement — not a client record. The company, people, volumes and results below are a representative composite, written to show how a forward-deployed engagement runs end to end. The workflow, the architecture, the controls and the method are real and technically valid.
Offering usedReadiness & Scoping SprintTwo weeks inside your systems; one workflow scoped in writing.
Illustrative results, first 90 days after cut-over, in-scope outlets only:
26%
Forecast error on the top 40 prep items, per outlet per daypart (WAPE)
Before 41%
6.1%
Pre-consumer food waste, share of food cost, outlets with digital waste logs
Before 7.9%
6%
Outlet-days with a stock-out of a top-20 item before 9 pm
Before 12%
9 minutes
Manager time to build the daily indent, median
Before 40 minutes
FDE / PlayExplainer
09 scenes
The whole story in about a minute
Nine short scenes, from the morning guess to the results. Press play, or pick a scene.
01 — Morning guess
Every morning, the kitchen guessed.
Before opening, a shift lead decided how much chicken to marinate and rice to cook, from memory and last week's sales. On one outlet-day in eight, a top-20 item ran out before dinner ended.
Read chapter 1At a glance
- Client
- A quick-service and casual-dining chain with 126 company-run outlets in eleven cities, three regional central kitchens and a large delivery business
- Workflow
- Forecast item demand per outlet per daypart; produce the morning prep sheet; draft the central-kitchen and supplier indents that the outlet manager approves
- Engagement
- Readiness & Scoping Sprint (2 weeks), then Production Sprint (6 weeks)
- Team
- One named senior forward-deployed engineer, full time. Client side: the Head of Supply Chain (owner), a supply planning analyst, a data engineer, two area managers, a security reviewer
- Where it runs
- The client's own cloud account and region. No data retained outside it
- Handover
- Runbook executed by the client's team in week six; our access revoked the same day
| Measure | Before | After |
|---|---|---|
| Forecast error on the top 40 prep items, per outlet per daypart (WAPE) | 41% | 26% |
| Pre-consumer food waste, share of food cost, outlets with digital waste logs | 7.9% | 6.1% |
| Outlet-days with a stock-out of a top-20 item before 9 pm | 12% | 6% |
| Manager time to build the daily indent, median | 40 minutes | 9 minutes |
| Indents sent without a manager's approval | not applicable | 0, by design |
FDE / 01Case study
01 / 12
In shortEach outlet guessed its prep and its orders every day, so food was wasted and top items ran out.
The chain sold burgers, wraps, rice bowls and fried chicken across four dayparts: breakfast at 38 outlets, then lunch, the afternoon snack window and dinner everywhere. About 42% of orders came through delivery aggregators. The rest were dine-in, takeaway and the chain's own app.
Every outlet ran on the same cycle. Before opening, a shift lead decided how much chicken to marinate, how many dough balls to proof, how much sauce to batch and how many portions of rice to cook. By two in the afternoon the outlet manager had to send an indent to the regional central kitchen for the next day's marinated proteins, sauces and bases, and a separate order to three or four local suppliers for produce, dairy and bread.
Both decisions were made from memory and a spreadsheet of last week's sales. The quality of the spreadsheet depended on the manager.
The cost showed up in three places:
Waste. Outlets that logged waste digitally reported pre-consumer waste close to 8% of food cost. Marinated chicken and cooked rice, which cannot be carried to the next day, made up most of it.
Stock-outs. On one outlet-day in eight, a top-20 item ran out before dinner ended. It happened most often on Friday evenings, on rainy days when delivery spiked, and during aggregator promotions nobody at the outlet had been told about.
Central-kitchen churn. The kitchens made to the sum of the indents, then took urgent top-up calls at noon. Top-ups meant a second van run and overtime on the production line.
FDE / 02Case study
02 / 12
In shortA dashboard and a par-level spreadsheet were tried, but neither became a prep quantity for tomorrow.
The chain had forecasting on its roadmap for three years. Two things had been tried.
A reporting dashboard. The analytics team built weekly sales charts per outlet. Managers were meant to use them to plan. Few did, because a chart of last week is not a prep quantity for tomorrow morning.
A par-level spreadsheet. A regional operations manager set fixed par levels per item per outlet. It helped for a quarter, then drifted as the menu and the delivery mix changed. Nobody owned updating it.
Nobody had tried to connect a forecast to the two artefacts that matter at an outlet: the prep sheet at 6 am and the indent at 2 pm. The data team owned the forecast idea. Operations owned the outlets. Supply chain owned the central kitchens. The work sat between all three.
FDE / 03Case study
03 / 12
In shortTwo weeks in kitchens and data, ending in a one-page scope signed by the Head of Supply Chain.
The engineer spent the first four days in kitchens: two morning prep shifts, an indent session with an outlet manager, a day on the central-kitchen production floor and an afternoon with the aggregator partnerships team. The rest went on systems and data.
- two morning prep shifts
- an indent session with an outlet manager
- a day on the central-kitchen production floor
- an afternoon with the aggregator partnerships team
What was found:
FIG. 3.2- The POS held three years of item-level sales for most outlets. Aggregator orders reached the POS through an integration layer at 108 outlets. At the other 18, staff re-keyed aggregator orders from tablets, so some were missing and some were entered twice.
- The aggregators' own order reports arrived a day late, as settlement files. They could not feed a forecast that had to be ready at 5.30 am.
- Waste was logged digitally at only 46 outlets. The rest used paper sheets. The waste metric could therefore be measured honestly at 46 outlets only, and the scope said so.
- The central-kitchen system already accepted indents through an import interface used by the existing indent form. Supplier orders were emailed from the same form. Write-back could use the same path, under the manager's own approval.
- Promotions lived in marketing briefs, as slide decks and emails. Menu changes lived in a spreadsheet owned by the culinary team.
- Recipe yields existed in the ERP bill of materials, but a quarter of them had not been updated since a menu refresh.
The one-page scope, signed by the Head of Supply Chain:
- WorkflowItem-level forecast per outlet per daypart for the next three days; the morning prep sheet; draft central-kitchen and supplier indents approved by the outlet manager
- In scope126 outlets; the top 40 prep-driving items and the 210 raw materials they draw on; four dayparts
- Out of scopeCentral-kitchen production planning, labour scheduling, beverages and packaged goods, catering orders
- MetricWAPE on the top 40 items per outlet per daypart; pre-consumer waste as a share of food cost at the 46 outlets with digital waste logs
- OwnerHead of Supply Chain
- GuardrailsNo indent is sent without the outlet manager's approval. No prep or order quantity falls below the item's safety stock. Withdrawn items forecast zero. Promotions enter only from a confirmed calendar
- Exit gateOne week of shadow run against the managers' own indents, one week live with rollback armed, runbook executed by the client's data engineer
The culinary team also corrected the recipe yields for the 40 items before the build began. A forecast multiplied by a wrong yield is a wrong prep sheet.
Timeline09 Stages
The engagement, stage by stage
Nine stages on one clock, from before the engagement to ninety days after cut-over. Press play, or pick a stage.
Stage 01Before
1 in 8
outlet-days a top-20 item ran out
- 126 outlets, eleven cities
- Prep guessed from memory
- Waste near 8% of food cost
01 / 09
Morning guess
Every morning, the kitchen guessed.
Before opening, a shift lead decided how much chicken to marinate and rice to cook, from memory and last week's sales. On one outlet-day in eight, a top-20 item ran out before dinner ended.
Read chapter 1FDE / 04Case study
04 / 12
In shortSix weeks: load the sales, build the forecast, run it in shadow, switch it on, hand it over.
the paused clock in week one
W0Scope
What happened
Scope page signed; access requested to the POS data warehouse, the integration layer's order log, the central-kitchen import interface, the ERP bill of materials and the waste logs
What existed at the end
The signed scope and an access checklist
What happened
Scope page signed; access requested to the POS data warehouse, the integration layer's order log, the central-kitchen import interface, the ERP bill of materials and the waste logs
What existed at the end
The signed scope and an access checklist
What happened
Repository created in the client's source control; engineer joined the supply planning stand-up. Access to the integration layer's order log needed approval from the aggregator partnerships team, which took three working days. The sprint clock paused, as agreed at scoping
What existed at the end
First pull request merged on day seven: a nightly load of POS sales by item, outlet and 15-minute slot into the client's warehouse
What happened
Forecast running for 30 outlets behind a feature flag; prep sheet and indent drafts produced but not shown to outlets. Golden set agreed with supply planning and two area managers
What existed at the end
A working prototype and a backtest golden set covering 16 held-out weeks at 30 outlets
What happened
Promotion and menu calendars, safety-stock rules, prep-sheet and indent generation, manager approval screen, central-kitchen write-back, audit log, dashboards. In week three the harness caught inflated delivery forecasts (section 6). Shadow run began in week four
What existed at the end
A system producing every prep sheet and indent in parallel with the managers, without sending anything
What happened
Live at 12 outlets in one city, then 48, then all 126, each step gated on shadow-run comparison
What existed at the end
Managers approving system-drafted indents; rollback one switch away
What happened
Client's data engineer performed a release, a rollback and a model retrain without us at the keyboard
What existed at the end
Signed runbook, decision record, revoked access
the paused clock in week one
Calendar time was six weeks and three days. The three days were the paused clock in week one. They were written down when they happened, not explained at the end.
FDE / 05Case study
05 / 12
In shortA forecast that drafts the prep sheet and the indent, with the outlet manager approving every order.
Try a day
Pick what happens. Watch where the indent goes.
The same system drafts every indent. What happens that day decides whether it is sent or goes to the area manager.
What happens that day
rain forecast, delivery up
Indent log
- 01Sales dataPOS sales and aggregator orders loaded
- 02CleanVoids, staff meals and cancelled orders removed
- 03ForecastThe weather forecast for the outlet's city lifts delivery demand
- 04Plan rulesYields, batch sizes, shelf life and safety stock applied
- 05Draft indentDraft indent by 11 am; the prep sheet carries the reason line
- 06Manager approvesThe manager approves each line
- 07Indent sentSent through the central kitchen's existing import interface
Indent sent
The prep sheet gives the reason, a number the shift lead can explain to the kitchen.
Clean and deduplicate. Sales land from the POS warehouse nightly and from the integration layer's order log every 15 minutes. Aggregator orders are keyed on the aggregator's order identifier, so a status update, an edit or a re-keyed tablet order cannot count twice. Voids, staff meals and cancelled orders are removed. Hours when an outlet was closed or an item was marked unavailable are flagged, so a stock-out is not learned as low demand.
Forecast. A statistical forecasting model, trained per item family across all outlets, predicts demand for each item, outlet and daypart for the next three days. It uses sales history, day of week, public holidays and festival dates, a weather forecast for the outlet's city, cricket fixtures, local events entered by area managers and the promotion calendar. It produces two numbers: a median and an 80th-percentile quantity. Prep uses the median for items with a short hold time and the higher number for items that are cheap to carry.
Promotions and menu changes. A language model, reached through a private endpoint in the client's region with no data retention, reads marketing's promotion briefs and drafts calendar entries: which items, which outlets, which dates, which channel. A category manager confirms each entry before the forecast can use it. Unconfirmed promotions are ignored. Menu changes come from the culinary team's spreadsheet, now loaded daily: a withdrawn item forecasts zero from its end date, and a new item borrows the demand shape of the item it replaces, with a note on the prep sheet saying so.
Plan. Deterministic rules, not a model, turn the forecast into quantities. They apply recipe yields from the ERP, batch sizes, hold times and shelf life, stock on hand from the evening count, and a safety stock per item per outlet set by supply planning. No quantity may fall below safety stock, whatever the forecast says. Central-kitchen items are rounded to tray and case sizes and checked against the 2 pm cut-off.
Prep sheet. At 6 am each outlet gets a printable sheet and a tablet view: what to prep, how much, in which wave for each daypart, and one line of reason where the number differs from the usual Friday ("rain forecast, delivery up", "aggregator offer on wraps"). The shift lead can change any figure. The change is recorded.
Draft indents and approval. By 11 am the manager sees a draft central-kitchen indent and a draft supplier order, with each line's forecast, stock on hand and safety stock shown side by side. The manager approves, edits or rejects each line. Nothing is sent until the manager presses approve. Edits above a set percentage ask for a reason from a short list. After 1.45 pm an unapproved indent is not sent automatically; the area manager is alerted instead, and the outlet falls back to its previous day's indent only if the area manager chooses that.
Write-back. Approved central-kitchen indents go through the existing import interface, as a service account with the same permissions as the indent form. Supplier orders go out by the existing email route, from the outlet's own address.
Audit and monitoring. Every forecast, rule result, prep change, manager edit and approval, with the model version, goes to the client's log store. Dashboards show forecast error, bias, waste, stock-outs and manager edit rates by outlet. Thresholds page the data engineer when forecast error at a city drifts above its band or when a data feed is late.
- Model
The model forecasts and drafts.
- POS
Rules set floors and round quantities.
- Caller
A named person, the outlet manager, decides what is ordered.
System map
How the pieces connect
Every part of the system and of the story, lit one scene at a time. Press play, or pick an event.
Timeline9 events
ObjectPerson
Managerapproves
Every morning, the kitchen guessed.
Metric
1 in 8outlet-days a top-20 item ran out
Properties
- 01
- 126 outlets, eleven cities
- 02
- Prep guessed from memory
- 03
- Waste near 8% of food cost
Description
Before opening, a shift lead decided how much chicken to marinate and rice to cook, from memory and last week's sales. On one outlet-day in eight, a top-20 item ran out before dinner ended.
Linked objects 2
- Kitchen
- Supplier order
FDE / 06Case study
06 / 12
In shortSixteen weeks of past sales that every change must pass before any outlet sees a number.
The golden set was agreed at the end of week two with supply planning and two area managers.
A backtest set: 16 held-out weeks at 30 outlets chosen to cover every city, both formats, breakfast and non-breakfast outlets, and high and low delivery mix. That is around 80,000 item-outlet-daypart cases with known actual sales, cleaned the same way as production data.
Answers taken from what sold, adjusted for stock-outs: where an item ran out, the case is scored only up to the stock-out time.
A set of 60 past indents where area managers wrote down what the right order would have been, with the benefit of hindsight. These tested the rules, not the forecast.
A red-team slice: a withdrawn item, a two-day aggregator promotion, a festival day, a heavy-rain day, an outlet closed for a week, a recipe yield changed mid-period and a day of duplicated aggregator orders.
- RT-01a withdrawn item
- RT-02a two-day aggregator promotion
- RT-03a festival day
- RT-04a heavy-rain day
- RT-05an outlet closed for a week
- RT-06a recipe yield changed mid-period
- RT-07a day of duplicated aggregator orders
Scoring on what hurts: WAPE and bias per item and daypart, with under-forecasting of the top 20 items weighted more heavily. Separate pass-or-fail rule tests: no quantity below safety stock, no quantity for a withdrawn item, no indent line after the cut-off.
The suite runs in the client's CI. A change that worsens WAPE on the top 20 items by more than a set margin, or fails any rule test, fails the build.
- IF worsens WAPE on the top 20 items by more than a set marginBLOCKS
- IF fails any rule testBLOCKS
fails the build
In week three it did exactly that. The integration layer had moved from a nightly batch to an event feed a month earlier. The event feed wrote a new row for each status change on an aggregator order: accepted, preparing, picked up. The prototype had been trained before the change. The retrained model forecast delivery-heavy outlets about 30% high on dinner. The red-team day of duplicated orders failed the build before any outlet saw a number. Deduplication on the aggregator order identifier was added, the late settlement files were kept for a weekly reconciliation only, and the harness gained a check that daily order counts match the POS within a tolerance.
FDE / 07Case study
07 / 12
In shortEverything stays in the client's own cloud, and no indent is sent without a manager's approval.
Perimeter. Everything runs in the client's cloud account and region. Egress is limited to the private model endpoint, which retains nothing, and to the public weather forecast feed. No customer personal data is used; the forecast works on item counts, not on who bought them.
Identity. The service account can create indents through the import interface and send from outlet mailboxes through the existing form, and nothing else. Our engineer's access went through the client's identity provider, showed in their audit log like anyone else's, and was revoked at handover.
Autonomy is bounded. The model forecasts; rules set floors; managers decide. No indent is sent without approval. No quantity falls below safety stock. Promotions need a confirmed calendar entry. Supply planning can change safety stocks, hold times and edit thresholds in configuration without a release.
Failure is visible. If a data feed is late, the prep sheet prints with a banner saying the forecast is based on yesterday's data, and the draft indent is marked the same way.
Review. The security team reviewed the design in week two and the deployment in week five. Their findings and how each was closed are in the decision record.
FDE / 08Case study
08 / 12
In shortA shadow week first, then city by city, with one flag to go back to the old indent form.
The shadow run was the gate. For a week the system drafted every prep sheet and indent while managers worked as before, and the two were compared line by line against what actually sold and what was wasted. Differences were sorted into three piles: the system was wrong, the manager was wrong, and the rule was unclear. Most of the third pile was safety stock on slow items. It went back to the Head of Supply Chain as policy decisions.
For a week
the system was wrong
the manager was wrong
the rule was unclear
went back to the Head of Supply Chain as policy decisions
Rollout went by city, not by date: 12 outlets in one city, then 48 across four cities, then all 126. Each step needed three clean days: no indent sent late, no rule test failing, and manager edit rates inside the agreed band. Rollback was one feature flag that returned every outlet to the old indent form, pre-filled with the previous day's order. It was tested in week five and never needed.
0112 outlets in one city
0248 across four cities
03all 126
EACH STEP · three clean days: no indent sent late, no rule test failing, and manager edit rates inside the agreed band
Area managers joined the first morning at each of the first 12 outlets. The most useful change they asked for was the one line of reason on the prep sheet. Shift leads trusted a number they could explain to the kitchen.
FDE / 09Case study
09 / 12
In shortThe client's data engineer retrained, released and rolled back the model before we left.
The engagement ended on the manifest, not on the calendar.
In the handover dry run, the client's data engineer retrained the model on the latest four weeks, scored it against the golden set, released it, and rolled it back, with our engineer in the room but not at the keyboard. The runbook was signed after that, not before.
Key numbers
The story in nine numbers
One number for each scene, from one outlet-day in eight running out to waste down to 6.1%. Press play, or pick a number.
1 in 8
outlet-days a top-20 item ran out
01Morning guess
Every morning, the kitchen guessed.
Before opening, a shift lead decided how much chicken to marinate and rice to cook, from memory and last week's sales. On one outlet-day in eight, a top-20 item ran out before dinner ended.
- 126 outlets, eleven cities
- Prep guessed from memory
- Waste near 8% of food cost
FDE / 10Case study
10 / 12
In shortLess waste, half the stock-outs, and indents built in 9 minutes instead of 40.
Figures are illustrative, measured on in-scope outlets over the first 90 days after cut-over.
Forecast error on the top 40 items fell from 41% to 26% WAPE per outlet per daypart. Daypart forecasts for single items are noisy by nature; the gain came mostly from weather, promotions and clean delivery data.
BEFORE41%AFTER26%Pre-consumer waste fell from 7.9% to 6.1% of food cost at the 46 outlets with digital waste logs. Cooked rice and marinated chicken accounted for most of the fall.
BEFORE7.9%AFTER6.1%6%8%−1.8 ptsStock-outs of top-20 items before 9 pm halved, from 12% of outlet-days to 6%.
BEFORE12%AFTER6%Median time to build the daily indent fell from 40 minutes to 9. Managers now review lines rather than write them.
Noon top-up calls to the central kitchens fell by about a third, which removed most second van runs.
No indent was sent without a manager's approval, because the design does not allow it. Managers edited about one line in seven in the first month and one in twelve by the third.
What did not improve, and was never promised:
FIG. 10.2New outlets with less than eight weeks of history. They borrow the pattern of a similar outlet, with a wider safety stock. Their waste and stock-outs are no better than before. Four outlets opened in the period.
Days with sudden, unscheduled demand: a holiday declared the evening before, a local protest that shut a market. The forecast cannot see these coming, and the prep sheet says so on the rare days the manager flags one.
Waste at the 80 outlets still on paper logs. It may have fallen; it was not measured, and the results do not claim it.
FDE / 11Case study
11 / 12
In shortSix rules for anyone turning a forecast into a prep sheet and an order.
- Fix the recipe yields first.
A good forecast times a wrong yield is a wrong prep sheet.
- Count every order once.
Delivery data that arrives late or twice will teach the model the wrong week.
- Treat stock-outs as missing data, not low demand.
Otherwise the forecast learns to run out.
- Let the forecast draft and the manager decide.
Approval kept managers in charge, and their edits became the best signal of where the model was weak.
- Give every unusual number a reason.
Kitchens follow a figure they can explain.
- Measure waste only where it is measured.
A result claimed for outlets on paper logs would not survive the first question.
FDE / 12Case study
12 / 12
In shortThe client took it in-house, moved every outlet to digital waste logs, and came back for more.
The client took the system in-house and did not buy managed operations. Their supply planning analyst moved the remaining 80 outlets to digital waste logs over the following quarter, so the waste metric could be measured chain-wide. They came back for a second Production Sprint on central-kitchen production planning, which reads the approved indents this system now produces and had been out of scope the first time.