NerveTài liệu

Doanh thu

Rate recommendations and parity

Accept a bounded, forecast-driven price move and watch it reach every mapped channel — and fix a channel that has drifted out of parity.

Cập nhật lần cuối

Who this is for: Manager, Owner, Read-only — reading and generating requires rms.recommendation.read; accepting or dismissing requires rms.recommendation.manage, which the default Manager bundle carries and Read-only does not. Where: Revenue → Recommendations

This is where the analytics become a price. A recommendation is a proposed move for one rate plan over one date window, generated from the demand forecast and bounded by guardrails. Accepting it changes the rate plan's price and queues the change out to every mapped channel, in one action.

Parity alerts belong on this page too: a parity alert is the same loop failing to close — a channel still selling a price you no longer intend.

Generate recommendations for a window#

  1. Set From and To to the stay window you want priced.
  2. Select Generate.

The list refreshes with a recommendation for every rate plan the engine will price. Generating again for a different window replaces the pending set rather than adding to it, so the list is always one coherent proposal and not an accumulation. Decisions you have already made are untouched — accepted and dismissed recommendations stay on record.

Two kinds of rate plan are never recommended:

  • Direct-only plans, because the point of the move is to reach the channels.
  • Derived and cascade plans, whose price follows a parent. Move the parent and they follow on their own — see room categories and rate plans.

A plan the guardrails will not move is simply absent from the list. An empty list is a valid answer: it means the forecast does not argue for changing anything.

Read a recommendation#

Each row carries the rate plan code, the date window, the current price, the proposed price, and a one-line rationale naming the forecast occupancy that produced it.

The rules behind it are fixed and worth knowing before you accept anything:
Raise when forecast occupancy is at or above 80%
Drop when forecast occupancy is at or below 40%
Between the two hold — no recommendation
Largest raise +20%
Largest drop −15%

The size of the move scales with how far past the threshold demand is — 85% forecast occupancy argues for a small raise, 95% for a larger one — up to the cap. The forecast that feeds this is the pace heuristic described on forecast and pace, which knows your booking pace and nothing about your market. You are the part of this loop that knows about the city marathon.

Accept a recommendation#

  1. Find the row.
  2. Select Accept.

Accepting does three things, in order, as one action:

  1. The rate plan's price is set to the recommended price, in the same catalog the Reservations module reads.
  2. An ARI rate change is queued to every channel that plan is mapped to.
  3. The recommendation is marked accepted, with the price it moved and the forecast that argued for it.

Follow the push in availability and ARI distribution — the change appears there with a per-channel delivery status and retries on its own if a channel is unreachable. That is the end of the round trip: forecast to recommendation to price to channel.

A recommendation can be decided once. A second accept, or an accept after a dismiss, is refused rather than applied twice — which also means two people clicking at the same moment cannot double the increase.

Ghi chú

A property with no connected channels is not an error. The price is applied and sells through the direct booking engine; there is simply nothing to push.

Ghi chú

On staging every channel connection runs against an in-process stub. Delivery states are real and behave as specified, but nothing reaches a live OTA.

Dismiss a recommendation#

  1. Find the row.
  2. Select Dismiss.

Nothing changes: no price, no push. The recommendation is recorded as dismissed and stays visible, which is the point — the record of a move you decided not to make is as useful in a review as the one you made.

Act on a parity alert#

The parity report sits at the foot of Revenue → Analytics. For every rate plan distributed to a channel it compares the plan's current price against the price that channel was last told, and flags any gap wider than 1% of the intended price.

A drifted row means the channel is selling at a price you no longer intend. The usual cause is a price changed in the catalog without redistributing it, and the fix is a redistribution rather than another price edit:

  1. Confirm the intended price on that plan is the one you meant — room categories and rate plans.
  2. Push the plan's rates for the affected dates — availability and ARI distribution.
  3. Re-read the parity report. The row returns to parity once the push is delivered.

Mẹo

Parity is the cheapest health check in this section. A channel that drifts repeatedly after successful pushes is a mapping problem, not a pricing one — see connecting a channel.

What's next#