AI rate recommendations: what a revenue manager should check

A rate recommendation is a suggested change to a room rate, produced by software and approved by a person. Before approving, a revenue manager checks three things: the inputs behind it, the rule that fired, and what the change is meant to do. Then they record approve, adjust or reject, with a reason.

A queue of suggested rate changes is waiting before the morning meeting. Each line is a date, a room type and a new price, and each one will reach every connected channel the moment someone approves it. The question is not whether the number looks reasonable. It is whether you can trace it to something you can check. This article gives you the parts a reviewable reason must contain, the checks to run before approving, and a way to record and review decisions that keeps accountability with a person.

Why can't a rate suggestion be reviewed without its reason?#

Because the number alone gives the reviewer nothing to compare against. The reason is the only part of a suggestion that can be held up against facts the hotel already owns.

A rate is a commitment, not an opinion. Once approved, it becomes the price a guest can book and the price an agency sees, so the approval is an action with consequences on every channel. The reviewer's task is not to decide whether the number feels right, but whether the inputs are current and correct, and whether the rule is one the hotel would apply by hand.

Confidence is not evidence. The National Institute of Standards and Technology's Generative AI Profile (NIST AI 600-1, July 2024) (opens in a new tab) defines confabulation as confidently stated but erroneous content, and lists automation bias, the tendency to over-rely on machine output, among the risks of human-AI arrangements. A well-written paragraph is not a checked one.

A written reason also turns a suggestion into a decision you can defend later to an owner, a contracted agency or an auditor. Without a reason, a rejection carries no information: the same suggestion returns tomorrow, because nothing told the system what was wrong. And the reason is training material for your own team. A junior revenue manager learns the hotel's pricing logic by reading why a change was proposed and why it was adjusted. For a broader grounding, see our guide to AI in hotels: uses, limits and safeguards.

What does a reviewable reason contain?#

Five parts: the inputs it used, the rule it applied, what the change is meant to do, the scope of the change, and how it can be undone. If any part is missing, the suggestion is not reviewable yet.

The inputs are business on the books for the same date last year, the current rate on each channel, the restrictions in force, contracted rates and any known event. The reviewer checks that each input is current and belongs to the right date, room type and rate plan. The rule is the condition that fired and the size of the change, stated as a condition rather than a conclusion: for example, "pickup for this date is behind the same point last year, so raise by a set amount."

The intended effect is what the change is meant to do, such as protect a rate floor, close a gap in a soft week or stop a channel selling below a contracted rate. It is a goal, never a promised result. Scope says which dates, room types, rate plans and channels move; most bad approvals are scope errors, where a change meant for one room type reaches all of them. Undo says how the change is reversed and what reversing it costs, including any booking already taken at the new rate. Finally, every rule should have a named owner, so a rule that keeps misfiring has somewhere to go.

Which checks come before you approve a rate change?#

Contracts, parity terms, restrictions, channel mapping, tax and meal basis, and the facts the system does not know. Run them in that order and most bad approvals stop before they reach a channel.

Agency and corporate contracts come first: the new rate must not undercut a contracted net rate or break a negotiated ceiling for the same dates. This is the check that costs the most when it is missed, because the agency finds out before you do. Next, parity and rate-plan terms: if you have agreed a best-available or most-favored condition with a partner, check that the change does not break it.

Restrictions must still make sense at the new rate. A higher rate with a three-night minimum can empty a date that a lower rate with no minimum would have filled. Channel scope and mapping: know which channels receive the change, and confirm that room type, rate plan, meal basis and tax inclusion are mapped correctly on each one. Currency and tax basis: the rate is quoted on the same basis as before, room only or breakfast included, tax included or excluded. A change of basis disguised as a change of price is a common and expensive error.

Timing matters too: know how long the change takes to reach each channel, and whether anything can be booked at the old rate in between. And supply the unrecorded facts yourself: a wedding block, a renovation, a group on hold, a closed competitor you know about. The system cannot weigh what nobody entered.

