Personalized F&B offer generator

A mid-stay dining or bar offer is ready for a manager when it names the guest signal it used: a dietary flag, a prior order, or both. If neither field has content, the draft stays blank. Quality here is the cite, not a polished paragraph that could apply to any in-house guest.

The job is a targeted offer during the stay, not a restaurant marketing blast and not a forecast of covers. Demand planning lives elsewhere, including the f-and-b demand forecaster. This page is about one guest, one stay, and an offer that a food and beverage manager can read, edit, and send.

What the manager should see on a usable draft:

• The guest or room context the property already uses for in-house messaging
• The dietary flag or prior order the draft is using, quoted or paraphrased so the cite is obvious
• The proposed dining or bar offer, limited to outlets and times the property actually operates
• An empty body when flags and orders are silent, not a generic line about hoping they are hungry

An offer with no dietary or order cite fails this test even if the copy is warm. The failure is not tone. The failure is that the manager cannot tell why this guest, tonight, should get this outlet or this dish.

Pull two fields first. Dietary flags are the restrictions and preferences the property already stores: allergen notes, religious or ethical diets, no shellfish, oat milk only, and similar. Prior orders are what this guest actually ordered at the property's outlets on this stay or a previous stay, if the PMS or POS still holds that history.

Load them from the same guest record the front office and outlets already trust. Preference work at arrival, such as guest preference-based room setup, often captures dietary notes that F&B never sees unless you join them. Loyalty systems may hold outlet history that the current stay folio does not; retrieve that context the same way you would for loyalty context retrieval, then stop. You are not rebuilding a profile. You are reading two fields.

If a flag exists, keep the original wording in the working notes so the draft can cite it. If an order exists, keep the outlet, the item or category, and the stay it belongs to. Do not infer a party size from the check. Do not invent a cover count to make the offer sound busy or exclusive.

When both fields are empty, stop the draft. Do not scrape the reservation comment for a guessed diet. Do not treat a spa booking or a late checkout as a dining preference. Those might inform a concierge answer through something like ai concierge rag powered, but they are not a dietary flag or a prior order.

If a flag exists but the kitchen cannot honor it tonight, still keep the cite, and do not promise a dish. If a prior order is from an outlet that is closed, the cite still stands; move the offer to an open outlet that can fire a related item, or wait.

Write the draft only after the load step returns at least one usable field. Put the cite in the draft itself, not in a hidden log. The manager who sends the message should see why this wording exists.

Illustrative example, not a measured result. Room 412, in-house for two more nights. Dietary flag on the guest profile: pescatarian, no shellfish. Prior order from last night: grilled sea bass at the lobby restaurant, no dessert. A usable draft might read: You flagged pescatarian, no shellfish, and last night you had the grilled sea bass. If you would like a table tonight, the terrace kitchen has a citrus-and-herb catch of the day with no shellfish on the garnish. Reply and we will hold a table. The manager still chooses channel, time, and whether to send.

That draft works because a reader can point at the flag and the order. It does not claim how many covers the terrace will do. It does not say the guest is dining for two unless the reservation already says so. It does not auto-send.

Keep the offer inside what the outlet can actually fire. If the flag is an allergen, name the safe path the kitchen already documents. If the prior order is a specific cocktail, offer a related pour at the bar that is on the current list. Do not invent a dish to match the flag.

If only one of the two fields has content, draft from that one and say so. A dietary flag alone can support an outlet suggestion that respects the restriction. A prior order alone can support another round of what they had, or a neighboring item at the same outlet. Do not pad the missing field with a guess so the template looks complete.

Empty stays empty. A silent dietary field plus a silent order history is not a prompt to be creative. It is a stop.

The common failure is an offer with no dietary or order cite: Hope you are hungry. Our steakhouse is a favorite with guests this week. That sentence can go to anyone. It does not show the manager a reason to send it to this room. Delete it. Leave the draft field blank so the queue shows no signal, not a fake personalization.

Another quiet failure is filling the blank with adjacent facts. A loyalty tier, a connecting-room request, or a kids' club enrollment is not a dining flag. Using those to justify a kids' menu or a tasting menu still produces an offer with no dietary or order cite. Hold those for other workflows. Do not borrow them here.

Treat guest declined to state the same as silent. A blank, a dash, or a system default of none is not a flag you can cite. If the POS has a check with a room charge total and no line items, that is not a prior order you can cite either. Wait until the items exist, or leave the draft empty.

Treat the output as a suggested message sitting in a review queue. The food and beverage manager, or the outlet supervisor they designate, is the sender. The draft is not sent when it appears on screen. It is not sent when it looks finished. It is not sent when a channel integration is ready.

Treating the draft as sent is the second failure mode. Auto-send turns a quality check into a guest-facing mistake: wrong outlet hours, a dish 86'd at four, a dietary cite the kitchen cannot honor tonight, or a message that lands while the guest is already seated. Keep human send. The manager confirms the outlet is open, the item is available, and the cite still matches the profile.

Do not invent a cover count in the draft or in the send. Cover counts are an operational number from the book or the POS, not a personalization field. Writing we have a table for four when the stay is a solo traveler, or join us for a full house tonight, is invention. If the reservation or the in-house party size is already on the folio, the manager may use that fact. If it is not, leave party size out of the offer.

Channel and timing stay with the manager: in-stay app, SMS the property already uses, a note under the door, or a verbal offer from the host. The generator does not choose the channel by default. It produces text with a cite, or it produces nothing.

Dietary flags and prior orders usually already live in the property's hospitality stack. Property and hotel systems in the class of Oracle Hospitality, Mews, Agilysys, and guest-messaging platforms in the class of Ivy / Go Moment are where those fields tend to sit: profile notes, POS checks, in-stay messages. Treat them as a class of sources, not as ranked products, and do not assume a named feature you have not configured.