Best available rate (BAR): building a rate structure with derived rates

The best available rate (BAR) is the lowest publicly bookable rate for one room type on one date, with no membership, contract or special condition attached. A clean rate structure keeps one BAR per room type per day and derives every other public plan from it by a written rule: percentage, fixed amount, rounding step and inherited restrictions.

Two people open the same hotel's booking page on the same day and see two different prices for the same room, and neither the front desk nor the revenue manager can say which one is the reference. That gap is usually a rate structure problem, not a pricing problem. After reading this you will be able to state your BAR precisely, decide which plans derive from it and how, audit your plan list, and check that the structure holds in every channel.

What is the best available rate (BAR)?#

BAR is the reference rate a hotel publishes for one room type on one date: the lowest price any member of the public can book without a contract, a membership or a special condition. Every other public rate plan is then built from it by a written rule.

Three properties make a rate a BAR. It is public, meaning anyone can book it. It is unconditional, meaning no advance purchase, no minimum stay and no membership is required. And it is specific, meaning it belongs to one room type on one date.

BAR is a reference, not a price list. Its job is to be the single number that other plans point at, so a change made once arrives everywhere. Name it the same way in the property management system, in the channel manager and in staff conversation. When the front desk says BAR and the booking engine means something else, the structure has already drifted.

Be clear about what BAR is not. It is not the net rate agreed with a travel agency, not the group rate, not the corporate negotiated rate and not the member rate. Those sit outside the public ladder, and we come back to them later.

A practical test: pick one date and one room type, and ask two people to state the BAR and show where it is stored. If the answers differ, the reference is not real. The most common failure behind that is a derived plan edited by hand in a channel. The system still holds a BAR, but the guest sees a number that no longer follows it.

BAR levels or a BAR set day by day?#

Both exist and they answer different questions. BAR levels are the ladder across room types and board bases; the day-by-day BAR is the value that ladder carries on each date.

A level is a fixed step: standard room to superior, room-only to breakfast included, single occupancy to double. Define the step once, as an amount or a percentage, and it holds on every date. The date value is the number the hotel actually decides: season, demand, a local event, a holiday week. Set it once per room type per date and let the levels move with it.

Hotels get into trouble when they set one annual BAR figure and then patch exceptions by hand. The exceptions become the real structure and nobody can reconstruct it later. A rule of thumb: levels are rules, dates are values. If a room type's price changed because the base changed, the structure worked. If someone had to edit it, it did not.

Single occupancy is a level rule, not a separate rate plan. Making it a plan doubles the number of cells to map without adding a customer condition. Review the day-by-day values on a fixed rhythm, and check the consequences after each change rather than the change itself. If the day-by-day values move often, that is a pricing question, covered in dynamic pricing in hotels: what it means when people set the rates.

The four layers of a rate structure#

The examples in the last column are illustrative only; your own steps will differ.

How do derived rates work: the rule, the rounding and the restrictions?#

A derived rate plan is a written rule that turns BAR into another public price: a percentage or a fixed amount, a rounding step, and a separate decision for every restriction it does or does not inherit.

The rule comes in four shapes. A percentage off, typically for a non-refundable plan. A percentage on, for breakfast or half board included. A fixed supplement, for an extra bed or parking. Or a step per night, for longer stays. Write the rule down in one sentence. If it cannot be written in one sentence, it is a second BAR wearing a plan name, and it will be maintained by hand forever.

Choose a rounding step, whole lira or the nearest ten, and apply it identically in the system and in every channel. Different rounding in two places produces two prices for one plan.

Which restrictions should a derived plan inherit?#

Restrictions are decided one by one, not with a single switch. Closed dates and stop-sells usually inherit, because a closed hotel is closed for everyone. Minimum stay, closed-to-arrival and closed-to-departure often must not, because they exist to protect the flexible BAR. A non-refundable plan that inherits a minimum stay meant for BAR will refuse short bookings it was designed to win. An early-booking plan needs its own booking window rather than the BAR's restrictions. The mechanics of these controls are explained in hotel rate restrictions explained: minimum stay, CTA and CTD.

The quiet failure looks like this: a derived plan inherits a stop-sell but not the date range behind it, so it stays open on nights the hotel is full. Document the inheritance decision next to the plan, so the next person does not have to guess it from the prices.

How many rate plans are too many?#

Too many is the point where nobody can state a plan's rule without opening the system. A workable structure has one plan per real customer condition, not one per channel, season or idea.

Count cells, not plans. Every plan multiplies across room types, dates and channels, so a tenth plan is not a tenth of the work. For each plan, name the guest condition it serves, such as advance purchase, longer stay, board basis, package or membership, and the rule that derives it from BAR. A plan that fails either test is a candidate for retirement.

Retire plans that produced no bookings in a season. An unused plan is not a free option: it is a mapping that can break silently and a price that can leak. Do not create a plan to solve a channel problem. If a channel shows the wrong price, the mapping is wrong, and a new plan adds a second error on top of the first.

Keep plan names stable. Renaming a plan in the system breaks the mapping in every channel that knew the old name. A package is a derived plan plus inclusions: keep the inclusions in the plan description and the price rule in the derivation, so the two cannot contradict each other. For the two conditions that carry most of this weight in practice, see early booking and non-refundable rates: when do they pay off.

Where do contracted net rates fit?#

Outside the public structure. A net rate agreed with a travel agency is a contract term, not a derivation from BAR, and it should never appear in the public ladder.

Net is what the agency pays; the agency sets the selling price. Deriving net from BAR by a fixed discount ties a signed contract to a number the hotel changes every day. Keep contracted rates in their own table with their own validity dates, allotment, release period and cancellation terms. They answer to the contract, not to the pricing calendar.

Parity is the risk. A net rate that leaks into a public channel breaks the contract and the structure at the same time, and the leak is usually a mapping error, not a decision. A quote the hotel can explain line by line is worth more than a discount it cannot reconstruct: the net, each rule that applied, and the final price. Corporate negotiated rates follow the same logic: a named account, a fixed term, a defined set of room types, kept apart from the public ladder. When a contract and the public structure disagree, the contract wins for its own dates, and the public structure should be checked for the leak. The full mechanics are covered in hotel net rates for travel agents: rules and clear quotes.

How do you check the structure in every channel?#

Walk one date and one room type through every channel and compare what a guest sees with what the system holds. The structure is only as good as its weakest mapping.

Map first. Every plan in the system must map to exactly one plan in each channel; an unmapped plan does not fail loudly, it simply disappears from that channel. Test a date with a restriction and a date that is closed, because restrictions are where inheritance and mapping disagree most often. Check rounding: the same derived plan should show the same price in every channel, to the lira.

Then test propagation. Change one date's BAR, and confirm that every derived plan and every channel moved. A single change that does not propagate tells you where the manual edit lives. Keep a written record per plan: name, rule, rounding, inherited restrictions, channel mapping and owner. It is the reliable way to hand the structure to a new reservations manager without rebuilding it from prices. Repeat the check after every contract change and every new channel, not only when a guest complains. The mapping itself is covered in detail in channel manager mapping: room types, rate plans and testing.

What to do next#

Pick one room type, one date and one channel, and write down the BAR, the rule behind every derived plan, the rounding step and which restrictions each plan inherits. If any line cannot be filled in, that is the gap to close first. Once the reference and its rules are written, the day-by-day values, the plan count and the channel mapping all become checks rather than guesswork.