How a channel manager works
- Mapping — each room type and rate plan in the PMS is matched to the channel's own codes.
- ARI out — when availability, rates or restrictions change for a night, the update is pushed to every connected channel.
- Reservations in — new bookings, modifications and cancellations from channels arrive in the PMS as real reservations and reduce availability everywhere else.
- Confirmation — the channel acknowledges each message, so failures can be seen and retried.
Features that matter
| Feature | Why it matters |
|---|---|
| Per-channel pricing | Sell the same plan at different prices where contracts allow |
| Safe retries | A repeated message must never create a second booking |
| Overbooking handling | A booking that does not fit should wait for a decision, not disappear |
| Delivery visibility | See what each channel confirmed and what failed, and why |
| Parity checking | Compare channel bookings against the rate each channel was sent |
Channel manager vs PMS
The PMS is the source of truth for inventory, guests and money; the channel manager distributes that truth. When they are separate products, the link between them is a common source of errors. See PMS vs channel manager vs booking engine.
How bedsKey's channel manager works
The channel manager is built into bedsKey. Every changed night is pushed at that channel's price, as far ahead as you choose; bookings, changes and cancellations arrive as real reservations, and a retry never books twice. It speaks the published OpenTravel (OTA) XML message set, with channel adapters built. Room-type and rate-plan mapping can be bulk-pasted and is validated before it applies, every channel booking is compared against the rate that channel was sent, and a booking that does not fit waits on an overbooking queue. A connection cannot go live until its test against the channel's own sandbox is recorded. bedsKey’s channel manager has certified OTA connections.