Café Sales Forecast: Build a Weekly Model from Orders and Capacity

Define the unit before collecting the history

Choose a consistent order definition, revenue basis and time boundary. An order is not necessarily one guest or one item. Decide how completed orders, cancellations, refunds and discounts enter the report, and use that definition for both history and the forecast. State whether reported revenue excludes taxes and how any adjustments are assigned; reconcile the policy with the accounts records.

Split the week into periods with different trading patterns, such as weekday breakfast, weekday lunch and their weekend equivalents. Add separate channels when their order values or operating demands differ. Each order must belong to one row. Do not count a takeaway transaction in both a service-period total and an additional takeaway total.

The BCcampus food-service management text explains how sales history by day and meal period can reveal differing demand patterns and inform planning. Use that principle with the information your own records actually contain. A report's existence does not make every field complete, comparable or suitable for forecasting.

Build a comparable starting point

Review several comparable services rather than copying the most recent day. Mark closures, unusually large bookings, promotions, price changes and known local events. Keep the observed figures and the reason for each adjustment visible. Removing an inconvenient low-sales day without an operational reason makes the forecast harder to trust.

Recorded sales also have limits. A sold-out dish, a closed ordering channel or a queue that caused customers to leave may restrict completed orders. Those sales are not a direct measure of all potential demand. Keep documented constraints beside the history rather than guessing the number of lost orders.

For a new café, label order assumptions as assumptions. Use a menu trial, observed location activity and the proposed service format to challenge them, while recognising that passers-by are not confirmed customers. Start with a range and update it when real trading evidence arrives.

Worked example: four trading segments

This fictional café models breakfast and lunch over five weekdays and two weekend days. All four rows use the same net-revenue policy. There are no overlapping channels in this simplified example. Orders per service are multiplied by the number of trading days, then by the average net order value.

The result is 455 forecast completed orders and INR 117,400 of net revenue for the week. It is revenue, not contribution, profit or cash in the bank. Ingredient and operating costs need their own models, and settlement timing belongs in the cash-flow forecast.

Check the peak inside the service period

A service-period total can look feasible while its busiest interval overwhelms the operation. In a separate fictional capacity trial, the supported lunch workflow completes 10 comparable orders per 15 minutes across a 90-minute window. The simple nominal total is 60 orders. The weekend lunch forecast of 55 is below 60, but that comparison alone does not approve the plan.

If 30 orders arrive in the first 15 minutes, an operation completing 10 in that interval has 20 still to work through, before considering later arrivals. The timing and mix of those orders matter. Observe the constraint, the queue and the customer experience; do not treat a quiet later interval as evidence that an earlier wait was acceptable.

Check seating and table use for dine-in demand, and the shared preparation, cooking, pass and collection work across channels. Two channels do not each receive the full capacity of the same kitchen. Use actual trials and clear resource allocation to identify the constraint; a revenue forecast is not a reason to bypass operating controls.

Use scenarios to expose decisions

In an original sensitivity scenario, reduce expected orders in every segment by 20% while keeping average net order values unchanged. Forecast weekly revenue becomes INR 93,920. Raising every segment's orders by 20%, with the same order values, gives INR 140,880. These are arithmetic scenarios, not probabilities or predictions.

The higher scenario also raises weekend lunch from 55 to 66 orders per service. That exceeds the illustrative nominal support of 60 before any arrival-pattern check. Record the constraint explicitly. Do not quietly cap the forecast and call the difference solved, or assume extra equipment creates demand and capacity at the same time.

Decide what each scenario would change: the purchasing assumption, the service trial, the ordering window or the cash requirement. Keep changes to price, order value and order volume separate so you can see which assumption produced the result.

Compare the result and explain the difference

After the week, compare actual completed orders and net revenue using the same boundaries. In a separate illustrative result, 430 actual orders and INR 111,800 revenue are 25 orders and INR 5,600 below the forecast. Those totals do not explain whether the difference came from timing, channel mix, prices, availability or demand; return to the individual segments and the exception notes.

Keep the original forecast version. Record the actuals, the explanation supported by evidence and the adjustment for the next comparable period. A forecast that is repeatedly overwritten to match results cannot show what the team has learned.

Use a small set of assumptions that someone can own and update. The useful outcome is a clearer operating decision with a stated uncertainty, not a precise-looking spreadsheet that nobody can connect to service.