Cloud Kitchen Inventory: Forecast Prep by Delivery Platform With AI

Export 8 to 12 weeks of order history from each delivery app, tag each order with platform, weekday, daypart, promotion and weather, and have an AI assistant work out a baseline and measured uplifts per combination. Multiply forecast orders by each dish's item mix and recipe quantities to get the prep sheet, then compare it with actuals weekly.

Doing it per platform matters because the apps don't move together. Each runs its own campaigns, shows its own menu and draws its own crowd, so one blended average under-preps on a promotion night and over-preps on a flat one. The other trap is that history records what you sold, not what you could have sold if the brand had not been paused or the buns had not run out. Most of the work below is cleaning that up, not modelling; for cloud kitchen inventory, clean order data beats a clever model.

Follow me on Instagram@sagnikteaches

Why a blended average misses on promotion nights

Take the burger brand of a two-chef cloud kitchen that sells through two marketplace apps, called App A and App B here. These are ten weeks of Friday dinner orders (17:30 to 21:30), with promotions and wet evenings marked. Every figure in this tutorial is made up to show the method; yours will differ.

Connect on LinkedInSagnik Bhattacharya

Averaging every Friday on App A gives 63.2 orders, a number that never actually happened. The six ordinary dry Fridays average 58.5, the two promotion Fridays 73.5 and the two wet Fridays 67. App B averages 31.2 across all ten weeks, but its seven ordinary Fridays sit at 29.9. Prepare for 63 on an ordinary Friday and you bin food. Prepare for 63 on a promotion Friday and you run short in the busiest part of the evening.

Subscribe on YouTube@sagnikteaches

Next Friday has a promotion planned on App A and a wet forecast. The method below gives about 78 orders on App A and 34 on App B, 112 in total. A blended average of 94 would leave the kitchen 18 orders short, which is roughly where the buns run out.

Pull the history from each platform, minus the customer details

Start with what each platform lets you download. DoorDash's Merchant Portal has an Orders area with a History tab, and a Report Builder where users with Admin or Manager access can create a one-time or recurring Financial Report. Uber Eats Manager has a Reports area with an Order History report: you choose the stores and a date range of up to 31 days per request, so eight to twelve weeks takes two or three requests, and its operational data runs about two days behind. File layouts and menu names change, so open each export and look at it before you trust it.

What you need is one row per order, or per item, showing when the order was placed, its status, the items and quantities, and the order value. Use the placed time rather than the delivery time, because prep happens before either. If a platform only gives you payout summaries, take order counts from your point-of-sale or order-aggregator reports instead, or copy the History view into a sheet for eight weeks. An afternoon of copying beats forecasting from nothing.

• Keep: date and time placed, platform, brand, status, item, quantity, order value, and any promotion shown on the order.
• Delete before the file goes anywhere: customer name, address, phone number, delivery notes and courier details.

The forecast never needs the personal columns, and dropping them makes the file easier for the AI to read as well. If your plan has a switch for using chats in model training, turn it off for this work. Business plans from the main vendors don't train on your content by default, but setting names change, so check the privacy page of whichever tool you use.

Eight weeks is the practical minimum and twelve is better. Each baseline needs five or six clean observations of the same platform, weekday and daypart, and promotions, wet evenings and paused nights each take a few away.

Build one clean order table before the AI sees it

1. Paste each platform's export into its own tab, untouched, so you can always go back to the original.
2. Keep completed orders only. Cancelled orders are not demand you served, but note any you declined or let time out because the kitchen was swamped. That is demand you lost, and it belongs in the exclusion column.
3. Add weekday and daypart columns from the placed time. Four dayparts are enough to start: lunch 11:30 to 14:30, afternoon 14:30 to 17:30, dinner 17:30 to 21:30 and late 21:30 to close. Move the boundaries once you have charted orders per hour and seen where yours cluster.
4. Map every item to one standard dish name (see below).
5. Add flag columns: promotion (none, funded by you, funded by the platform, plus the mechanic), wet evening, and exclude (kitchen paused, equipment failed, ingredient sold out).
6. Check one week's order count per platform against the platform's own figure. If they differ by more than a couple of orders, find out why before going further.

Item names are the usual mess. The same dish arrives under different strings depending on which app's menu it was built on, modifiers get glued onto the name, and bundles hide several dishes inside one line. This is a good job for an AI assistant: paste the unique names, ask for a proposed mapping, and approve it line by line. If the same dish carries different names on each app, fix the menus as well; keeping every brand's menu consistent across apps covers that, and the spreadsheet side is easier with the steps in cleaning messy data.

