Price rules by time and by outlet: the same dish, a different price at the pool

Almost every hotel with a restaurant has a dish that sells in more than one outlet and at more than one price. The same club sandwich costs one thing in the dining room, a bit more at the pool bar and more still when it goes up to the guest room. When that difference lives in the server’s head or in three duplicated items, you get capture errors, split reports and arguments with the controller.

The problem with having three club sandwiches in the system

The most common fix, and the worst one, is to create one item per price: “Club sandwich”, “Club sandwich pool” and “Club sandwich room service”. It works on day one. By month three nobody knows which one sells where, the item report shows three lines for a single thing and the sales ranking lies because it divides in three what it should add up.

The damage does not stop at the report. Each duplicated item has its own recipe, or worse, has none. When the cost of bread goes up, someone updates one recipe and forgets the other two. When the kitchen wants to know how many club sandwiches it made yesterday, it has to add by hand. And when a pool server rings up the dining room item out of habit, the guest pays less and nobody notices until the shift close.

In a hotel restaurant this multiplies, because there are more outlets than in a street restaurant: dining room, bar, pool, room service, coffee shop, banquets. If every outlet needs its own copy of every dish, a sixty item menu becomes a list of three hundred.

What a price rule is

A price rule is an instruction that lives outside the item: “when this dish sells in this outlet, in this time window or to this kind of guest, apply this price or this adjustment”. The dish stays one dish. It has one recipe, one cost, one name and one place in the report. What changes is the condition under which it is sold.

The difference looks small and it is not. A field inside the item, something like “pool price”, forces every item to carry every possible case, and every time a new case appears you have to touch every item. A rule is created once and applied to whatever you point it at: a dish, a whole category or the entire menu.

Rules have four parts: what they apply to (an item, a category, the whole menu), under what condition (outlet, time window, day of week, guest type, corporate agreement), what they do (fixed price, percentage markup, discount, special price) and with what priority they apply when they collide with another rule.

Why rules prevent capture errors

A capture error is born when the server has to decide. If at the pool they have to choose between “Club sandwich” and “Club sandwich pool”, one day they will choose wrong. If they have to type the price or apply a percentage by hand, one day they will type it wrong. With a rule there is nothing to decide: they open the check at the pool bar, ring up the club sandwich and the system applies the price that belongs to that outlet.

The same goes for time. The five to seven bar promotion does not depend on someone remembering to turn it on, or on the manager stopping by to turn it off. It starts and ends on its own. And when the corporate guest with an agreement orders dinner, the agreement price appears because the folio says so, not because the server remembered to ask the front desk.

For the controller this changes the audit completely. Instead of reviewing hundreds of manual price changes, they review a short list of active rules. If a dish sold at an odd price, the question is no longer “who changed it” but “which rule applied”, and that answer is on the ticket. It is the same logic that says a room charge must be tied to the folio and not to a typed room number (Room charge): take decisions away from the capture.

Five rules almost every hotel needs

• Outlet markup: the pool bar and room service carry a percentage over the dining room price, because service costs more to deliver there.
• Time window: the afternoon drinks promotion, breakfast at buffet price until a set hour and the late night menu price after ten.
• Day of week: the Sunday menu, the Friday grill or the weekend dinner price when the menu changes.
• Corporate agreement: the guest on a company account pays an agreed food price, with a cap and without alcohol, exactly as signed (/cuentas-de-empresa).
• Season: the high season price list with a start and end date, which comes in and goes out on its own without anyone reprinting the menu.

Notice that none of the five is a field on the dish. All of them are conditions of sale. If next year you change the pool percentage or the promotion hour, you touch the rule and not the sixty items.

How they sort themselves out when they collide

Priority

A corporate guest orders a club sandwich at the pool at six in the evening. Does the pool markup apply, the afternoon promotion or the agreement price? If the system has no clear answer, the server will have one, and we are back to the original problem. That is why every rule carries a priority: the agreement usually wins because it is signed, the outlet rule comes next and the time rule is the weakest.

Validity

Every rule should have a start date and, when it applies, an end date. A promotion with no end date is a permanent discount nobody approved. A season rule with no start date activates when someone remembers, which is usually a week late.

An illustrative example with numbers

The figures below are invented to show the calculation; they are not market data and they are not from any property. Imagine the club sandwich has a base price of 180 in the dining room and a +15 % rule at the pool bar, which puts it at 207. Its recipe costs 60, and it is a single recipe because it is a single item.

In one month it sells 300 in the dining room and 120 at the pool. The dining room brings in 300 × 180 = 54,000 and the pool 120 × 207 = 24,840. The total is 78,840 for 420 units. The cost is 420 × 60 = 25,200, so the gross margin on the dish is 78,840 minus 25,200, that is 53,640, which is 68 % of sales.

With a single item the report shows you that whole line: 420 units, two outlets, one cost, one margin. With three duplicated items you would see three lines with partial figures, and if one of the recipes kept last year’s cost, the margin on that line would be false. The arithmetic is the same; what changes is that you can read it.

What the report gains

Under the hospitality accounting standard, food and beverage revenue is presented by outlet. A price rule by outlet gives you exactly that without duplicating anything: the same item lands in dining room revenue or pool revenue depending on where it sold, and the controller builds the schedule without touching a spreadsheet (Reports).

The item ranking gains too, because it finally adds what it should. The kitchen gains a single production figure. And the discount report gains, because what used to be a manual change is now a rule with a name: when you review the month’s comps, you will know how much was scheduled promotion and how much was a gift from the server.

Common mistakes when setting up rules

• Creating one rule per item when one per category was enough. Sixty pool rules are as hard to maintain as sixty duplicated items.
• Leaving promotions without an end date. Next year nobody remembers why the bar is still giving away the second beer in January.
• Not defining priority and letting the system apply “the last one created”. The day two rules collide, the price will be a surprise.
• Setting the agreement price as a manual server discount instead of a rule tied to the folio. It gets forgotten, applied to the wrong guest and cannot be audited.
• Allowing manual price changes with no reason and no authorization. If the back door exists, rules stop mattering.

What to do this week

1. Export your item list and flag the ones that exist two or more times at different prices. That is your list of duplicates to merge.
2. Write down on one sheet the real price conditions you have today: by outlet, by time, by day, by agreement, by season. They usually fit on a page.
3. Give every condition a priority and a validity. If you cannot say when a promotion ends, ask yourself whether it should still be alive.
4. Check how many manual price changes there were last month and who made them. That number is the size of your capture problem.
5. Test the rule set against three hard cases: the corporate guest at the pool during promotion hours, dinner at ten in the room and the banquet at an agreed price.

In Inn Restaurant every dish is a single item, and the price by outlet, time window or agreement is a rule with priority and validity, applied on its own at the pool bar (Pool bar) just as in the dining room. If you want to see how that rule set would look for your hotel, the 15 minute demo is booked at (contact).