Test a forecast on shifts that have already happened before using it to schedule staff or order supplies. Compare its predictions with actual demand and with a simple same-weekday baseline. Then check whether the differences would have changed a real operating decision.
A forecast can look reasonable in a weekly total while missing a busy Friday dinner. For an operator, the useful question is not just whether the number is close. It is whether the prediction helps you make a better decision at the time you must make it.
1. Establish a historical baseline
Start with one target you can measure consistently. For example, predict the number of completed orders during Friday dinner, defined as 5 p.m. to 9 p.m. Include the same channels each week, and decide how to treat canceled orders before you begin. If dine-in checks and online orders are counted differently, document the rule.
Order count is a starting point, not a complete staffing or purchasing plan. A large catering order and a small takeout order may each count as one order but create very different work. If your decision depends on portions, items, guests, or sales dollars, choose that target instead and keep its definition consistent.
Next, set a forecast deadline. If the schedule is posted on Monday, compare predictions that could have been made on Monday—not predictions updated on Friday afternoon. For supplies, use the time you normally place the order. A later forecast may be more accurate but useless for a decision already made.
Build a baseline from information available at that deadline. A practical option is the average demand for the same shift over the previous four comparable weeks. Record the dates used, exclude or separately label unusual weeks, and write down the calculation. If there are not four comparable weeks, use the history you have and flag the baseline as less dependable.
Your restaurant POS system and order records may help establish actual demand. Before relying on any report, confirm its time zone, channel coverage, cancellation rules, and whether historical figures can be retrieved in the form you need. A total sales report is not automatically a shift-level order count.
2. Compare predictions with actual demand by shift
Hold out dates the forecast did not use for training or tuning. For each held-out shift, save the baseline and AI prediction as they stood at the decision deadline. After the shift, record actual demand using the same definition. Do not revise an old prediction after seeing the result.
The following worksheet is hypothetical. Each row represents a Friday dinner shift. The baseline is the average of the previous four comparable Friday dinners, calculated using only information available before the schedule deadline. The numbers are completed orders, rounded to whole orders.
| Shift | Actual | Same-weekday baseline | AI prediction |
|---|---|---|---|
| April 3 | 100 | 90 | 105 |
| April 10 | 120 | 110 | 100 |
| April 17 | 80 | 90 | 85 |
Calculate absolute error by taking the difference between the prediction and actual demand, without the plus or minus sign. The baseline errors are 10, 10, and 10 orders: 30 total, or 10 per shift on average. The AI errors are 5, 20, and 5: also 30 total and 10 per shift on average.
That tie hides a useful difference. On April 10, the AI prediction was 20 orders low, twice the baseline error. For a busy shift, being short may matter more than scheduling a little extra coverage. Also record the signed error—prediction minus actual—to see whether a tool repeatedly predicts too high or too low.
Translate the numbers into the choice you face. Suppose the staffing rule for this example is to add one four-hour support shift when the forecast is at least 110 orders. The extra shift costs $80 in wages, excluding payroll taxes, benefits, meals, and any other labor costs. On April 10, the baseline of 110 triggers the extra shift; the AI prediction of 100 does not. Actual demand was 120. Under this rule, the AI choice saves the $80 in wages but leaves the shift without planned support during higher demand. The example does not assign a dollar value to wait times, missed sales, or staff strain.
That does not prove the baseline is better. Three shifts are far too few to establish performance. Repeat the comparison across many held-out shifts, including different weekdays, meal periods, and demand levels. Review both average error and the individual misses that would change a schedule or purchase.
3. Check unusual events and missing data
Look at holidays, local events, promotions, weather disruptions, closures, and large bookings separately. A normal Friday baseline may be a poor comparison for a holiday Friday. Ask whether the forecast had the event information before the decision deadline, and keep a record of what was known at that time.
For example, suppose an upcoming Friday has a nearby event and your recent comparable Fridays averaged 100 orders. A manager expects 30 additional orders based on past event nights and enters a planning estimate of 130. An AI forecast says 105. The manager should check which past events are genuinely comparable, whether reservations support the estimate, and whether the event is expected to affect the dinner period. Neither number should be treated as certain simply because it is precise.
Make a plan for a range as well as a single number. If demand could reasonably be 105 to 130 orders, decide which coverage can be arranged in advance and what can be added later. For perishable supplies, check lead times, storage, usable inventory, and the consequences of running short before increasing the order.
Missing data deserves its own check. Suppose the online-order feed was unavailable for two hours on one historical Friday. A reported total of 70 orders may reflect an incomplete record rather than a quiet shift. Mark the period as incomplete, investigate whether another record can reconcile it, and avoid treating the total as a normal comparison until it is understood.
Ask any forecasting vendor how it flags gaps, late-arriving transactions, duplicates, and changes in menu or trading hours. Also ask whether a forecast can show when its inputs were last updated and which data sources were included. A prediction made from yesterday's complete data may be more useful than one that appears current but omits an important channel.
Data can come from several tools. When reviewing restaurant management software, establish which order and reservation views are available for your setup. Separate payroll, inventory, or accounting tools may still be needed; ask how the records will be reconciled rather than assuming every system shares data automatically.
4. Set review rules, overrides, and a rollback
Before using a forecast operationally, decide who reviews it and what requires a closer look. A practical starting rule is: review any prediction that differs from the baseline by more than 15%, any forecast built on incomplete data, and any shift affected by a known unusual event. The 15% figure is an example, not a universal standard. Set a threshold that fits the cost and flexibility of your decisions.
Calculate the difference against the baseline. If the baseline is 100 orders and the prediction is 120, the difference is 20 orders, or 20% of the baseline, so it triggers review. If the baseline is zero, a percentage comparison is not useful; use a separate rule for a newly opened or normally closed shift.
Keep an override log that a manager can maintain quickly. Record the shift, forecast deadline, baseline, AI prediction, data freshness, reason for review, final planning number, and person who approved it. After service, add actual demand and a short note about the result. Preserve the original prediction alongside the override so you can evaluate both.
Start with simulated checks: use past shifts and draft schedules or purchase quantities without sending a guest message, charging a card, or dispatching a courier. Compare the draft decisions with what actually happened. Then, if the results justify it, run a limited live-service pilot on selected shifts with a manager's approval and a backup plan. A live pilot changes an actual schedule or order, so tell the affected team and make ownership clear.
Write down the rollback before the pilot begins. For example, if a data feed is incomplete or two pilot shifts miss the agreed tolerance, pause forecast-led changes and return to the documented baseline plus manager review. Set the tolerance in advance in units that matter, such as orders per shift or a staffing decision missed—not just an overall monthly average.
Continue monitoring after adoption. Review forecast errors by shift, investigate repeated underprediction, and revisit the rules when hours, channels, or demand patterns change. Historical labor ratios can help explain what happened on past shifts; they do not establish whether a future-demand prediction is reliable.
Choose a workflow you can audit
Ask vendors to walk through one past shift from source data to prediction, manager override, and actual result. Can your team retrieve the original forecast? Can it see when inputs were refreshed? What happens when a channel is missing? How are corrections recorded? Request a written explanation of setup, reporting access, support, and current costs.
For the wider software decision, the guide to one platform versus separate tools can help you map which records belong where. Check current Fleksa plans for pricing; pricing information was checked in November 2026, and current terms should be confirmed before purchase.
Next, take four comparable shifts and define your target, deadline, and baseline. Then compare Fleksa's management workflow against the reporting and review requirements on your list.
Frequently asked questions
How many shifts should I test?
There is no single sufficient number for every restaurant. Three example shifts cannot establish performance. Collect many held-out shifts across relevant weekdays, meal periods, and demand levels, and examine consequential misses as well as averages.
Should I use order count or sales dollars?
Use the measure closest to the decision. Order count may help estimate transaction volume, while item quantities may be more useful for purchasing. Define the measure and channels consistently before comparing predictions with actuals.
What if the AI forecast beats the baseline on average?
Check whether it also handles busy shifts, unusual events, and incomplete data well enough for your decisions. Keep human review and a rollback rule even when the average error improves.