Bundles matter more than they look. If a combo stays as one line, the prep sheet counts the burger but not the fries and shake that came with it, and you under-prep both. Splitting bundles into components is the single most useful cleaning step for cloud kitchen inventory, because the platform sees a combo while the fryer sees potato.

I'm cleaning delivery-app order data for a cloud kitchen.
Below are the unique item names from two platform exports, with the platform in brackets.
1. Propose one standard dish name for each (lower case, underscores).
2. Where a name is a bundle, list its components and quantities.
3. Where a name has a modifier (add bacon, no onion), keep the dish name
   and list the modifier separately.
4. Do not merge two dishes unless the recipe is identical. If you are
   unsure, put the name in an "ask me" list instead of guessing.
[paste the names here]

Illustrative output
double_smash   <- "Double Smash Burger" (A); "Double Smash (2 patties) + cheese" (B)
combo_dbl      = double_smash x1 + fries x1 + shake x1   <- "DBL SMASH combo" (B)
chicken_burger <- "Crispy Chicken Burger - add bacon" (A); modifier: bacon x1
ASK ME: "Smash Stack" (B) - double smash under another name, or a triple?

Read the "ask me" list first. That is where the assistant admits it cannot see your recipes, and a wrong guess there quietly corrupts every later number.

Baselines by weekday, daypart and platform

A baseline is the average for one platform, one weekday and one daypart, using only weeks with no promotion, no wet evening and no exclusion. For the burger brand's Friday dinner on App A those weeks are 1, 2, 5, 6, 9 and 10 (week 6 was a promotion on App B only): 57, 60, 58, 59, 56 and 61, which average 58.5. For App B it is seven weeks and 29.9.

Repeat that for every platform, weekday and daypart that matters. Four dayparts, seven days and two platforms make 56 cells per brand. A pivot table fills them in one go, and the AI will write the pivot steps or the AVERAGEIFS formulas if you have not built either.

Cells with fewer than five clean weeks are not trustworthy yet. Merge neighbouring cells until the history grows (Monday to Wednesday lunch on App B, say) and write "merged" beside them so you remember why the number looks smooth.

Measure promotion and weather effects from your own weeks

An uplift is how far a promotion or a wet evening pushes orders above the baseline: the average of those weeks divided by the baseline, minus one. On App A the two promotion Fridays averaged 73.5 against 58.5, an uplift of 25.6%. The two wet Fridays averaged 67, an uplift of 14.5%. On App B the wet Fridays gave 12.2% and the single promotion Friday 20.6%.

Those App B promotion numbers rest on one week, which is not enough to treat as a rule. Until an effect has shown up three times, use half of it, or borrow App A's figure and note that you did. Weather works the same way: two wet Fridays say "probably a lift", not "14.5%". There is no need to buy a weather feed; tick the wet-evening flag from the forecast you already look at.

Log each campaign with its mechanic (percentage off, free delivery, spend-and-save) and who pays for it. DoorDash's monthly statements separate customer discounts funded by you from those funded by DoorDash, and the two behave differently in your margin as well as your order counts. For the forecast you only need the flag; whether a discount pays is a margin question, which comes up at the end.

When a promotion and a wet evening land together, don't multiply the two uplifts. You have rarely seen them together, and the effects overlap, because some of the customers a rainy evening brings are the same ones the promotion would have found. A conservative working rule is to count the larger uplift in full and half of the smaller one. Next Friday on App A that gives 58.5 × (1 + 0.256 + 0.145 / 2) = 77.7, call it 78. App B has no promotion, so 29.9 × 1.122 = 33.5, call it 34. As a sense check, 78 is 5% above App A's record of 74. If a forecast lands more than about 10% beyond your record, ask whether the kitchen could physically serve it.

Prompt: let the AI do the sums, then check three numbers

Paste the weekly table into ChatGPT, Claude or Gemini, whichever you already use, and give it rules rather than asking it to "forecast". Telling it exactly what to average, what to leave out and how to stack uplifts is what makes next week's answer comparable with this week's. If your assistant can analyse uploaded files, upload the cleaned CSV instead of pasting, and ask it to show the formulas it used so you can rebuild them in your own sheet.

You are checking a delivery-app demand forecast for a cloud kitchen. Use only the table below.
Columns: week, app_a_orders, app_a_promo (1/0), app_b_orders, app_b_promo, wet_evening.
These are Friday dinner orders, 17:30 to 21:30.
Rules:
1. Baseline = mean of weeks where promo = 0 and wet_evening = 0, per app.
2. Uplift = mean of the affected weeks / baseline - 1, per app and per effect.
   State how many weeks each uplift rests on.
