Who may change a rate? Discount limits and override rules for hotel staff

A hotel rate override is a price change made for one booking, outside the published rate structure. A workable policy names who may change which price, sets a maximum movement per role, allows a short list of checkable reasons, records every override in the hotel system with a reason code, and reviews the pattern weekly.

A guest at the desk holds up a phone showing a lower price on a booking site. The agent has two minutes to decide, and no written rule about what they are allowed to do. Whatever happens next is a pricing decision the hotel made without meaning to make it. After reading this, you will be able to write the one-page policy that covers it: roles, ceilings, reason codes, records and a weekly review.

Where do rates get changed outside the rate structure?#

Rates leave the rate structure at a handful of predictable points, and almost all of them sit in front of a person under time pressure.

The front desk closes a walk-in at the end of a slow shift, where the alternative feels like an empty room. Reservations matches a price a caller has seen on a booking site, without checking whether the two prices are for the same room, board and cancellation terms. Sales grants a concession to a corporate or group client, often as a free upgrade or a waived charge rather than a lower room rate.

The duty manager handles a complaint by removing a charge or discounting the remaining nights. Upgrades and complimentary rooms are discounts in disguise: the guest pays less than the room was worth that night. Late checkout, early check-in and extra-bed charges are prices too, and they are rarely covered by a rate policy.

Each of these is legitimate on its own. The leak is not the discount; it is the absence of a rule, a record and a review.

Who may change which price, and by how much?#

Write one table that gives every role a ceiling, a scope and a named approver, and publish it where the desk can see it.

Scope matters as much as size: a role may be allowed to move a single night but not a ten-night stay, or to adjust a room rate but not a package. The ceiling should be expressed in a way the person can apply in seconds, for example a percentage of the rate on screen or a fixed amount per room per night. Name the approver for each step, and name a deputy, otherwise the rule collapses every evening after six.

The general manager is not exempt: the highest tier should still be recorded, because the point is the record, not the suspicion. Keep the table short enough to memorize, since a policy with nine tiers is a policy nobody applies. Review the ceilings once a season against what actually happened, not against what you assumed.

A starting structure you can adapt#

The following table is for example only. The numbers are illustrative and must be set by each hotel.

Every row is recorded the same way: an override with a reason code, attached to the reservation. Sales concessions carry the contract reference on the reservation instead.

Which reasons are allowed, and how do you code them?#

Allow a short closed list of reasons, each one describing the booking rather than the guest, and each one checkable later by someone who was not there.

A closed list beats free text: free text cannot be counted, and anything that cannot be counted cannot be reviewed. A reason code must describe the commercial situation, never the person. "Price match against a booking site" is a code; "difficult guest" is not, and neither is anything about nationality, age or appearance.

Attach the evidence each code needs, so the reviewer can confirm it: a screenshot, a contract number, a complaint reference, a channel name. Separate codes that point at pricing from codes that point at operations, because service recovery is an operations signal and a price match is a pricing signal. Keep the list to roughly eight to twelve codes; beyond that, people start choosing the first one in the menu. Publish the list with the limits table, so the agent sees the ceiling and the reason in the same place.

How should each override be recorded?#

Every override should live inside the hotel system, attached to the reservation, with the same fields every time, so it can be joined to the bill and the night audit.

Capture seven things: who approved it, when, which reservation, which rate was in force, the new price, the reason code, and whether it covers one night or the whole stay. An override should sit beside the published rate, not overwrite it. The guest pays the override; the rate structure keeps its own number for the next booking. Give every override an end, because a concession with no expiry quietly becomes the new price for that account.

Paper logs fail for a structural reason: they cannot be joined to the reservation, the folio or the night audit, so nobody can total them without retyping them. Permissions should decide who can even see the override field, so the record and the authority come from the same place; a user roles and permissions checklist is the natural place to define this. Where a system logs changes and allows them to be reversed, the review becomes a matter of reading a list rather than reconstructing a night from memory.

AI Otel's decision record, built and running in a public demo environment, is designed on the same principle: small changes apply automatically and are logged, larger ones wait for a person, and every change can be undone, except a message already sent to a guest. The threshold between small and large is fixed in the software, not set by the hotel.

Do upgrades and complimentary rooms follow the same rules?#

Yes. An upgrade and a complimentary room are discounts with a different name, and they cost the hotel the same difference in price.

Price an upgrade at the difference between the two room rates for those nights, not at zero, so the cost of the decision is visible. A complimentary room is a 100% discount and should sit in the highest approval tier, with its own reason code. Upgrades given to fill a better room that would otherwise stay empty are a different decision from upgrades given to please a guest; use different codes. Count upgrades and comps in the same weekly review as cash discounts, otherwise the totals understate what the hotel gave away.

Sell the upgrade where the guest can see it, at a price, before arrival and during the stay, and the free upgrade stops being the default answer. An accepted paid offer should land on the guest's bill automatically, so the upgrade is revenue rather than a concession. The mechanics of pricing room upgrades and extras deserve their own pass before the policy is written.

What should the weekly override review cover?#

Thirty minutes, one list, one decision. The review exists to change a rate or a rule, not to find someone to blame.

Pull every override for the week with its reason code, its approver and the published rate that was in force at the time. Count by reason code first, then by role: a code that appears every week is telling you something about the rate structure. Look for repeats on the same day of the week, the same channel, the same room type or the same arrival window; that is where the pattern hides.

Ask the counterfactual for a sample: would this room have sold anyway that night? If yes, the discount bought nothing. Check that each override had the evidence its code requires, and that approvals came from the named tier. Keep the tone factual, because a review that punishes people produces fewer records, not fewer discounts.

End with exactly one change: a rate, a ceiling, a code or a piece of training. Write it down and check it next week.

When does a pattern mean the rate itself is wrong?#

When the same code keeps appearing in the same situation, the override is doing the job the rate structure should be doing.

Repeated price matches on the same room type mean the published rate sits above what the market is visibly offering for those dates. Repeated same-day discounts mean the rate is set for a demand level that does not arrive, and the last-minute rule should be written down instead of improvised. Repeated service recovery discounts are an operations signal, not a pricing one; changing the rate will not fix them.

Repeated group concessions mean the group rate card is out of date, or the sales team is negotiating against a number nobody has revised. Repeated long-stay overrides mean the hotel needs a written weekly and monthly rate, priced so peak nights are not given away with the quiet ones. The test is simple: if the same override would be given again next week by a different person, it is a rate, so write it into the structure and retire the code. If the structure itself is the problem, go back to building a rate structure with derived rates or the basics of how to set hotel room rates.

What to do next#

Start with the table: one page listing each role, what it may change, its ceiling and who approves beyond it, published where the desk works. Add the reason codes, record every override inside the hotel system, and put thirty minutes in the calendar each week to read the list. The limits, the codes and the review are one loop: the limits stop the improvised discount, the codes make it countable, and the review turns the count into a rate decision. When you want to see how the loop looks in practice, talk to OtelCiro.