# Rate plans

A **rate plan** is a named pricing arrangement that travellers book against — the answer to *"at what price, with what conditions"*. A property can sell against many rate plans at the same time — refundable, non-refundable, member-only, package — each with its own base rate, currency, meal plan and rules.

{% hint style="info" %}
**One room, several rate plans, several products.** *Best Available Rate*, *Non-Refundable Europe*, *Member Saver* and a *Half-board upgrade* on the same room are four products for four audiences. The platform tracks them independently and sells them in parallel.
{% endhint %}

***

## What a rate plan defines

| Element                 | What it says                                                                                                                   |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **Name**                | The label travellers and operators see (*Best Available Rate*, *Member Saver*, *Non-Refundable Europe*).                       |
| **Base rate**           | The starting price per night, per room, per occupancy.                                                                         |
| **Currency**            | The currency the rate is denominated in. Multi-currency setups handle the contract / settlement / display split automatically. |
| **Meal plan**           | What is included with the stay (room only, breakfast, half-board, full-board, all-inclusive).                                  |
| **Audience**            | Who can see and book it (public, members only, B2B partners, specific markets).                                                |
| **Cancellation policy** | When and how the booking can be cancelled, refunded, or modified.                                                              |
| **Channel exposure**    | Which outbound channels the rate plan is published to.                                                                         |

A rate plan does not exist alone — it lives on a property, applies to one or more rooms, and is calendared per date.

***

## Many rate plans on the same room

The same room typically sells against several rate plans simultaneously. A *Deluxe Sea View* might be available as:

* **Best Available Rate** — the public refundable rate, EUR 180/night with breakfast.
* **Non-Refundable Europe** — 10% off for European travellers, locked in at booking.
* **Member Saver** — 15% off for logged-in members, refundable.
* **Half-board upgrade** — Best Available Rate + half-board, EUR 220/night.

A traveller (or a partner channel) sees only the rate plans they qualify for. A member sees both the public rates and their member rate; a European traveller sees the non-refundable; a B2B partner sees a B2B-only rate plan that does not surface to retail.

***

## Base rate vs. final rate

The **base rate** is what you set on the rate plan for a date. The **final rate** is what reaches the traveller after the engine layers everything on top.

<figure><img src="/files/CDhtsr1zsggn7i0rzEWk" alt="Base rate goes through 6 transformation layers to become the final rate"><figcaption><p>The engine applies meal plan, markup, promotion, discount, audience rules and the MSP clamp in order. You set the base; everything else rolls up automatically.</p></figcaption></figure>

The engine applies the layers in order:

1. **Meal-plan adjustment** (e.g. half-board supplement)
2. **Markup or commission** (from the contract)
3. **Active promotions**
4. **Discounts**
5. **Audience-specific rules** (member, market, channel)
6. **Minimum selling price (MSP) clamp** — explained below

You typically set the base rate; the engine handles the rest. Change the base, and every affected final rate rolls up automatically. For the full derivation chain see [Pricing engine](/console/pricing-and-availability/pricing-engine.md).

***

## Derived rate plans (parent → child)

Sometimes you do not want to set a base rate at all — you want a rate plan whose price *follows another rate plan*. A common pattern:

* *Best Available Rate, refundable* — your master rate plan; you set the base.
* *Non-Refundable* — same rooms, no refund window, **10% off the master rate**.
* *Member Saver* — same rooms, **15% off the master rate**, refundable.

The two derived rate plans never carry their own base rate. They follow the master, with an offset. Change the master and the derived plans update automatically.

### What can be inherited

A child rate plan can follow its parent on any combination of these aspects:

| Aspect                          | What it means                                                                                       |
| ------------------------------- | --------------------------------------------------------------------------------------------------- |
| **Price**                       | The child's rate is computed as parent ± offset (percentage or fixed amount).                       |
| **Restrictions**                | Stop-sale, min/max stay, day-of-week rules — the child uses the parent's.                           |
| **Cancellation policy**         | The child uses the parent's policy.                                                                 |
| **Status (open / closed)**      | The child opens and closes with the parent. Modes: never, when-open-only, when-closed-only, always. |
| **MSP** (Minimum Selling Price) | The child inherits the parent's MSP floor.                                                          |

