Skip to main content

Runbook: Investigating Overbooking Issues (Channel Manager)

1. Overview & Problem Definition​

This runbook provides a step-by-step technical guide for investigating and resolving overbooking incidents caused by inventory/allotment mismatches within the Channel Manager (CM) and Internal OTA Service.

  • Reported By: Property ID 64 | Antara Villa
  • Initial Condition: An overbooking occurred on Traveloka with Booking ID 20261116221574 (BNL ID 48635764) received by CM on 2026-03-21 12:30 PM, even though system logs showed 1 inventory remaining.
  • Root Cause Hypothesis: An earlier booking from tiket.com 72724578 (BNL ID 48563774) was confirmed on 2026-03-17 03:50 PM but failed to reduce the inventory allocation. This occurred during a system outage on March 17th, causing the incoming booking payload to bypass the auto-reduction mechanism without being logged properly.

2. Investigation Workflow (Step-by-Step)​

STEP 1: Check Portal Channel Manager Logs​

The objective of this step is to verify whether the initial allotment calculation generated by the Channel Manager was correct before being sent to the internal services.

  1. Access the Channel Manager Portal.
  2. Search for logs using the Property ID (64) and filter by the Event Date (e.g., March 17th to March 21st).
  3. Analyze the raw XML Allotment payload pushed to the internal OTA service.
  4. Diagnostic Indicators:
    • Scenario A: If the actual physical inventory for Room A should be 1, but the XML log explicitly shows an allotment of 2, the root cause lies in an incorrect calculation logic within the Channel Manager. Proceed to STEP 3.
    • Scenario B: If the XML allotment count in this log is accurate (e.g., correctly showing 1 remaining slot), proceed to STEP 2.

STEP 2: Check Monthly Deals Logs (External Push)​

If the internal Channel Manager log is correct, you must verify what payload was actually dispatched to external OTAs (e.g., Booking.com, Expedia, Traveloka, Tiket.com).

  1. Navigate to the Monthly Deals logging dashboard.
  2. Search and retrieve the XML allotment payloads pushed by the internal OTA service to the external channel.
  3. Compare the XML data found here with the XML payload from STEP 1.
  4. Diagnostic Indicators:
    • Scenario A: If the XML in STEP 1 calculated the allotment correctly but the XML in STEP 2 contains an incorrect value, a calculation/transformation error occurred within the Internal OTA Service. Proceed to STEP 3.
    • Scenario B: If a log exists in STEP 1 but no corresponding log is found in STEP 2, it indicates a service failure or drop. Proceed directly to STEP 4.

STEP 3: Database Reconciliation (Booking_dates Table)​

When log calculations mismatch or fail, you must query the database to establish the ground-truth state of bookings and manually cross-reference the data.

  1. Execute the following SQL query to extract all room bookings for the affected property and stay dates:
SELECT 
    bd.id, 
    bd.booking_id, 
    bd.date, 
    bd.Booked_date, 
    bd.Room_id, 
    bd.sub_room_id, 
    bd.Numberof_rooms, 
    b.status
FROM Booking_dates bd
LEFT JOIN Bookings b ON b.id = bd.booking_id
WHERE bd.Property_id = 64 
  AND bd.Booked_date >= '2026-03-23' 
  AND bd.Booked_date <= '2026-03-24'
ORDER BY bd.Booked_date DESC;

  1. Manual Reconciliation: * Sum up the Numberof_rooms for all active bookings (b.status = 'confirmed' or active equivalent) for the target dates.

    • Subtract this sum from the total property room capacity to determine what the allotment should be.
    • Compare your manual calculation against the values logged in STEP 1 and STEP 2.

  2. Data Remediation Action:

    • If you discover missing rows or discrepancies in the Booking_dates table (commonly caused by data loss during a system outage), trigger the automated self-healing script
    • Remediation Tool Path: Execute an API call to the following internal cron endpoint to regenerate the missing/corrupted booking dates: 
      POST /api/v1/cron/booking-date-issue

STEP 4: Handling System Outages & Internal Service Failures​

This step applies when logs are present and correct in the Channel Manager portal (STEP 1), but completely missing from the external push logs (STEP 2).

  1. Root Cause: The internal OTA service experienced an outage or downtime when the booking payload arrived from the Channel Manager. As a result, the system failed to process the incoming XML and never pushed the updated inventory out to external OTAs.

  2. Remediation Action:

    • Perform a Force Push XML action from the Channel Manager dashboard to the internal OTA service.
    • This action forces the system to re-read the current database state, re-evaluate inventory metrics, and distribute the updated, corrected allotment to all connected external OTAs.

3. Quick Troubleshooting Matrix​

Log Observation / SymptomRoot CauseCorrective Action / Resolution
STEP 1 XML contains incorrect allotment count.Calculation bug or cache discrepancy within the Channel Manager portal.Perform DB reconciliation (STEP 3). Re-sync via internal tool if necessary.
STEP 1 XML is correct, but STEP 2 XML has wrong allotment.Internal OTA service failed to transform or process the data correctly.Coordinate with the Development Team. Perform a force sync/push.
STEP 1 XML exists, but STEP 2 log is entirely missing.Internal OTA service was down/unreachable during the time of booking.Force Push XML from the Channel Manager to re-trigger the inventory distribution.
Gaps or missing rows identified in the Booking_dates table query.Data write dropped due to a database lock or system outage.Trigger the correction tool via api/v1/cron/booking-date-issue.

4. Post-Resolution Verification​

Before resolving and closing the incident ticket:

  1. Verify that the allotment values displayed on the external OTA partner portals (e.g., Traveloka Extranet, Tiket.com Extranet) match the verified real-time database capacity.

  2. Confirm that no further overbookings are pending for the affected date range.

  3. Update the incident ticket (e.g., LINK_NEXUS-2XX) with details of the remediation step taken (e.g., “Triggered booking-date-issue cron and force-pushed allotment”).