All work

Weather-Ready / Graduate analytics practicum

Planning dinner service with weather forecasts

A restaurant manager needs to decide how many guests to prepare for before dinner begins. I built an AI prototype connecting weather and local context with guest estimates, explanations and feedback after service.

Setting
MS in Business Analytics practicum, informed by restaurant discovery interviews.
My contribution
Connecting forecasting, explanations, and stored feedback in a working prototype.
Intended use
Help managers interpret demand estimates alongside what they know about an upcoming service.
Project stage
Prototype; restaurant pilot outcomes remain unmeasured.

An estimate of dinner guests, with a planning range

A weather forecast alone does not tell a restaurant how many people it will serve. Weather-Ready estimates dinner guests using weather and local signals, then explains what affects that estimate.

In the screen below, Wednesday is marked as slower than usual, with heavy rain, an estimate of 136 guests, and a planning range of 112–155. The screen also asks the manager to confirm the service setup. These are values in the interface example, rather than observed restaurant results.

Prototype forecast: Wednesday shows heavy rain, 136 estimated guests, a range of 112–155, and a prompt to confirm service. Other dates remain visible for context.

Forecast screen from the Weather-Ready prototype. Guest counts and ranges are values shown in this interface example.

View full-size forecast screen

Accounting for patio closures and private events

A closed patio, an early closing, or a private event changes what a normal evening means. The service-plan form lets a manager record those known changes, instead of treating every change in guest numbers as a weather effect.

After service, managers can record what actually happened. I connected forecasts, explanations and stored feedback so planning and later review used the same workflow. Feedback updates the prototype’s stored state for later runs; whether that improves forecast quality still needs testing.

Plans and Actuals screen with the service-state dropdown open: normal service, partial or early close, patio closed or constrained, private event or buyout, holiday-modified service, and closed service.

The prototype's service-plan form records operating changes such as a closed patio, early closing, or a private event.

View full-size service-plan screen
How the prototype connects these steps

A FastAPI backend supports a React and TypeScript interface, with DuckDB storing the data and Azure OpenAI-backed agents supporting the workflow. Forecasting logic combines demand signals and explanations; feedback updates stored state for subsequent runs.

How the prototype connects these steps

A FastAPI backend supports a React and TypeScript interface, with DuckDB storing the data and Azure OpenAI-backed agents supporting the workflow. Forecasting logic combines demand signals and explanations; feedback updates stored state for subsequent runs.

What a restaurant pilot would need to test

The practicum produced a working prototype. A restaurant pilot would need to compare its forecasts with a baseline, measure errors under different service conditions and test whether the explanations help managers plan service.