You pick which aspects to inherit per child. A typical *Non-Refundable* child follows price and restrictions but carries its own cancellation policy. A typical *Member Saver* child follows everything except price (its own discount math).

{% hint style="info" %}
**What is MSP?** Some contracts impose a floor — a price below which you cannot sell. It is usually for rate parity (you cannot show the same room cheaper on another channel) or brand protection. If the engine computes a final rate below the MSP, it automatically clamps up to the floor; the booking lands and your contract is not violated. For the full clamp flow see [Pricing engine → MSP](/console/pricing-and-availability/pricing-engine.md).
{% endhint %}

### Offset — percentage or fixed

A child's price relation to its parent is one of:

* **Percentage** — *parent − 10%* or *parent + 5%*. Common for member rates and risk-priced non-refundable rates.
* **Fixed amount** — *parent − EUR 20 per night*. Common for promotional bundles or seasonal adjustments.

Each child uses one mechanism, not both, on a given relation.

### Chains

A derived rate plan can itself be a parent of another derived rate plan — *Best Available Rate → Non-Refundable → Non-Refundable Mobile*. Derivation chains can be **up to 5 levels deep**; cycles (a child indirectly pointing back to itself) are rejected.

### Why this is useful

Derived rate plans let you maintain pricing rationally. You change the base once; all the variants follow.

A concrete example: remember *Deluxe Sea View* at EUR 180? Raise the Best Available Rate from EUR 180 to EUR 200 for early summer and **Non-Refundable Europe automatically becomes EUR 180** (200 − 10%), **Member Saver becomes EUR 170** (200 − 15%). You do not have to update three plans by hand.

When you add a new market or a new audience, you derive a new rate plan from the existing master. The math stays explainable — every booking shows the chain that produced its rate.

***

## Setting rates across dates

The platform's rate calendar lets you:

* **Open a date range** for a rate plan and a room — drag-select May 1 to October 31.
* **Apply a base rate** in one move — EUR 180/night for the full range.
* **Vary by day of week** — EUR 180 weekdays, EUR 220 weekends.
* **Override specific dates** — June 15 is a high-demand event date, EUR 280 just for that night.
* **Bulk-edit with Adragent** — *"Apply weekend pricing of EUR 220 to Hotel Sunrise's Best Available Rate for all weekends in May."*

Every change goes through preview before commit. See [Cell history](/console/pricing-and-availability/cell-history.md) for what gets recorded.

***

## Rate plans and channel exposure

You decide per channel which rate plans go out. When you create a new rate plan, exposure starts from one of the defaults; you can change it manually whenever you need to.

The defaults:

* **Direct-only** — internal pricing tools, staff bookings, demos. Never published. *Practical use: test a new package on your own site first, before exposing it to OTAs and metasearch.*
* **Public retail** — public rate plans go to public channels (online travel agencies, hotel comparison engines).
* **B2B-only** — partner rates that go to B2B channels but not to consumer-facing ones.
* **Channel-specific** — a promotion you only want a metasearch engine to see, or a rate plan you only want a B2B inventory distributor (bedbank) to receive.

Per-channel exposure is the same overlay used for everything else — see [Stop-sale & restrictions](/console/pricing-and-availability/stop-sale-restrictions.md).

***

## Cancellation and modification policies

Each rate plan carries a cancellation policy that travels with the booking. A policy is **tier-based** — it can have multiple penalty steps tied to how close to check-in the cancellation happens.

| Tier shape                       | Example                                                                      |
| -------------------------------- | ---------------------------------------------------------------------------- |
| **No charge** before a cut-off   | *Free cancellation until 24 hours before check-in.*                          |
| **Percentage penalty**           | *50% of the booking value if cancelled 24–6 hours before check-in.*          |
| **Fixed first-N-nights penalty** | *Charge for the first night if cancelled less than 6 hours before check-in.* |
| **Fixed amount**                 | *EUR 50 fee for any cancellation within 48 hours.*                           |
| **Non-refundable**               | *No refund regardless of timing — booking locked at confirmation.*           |

