Reservations
Reservations overview
The commercial side of the house: what you sell, at what price, with what restrictions, through which channel — and who is allowed to change it.
Last updated
Who this is for: Owner and Manager — reading needs
crs.booking.readorcrs.rates.read; most of the writing here is Owner-level by default. Where: Reservations
Front Desk owns what you deliver. Reservations owns what you sell: the catalog, the price, the restrictions, and every channel the property sells through. It is the module a revenue manager lives in.
One fact runs through all of it — the direct booking engine and every connected OTA sell the same inventory and the same restrictions. There is no second copy to keep in step.
Note
This section uses the default terminology. Your house may have renamed these terms under Settings → Terminology.
Who works here#
This is the section where the default Manager bundle stops short, and it surprises people.
| Role | Can | Cannot |
|---|---|---|
| Owner | Everything | — |
| Manager | Read bookings and rates; answer messages; reply to reviews; edit property content | Edit rates, availability or restrictions; manage channels; manage listings |
| Read-only | Read bookings, rates, messages and reviews | Any change |
That split is deliberate: a price or a stop-sell that reaches an OTA is hard to retract, so the write permissions sit with the Owner unless a custom role moves them. Roles are configurable per organisation — see roles and what each one can do.
Where a screen needs a permission the Manager bundle does not carry, its page says so on the header line.
What's in this section#
- Bookings from every channel — what came in, and what could not be matched.
crs.booking.read - Room categories and rate plans — the catalog and derived pricing.
crs.rates.read - Availability and ARI distribution — push a change and watch it land.
crs.availability.write - Restrictions and stop-sell — closing a date everywhere at once.
crs.restrictions.write - Distribution settings and the availability series — cut-offs, guardrails, what a channel may sell.
crs.rates.read - Connecting a channel — connect, map, certify.
crs.channel.manage - Listings and vanity properties — one hotel as several OTA storefronts.
crs.vanityproperty.manage - Guest messaging from OTAs — one inbox for every channel.
crs.messaging.read - Reviews — read, reply, and review the guest back.
crs.reviews.read - Property content — description, photos, facilities, policies.
crs.content.write
When something else is the master#
If your property runs an external channel manager and it is connected on the Integration Hub, it masters the facts it owns — mappings, ARI, or both. Nerve renders those screens read-only and refuses server-side writes to them, and a banner on the affected screen says which facts are involved.
There is never more than one writer to a fact. Whatever the arrangement, the front desk stays the system of record for stays.
How it connects#
A booking becomes a stay. Anything that arrives here — from a channel or from the direct booking widget — materialises as a Front Desk stay on the right room type and rate, with taxes and the payment-collection method carried onto the folio. From that point it is an ordinary arrival: see the Front Desk overview.
Revenue pushes back through here. Accepting a rate recommendation in the Revenue module updates the rate plan and queues an ARI change to every mapped channel — it does not stop at the price.
The booking widget sells the same truth. A stop-sell applied here closes the direct widget as well as the OTA, which is the whole reason restrictions live in one place.
Note
On staging, every channel connection runs against an in-process stub. Connections, mappings, ARI pushes, messages and reviews all behave as specified and delivery states are real — but nothing reaches a live OTA.