3. If an uplift rests on fewer than 3 weeks, label it "thin".
4. Forecast next Friday. App A has a promotion AND wet weather; App B has wet weather only.
   When two effects apply, add the larger in full and half of the smaller. Show the arithmetic.
5. Do not round until the final line. List any week you excluded and why.
[paste the ten rows here]

Illustrative output
App A: baseline 58.5 (6 weeks). Promo uplift +25.6% (2 weeks, thin). Wet uplift +14.5% (2 weeks, thin).
App B: baseline 29.9 (7 weeks). Promo uplift +20.6% (1 week, thin). Wet uplift +12.2% (2 weeks, thin).
Forecast, next Friday:
  App A = 58.5 x (1 + 0.256 + 0.145/2) = 77.7
  App B = 29.9 x (1 + 0.122) = 33.5
  Total = 111.2 orders
Excluded weeks: none.

Three checks take two minutes. Count the weeks behind each baseline yourself (6 and 7). Recompute one uplift by hand. Then confirm that the assistant used the stacking rule you gave it; a straight multiplication would have produced about 84 orders for App A, far above anything the kitchen has served. If it breaks a rule, tell it which one and ask for the answer again. Ignore any language about confidence; the "thin" labels are the useful part.

From forecast orders to a prep sheet

Orders are not prep. Prep needs dishes, then components. The item mix, meaning dishes per 100 orders, differs by platform because each app carries its own menu, bundles and prices. These are the burger brand's mixes from the same ten weeks:

Apply each platform's mix to its own forecast. Seventy-eight orders on App A and 34 on App B give 62.8 double smash, 31.1 single smash, 33.8 chicken burgers, 52.0 loaded fries, 41.9 fries and 24.6 shakes. Then convert with the recipe quantities: a double uses two 90 g beef balls and a single uses one; every burger takes a bun and 25 ml of sauce; loaded fries add 40 ml of sauce; each portion of either fries uses 0.25 kg of raw potato; a shake uses 0.3 litre of base. Add a buffer that follows shelf life, small on anything that spoils or cannot be sold tomorrow and larger on batch items that keep.

The blended approach would have called for 131 beef balls, 108 buns and 19.8 kg of potato, using 94 orders and an averaged mix. That is 26 beef balls, 20 buns and 3.7 kg short of this plan, on the busiest night of the week. For the busiest nights, consider two prep waves, with part of the batch ready before service and the rest by about 19:00. It keeps quality up and stops you binning a full batch if the promotion underperforms.

Rolling three brands into one ingredient order

A cloud kitchen forecasts by brand and platform, but it buys by ingredient. Brands share suppliers and often share ingredients, so the last step adds each brand's need into one line per ingredient. This is Friday dinner need for the burger, wings and rice-bowl brands, before buffers and stock on hand, using the same method on each:

Keep each brand's forecast on its own tab and let one summary tab add them with SUMIFS; the assistant will write the formula if you describe the tab layout. Look at the rounding too. The coleslaw need is 5.3 kg, so two tubs fall just short and three leave 2.2 kg to bin. When a total lands barely above a pack size, check whether trimming a buffer saves a whole pack, or whether the leftover can go into tomorrow's prep. For stock that keeps, such as dry rice, rounding up is harmless. Subtract what is already on the shelf before ordering, and order perishables as often as the supplier allows.

Three ways the history lies to you

Each of these three examples is illustrative; the patterns are what to look for in your own data.

Demand you never recorded

One Saturday the fryer tripped at 19:40 and the brand stayed paused on App B until 20:25. That evening's 19 orders went into the average as an ordinary Saturday, and next month's baseline sagged by a couple of orders. Mark paused periods as excluded. When you cannot say exactly how long, exclude the whole daypart.

A campaign that was not on your sheet

A free-delivery campaign ran on App B one Thursday. Nobody had logged it, so the forecast said 24 orders and 41 arrived. The buns ran out at about 19:20 and the kitchen paused the brand for 35 minutes to catch up. Every Monday, copy the week's campaign dates from each portal and from any campaign emails into the flag column before you run the forecast.

A brand that is only a few weeks old

A brand launched five weeks ago has no baseline yet. Borrow the nearest brand's baseline on the same platform at about 60% for the first four weeks, flag every number as borrowed, and switch to the brand's own average once it has five clean weeks. The 60% is a deliberately cautious guess. It is easier to add a second prep wave on the night than to bin a full evening of food.

Holidays and school terms belong in the flag column too. Add a "special day" flag with a short note and let the uplift calculation treat it like any other effect. After a couple of repeats, last year's equivalent week, if you have it, becomes the best evidence you own.

Checking the forecast against what happened

