Skip to main content
DoneThat

AI Adoption GuideHospitalityPrepare

F&B demand forecaster

Predicts restaurant covers and in-room dining volume from occupancy data and historical consumption patterns.

Hospitality processBookConfirmPrepareArriveStayDepartReviewReturn

By Don, DoneThat’s AI coach · updated

What belongs on a cover forecast you can staff against

A cover forecast is usable only when every populated cell cites three things: the occupancy lock it used, the meal period it applies to, and the history vintage that produced the number. If any of those is missing, the cell is not a forecast. It is a guess with a spreadsheet attached.

The outcome is quality, not a fuller grid. Restaurant covers and in-room dining volume appear only where occupancy, period, and vintage can be shown together. Empty stays empty when history is thin. Do not invent covers so the sheet looks complete. An F&B manager still staffs the floor, the pass, and room service from what is known, plus judgment for what is blank.

Breakfast, lunch, dinner, and in-room dining are different demand shapes. A stay-over night does not imply the same outlet mix as an arrival-heavy night. Name the meal period, or staffing pulls people from the wrong station.

Occupancy is the demand envelope, not the cover count. Mix, length of stay, and whether guests are in the building at the meal change restaurant and IRD volume even when rooms sold look similar. Lock that occupancy figure, timestamp it, and share it with anyone else planning the same house, including dynamic demand-based pricing and housekeeping schedule optimizer.

Lock occupancy before you score any meal period

Lock occupancy first. Score covers second. If the rooms figure is still moving, every outlet number you write is stale before the briefing.

The lock is a snapshot: rooms occupied or due in for the date, plus the mix that matters for F&B, in-house versus arrivals versus departures, group versus transient, and packages that include meals. You do not need a perfect model of guest intent. You need one snapshot that kitchen, restaurant, and IRD all treat as the same house.

Occupancy and stay pattern already live in the property stack. Treat PMS and hospitality suites in the class of Oracle Hospitality, Mews, and Agilysys, and revenue systems in the class of IDeaS, as a class of sources, not as a ranked shortlist. Pull the lock from the same occupancy those systems are already using for rooms and rates. Do not score F&B from an older pickup report while rooms is working from a newer one.

Once occupancy is locked, freeze it for the scoring run. Later pickup updates the next run. It should not silently rewrite tonight's covers while prep is already in motion. If occupancy changes enough to matter, rerun the forecast and mark the new vintage. Do not patch individual cells by hand.

A forecast that cites covers but not the occupancy lock is the first failure mode. It looks precise and cannot be audited. When breakfast misses, nobody can tell whether the rooms number was wrong, the period mapping was wrong, or the history came from a different kind of night.

Score with vintage; leave the cell blank when history is thin

After the occupancy lock, score each meal period against comparable history. Vintage names that history: which dates, which mix, which outlet, and how old the pattern is. A cover number without vintage cannot be defended in the afternoon briefing.

Comparable means the same meal period, a similar in-house mix, and the same outlet or IRD stream. A Tuesday in-house pattern is a poor match for a Saturday with a wedding group. If you cannot name the comparables, you do not have vintage. You have an average.

When the comparable set is thin, leave the cell blank. Thin history is not a license to blend distant dates until a number appears. Inventing covers to fill the grid is the second failure mode. It hides uncertainty, and the manager then staffs as if the blank had been a measurement.

Blanks tell the manager where judgment, a call to sales, or a walk of the book must replace the model. A blank breakfast in a new outlet is honest. A filled breakfast built from another property's pattern, or from a handful of dissimilar nights, is not.

Score restaurant and in-room dining separately. IRD often moves on a different clock than the restaurant. Late arrivals and in-room evenings can lift IRD while the dining room is quiet, or the reverse. Do not split a single house cover pool across outlets without vintage for each stream.

Personalized F&B offer generator work should read the same occupancy lock and the same blanks. An offer that assumes a full dining room on a night the forecast left blank is marketing fiction.

Saturday dinner with a group in house

Walk one night. Do not treat it as a measured result.

Saturday dinner at a city hotel, with a wedding group in house plus transient stayovers. Occupancy is locked from the afternoon rooms snapshot, including the group block that is due to dine in banquet, not in the restaurant. The meal period is dinner. Restaurant vintage is prior Saturdays with a similar transient in-house count and no banquet overflow into the outlet. IRD vintage is prior Saturday evenings with a similar arrival curve.

Banquet covers sit on the event order. They are not restaurant covers and do not get copied into the dining-room cell to make the house total look busy. Score the restaurant cell only from restaurant-comparable nights. If those nights are few, or the mix is not close, leave the restaurant dinner cell blank even though the ballroom is full.

IRD is scored on its own vintage. A wedding in house can suppress IRD while guests are at the reception, or lift it later when guests return. If you lack evenings that look like this one, leave IRD blank rather than interpolating from generic Saturdays.

The manager staffs from populated cells plus the event order. Banquet has its BEO. The restaurant lineup follows the scored cell if it exists, or a conservative call after walking the book if it is blank. Nobody pretends a blank is zero, and nobody fills it with a round number so the labor system will accept the file.

This is the only illustration. It is a method check, not a before-and-after.

Staff the floor; do not treat the forecast as a purchase order

The F&B manager still staffs. The forecast does not hire, and it does not order protein.

Treating the forecast as a purchase order is the third failure mode. Covers are a demand signal for a meal period, not a prep list and not a market-sheet quantity. Conversion to prep depends on menu mix, reservations on the books, banquet BEOs, walk-in habit, and what is already in the cooler. A scored dinner cell can inform how many servers and cooks you schedule. It cannot tell purchasing how many cases to receive.

Staffing uses the populated cells, the blanks, and the live book. Outlet reservations, private dining, and IRD tickets already in motion override a model cell when they conflict. If the forecast is blank, staff from reservations, the event diary, and a manager call, then record that the model did not speak. If it is populated, staff toward it, then adjust for known groups and for departure time optimizer signals that change who is still in house at breakfast.

Breakfast is where occupancy-lock errors show first. Early departures and late check-outs change who is in the building at the first meal. F&B should use the same lock rather than a separate breakfast guess.

After the meal period, keep actual covers next to the forecast only where vintage existed. Do not backfill blanks with actuals and call them predicted. Invented cells must never enter the vintage set.

A forecast with no vintage, a grid filled to avoid blanks, and a purchasing list printed straight from covers are the same quality failure in three costumes. Lock occupancy. Score with vintage. Leave blanks. Then staff.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first