Is the channel connection really working? A daily check for rates and availability
A channel manager can report itself as connected while a single rate or date stops updating. This guide explains the daily three-by-three comparison, how to read sync logs, and what to demand from your provider.
Contents
Key takeaways
- A channel connection can report itself as connected while a single rate or date has stopped updating, so the daily check compares values, not a status light.
- Compare the same three room types on the same three dates in the PMS and in each channel's extranet, every day, weekends included.
- Read the sync log for rejected messages and the pending queue for unconfirmed ones; a queue that only grows means the connection is not keeping up.
- When numbers differ, close the room or rate on the channel first, correct it in the PMS, then verify on the extranet and write down what happened.
- Ask the provider which failures raise an alert, who receives it and how fast, and assume no alert exists until you have seen one arrive.
A channel manager is software that pushes your rates and availability to booking sites. It can fail silently: the link stays up while one rate or one date stops updating. Do a channel manager sync check for hotels daily by comparing three room types on three dates in your PMS against each channel's extranet, then read the sync log and the pending queue.
The phone rings: a guest says the room is cheaper on a booking site than at the desk. Or the last room sells twice, because it was still on sale online an hour after the front office closed it. Neither is a crash. Both are silent sync failures, and both are preventable with a five-minute routine. After reading this, you will know how the failure hides, what to compare each morning, how to read the log and the queue, and what to demand from your provider.
How does a channel connection fail without anyone noticing?
Because "connected" describes the link, not the data. A channel manager can hold an open connection to a booking site while individual rate or availability messages are rejected, delayed or overwritten. To see why, it helps to understand how a channel manager connection works, message by message.
A channel manager holds one copy of your rates and availability and sends it to each booking site. Every send is a separate message per room type, rate plan and date, so one message can fail while the rest succeed. Partial rejection looks healthy: one rate plan out of six fails a rule the channel enforces, such as a minimum stay that contradicts the rate, and the other five keep updating.
Two subtler failures exist. A stale overwrite happens when a message queued yesterday arrives after today's change and puts the old value back, with no error anywhere. Mapping drift happens when someone renames or deletes a rate plan in the PMS: the channel keeps the last value it ever received and never updates that plan again.
One case is not a sync failure at all. The extranet can show the new price while the public search page still shows the old one for a while; that is a cache, and it needs a different response. By default, real failures are written to a log, not announced to a person, so silence is the normal state of a broken connection.
| What failed | What the PMS shows | What the channel shows |
|---|---|---|
| Rate message rejected | New price saved | Old price, no hotel-side error |
| Availability stuck in queue | Room closed | Room still on sale |
| Rate plan renamed in PMS | New plan name | Old plan frozen at last value |
| Closed date reopened by stale message | Closed | Open |
| Public page cache | Correct price | Correct in extranet, old on search page |
What should the daily five-minute check compare?
Three room types on three dates, in the PMS and in each channel's extranet, plus one date you have deliberately closed and one room type you have deliberately sold out. The room types should be the three that carry the most nights, not the three that are easiest to find on the extranet. Getting the setup right starts with channel manager mapping for room types and rate plans.
Choose three dates: tonight, the next weekend, and a date at least a month out where a rate change is planned or a contract rate starts. In each cell, compare four values: price, open or closed, minimum-stay and closed-to-arrival rules, and the currency and tax basis shown. Read the channel's extranet, not the public search page; the search page adds cache, currency conversion and membership layers that hide the raw value.
Write down the time of the check. A difference found at 09:00 and the same difference found at 18:00 have different causes and different costs.
The three-by-three grid
ChecklistDaily checklist for the person on duty
- Three highest-volume room types named in the log
- Tonight, next Saturday and one date 30 or more days out
- Price compared in the same currency and tax basis
- One deliberately closed date still closed on every channel
- One sold-out room type still unavailable on every channel
- Minimum-stay and closed-to-arrival rules match
- Time of check recorded
- Name of the person who checked
Why the closed date matters more than the price
Include one closed date and one sold-out room type because these catch the dangerous direction: a room on sale that the hotel cannot honor. A wrong price costs margin. A room sold twice costs a relocation, a refund conversation and a review. The closed-date check takes ten seconds and protects against the failure that hurts most.
How do I read the sync log and the pending queue?
The log tells you what was sent and what the channel accepted; the queue tells you what has not been confirmed yet. Read both for exceptions, not for volume.
Start with rejected and failed entries. A long list of successful messages tells you nothing about the one that did not arrive. Compare the timestamp of your change in the PMS with the timestamp of the accepted message; a gap of hours is a queue problem, not a rate problem. A queue that only grows, or that still holds items older than your last change, means the connection is not keeping up with the hotel's own edits.
Watch retry counts. A message retried many times and then marked successful may have arrived after a newer message and overwritten it. Separate "sent" from "confirmed"; only the channel's confirmation means the value is live on that site. Screenshot the log entry before you escalate: the provider will ask for the message identifier and the time, and the entry may roll out of the window.
Watch outA green light is not a check
The only proof that a rate or a room is live is a value you have compared yourself, or a confirmed message in the log with a time next to it.
What do I do when the numbers differ?
Close first, correct second, record third. Stop the loss on the channel before you investigate the cause in the PMS.
If the channel is selling a room the PMS has already sold, close that room type or that date on the channel immediately, then fix and re-push. The order matters more than the speed. If the channel price is lower than the PMS price, decide within minutes whether to close the rate or match it; leaving it as it is is also a decision, and it is the expensive one.
Correct in the PMS, not in the extranet, unless the PMS is the thing that is wrong. A manual extranet edit is overwritten by the next push and hides the cause. Verify the correction on the extranet after the push, not in the log, because the log only shows what was sent.
Record the time found, what differed, what you did, the time verified, and who was told: revenue manager, provider support, front office. If a guest has already booked at the wrong price, honoring or renegotiating is a commercial decision for the manager; the technical job is to stop the next booking. Double bookings have their own mechanics, covered in how double bookings across channels happen and how to prevent them.
Who runs the check at weekends and on holidays?
A named person, every day, including Saturday, Sunday and holiday mornings, because that is when last-room sales and manual rate changes happen. A failure that starts on Friday evening is usually found on Monday, when the damage is already a booking. The check is a seven-day job, not a weekday job.
Assign by name for each day with a named backup, and put it in the front office shift handover rather than in one manager's personal routine. The weekend version can be shorter: availability on the three room types for tonight and tomorrow, plus the closed date, and nothing else.
Holiday eves and the first morning of a long weekend carry the most risk; add a second, afternoon check on those days. If the provider's support is closed, the fallback is the extranet: close the room types you cannot verify, and reopen them when you can. Keep the same log format at weekends, or the monthly review will have holes exactly where the incidents were. Weekend checks also interact with setting the same-day cut-off hour so the desk is not surprised.
What should I ask my channel provider about alerts?
Ask which failures raise an alert, who receives it, how fast, and whether it fires on a rejected message or only when the connection drops. The last one is the least useful, because a lost connection is the failure most likely to be noticed anyway.
Checklist
- Which events trigger an alert: rejected message, queue backlog, mapping change, lost connection?
- Who receives it, and how: a shared inbox or a named person with an out-of-hours phone?
- Weekend and holiday coverage, or does everything wait for the next business day?
- A daily digest of changes sent but never confirmed
- Per-channel health on one screen, with the time of the last successful push
- Retry policy, and whether a retry can overwrite a newer value with an older one
- A way to test the alert with a throwaway rate plan before relying on it
- The response time the provider commits to
Assume no alert exists until you have seen one arrive. Test it with a rate plan you can afford to lose, on a weekday, before a real weekend depends on it.
How do I keep a log for the monthly review?
One line per incident, in the same format every day, so that a month of lines shows which channel, which room type and which hour fail most.
| Date | Time found | Checked by | Channel | Room type | Date affected | What differed | Action | Time verified | Told |
|---|---|---|---|---|---|---|---|---|---|
| (example) 12.03 | 08:50 | A.Y. | Site B | Deluxe | 15.03 | Rate left at last week's price | Closed, corrected, re-pushed | 09:05 | Revenue mgr |
| (example) 19.03 | 09:10 | M.K. | Site C | Standard | 19.03 | Sold-out room still open | Closed on extranet, escalated | 09:20 | Provider support |
Both rows are illustrative. Log the clean days too, at least as a count; a month with no incidents and a month with no checks look identical in a file of incidents only.
At month end, count by channel and by hour. A cluster at 23:00 points at the night audit or a scheduled job; a cluster on one channel points at mapping or a contract rate. Take the two worst incidents to the provider conversation and to the next contract review, with the log lines attached. Keep the log outside the PMS and outside one person's mailbox, so it survives staff changes and can be read by whoever runs the check next. If the pattern points at the software itself rather than the connection, the next step is switching channel managers without losing bookings.
What to do next
Run the three-by-three comparison tomorrow morning at a fixed hour, write the first line in the log, and send the alert questions to your provider the same week. The check, the log and the alert together turn a silent failure into a five-minute correction, and the monthly count tells you which channel and which hour deserve the next fix.
Frequently asked questions
How often should a hotel check channel rates and availability?
Daily at minimum, including weekends and holidays. Add a second check on days with planned rate changes, holiday eves and last-room sales. The check is a comparison of values in the PMS and the extranet, not a glance at a connection status.
The extranet shows the right price but the booking site shows an old one. Why?
Usually a display layer, not a sync failure: page cache, a different display currency, tax included or excluded, a member or mobile rate, or a different rate plan being shown. Check in a private browser window, in the guest's currency, and confirm which rate plan the page is actually displaying before you escalate.
Can a channel manager say connected while nothing is updating?
Yes. Connection status and message acceptance are different things. The link can be open while one rate plan is rejected or a message sits in the queue. Only a confirmed log entry or a value you compared yourself proves the data arrived.
Which mismatch is more dangerous, price or availability?
Availability. A room sold twice costs a relocation, a refund conversation and a review; a wrong price costs margin. Both are handled the same way: close the room or the rate on the channel first, then correct the cause in the PMS.
Do we need to check every channel every day?
Prioritise the full comparison by the nights each channel produces, but check availability on every connected channel at least once a day. A channel that brings two bookings a month can still create a double booking.