Each Monday, paste last week's actuals next to the forecasts and measure the error. A simple measure is weighted absolute percentage error: add up the gaps between forecast and actual, ignoring whether each was over or under, then divide by total actual orders. Here is one illustrative week:

The gaps add up to 26 orders against 301 actual orders, an error of 8.6%. Judge the figure against your own history rather than a universal target. As a rule of thumb, a number that stays under about 10% means you should spend your time on waste, not on the model. A number above 20% to 25% for two weeks running usually means a missing flag: an unlogged campaign, a holiday, a paused brand or a menu change.

Pair the error with two simple logs. A waste log records what was prepped but not used, in the same units as the prep sheet. If you bin more than about 8% of an item three weeks running, halve its buffer. A stock-out log records the item and the time it ran out. A stock-out on a night with nothing unusual in the flags means that item's buffer is too small. The tutorial on why AI stock forecasts go wrong lists more traps worth scanning once the routine is running, and how AI inventory forecasting works explains the mechanics if you want the theory behind the averages.

Then keep the routine small. On Monday, add last week's rows, update the flags for the coming week, run the prompt, make the three checks and print the prep sheets. That is about fifteen minutes. After eight weeks or so, the uplifts that rested on one or two observations will rest on four or five, and you can drop the half-weight rule for them.

Notice what the routine does not tell you: whether each order made money. A promotion that lifts App A by 26% is only good news if the margin survives the discount and the commission, and the per-brand margin walk-through shows how to check that before you repeat the offer.

Questions about forecasting cloud kitchen prep

How far ahead should a cloud kitchen forecast?

Forecast one week at a time and rerun it every Monday, because promotions and weather are only known a few days out. Prep from the forecast for the next day or two, order perishables to your supplier's delivery window, and look two to four weeks ahead only for dry goods, packaging and the staff rota, where a rough figure is enough.

Can I forecast without a POS or order aggregator?

Yes. Use each platform's own order history or report, and if a file lacks item detail, count orders by day and daypart from the History view for eight weeks. Item mix can come from a sample of a few weeks of tickets. The forecast is only as detailed as your data, so start with order counts and add dish-level detail later.

Should I forecast by dish or by ingredient?

Forecast orders by brand and platform, convert them to dishes with each platform's item mix, then convert dishes to ingredients with your recipe quantities. Buy and prep by ingredient, because brands share them. Forecasting a single ingredient directly hides promotions and menu changes that only touch one dish or one app.

Is cloud kitchen inventory software better than a spreadsheet?

It helps once several people count stock or you run more than one kitchen, because counts, recipes and supplier orders then live in one place. Before paying, check that it imports each delivery app's orders separately, forecasts by daypart and lets you flag promotions and paused periods. A tool that blends every app into one number repeats the mistake this method avoids, so run the spreadsheet routine first and you will know what to ask in a demo.

Is it safe to upload order exports to an AI tool?

Strip customer names, addresses, phone numbers and delivery notes first, because a forecast needs only times, items, quantities and values. Then check the tool's privacy settings: business plans from the main vendors do not train on your content by default, while consumer plans let you switch training off. Setting names change, so read the privacy page of the tool you use.

Further reads

• Are Ghost Kitchens Still Worth It? A Cash-Flow Test You Run With AI — Test whether the kitchen still pays once the forecasts are running.
• Delivery App Commission: Should Takeaway Menu Prices Rise on Apps? — Decide whether app prices should sit above your own menu.
• Restaurant Inventory Management With AI: Par Levels and Orders — Par levels for a dine-in kitchen, using the same ideas.
• Food Truck Inventory Management: Build Tomorrow's Prep List — Build tomorrow's prep list from today's stock count.
• How to Forecast Covers and Cut Food Waste With AI — Forecast covers for a dining room and cut food waste.
• Hotel Breakfast Food Waste: Predict Buffet Demand With AI — A worked breakfast-covers forecast from occupancy, with an accuracy test, buffet replenishment rules and a five-minute waste log for a small hotel.
• Pizza Shop Inventory: Plan Dough and Toppings From Weekend Orders — Turn eight weeks of orders into dough balls, cheese and topping quantities for Friday to Sunday, then tune the plan from a simple waste log.
• What Is a Ghost Kitchen? How an Existing Restaurant Can Test One — What a ghost kitchen is, and how a restaurant can test one from its current kitchen on one delivery app: menu, per-order economics and a four-week log.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: DoorDash Merchant Portal learning-centre pages (financials, payout and monthly statement); Uber's merchant help article on customer and order data in Uber Eats Manager; AI vendors' business-plan privacy terms as recorded in September 2026. Order figures in the examples are illustrative.