Restaurant management built around the kitchen pass Seven modules, one order record, one login
Dearrasa

Home/Modules/AI Forecasting & Menu Insights

Module 06

A forecast is only useful if it comes out as a prep sheet.

Charts do not change a kitchen. Quantities do. This module turns your own sales history into how much to prep, how much to buy and how many hands to roster, and it tells you plainly what it used to get there.

Output first

Four things it produces, in the form you can act on.

Output 01

Prep sheet

Quantity per sub recipe and per item for tomorrow's service, split by daypart, printable for the morning brief.

Output 02

Indent list

What to order, adjusted for stock in hand, supplier lead time and shelf life, ready to edit before it goes out.

Output 03

Cover curve

Expected covers by hour so the roster and the kitchen brief are working from the same expectation.

Output 04

Menu contribution

Every dish on two axes, how often it sells and what it earns after real ingredient cost, with the action stated.

Stated plainly

What the forecasting model actually reads, and what it does not.

There is a lot of vague language in this industry about artificial intelligence. Here is the specific list, so you can judge whether the output deserves your trust.

It reads

  • Your item level sales history with timestamps, per outlet, which is the largest single input by a wide margin.
  • Day of week and daypart patterns, because a Wednesday lunch and a Saturday dinner are different businesses.
  • The calendar including public holidays, regional festivals, and local school and exam periods where they matter to your location.
  • Your own recorded events, the private party, the live screening, the renovation week, so unusual days train the model correctly instead of distorting it.
  • Menu and price changes, so a jump in sales that followed a price cut is not read as organic growth.
  • Recipes and stock movement, which convert forecast dishes into forecast ingredients.
  • Weather signals where a correlation is actually present in your own history, mainly for outdoor seating and delivery volume.

It does not read

  • Other restaurants' data. Your forecast is trained on your outlets only. Nothing you generate is pooled to train a shared model.
  • Guest personal data. Demand forecasting uses aggregate sales, not individual guest identity.
  • Anything about your staff as individuals. Station load is a volume figure, not a performance rating.
  • Social media chatter or review scores. Interesting to read, too noisy and too slow to forecast tomorrow's biryani count.

A new outlet has no history

For the first weeks a new location has nothing to learn from, so the forecast is weak and we say so on the screen rather than presenting a confident number. Where you run other outlets, a comparable one can seed it. Accuracy improves as the outlet accumulates its own trading history, and the module shows its recent accuracy against what actually happened so you can decide how much weight to give it.

Menu insights

Four groups every menu falls into, once you know the real cost.

This only works when recipe costing is live, because contribution calculated from a guessed food cost is a decoration rather than an analysis.

Sells well, earns well

Protect it

Keep it available, keep the recipe consistent, and be careful about moving its price. These dishes are the reason people come back.

Sells well, earns little

Rework it

Portion, garnish, supplier or price. A small correction on a high volume dish is usually the largest margin gain available to you.

Sells rarely, earns well

Promote it

Menu position, a captain suggestion, or a pairing. The margin is already there, the visibility is not.

Sells rarely, earns little

Question it

Every such dish still costs you stock, shelf life and kitchen attention. Some earn their place for other reasons, and the module tells you which do not.

Recommendations are stated with the numbers behind them, and they are recommendations. A dish can be worth keeping for reasons no model will ever see, and this one does not pretend otherwise.

Practical questions

Accuracy, history and honesty.

How much history do you need before this is useful?

Roughly eight to twelve weeks of item level sales gives a usable weekly pattern. Festival and season effects need a longer run, and until the model has seen a given festival once it will treat it as an ordinary day unless you tell it otherwise. If you can export item level sales from your current system, we can seed it.

How accurate is it?

It varies by outlet, by item and by how stable your trading is. Rather than publish a number that would mean nothing for your restaurant, the module reports its own accuracy against actual sales for every forecast it produced, so you can watch it earn or lose your confidence with your own data.

Can we override it?

Always. Prep and indent quantities are editable, and an override is remembered as a signal rather than discarded. If you consistently prep more of one item than the forecast suggests, that is information about your service, not an error on your part.

Is our data used to train anything shared?

No. Forecasts are per tenant, trained on that restaurant group's own history. See Security for how the data is separated and stored.

Next service

Send us three months of item level sales.

We will forecast a week you have already traded, hold it against what actually happened, and show you the result without editing the parts that missed.