Changing prices for high season: how to do it in a minute without reprinting anything

High season starts on Friday and the hotel restaurant manager has known for two weeks that prices go up. Even so, on Friday night there are menus with the old price on three tables, the pool server charges the usual because nobody told him and the guest in room 214 gets a ticket with a different price from the menu she read on her phone. The problem is not the increase; it is that the increase is applied by hand, in many places, by many people.

What happens today when you change prices

In most hotels changing prices is a project. Someone prepares a sheet with the new prices, someone types them item by item into the point of sale, someone sends the menu to print or sticks labels over the old one, someone tells the front desk to update what the dinner package says and someone forgets to tell the pool bar.

Because each step is done by a different person at a different time, two prices coexist for several days. The guest who compares the printed menu with the ticket complains, and rightly so. The server, to avoid the complaint, charges the old price “just this once”. And the controller, closing the month, finds the same dish sold at two prices with no rule to explain it.

The return to low season is worse, because nobody is in a hurry to lower prices. The high season list stays weeks too long, the corporate guest in February pays December prices and the comparison against last year stops making sense.

A price list is a rule with a start and an end date

The right way to think about the season price is the same as the price by outlet: it is not a field on the dish, it is a rule that applies under a condition. The condition here is the date. “From December 15 to January 8, the high season menu replaces the base” is a single instruction the system executes at the exact hour, in every outlet, with nobody awake.

The season list can be a percentage over the base (everything goes up 12 %), a full list with prices written one by one, or a combination: a general percentage with exceptions. What matters is that it lives apart from the base menu, so when the season ends the base comes back intact, with the prices it had, without anyone typing them again.

The same mechanics work for seasons that are not on the calendar: the long weekend, the conference that fills the hotel, the sporting event in town. All of them are scheduled in advance and all of them end on their own. The seasonal operations page explains how this combines with hours and staffing (Seasonal hotel).

What a proper validity needs

• A start date and time, because the season does not start at midnight in every hotel: it may start with Friday breakfast or with dinner.
• An end date and time, mandatory. A season list with no end is a permanent increase in disguise.
• Which outlets it applies to, because sometimes the restaurant goes up and the coffee shop does not, or everything goes up except included breakfast.
• What happens with the rules that already exist: the pool markup applies over the season price, and the agreement price still wins.
• Who approved it and when, so the controller has the signature before it goes in and not after.

With those five things defined, the price change stops being a project and becomes a one minute task done in October for December. And if in November the owner decides the increase should be 10 % and not 12 %, you edit the rule that has not gone in yet, without touching anything else.

The digital menu updates itself

The printed menu is the slowest link in the whole process. Every price change means design, printing, handing out to the tables and collecting the old ones, and there is always one left in a drawer that shows up in May. When the menu the guest sees is the same one the system uses to charge, there is no link: the price shown by the code on the table, the one shown in the room service message and the one on the ticket are the same data read at the same time.

This has an effect that shows more in high season than at any other time: the guest trusts you. They see the price on their phone, order, get a ticket with that price and charge it to the room without arguing. The “the menu said something else” complaint disappears because there are no longer two menus (Digital menu).

If your hotel wants to keep a physical menu for style, the answer is to print it without prices, or with a code to see today’s price. What does not work is a printed menu with prices in a hotel that changes prices two or three times a year.

An illustrative example with numbers

The figures below are invented to show the calculation; they are not from any property and they are not a recommended increase. Suppose the hotel restaurant decides to go up 12 % in high season, with a rounding rule to multiples of 5 so the menu has no odd prices.

If in a high season month the restaurant sells 2,000 dishes at an average base price of 160, sales at base price would be 2,000 × 160 = 320,000. With the season list, the average price rises to about 179 (160 × 1.12 = 179.2), and sales to 2,000 × 179 = 358,000. The difference, 38,000, is what the rule captures on its own over the month.

Now imagine the change was made by hand and that during the first four days, with 270 dishes sold, half the servers charged the base price. Those 135 dishes each missed 19, about 2,565 in total. It is not a figure that sinks the month, but it is money lost without any report showing it, and it repeats at every season change, two or three times a year.

The guest with an agreement does not pay high season

In a hotel there are guests whose food price is signed: the company with a corporate account, the conference group with a dinner package, the agency with a rate that includes breakfast and dinner. For them the season list does not apply, and if it does, it is a breach of the agreement that someone will claim.

That is why rule priority matters so much in high season. The agreement rule, tied to the guest folio, must win over the season list without the server having to remember. When the corporate guest orders dinner on December 20, the price is the agreement price; when the guest at the next table who booked online orders it, the price is the season price. Same menu, same server, two correct prices, no human decision. The company accounts page explains how the agreement is tied to the folio (Master accounts and agreements).

Open checks and what the controller should see

There is a detail almost nobody plans for: the table that opened its check at eleven the night before the season and closes at half past twelve. What price does the dessert ordered at ten past twelve carry? The correct answer is that each item is charged at the price in force when it was captured, not at the price when the check closed. That way the ticket is defensible line by line and never changes retroactively.

The same applies to room service ordered before midnight and delivered after, and to group consumption on a master account open for several days. The system must store the price at the moment of capture and the rule that produced it, so the controller can explain any line months later.

A price change done properly also leaves a full trail: which list went in, when, who approved it, which outlets it applied to and which items it changed. With that trail the controller can compare sales for the same period last year separating two effects: how much came from price and how much from volume. Without it, they only see that December sold more and do not know why.

They should also see the manual price change report for the first week of the season. If the rule went in properly, that report should be almost empty. If it is full, someone is charging the old price by hand, and that is a training problem or a rule configuration problem, not a season problem.

Common mistakes

• Changing base prices instead of creating a list with a validity. When the season ends nobody remembers what the previous prices were.
• Forgetting the pool bar or the coffee shop because “someone else handles that”. Outlets that are not updated charge old prices for the whole season.
• Applying the increase over the agreement price because the season rule had higher priority. The company spots it on its statement and claims.
• Reprinting the menu with prices and finding in March that there are December copies on the terrace tables.
• Not defining the rounding rule and ending up with prices like 106.4 on the menu.

What to do this week

1. Write down the exact dates of your next two high seasons, with start and end times, and confirm them with the front desk.
2. Decide the increase by category and the rounding rule, and send it in writing to the controller for approval before typing it in.
3. Check which guests have a signed price (companies, groups, agencies) and confirm that their agreement rule wins over the season rule.
4. Schedule the season list with its validity today, even if it starts in two months, and test it with a simulated sale in every outlet.
5. Remove any printed menu with prices from the tables and leave only access to the digital menu.
6. Book a review of the manual price change report for the first week of the season.

In Inn Restaurant the season list is scheduled with a start and end date, respects the agreement price tied to the folio, applies in every outlet at the same hour and the guest’s digital menu reflects it instantly. If you want to see how your next season would be scheduled, the 15 minute demo is booked at (contact).