If your hotel website accepts a reservation for a room that has already sold on Booking.com, Airbnb or at the front desk, stop treating it as a website-design problem. First establish which system should control inventory, whether the booking actually reached it, and whether every selling channel received the change. A new booking widget will not fix inconsistent availability.
For a hotel already taking bookings, the safest first purchase is usually a booking-sync investigation and supported-connector repair, not a custom channel manager. The investigation should produce a timeline of the conflicting reservations, a verified cause, a temporary operating procedure and tests proving the corrected flow. A small iCal setup error may need only vendor support. Repeated failures across a PMS, booking engine and multiple online travel agencies (OTAs) can justify a substantial paid integration project.
First, prevent another double booking
If there is an active conflict, have the front desk confirm both reservation records and contact the relevant booking provider using its established guest-resolution process. Preserve guest confirmations, reservation IDs, timestamps and messages. Do not silently cancel a paid guest or assume that deleting a duplicate record removes the booking from the external channel.
While the issue is investigated, designate one staff member to reconcile and temporarily close the affected inventory in the systems that actually sell it. Use the providers’ supported stop-sell or manual-closure controls; check that closures were accepted. Avoid blindly disconnecting all channels, which can itself create stale availability or lost reservations. Keep a written log of every manual intervention.
This is operational containment, not a permanent technical fix.
Find the first point where the two calendars disagree
The useful diagnostic is a reservation timeline, not a screenshot of two dashboards.
| Evidence | What it helps establish |
|---|---|
| Guest confirmation and OTA reservation ID | Whether a real reservation was accepted |
| PMS or booking-engine reservation ID | Whether the booking was imported or created locally |
| Room-type and rate-plan mapping | Whether both systems refer to the same sellable inventory |
| Last successful import and export times | Whether updates were delayed or the connection stopped |
| Channel-manager error and acknowledgement logs | Whether the provider received, rejected or retried a change |
| Manual front-desk changes | Whether staff bypassed the system that owns availability |
Take one affected date and room type. Trace the first reservation from acceptance to PMS entry, inventory reduction and the next channel update. Then trace the second reservation. The earliest missing or incorrect state change is usually a better starting point than replacing the entire website.
A room labelled “Deluxe King” on the website may map to a different room ID on an OTA. Match stable room and rate identifiers, not only their display names. Booking.com’s availability documentation separates room inventory, rates and restrictions; they are not interchangeable fields.
Check whether you are using iCal or a channel-manager connection
These are not equivalent synchronization methods.
iCal calendar links exchange blocked or booked dates on a refresh schedule. They can be appropriate for a small short-stay property with limited listings, but they are not a transaction lock. Airbnb’s official calendar help currently says its imported calendars automatically refresh every three hours, with a manual refresh option subject to limits. It also warns that some blocks from another calendar may not be reflected. Do not promise instant, conflict-free sales based on an iCal link.
A supported PMS/channel-manager integration can exchange availability, rates, restrictions and reservations through provider-supported connections. But “connected” is not proof that every room is mapped correctly or every update succeeded. Confirm whether the connection has permissions for both reservations and rates/availability. Booking.com’s Connections API documentation describes these as distinct connection types granted by the property.
If the hotel sells its last room through several channels, a supported inventory connection is generally a more appropriate design than relying on periodic calendar imports. Ask the current provider what it supports before commissioning custom code.
Five common causes, and what each repair actually involves
1. The room or rate plan is mapped incorrectly
The website’s “Superior Room” and the OTA’s “Superior Double” may not refer to the same inventory pool. One rate plan may remain open even though the intended room type is closed.
Repair: Audit identifiers, room counts, rate-plan relationships and date restrictions. Test the last available room, not only a hotel with plenty of spare capacity.
2. A booking reached the channel manager but never reached the PMS
An integration may fetch a reservation and fail while saving it locally. Some systems then retry or issue a fallback notification. A successful API response is not proof that the PMS stored the correct reservation.
Booking.com’s Reservations API overview explains retrieval and acknowledgement for supported connectivity partners. Its OTA XML flow expects partners to acknowledge processed reservations and handle repeated delivery without creating duplicate bookings. A hotel using a third-party provider should ask that provider to inspect these logs rather than attempting to access partner APIs without authorization.
Repair: Trace delivery, local persistence, acknowledgement and retries. Recover missing reservations through the provider’s supported procedure, and reconcile them against the front-desk ledger before reopening inventory.
3. Staff created a walk-in outside the inventory system
A walk-in entered in a spreadsheet, WhatsApp chat or an unrelated calendar may never reduce online availability.
Repair: Make the PMS or approved central booking record the operational source of truth. Train staff to enter phone, walk-in and maintenance blocks there, and verify that the update reaches selling channels.
4. Cancellations and modifications are not processed correctly
A guest changes dates, the PMS keeps the old stay, and availability is wrong on both date ranges. Conversely, a cancellation may reopen inventory that should remain blocked for another reason.
Booking.com’s modified and cancelled reservation guidance documents a separate change-processing flow for supported integrations.
Repair: Verify new bookings, modifications and cancellations as separate events. Preserve a history of changes rather than replacing the old record without explanation.
5. A connection is stale, disconnected or failing silently
Credentials can expire, permissions can change, provider requests can fail and sync jobs can stop. A dashboard that merely says “Connected” may not show the age of the last successful inventory update.
Repair: Check provider connection status, failed operations, alerting and a controlled resynchronization. Do not repeatedly push arbitrary availability values into production without a trustworthy inventory count.
What should you pay a developer to fix?
Price the diagnosis, correction and proof of recovery separately. The following are project-scoping categories, not market averages or fixed quotes.
| Situation | Sensible buying decision |
|---|---|
| One incorrect iCal URL or a stale manual calendar | Use vendor documentation/support or a focused configuration service; usually not a major software project |
| Existing supported connector with broken mapping or staff workflow | Commission a configuration and operating-process repair, with real booking tests |
| PMS, website and OTA integration repeatedly disagree | Commission a documented technical investigation, connector repair, reconciliation and monitoring |
| Unsupported legacy PMS or multi-property inventory rules | Compare replacing the incompatible system with building a supported custom bridge |
A serious cross-system recovery can realistically become a ₦450,000+ or $1,000+ engagement, especially when it involves API access, multiple properties, historical reconciliation, staff handoff and ongoing support. A single incorrect calendar setting does not justify that price. The quote should state what is known, what depends on third-party access and what evidence will count as acceptance.
For a procurement decision rather than an active incident, see my hotel channel-manager integration cost guide. It covers when to connect a supported booking engine and when a custom integration is defensible.
Eight tests before reopening all selling channels
Use test reservations or provider-approved test procedures wherever possible; do not create real guest bookings simply to test a developer.
- The last available room is sold through one channel and becomes unavailable on the hotel website and other connected channels.
- A direct website reservation enters the correct PMS property, room type, dates and rate plan.
- A front-desk walk-in or maintenance closure changes online availability.
- A booking modification moves the reservation without leaving incorrect blocks on either date range.
- A cancellation restores only the inventory that is actually sellable.
- A repeated reservation notification does not create a second booking.
- A temporary connection failure creates a visible alert and a recoverable backlog, not a silent success.
- The hotel can identify a reservation and its payment status after a delayed notification, without charging or confirming twice.
The developer should supply a mapping sheet, an incident timeline, the relevant configuration changes, a test record, monitoring responsibilities and an escalation path for provider outages. A “fixed” badge on a dashboard is not enough.
Keep direct bookings and payments in the same recovery plan
Some hotels have a second failure: the guest pays a deposit on the website, but the booking is never confirmed in the PMS. Others mark a booking confirmed before payment verification, then hold inventory indefinitely after an abandoned checkout.
Treat reservation status, inventory commitment and payment status as separate records that must reconcile. A payment-success screen is not the source of truth for a reservation. Use verified gateway events, stable references and idempotent processing, as explained in my payment gateway integration cost guide.
If the hotel’s direct-booking page itself is difficult to use on mobile, that is a separate conversion problem. The direct-booking versus OTA guide helps frame that decision. Do not mix a booking-flow redesign with an emergency inventory repair unless both are actually necessary.
What to send before requesting a repair quote
Share the hotel website, PMS and channel-manager names, connected OTAs, number of properties and room types, whether iCal or API connections are used, and one anonymized example of conflicting reservations with timestamps. Explain whether the failure began after a migration, a configuration change or an outage.
Do not send guest personal data, passwords, payment credentials or provider API secrets in an initial enquiry. The hotel should retain ownership of its vendor accounts, domain, reservation data and support relationship.
I work on websites and product workflows where booking, payment, permissions and system handoff must agree. If your hotel is losing direct bookings or selling the same inventory twice, tell me which systems disagree and what happened. I can help scope the booking-flow and integration investigation, including when the right next step is the provider’s specialist support rather than custom development. You can also review my web design service for the guest-facing website work.
The outcome to buy is not “sync turned on.” It is a reservation that appears once, reduces the correct inventory, survives changes and remains explainable when a provider fails.
