Start with the room, not the OTA screen
The fastest way to lose control is to let whichever screen was opened last decide what is sellable. A room can look available online while it is blocked for maintenance, needed for a room move, or unavailable because of a confirmed booking that has not yet been recorded everywhere.
Start each shift with the physical position. Ask what changed since the previous handover:
- new direct, phone, walk-in, or WhatsApp bookings;
- cancellations, extensions, and room moves;
- rooms held for a guest, owner stay, repair, or inspection;
- rooms released back into service; and
- dates where only zero or one suitable room remains.
Then compare those changes with one designated current record. This can be a PMS, a controlled workbook, or another operating record your team has chosen. The important point is that the team agrees which record is current. Exports, screenshots, printed arrival lists, and old spreadsheets can help as references, but they should not compete with the record used to make a selling decision.
Do not call it a perfect source of truth. It becomes useful only when the team enters direct changes, checks physical room status, and resolves exceptions. The language matters because it keeps the work honest: a record is current because people keep it current.
For a Bali property, this can be as simple as checking the room list before morning staff start answering WhatsApp enquiries. The check is not a big audit. It is a short answer to a practical question: can this room still be assigned for these dates?
Give every channel a clear map
The same room can have different labels in different places. One OTA may call it Garden Double. Another may call it Deluxe Garden. A rate can also have its own conditions. If staff only remember these differences, the mapping disappears when the person who knows it is off duty.
Keep a small, credential-free mapping register. It should show the information someone needs to understand an availability change without exposing passwords, tokens, guest information, or contract details.
| Channel | Listing or room label | Internal room and rate | Normal update method | Owner and backup |
|---|
| OTA A | Garden Double, Flexible | Garden Room, Flexible | Connected workflow | Reservations lead, duty manager |
| OTA B | Deluxe Garden, Standard | Garden Room, Flexible | Manual portal | Front desk, reservations lead |
| Direct bookings | Garden Room | Garden Room, Flexible | Entered in current record | Front desk, owner |
The example is fictional. Your labels will be different. The value is not the table itself. It is being able to answer, before changing anything, which room, rate, dates, and channel are affected.
Booking.com documents roomrate management as a room type, rate plan, and related conditions. That is a Booking.com-specific model, not a universal rule for every OTA. It is still a useful reminder that “close the Garden Room” may be too vague when the team needs to know the exact room-and-rate combination. Read Booking.com's roomrate guidance when the property needs its current Booking.com setup explained.
Make one controlled change at a time
Availability errors often begin with a reasonable urgent action: someone sees the last room, opens an extranet, changes a number, and intends to update the main record later. The room may be safer for the moment, but the team has created a change that the next shift cannot easily trace.
Use a simple order instead.
First, change the designated current record after confirming the physical room status. Then define the scope: room type, rate label if it matters, dates, intended state, and affected channels. Record what the position was, what it should become, why it changed, and who made the decision. Finally, use the property's normal method and verify the result.
This does not need to become a long form for every small change. It is a habit of making the change understandable. A note such as “closed September” does not help the next person. “Garden Room, Flexible rate, 14-16 September, closed after maintenance block, checked by reception” does.
For a broad change or the last suitable room on a busy date, add a second check if it helps your property. The second person should compare the physical position, dates, and mapping before the change is made. A second click without that comparison does not add much protection.
Do not use arbitrary availability buffers just because another hotel does. A two-room buffer may hide sellable rooms at one property and still be too small at another. Build the second-check practice around the rooms and dates that have actually caused pressure for your team.
Verify the affected room and dates
Sending an update and seeing a successful screen are not the same as confirming the exact state you intended. Verification means checking the mapped room, relevant rate, and dates on each affected active channel according to the property's observed method and the provider's current guidance.
There is no universal waiting time to put in a staff handbook. Connected systems, manual portals, imported calendars, and provider processes do not all behave the same way. The team needs an observed method for its own setup, rather than a promise copied from another hotel.
Booking.com provides a useful example of why scope matters. Its availability documentation distinguishes a room-type closure from a closure for one room-and-rate combination, and reopening is an explicit action in that workflow. Its troubleshooting guidance also notes that a successful HTTP response can arrive alongside errors or warnings when at least one update succeeded. In plain hotel language, do not treat a successful send as proof that every intended change landed. Check the availability update guidance and troubleshooting guidance for Booking.com-specific details.
Airbnb documents automatic and manual refresh for imported iCal calendars. That is narrowly about imported calendars. It is not a timing promise for an API connection, a channel manager, or another OTA. See Airbnb's imported-calendar help when that is the method your property uses.
The operational rule is simpler than the technical detail: if the result is unexpected, partially applied, closed when it should be open, or still open when it should be closed, do not keep changing numbers until it looks right. Open an exception.
Make exceptions visible at handover
“Waiting for sync” is not a handover. It gives the next person no clear room, owner, deadline, or action.
Every unresolved availability difference needs six pieces of information:
- the affected room, rate where relevant, and dates;
- the intended state in the current record;
- the state currently observed on the channel;
- the owner and backup;
- the next check; and
- the evidence or support-reference location.
For example: “Garden Room, 14-16 September. Current record says closed after a maintenance block. OTA B still shows open. Reservations lead checks the portal at 15:35. Supporting screenshot in the restricted availability folder.”
Those times are an illustration, not a provider service level. The point is that an incoming supervisor can see what is open, who owns it, and what should happen next.
At handover, review unresolved changes before moving to general arrivals or guest requests. For constrained dates, the availability exception may matter more than a routine note because another booking can turn uncertainty into a guest problem.
Use a small cadence that follows real work
A full comparison of every future date on every channel sounds safe, but it can consume a shift without improving control of today's changes. Begin with a cadence the team can sustain:
- Check changes at shift opening.
- Verify each material availability change on the affected mapped channels.
- Hand over unresolved exceptions before the next shift takes selling decisions.
Add focused attention to zero- or one-room dates when the property has learned that those dates need it. Review repeated exceptions each week. Repeated room-label confusion may be a mapping problem. Repeated manual overrides may mean the normal process is not usable when staff need it. Repeated unowned warnings mean the handover process needs a clearer owner.
This is the Kiyo perspective on the problem: good availability control is a shared operating habit, not an unchecked promise that software or a channel will always be correct. Kiyo is qualified to publish this guide because independent hotel teams need a clear method before they can judge whether their booking and distribution setup is helping them.
Kiyo can manage availability, rates, and stay rules in the property, then sync them to connected and correctly mapped OTA channels. An active integration and correct mapping are required, and an outside provider can still delay or reject an update. That is why Kiyo helps reduce repeated availability updates, while the team still verifies constrained dates and owns exceptions instead of assuming the work is finished.
The reason to consider Kiyo is that one availability decision can begin in the hotel's operating record and move through its connected distribution setup, rather than asking staff to repeat the same change in every extranet. See the Kiyo channel manager workflow alongside this guide, then test it against the rooms and dates that put the most pressure on your team.
If your team is deciding where a PMS ends and a channel manager begins, read PMS versus channel manager. That guide covers the system distinction. This one stays focused on the daily availability-control loop.
Know when this guide stops
This routine is for pre-incident control. It helps the team catch a mismatch, assign it, and verify the affected scope.
If two confirmed bookings now need the same limited physical room, the work changes. Do not use a general reconciliation routine to decide refunds, relocations, payment changes, or guest communication. Move to the double-booking incident guide for the next steps.
For tomorrow, do not attempt a full calendar audit. Choose the next constrained date. Check the physical rooms, current operating record, mapping register, and affected channels. Record one real change clearly enough that the next person can understand it. That is how a multi-OTA process becomes calmer, one traceable decision at a time.
If you would like a neutral second opinion on your availability-control routine, talk to Kiyo's team.