When is the reason too weak to approve?#

When it restates the number, cites data you cannot check, or rests on inputs that are missing, stale or about a different date. In each case the right move is to reject and say which part failed.

"Demand is high" is a conclusion, not a reason. Ask which input moved and by how much, and whether that input is one you trust for this date. Missing history is another weak foundation: a new hotel, a new room type, or a date with no comparable period last year leaves the tool with nothing to compare, and a suggestion built on nothing should be treated as a guess, however well written.

One-off events cut both ways. If a fair, a concert or a local closure is not among the inputs, the tool cannot have used it; if it is, check the date and the scale, because event calendars are frequently wrong. Stale inputs are quieter: rates loaded weeks ago, a contract signed since, restrictions changed by hand last week. The reason can be internally consistent and still describe a hotel that no longer exists.

A reason resting on competitor prices alone is weaker than one that agrees with your own booking pace. Competitor prices are other people's guesses; you cannot see their inventory, restrictions or contract book. And a reason that names something you cannot verify, such as an unnamed market signal, is not checkable and should not be approved on trust. NIST's Generative AI Profile (July 2024) describes confabulation as confidently stated but erroneous content, which is exactly the failure mode a well-written paragraph hides. For a structured way to probe a tool before trusting it, see how to test a hotel AI assistant.

How should you record approve, adjust or reject?#

Record the outcome, a short note in your own words, and the date. Three outcomes are enough, and the note matters more than the label.

Approve means the inputs check out and the rule is one you would apply by hand; record which inputs you verified, not just that you agreed. Adjust means the direction is right but the size, scope or timing is not; record what you changed and why, because an adjustment is a correction to the rule and should be read as one. Reject means an input is wrong, missing or stale, or a contract or restriction forbids the change; record which part failed, so the data or the rule can be fixed rather than the symptom.

Keep the note to one or two sentences in your own words. A note copied from the tool's own explanation adds nothing to the record. Record the rejections as carefully as the approvals: they are the only signal that a rule is firing on the wrong dates, and they are the first thing to read when a rate looks wrong a month later.

There is a security argument for this discipline too. The OWASP Gen AI Security Project's Top 10 for LLM Applications, Excessive Agency (LLM06, 2025 edition) (opens in a new tab) recommends limiting the tools an agent may call and their permissions to the minimum necessary, with a person approving high-impact actions before they are taken. Deciding in advance which rate changes are small enough to apply and log, and which wait for a person, is the same principle. Write the threshold down, so the boundary does not move with the mood of the morning. If you are evaluating vendors, our list of questions to ask an AI vendor covers this ground from the buying side.

How do you look back at past decisions without blaming the tool or the person?#

Review the decision and the outcome separately, on a fixed rhythm, and change the rule or the data rather than the story. The record exists to correct the system, not to grade a colleague.

A well-reasoned change can meet a bad week, and a careless one can get lucky; judging both by the result teaches the wrong lesson either way. Compare what the change was meant to do with what happened, using the hotel's own numbers: pickup for the date, the rate actually sold, cancellations and the business on the books at the same point last year. Read booking pace rather than a single day's figure, so that one quiet Tuesday does not become a rule change. Our guide to the hotel pickup report explains how to read that pace day by day.

Look for patterns in the rejections. One rule firing wrongly on the same room type every week is a data problem, not a judgement problem. Log rule changes with a date and a reason, so the next review can see what moved and why the numbers shifted with it. Keep the review about the mechanism: "the rule used a stale contract rate" is a finding; "the tool was wrong" and "the manager was careless" are both dead ends.

What to do next#

Take the next suggestion in your queue and write its three parts down before you touch the rate: the inputs it used, the rule that fired, and what the change is meant to do. If you cannot fill all three, reject it and note which part was missing. That single habit connects everything above: a reason you can check, checks you can run, a record you can read back, and a review that improves the rule instead of blaming the person.