Choosing a channel manager: ten questions on connections, mapping, support and exit
A channel manager decision made on a sales call can lead to overbookings months later. This guide provides ten questions, a pre-demo checklist and a scoring sheet to compare vendors on connections, mapping, support and exit terms.
Contents
Key takeaways
- A channel manager is judged on the connections it maintains, not the list it advertises: ask which are direct, which run through a third party, and who fixes each one.
- A restriction the channel does not support does not fail loudly; it disappears, and the room sells under the wrong terms.
- Ask to see the error log and the alert before you sign; an error you cannot see is a booking you cannot honor.
- Your room-type and rate-plan mapping is your data: ask for a sample export and the exit steps in writing before the first rate is sent.
- Score vendors on evidence from a scripted demo using your own rate plans, not on their answers to a questionnaire.
A channel manager is software that keeps one set of rooms, rates and restrictions and sends it to every booking site you sell on. When choosing a channel manager, judge it on what it connects to, which rates and restrictions it can send, how you see errors, what support covers and what happens to your mapping when you leave.
The rate is correct in your system and wrong on the booking site, and the first person to notice is a guest standing at the front desk. Most channel manager decisions are made on a sales call, months before that moment. After reading this guide you will have ten questions to ask, a checklist to send before the demo, and a scoring sheet that makes two offers comparable.
What does a channel manager actually do?
A channel manager holds one picture of your rooms, rates and restrictions and pushes it to every booking site you sell on, so you stop typing the same change into five extranets. It is a sender, not a source of demand and not a front desk.
Three pieces of software do three different jobs. The property management system (PMS) records the reservation and the guest. The booking engine sells rooms on your own website. The channel manager carries availability and prices outward to booking sites, known as OTAs (online travel agencies). For a fuller comparison, see PMS vs channel manager vs booking engine: what each one does.
The direction of travel matters. Rates and restrictions go out; reservations come back in. The reservation must land in the PMS without a person retyping it, because every retyped reservation is a chance to transpose a date or a room type.
The failure mode this tool exists to prevent is the same room sold twice, because two systems each believed it was free. What it does not do is equally important: it does not create demand, it does not set your prices, and it does not replace a person checking that the picture on the channel matches the picture in your system.
Decide your source of truth before you compare vendors. One system must be the place where a rate change starts, and every other system follows it. If the PMS is the source, the channel manager must never be edited directly except in an agreed emergency, and the exception must be logged.
A hotel can own a channel manager and still lose a room to a stale rate if nobody owns the daily check. The software sends what it is told; it does not confirm that the channel received it, displayed it, or displayed it correctly.
Which channels does it connect to, and who maintains each connection?
Ask for the channel list in writing with the date it was last checked, and for each channel ask whether the connection is direct or runs through a third-party connectivity provider. The second answer matters more than the first.
A connection is not a logo. Behind each channel sits an interface that one side must maintain, and when the channel changes it, someone has to fix the mapping. Ask what happens on the channel side when an interface changes: who is told, how quickly, and whether the hotel hears about it before or after a rate goes wrong.
Separate direct connections from connections that pass through an intermediary. Two hops mean two places where a rate can stop, and two support desks that can point at each other. Ask for a named contact per connection, and ask whether the vendor's support team can see the channel's own error message or only its own. For how these messages actually travel, see How a channel manager connection works: messages, delays and errors.
Ask which channels on the list are certified or tested end to end, and which are described as possible. Treat "possible" as not available. Ask for a reference hotel of similar size and seasonality, and ask that hotel what broke in the first month. Before go-live, test one booking per channel and confirm the reservation arrives in the PMS with the right room type, rate plan and guest details.
The connection checklist to send before the demo
ChecklistSend this list to the vendor before any demonstration, and ask for written answers
- Written channel list, with the date each connection was last checked
- Direct or via a third party, per channel
- Named contact per connection
- What happens when a channel changes its interface
- Which connections are tested end to end and which are only possible
- Reference hotel of similar size and seasonality
- One test booking per channel, confirmed in the PMS with correct room type, rate plan and guest details
- Who at the hotel is told when a connection fails
Which rates and restrictions can it actually send?
Ask for the full list of rate and restriction types the connection supports, channel by channel, because a restriction the channel cannot receive does not fail loudly. It disappears, and the room sells on terms you did not set.
The common set is worth walking through. Closed to arrival stops a guest arriving on a date while allowing arrivals on other dates that cover it. Minimum and maximum length of stay control the shape of the booking. Stop sale closes a room type entirely. Occupancy-based pricing sets what an extra adult or a child pays. Derived rates build a rate from a base rate, for example a nonrefundable rate derived from a flexible one.
Two selling models sit behind all of this. Allotment means a block of rooms set aside for a channel; free sale means any free room can be sold. These are industry practices with no official definition to appeal to, so the contract must say what the vendor means by each.
Currency and tax deserve their own questions. Which currency is the rate stored in, which currency does the channel receive, and who converts? How is tax and fee display handled: does the channel show the price the guest pays or the price the hotel receives? Ask how board types and rate plans are named, and whether the hotel controls the naming or inherits the vendor's.
Most important: ask what the system does when a restriction cannot be sent. Does it warn, block the push, or send the rate without it? The third behavior is the one that sells your rooms on the wrong terms. Insist on a scripted test with your own rate plans, not the vendor's demo property. The mechanics of that mapping are covered in Channel manager mapping: room types, rate plans and testing.
| Restriction or rate feature | Question to ask the vendor | What a weak answer sounds like |
|---|---|---|
| Closed to arrival | Supported on every channel we sell on? | "Most channels support it." |
| Minimum and maximum stay | Sent per date, per room type? | "It is handled automatically." |
| Stop sale | Does it stop the push or only the display? | "You can close the room in the extranet." |
| Occupancy-based pricing | Extra adult and child prices per channel? | "The channel calculates that." |
| Derived rates | Built from a base rate, or retyped per plan? | "You set each rate separately." |
| Currency | Stored where, sent where, converted by whom? | "Currency is not an issue." |
| Tax and fee display | Guest price or hotel price on the channel? | "It depends on the channel." |
| Allotment vs free sale | What does the vendor mean by each? | No written definition offered. |
| Board type naming | Hotel-controlled or vendor-inherited names? | "The standard names work fine." |
| Restriction cannot be sent | Warn, block, or send without it? | "It usually gets through." |
How do I see an error before a guest does?
Ask to be shown the error log and the alert during the demo, not told about them. If the hotel cannot read the failure, the hotel cannot fix it before it becomes a booking it cannot honor.
Three states are easy to blur: queued, accepted and live. Queued means the system accepted the change. Accepted means the channel took it. Live means a guest can see it. Only the third one is done, and only the third one earns money.
Ask what the log records: the time, the channel, the room type, the rate plan, the value sent and the channel's own reply. Ask how the hotel is alerted, to whom, and how often a repeated failure is repeated back to you. A system that alerts once and then goes quiet has decided, on your behalf, that the second failure does not matter.
Ask what happens on retry: how many attempts, over what period, and whether a failed push is retried after the rate has already changed again. Ask for a reconciliation view, a single screen where the hotel can compare what it sent with what the channel holds.
Then agree a daily check that a person owns. Pick one room type and one date, and look at the channel's own website, not the channel manager's screen. The consequence of a missed error is an overbooking, and once a guest is standing in the lobby that is no longer a software problem; the steps that follow are a separate discipline, covered in when the hotel has to cancel a confirmed booking.
Watch outA green tick means sent, not correct
A channel manager showing a green tick means the message was sent, not that the channel is selling the right room at the right price. The only proof is the channel's own public page, checked by a person.
What does support actually cover, and when?
Support is a set of hours, a set of people and a set of things they are allowed to do. Ask for all three in the contract, because a fast answer that cannot touch your mapping is not support.
Ask for the hours in your own time zone, and separately for the hours that cover the channel's time zone and your peak booking window. Ask who answers at night: the vendor's own team, a shared inbox, or nobody until morning. Ask which language support is delivered in, and whether the person who answers understands rate plans or only tickets.
Ask what the support team can do on your account: read only, advise, or change the mapping themselves. The third is worth paying for; ask for it in writing. Ask for the escalation path and the name of the person it reaches, and ask what happens when the fault is on the channel's side, which is the case that exposes how the two companies work together.
Test it before signing. Send one real but harmless request during the sales process and time the answer. Then put the response commitment and the exclusions in the contract, and read the exclusions, which usually cover channel-side outages.
TipJudge the answer, not the promise
The cheapest way to judge support is to send a real mapping question during the sales process, before the contract, and to judge the quality and speed of the answer you actually receive.
What happens to my mapping when I leave?
Your room types, rate plans and the codes that link them to each channel are your data, and leaving well is decided in the contract, not in the last week. Ask for a sample export and the exit steps before the first rate is sent.
Ask what an export contains: room type names, rate plan names, the channel's own codes, and the link between them, in a format a person can read. Ask who owns the codes on the channel side, because a new system must reuse them or the channel will create duplicates, and untangling duplicate rate plans on a channel's extranet is slow, manual work.
Ask for the notice period and whether the contract allows a parallel period, when both systems hold the same inventory. The parallel period is dangerous: two systems pushing availability to the same channel can produce two different answers, so agree which one is switched off first and when. Ask what happens to the channel-side connection when the contract ends: is it closed by the vendor, by you, or does it stay open and keep sending. Ask what is deleted and when, and get the answer in writing.
Treat a vendor that will not show an export before signing as a vendor that will not show one after.
Watch outTwo systems, one channel
Leaving a channel manager badly can leave two systems writing to the same channel. The switch-off order and the date must be agreed in writing before the new system sends anything.
How do I score two channel managers side by side?
Turn the questions into a sheet with weights, score each answer against evidence rather than against the sales pitch, and let price be one line rather than the decision. The sheet is what makes two offers comparable.
Weight the questions before you speak to either vendor, so the weighting is not shaped by the better presentation. Score each answer from zero to two: zero for a promise, one for a document, two for a demonstration on your own rate plans. Record the evidence next to the score, so a colleague who was not in the meeting can see why a vendor scored as it did.
Keep price as a single line, and compare it against the cost of the daily check and the parallel period, which are real work either way. Run the same scripted demo with both vendors: same room types, same restrictions, same test booking, same error scenario. Decide in the low season, not in the middle of one, and write the go-live date and the switch-off date into the plan. If you want a broader template for comparing hotel software offers, see a requirements document for hotel software.
| Question | Weight (1 to 3) | Vendor A (0 to 2) | Vendor B (0 to 2) | Evidence seen |
|---|---|---|---|---|
| Connections, direct or via a third party | 3 | |||
| Rates and restrictions supported | 3 | |||
| Error log and alerting | 3 | |||
| Support hours and what support may change | 2 | |||
| Export and exit terms | 2 | |||
| Scripted demo result | 3 | |||
| Price | 1 | |||
| Total |
What to do next
Build the scoring sheet this week, before any vendor call, and fill it only with evidence from a scripted demo on your own rate plans. The ten questions are not a test the vendor passes or fails; they are the list of things you will live with every day after the contract is signed, and the sheet is how you find out which of them you are buying.
Frequently asked questions
Is a channel manager the same as a booking engine?
No. The booking engine sells rooms on the hotel's own website and takes the reservation directly. The channel manager carries availability and prices outward to booking sites. Some vendors sell both in one product, which is convenient but makes the exit question harder, so ask which parts are separable before choosing a channel manager from a combined offer.
Can I run a channel manager without a property management system?
Yes. A small property can run this way, with the channel manager holding the inventory. The cost is that reservations arrive in an inbox and someone retypes them, and that the room count lives in a place that is not the front desk. The risk grows with the number of channels and the number of room types.
How long does switching a channel manager take?
It depends on how many channels, room types and rate plans must be remapped, and on how quickly the old connection can be closed. The sequence matters more than a duration: export, remap, test one booking per channel, run a parallel period with a clear switch-off order, then close the old connection in writing.
What should I test before going live?
One booking per channel, confirmed in the PMS with the right room type, rate plan and guest details. One restriction that the channel supports, checked on the channel's own public page. One deliberate error, to see the log and the alert. One rate change, timed from the moment it is saved to the moment a guest can see it.
Does the cheapest channel manager cost more in the end?
It can, because the hidden cost is the daily check and the time spent chasing failures. Frame it as work rather than money: ask how many minutes a day the reconciliation takes and who does it. A vendor that cannot answer that question has not measured it.