A Hotel Pricing Strategy Your Manager Will Approve

Most small hotels in Belize set prices once a year, write them on a laminated sheet, and change them only when something goes badly wrong. That works until a quiet Tuesday in September sits at the same price as Easter weekend. A hotel pricing strategy does not have to mean complicated revenue software or a consultant on retainer. It can mean three ordinary pieces of information, shown together, with a human deciding what to do about them.

I build and run Direct Belize, a hotel website and direct-booking platform with a market intelligence module inside it. This post describes what that module does, because it is a good example of a kind of software that sounds intimidating and is actually quite simple to use once you see it.

What is a rate shopper, and what does it tell you?

A rate shopper is a programme that reads the public prices of other properties, the ones a guest would see if they searched for a room. Mine reads comparable listings on Booking.com for the dates ahead, the nights you are still trying to sell.

It does not hack anything. It looks at the same pages a guest looks at, on a schedule, and writes down what it sees so that you can look at a week of competitor pricing in one screen instead of opening twenty browser tabs.

The useful part is not any single number. It is the pattern. When every comparable property on your stretch of beach has moved up for a particular weekend and you have not, that is worth knowing before the weekend arrives rather than after.

You choose which properties count as comparable. A ten-room guesthouse in Hopkins is not competing with a large resort on Ambergris Caye, and a rate shopper pointed at the wrong set of properties gives confident, useless advice.

Occupancy and pickup: the two numbers behind every price decision

Occupancy is the share of your rooms sold for a given night. Pickup is the number of bookings arriving per day, how fast reservations are landing for a date that is still in the future.

Occupancy on its own is misleading. A night that is 40 per cent sold six weeks out might be perfectly healthy, or it might be a problem, and you cannot tell without knowing whether bookings are still coming in.

The module charts both. You see the occupancy line for the nights ahead and the pickup underneath it, so you can tell the difference between a night that is filling slowly and a night that has stopped filling altogether.

That distinction drives most pricing decisions in a small hotel:

• High occupancy, strong pickup. You are probably priced below what the market will pay. Consider raising.
• Low occupancy, strong pickup. It is early. Hold your price and watch.
• High occupancy, pickup has stopped. You are near the top of demand for that date. Hold.
• Low occupancy, no pickup, date approaching. This is where a discount or a package earns its keep.

None of that is a secret of the trade. It is the reasoning most experienced managers already do in their heads. The software exists so the reasoning happens on evidence rather than on a feeling about how last year went.

Why local events belong in your pricing calendar

Belize demand is lumpy in ways that no generic algorithm trained abroad will understand. Costa Maya. September celebrations. A cycling classic. A school holiday in a feeder market. A long weekend that is a public holiday here and nowhere else.

The module keeps a calendar of local events alongside the rates and occupancy. When a date is flagged, the suggestion for that night takes it into account, and more importantly, so do you. An event calendar that a human maintains beats a clever model that has never heard of San Pedro.

This is the part I would ask a new client to fill in first. It takes an afternoon and it is the highest-value data in the whole system.

How does the software suggest a price?

It puts the three inputs together for each night ahead: what comparable listings are charging, how your own occupancy and pickup are tracking, and whether anything is happening locally on that date. Then it produces a suggested price per night.

The suggestion arrives with its reasoning visible. You can see the competitor spread it was based on and the occupancy position it was responding to, so the number is arguable rather than oracular. If you disagree, you should be able to say why, and you can.

And then nothing happens. That is deliberate.

The software proposes, the owner decides

No price changes until a manager approves it. A suggestion sits in a queue until a human looks at it and either accepts it, edits it, or ignores it.

When a price is approved, two things happen. It is written to your rate calendar, and it is published to your channel manager, the service that keeps rates and availability in step across Booking.com, Airbnb and Expedia. One approval, every channel updated.

I am firm about the approval step for a practical reason. You know things the software does not. A tour group has provisionally held eight rooms. The generator is being replaced that week. A regular guest is returning and you would rather not explain a surge. Automatic pricing that overrides local knowledge erodes trust in the whole system within a month, and once a manager stops trusting the screen, the screen is furniture.

The module sits inside Direct Belize, alongside the booking engine and the property website, so the prices you approve are the prices your own site quotes as well as the ones the channels show. If you are still weighing up whether to push for direct reservations at all, I wrote separately about direct bookings and your own hotel booking engine in Belize.

Spreadsheet or pricing module: a short comparison

A spreadsheet is a perfectly respectable place to start. Here is the honest comparison.

| | Spreadsheet | Pricing module | | --- | --- | --- | | Competitor rates | Manual checking, when you remember | Collected on a schedule | | Pickup over time | Hard to reconstruct | Charted automatically | | Local events | In your head | In a shared calendar | | Publishing a change | Log into each channel | One approval, pushed out | | Cost | Your time, every week | Build and hosting |

If you have six rooms and one strong season, the spreadsheet may well be right. If you have twenty rooms, three channels and a manager who is also doing housekeeping rotas, the time saved is the argument, not the cleverness of the pricing.

Where to start

1. List your real competitors. Five to ten properties a guest would genuinely compare you to. Be unsentimental about it.
2. Pull twelve months of your own bookings. Booking date and arrival date, both. That is what makes pickup visible.
3. Build the event calendar. Everything local that moves demand, for the year ahead.
4. Decide who approves prices. One named person, with a rule about how often they look. Software cannot supply that discipline.
5. Run it alongside your current method for a season. Compare the suggestions with what you would have charged anyway, and see where it earned its place.

Everything I build ships with the source code, documentation and in-app help, and the client owns it. If you would like to talk through what this would look like for your property, the contact page is the place to reach me.