Customer work · Quick-service restaurants

Hourly forecasts helped restaurant teams prepare before demand arrived

BluePi built store-level order and ingredient forecasts for every hour of the operating day. Restaurant teams used the forecast to prepare earlier, adjust for local conditions, and reduce food waste.

Explore the systemForecasting architecture
Restaurant forecasting architecture from order, store, menu, recipe, campaign, and calendar data in Amazon S3 through SageMaker order and ingredient models to an EC2 store application and Power BI evaluation

Preparation moved from reaction to an hourly plan

Restaurant teams needed to prepare ingredients before demand arrived, but daily or weekly averages could not describe the order mix for the next hour. BluePi connected order history, store data, menu information, and recipes to hourly order and ingredient forecasts.

01 · Broad demand averages

Stores prepared from experience and broad averages. Teams could not see how many orders of each type were likely during the next operating interval.

02 · Hourly store forecasts

A forecasting system generated hourly order and ingredient estimates for each store. A store application let managers review and adjust the forecast before preparation began.

03 · Preparation time and food waste

The system became part of the daily planning process for an initial store group. Earlier preparation reduced order preparation time, while a better view of ingredient demand reduced food waste.

From order history to an hourly preparation plan

Order history, store data, menu information, and recipes produced hourly order and ingredient forecasts. Store managers reviewed and adjusted the forecast before teams prepared for the next demand window.

Forecast at the store and hour

Every store received its own hourly forecast so local demand patterns remained visible instead of being hidden by one network-level average.

Translate orders into preparation

Recipe data converted expected orders into ingredient quantities so teams could prepare the likely mix before the demand window began.

Keep local adjustments visible

Managers could account for bulk orders, new launches, and local events. The system retained an audit trail so evaluation could distinguish model output from manual changes.

Where this pattern fits

This pattern fits restaurant networks where preparation decisions happen before short demand windows and where one network-level forecast hides local variation. A useful starting point is a representative store group with enough normal days, peaks, promotions, and local events to test the complete planning cycle.

Review your store planning workflow

Case details

Open a section to review the customer problem, implementation, business change, and architecture.

01The starting point

Restaurant teams needed an earlier and more precise view of hourly demand.

  • Short preparation window: Ingredients had to be prepared before orders arrived.
  • Store-level variation: Demand patterns differed by store, hour, menu mix, and local conditions.
  • Broad averages: Daily and weekly forecasts could not guide the next preparation interval.
  • Unplanned demand: Bulk orders, launches, and local events required manager judgment.
  • Waste risk: Preparing too much increased waste, while preparing too little delayed orders.
02What BluePi built

BluePi connected order history, forecasting models, store review, and forecast evaluation.

  • Planning data in Amazon S3: Online and offline transactions, store data, menu records, recipes, campaigns, and calendar information entered one forecasting path.
  • Data preparation: Outliers, stockouts, bulk orders, and new launches were treated separately.
  • Order forecasting model: Amazon SageMaker generated hourly forecasts for each store and menu group.
  • Ingredient forecasting model: Recipe data translated expected orders into ingredient requirements.
  • Store planning application: Managers viewed and adjusted the forecast for their store.
  • Supervisor access: Supervisors could review forecasts across their store group.
  • Audit trail: The application recorded manual adjustments.
  • Forecast evaluation: Power BI compared forecast with actual demand at hourly, daily, weekly, and monthly levels.
03Results

The forecasting system became part of the daily planning process for the initial store group.

  • Earlier preparation: Teams used hourly forecasts to prepare before expected demand.
  • Shorter preparation time: Stores reduced the time needed after an order arrived.
  • Lower food waste: Ingredient forecasts reduced unnecessary preparation.
  • Local control: Managers retained the ability to adjust for known events.
  • Visible forecast performance: Teams compared forecasts, manual changes, and actual orders.

System diagram