You stack tiers from furthest from check-in to closest; the system picks the active tier from the cancellation timestamp.

{% hint style="warning" %}
**If two tiers cover the same window, the one listed first wins.** The order you choose matters. Travellers see the resulting policy on the booking flow; the cancellation engine applies it deterministically.
{% endhint %}

### Date-range exceptions

Some date ranges deserve a stricter policy — peak season, holidays, major events. Each cancellation policy can carry **exceptions** that override the standard tiers for a specific range:

* *Standard policy: free cancellation until 24h before check-in.*
* *Exception (Dec 22 – Jan 5): non-refundable from booking.*

The exception is applied automatically based on the stay date; outside the exception range, the standard policy applies. You do not have to maintain two separate rate plans for peak vs. off-peak.

Policies are part of the rate plan, not a separate object — when a traveller chooses *Best Available Rate*, they are choosing the policy that comes with it.

***

## Rate plan templates

When you operate many properties, building rate plans from scratch each time is wasteful. The platform ships with **rate plan templates** — pre-configured shapes such as:

* *Best Available Rate, room only.*
* *Best Available Rate, with breakfast.*
* *Non-Refundable, room only.*
* *Non-Refundable, with breakfast.*

Onboarding a new property clones the templates you choose; the new property gets ready-to-edit rate plans within seconds. You then customise per property as needed.

You can extend the template catalog with your own shapes (chain-specific defaults, market-specific patterns) and reuse them across the entire organization.

***

## Guest categories — adults, children, age buckets

A rate plan applies differently to adults, children, and age-defined buckets within children. Rather than fixing this with a single "child" definition, the platform lets you define per-property guest categories:

* **Adults** — every property has exactly one adult category.
* **Children, with named age buckets** — *Children 0–2*, *Children 3–6*, *Children 7–12*. The buckets, the names, and the age ranges are yours to define per property.

Each rate plan can then carry per-bucket pricing rules (free, percentage of adult rate, fixed amount). A traveller booking with two adults and a four-year-old child gets the right rate for the bucket the child falls into.

This matches how partner channels define children's rates — a property with a *Children 3–6 free* rule publishes that fact correctly to every channel that supports it.

{% hint style="warning" %}
**Buckets must not overlap and must not leave gaps.** *Children 0–2* and *Children 2–5* cannot coexist; nor can *Children 0–2* and *Children 4–6* (the 2–4 gap is rejected). Misconfigurations are caught on the form before save, not at booking time.
{% endhint %}

***

## How rate plans relate to contracts

A rate plan you sell exists because of a **contract** — either with a property you operate, or with a supplier whose inventory you resell. The rate plan is the public face of contractual terms; the contract is what backs them.

A single rate plan can be backed by **more than one contract** — for example the same property can sell May–June through your direct contract and July–August through a B2B inventory partner (bedbank). The system tracks which contract version backs each rate cell.

When a contract changes (a new markup, a different season's net rate, a renegotiated commission), the rate plans that depend on it update; the engine reads the new contract terms automatically.

When a contract **expires**, the rate plans for the date ranges it covers stop accepting new bookings — existing reservations are honoured at the terms they were signed under, and no new ones can land. The system warns you ahead of the expiry so renewal does not get missed.

See [Contracts](/console/contracts-and-onboarding/contracts.md).

***

## Where to next

* **The bookable-units side** → [Inventory](/console/pricing-and-availability/inventory.md)
* **What controls bookability on a date** → [Stop-sale & restrictions](/console/pricing-and-availability/stop-sale-restrictions.md)
* **Promotions layered on top of rate plans** → [Promotions & discounts](/console/pricing-and-availability/promotions-and-discounts.md)
* **How the final rate is computed** → [Pricing engine](/console/pricing-and-availability/pricing-engine.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://adrasis.gitbook.io/console/pricing-and-availability/rate-plans.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.