A rate change log: recording who changed which price, why, and what happened next
A hotel rate change log turns a pricing decision into something a team can explain and review. This guide covers the twelve essential columns, the weekly routine, and the rules for software-proposed prices.
Contents
Key takeaways
- A hotel rate change log records the decision, not just the price: the reason and the expected effect are what make a move reviewable a month later.
- One line written at the moment of the change beats a tidy summary written from memory at month end.
- The log only works when the person who proposes a price and the person who approves it are both named, separately.
- When software proposes a price, the log should show the proposal, the person who approved it, and the rule or version behind it.
- A change reversed within a week is information, not a failure, provided the log says so.
A hotel rate change log is a one-page record of every price move: the date, the room type and rate plan, the channel, the old and new price, who decided, who entered it, the reason, and the result checked about 30 days later. It turns a pricing decision into something a team can explain and review.
An owner asks in a meeting why one room type sold below the planned rate for two weeks in July. Three people remember three different reasons, and the person who actually made the change is on holiday. The price is gone; the reasoning went with it. This article gives you the structure that prevents that conversation: the columns, the routine, the review, and the rules for software-proposed prices.
Why is a rate change log better than memory?
Because memory keeps the decision and loses the reasoning. A log keeps both, with a date, so any member of the team can explain a price move, not only the person who made it.
Memory rewrites itself. After a strong month the same change becomes "we saw demand coming"; after a weak month it becomes "the owner insisted". A dated line does not move. Staff turnover is the normal case, not the exception, and the log is the handover document for whoever takes over the rate sheet.
The log also settles disputes faster. A disagreement with an agency, an OTA or a corporate client about a contracted rate is resolved by a dated line rather than by searching an inbox. Rate parity problems show up as a gap between what the log says was sent and what a channel is actually selling. And the late question, "why is our average rate behind budget", is answered by the log rather than by rebuilding spreadsheets.
Without a log, the same pricing question is decided from scratch every season, and the hotel never learns whether its own reasoning was right.
NoteA log is not a diary
A line that cannot be checked against a system record, such as the rate sheet, the channel extranet or the reservation, is an opinion, not a record. Every line should point to something the systems can confirm.
Which columns does a rate change log need?
Twelve columns are enough for most hotels: identity, the change itself, the reason, and the review. Anything more is rarely filled in.
Separate "decided by" from "entered by". They are often different people, and the distinction is what makes the log checkable. Keep the reason as a short fixed list of codes rather than free text: demand, competitor move, cost change, contract, campaign, error correction. Free text drifts into vague wording within a month.
Record the basis of the price, not only the number: per room per night, breakfast included or not, and in which currency. Record whether the change went to every channel or to one, because a single-channel change is where parity questions start. Add an "expected effect" column with one short sentence, and a review date set about 30 days out, so the outcome is checked rather than remembered.
| Column | What goes in it | Why it matters |
|---|---|---|
| Date and time | When the change was made | Fixes the line against the market that day |
| Room type and rate plan | Which product moved | Locates the decision precisely |
| Channel or segment | Where it applies | Single-channel changes cause parity gaps |
| Old price | The rate before | Shows the size and direction of the move |
| New price | The rate after | The number everyone will quote later |
| Decided by | Who approved it | Separates the decision from the typing |
| Entered by | Who keyed it in | Makes the line checkable |
| Reason code | One code from the fixed list | Keeps reasons comparable over months |
| Expected effect | One short sentence | Lets you judge the reasoning, not just the result |
| Review date | About 30 days out | Closes the loop |
| Outcome | Keep, reverse or wait | Turns the log into decisions |
| Note | One line of context | Anything the codes cannot carry |
For what a good system record should capture beyond price, see what a good audit record should show.
Who writes the log, and when?
The person who makes the change writes the line at the moment of the change, and a second person checks it in the weekly meeting.
The revenue manager proposes the change and writes the reason and the expected effect. The general manager approves anything above a threshold the hotel sets in advance, and the approval is a name in a column, not a nod in a corridor. Reservations or front office confirms, the same day, that the live rate on each channel matches the line that was written.
The daily close is a natural checkpoint: one glance at the day's lines catches a change that was made but never recorded. Backfilling at month end is allowed, but the line must be marked as reconstructed, so a later reader knows it was not written at the time. Keep the file where the team already works, a shared sheet or the notes attached to the property system, never in one person's private folder.
ChecklistThe routine, in order
- Before the change, check the current live rate on every channel
- Write the line, including the expected effect
- Apply the change
- Confirm the live rate the same day
- At the daily close, check that today's changes are all logged
- At the weekly meeting, read the week's lines aloud
How does the log fit the weekly revenue meeting?
It becomes the first agenda item: last week's changes are read out, and each one gets a keep, reverse or wait decision written back into the log.
Five minutes at the start, reading only the current week's lines, not the whole file. Each line ends the meeting with one of three words in the outcome column, so the next meeting starts from a decision rather than a discussion. Small changes below the threshold are pre-approved, so the meeting spends its time on the few moves that matter.
The minutes should point to log lines by date and room type instead of repeating the numbers, which keeps one version of the truth. The same meeting reviews the lines that have reached their review date, so the log closes its own loop. For the wider structure, see the weekly revenue meeting agenda and decision log.
TipSequence matters
Put the log review before the pickup and pace discussion. The meeting then knows what the hotel itself changed before it reacts to what the market did.
What should you look for in the log after 30 days?
Look for reversals, silence and drift: changes that were undone quickly, changes that produced no bookings at the new price, and prices that quietly moved away from the plan.
Count how many changes lasted less than a week and read the reasons. A high reversal rate usually means the threshold for approving a change is too low. Check whether the channel actually received the change: compare the log with the live rate and with what a recent confirmation shows. Check whether bookings arrived at the new price or at a stale one that was still selling somewhere.
Compare the month against budget and against the same period last year, and write one sentence of conclusion rather than a report. The method for that comparison is covered in reading budget against actual in the monthly variance. Watch for repeated reason codes: several "competitor move" lines in one month may mean the hotel is following the market instead of deciding. Read the expected-effect column against the outcome. Being wrong with a written reason is useful; being right by accident teaches nothing.
Key pointThe test of a log
The log is judged by whether it changes the next decision, not by whether it is complete. A short log that is read every month beats a perfect one nobody opens.
What are the rules when software or an assistant proposes a price?
The same rules as for a person, plus three extra fields: what proposed the change, which rule or version it came from, and who approved it.
A proposal is not a decision. The log line is created when a person accepts the proposal, and the proposal itself is attached or referenced. Record the rule or version behind the proposal, so a reader a month later can tell whether the logic changed or the market did. If the software applies small changes automatically within limits the hotel set, those changes are logged the same day with the limit that allowed them.
Never let an automatic change appear as "system" with no owner. Name the person accountable for the rule, even when the rule ran alone. Keep the reason column human: "Rule 4 fired" is not a reason a general manager can use in a meeting; write what the rule was trying to achieve. Review the automatic lines separately once a month, because a rule that was right in one season is often wrong in the next. For the questions to ask before accepting a machine-proposed rate, see what to check in AI rate recommendations.
Watch out"Automatic" is not a record
A log that says only "automatic" is a gap with a timestamp. If nobody can name who is accountable for the rule, the change should not run unattended.
What does a one-page template look like?
One sheet, one row per change, the twelve columns, and a tab per month that is frozen once the month closes.
A header block holds the property, month, currency, and the name of the person who owns the log. The reason-code legend is printed at the top of the sheet, so nobody invents a new code at 11 pm. The review-date column is never left empty, and a simple filter shows only the lines due this week. One tab per month is archived read-only after the close, so history cannot be edited to look better.
At the bottom of each month, a three-line summary: changes made, changes reversed, one lesson. A single owner for the file. Shared editing is fine; shared ownership is how logs die.
Checklist
- Create the sheet with the twelve columns
- Print the reason-code legend in row one
- Add the header block
- Add the review-date filter
- Create twelve monthly tabs
- Write the three-line monthly summary block
- Name the owner in the header
What to do next
Start with one month and one sheet. Write a line for every rate change, read the week's lines at the start of the revenue meeting, and check the outcomes when their review dates arrive. The log earns its place the first time someone asks why a price moved and the answer takes ten seconds instead of an afternoon.
Frequently asked questions
What is a rate change log in a hotel?
It is a one-row-per-change record of price decisions, not a price history. Each row holds the date, the room type and rate plan, the channel, the old and new price, who decided, who entered it, the reason, the expected effect and the outcome. It lives where the team already works, in a shared sheet or attached to the property system, not in one person's folder.
How long should a hotel keep rate change records?
The log is an internal management record, not a fiscal document, so the retention period is the hotel's own choice. A practical minimum is the current budget year plus the following review cycle. Fiscal records follow separate rules, so confirm document retention with your accountant or legal adviser.
Should the log cover OTA changes only, or every channel?
Every channel, including the hotel's own website, direct reservations and travel agency rates. Parity and consistency questions only appear when all channels sit in one list, and a single-channel change is exactly the kind that gets forgotten. The channel column is what makes the whole picture visible.
Who should own the rate change log?
In a hotel with a revenue manager, that person owns the file and the general manager checks it weekly. In a smaller hotel the general manager owns it and the owner reads the monthly summary. The point is one named owner and a second person who checks, never the same name in both roles.
Does a rate change log replace the weekly revenue meeting?
No. It feeds the meeting and shortens it, because the week's decisions are already written down. The meeting still does the work the log cannot: judging the market, agreeing the approval threshold, and deciding what to do next.