A channel manager normally sits quietly between a property’s calendars and its sales channels. When it stops updating, the problem can remain invisible until two guests buy the same dates. In Greece, where summer and event demand can compress into a few hours, waiting for a software provider to resolve the incident is not an operating plan.
The safest response is controlled and deliberately boring: identify the source of truth, protect exposed inventory, preserve evidence, reconcile every reservation and reopen channels one at a time. This 60-minute drill gives Greek hosts and property managers a repeatable process for Booking.com, Airbnb, direct bookings and other connected channels.
It is operational guidance, not a promise that every platform or connectivity provider exposes the same controls. Account permissions, integration scope, room structure and support procedures vary. Adapt the sequence to your contracts, software and team.
First, decide whether this is really an outage
A blank dashboard is not proof that reservations have stopped. The provider’s interface may be unavailable while background connections continue working. The reverse is also possible: the dashboard may load while one channel, room type or rate plan has stopped receiving updates.
Use three independent checks:
- Provider evidence: look for an incident banner, support message or official status page.
- Channel evidence: open the Booking.com Extranet, Airbnb host calendar and any other high-volume channel directly.
- Transaction evidence: compare the newest reservation, cancellation or date closure with what appears in the central calendar and on the public channel.
Booking.com maintains an official Connectivity API status page covering areas such as reservations and rates and availability. A green platform status does not prove that your property mapping, credentials or provider connection is healthy, but it helps separate a wider platform incident from a property-specific failure.
The 60-minute channel manager outage drill
| Time | Objective | Action | Evidence to keep |
|---|---|---|---|
| 0–5 minutes | Declare control | Name an incident lead and freeze routine edits | Incident start time and owner |
| 5–15 minutes | Find exposure | Compare newest changes across the PMS and channels | Screenshots and reservation IDs |
| 15–30 minutes | Protect inventory | Close or reduce exposed availability directly | Channel confirmation screens |
| 30–45 minutes | Reconcile demand | Build one verified arrival and departure list | Timestamped incident sheet |
| 45–60 minutes | Stabilise | Escalate, brief staff and set the next review | Support case and handover note |
Minutes 0–5: stop competing edits
Assign one incident lead. Everyone else should stop changing availability, prices, restrictions and room mappings until that person establishes what is still working. When three team members independently “fix” calendars, they can create conflicting blocks, reopen dates or erase the sequence of events needed for support.
Record the time the issue was noticed, the last known successful update, affected properties and any error messages. Do not disconnect integrations, delete calendar links or remap room types as a first reaction. Those changes can widen the incident and destroy useful evidence.
Minutes 5–15: test the newest high-risk changes
Start with the reservation most likely to expose failure: the newest booking, cancellation, modification or manual closure. Check the same property and dates in the designated source of truth, Booking.com, Airbnb and the direct-booking engine.
Then test one date range in the near future and one in peak demand. A connection may fail only for a specific channel, rate plan, unit or update type. Record the result as a simple matrix instead of writing “sync broken.”
| Control | PMS/source | Booking.com | Airbnb | Direct site |
|---|---|---|---|---|
| Newest reservation | Present? | Present? | Blocked? | Blocked? |
| Recent cancellation | Released? | Released? | Released? | Released? |
| Next 14 nights | Inventory | Inventory | Availability | Availability |
| Peak/event dates | Restrictions | Restrictions | Stay rules | Stay rules |
This is also where the operating difference between a full connection and a calendar feed matters. Airbnb’s official calendar-sync guidance says imported calendars update automatically every three hours and can be refreshed manually. It also warns that some externally blocked nights may not transfer in the same way. A delayed iCal refresh is therefore not identical to an API outage.
For the underlying architecture and warning signs, use The Host Daily’s iCal versus channel manager guide for Greece. During an incident, however, the priority is not choosing new software; it is controlling today’s availability.
Minutes 15–30: protect the dates that can hurt most
If availability cannot be trusted, reduce exposure directly in each affected channel. The exact move depends on the portfolio:
- Close a small number of vulnerable dates manually.
- Reduce sellable unit counts where several identical units are mapped.
- Temporarily lengthen advance notice if same-day or next-day bookings create the greatest risk.
- Pause the direct booking engine if it cannot reliably check inventory.
- Protect high-value event or peak-summer dates before quiet winter dates.
Booking.com’s official Connectivity Portal describes connections that can handle reservations, rates and availability, content and other functions. The scope of a specific property’s connection depends on the provider and setup. That means an operator must confirm which control failed instead of assuming every field is affected.
Four channel manager examples—and what to verify
The products below are representative examples, not a ranking or buying recommendation. Their own websites describe different channel reach, connection types and wider PMS features. Marketing claims are not proof that a specific Greek property, rate plan or workflow is supported. Ask each provider to demonstrate your actual Booking.com, Airbnb and direct-booking setup before signing a contract.
| Example | What its official site currently highlights | Outage question to ask |
|---|---|---|
| Hosthub | Availability and rate synchronization across 200+ advertised channels; its Zero Double Booking Guarantee is stated to apply only to API-connected channels. | Which of our channels are API-connected, and which incidents qualify for the guarantee? |
| Guesty | Direct integrations with major OTAs, channel-specific pricing and synchronized reservations, rates, availability and listing content. | Which fields can staff safely edit inside each OTA when the central connection is unavailable? |
| Hostaway | Two-way API connections with major OTAs and a central multi-calendar, inbox and listing-management workflow. | How are failed pushes, delayed reservations and partially disconnected listings surfaced to the operator? |
| Lodgify | Channel management for major OTAs alongside a direct-booking website and booking engine. | Can the direct site be paused independently while OTA inventory remains open and verified? |
Do not choose from a feature count alone. For a Greek villa or apartment, the decisive test is the exact connection used by the property, what data moves in each direction, how quickly failures are detected, whether support covers Greek arrival hours and how cleanly the system recovers after manual channel edits.
Why channel complexity grows faster than the channel count
Adding one channel does not add only one comparison. If an operator checks every sales channel against every other channel, the number of pairwise paths is n × (n − 1) ÷ 2. This is a simple complexity model, not a prediction of outages or double bookings.
A central source of truth is valuable because it replaces many informal channel-to-channel checks with controlled connections to one system. But the graph also explains why an outage procedure matters more as distribution expands: staff still need a method to verify every exposed endpoint when central control is uncertain.
Minutes 30–45: create one verified reservation ledger
Export or copy all arrivals, departures, cancellations and modifications made since the last known good synchronization. Include the reservation ID, channel, unit, stay dates, booking status, guest count and the timestamp shown by the channel.
Channel records are authoritative for reservations received there. Do not rely on a forwarded email, payment screenshot or message notification when the Extranet or host account shows something different. Mark every mismatch and assign it to a person. If a reservation exists on a channel but not in the PMS, create a controlled temporary block in the other sales channels before investigating the import failure.
Minutes 45–60: escalate with evidence and brief operations
Open one support case containing facts the provider can act on: property and room IDs, affected channel, reservation IDs, timestamps, error text, screenshots, last successful update and the manual containment already completed. Avoid sending credentials, card data or unnecessary guest information.
Brief reception, cleaners and guest-support staff using the verified ledger. Tell them which calendar is temporarily authoritative, who may accept or move a booking and when the next review will occur. A technical incident becomes a guest incident when the arrival team works from stale information.
What not to do during an outage
- Do not disconnect everything. Removing connections without a rollback plan can create more gaps and duplicate blocks.
- Do not reopen dates because one screen looks empty. Confirm against channel reservations first.
- Do not let every staff member edit every channel. One lead should approve containment changes.
- Do not test with a real guest booking. Use controlled availability changes and the provider’s approved test process.
- Do not announce an outage to guests who are unaffected. Communicate only when a specific reservation, payment, message or arrival needs attention.
- Do not assume recovery equals reconciliation. A green status page does not prove that missed updates have replayed correctly.
The recovery sequence: reopen slowly
When the provider reports recovery, keep the incident open. First confirm that new reservations are flowing again. Then compare the verified ledger with the PMS and each channel. Check manually created closures, inventory counts, cancellations, modifications, prices and stay restrictions.
Reopen one low-risk property or date range and verify the result publicly before restoring the whole portfolio. Remove temporary blocks only when the underlying reservation is visible in the correct systems. If manual containment created short availability gaps, evaluate them carefully with the Greek rental calendar-gap playbook rather than applying a blanket discount.
Build the plan before Greek peak season
A usable channel manager outage plan fits on one page. It names the source of truth, lists direct channel logins and support routes, identifies the person who can close inventory, defines the last-known-good check and includes a reservation-ledger template. Test it before the property enters its busiest period.
No integration can guarantee that a double booking will never happen. The professional standard is faster detection, limited exposure, clean evidence and disciplined recovery. When the channel manager goes dark, the first hour should not be spent deciding who is in charge. That decision—and the sequence that follows—should already be written.
