traveller

New Reservations API features will help reduce reservation fallbacks

Discover the latest improvements to our Reservations API to help you reduce the fallout caused by fallback communications, downtimes and system errors.

Reservation fallbacks are an unfortunate occurrence that can negatively impact the guest experience and properties’ reputations. We’re enhancing our Reservations API to tackle three of the most common causes of reservation fallbacks – scheduled and unscheduled downtimes, system errors and reservation modifications made after the check-in date. We designed these new features to give you more flexibility in preventing these occurrences.

Reservation fallback holds

Planned and unplanned downtimes can lead to excess fallback communications, which can negatively impact your experience as a provider. To avoid this, during planned downtimes, we'll hold reservations in our queues until you're ready to process them again. The fallback procedure won't be triggered during this time. You can set up a reservation hold by logging in to your Provider Portal, clicking on ‘Company Settings’ and selecting ‘Scheduled Outage Holds’.

Increasing the hold time to 24 hours

During unplanned downtimes, we've enhanced the Reservations API to optionally hold reservations made more than a day in advance for up to 24 hours instead of the previous 30 minutes. After 24 hours, we'll default to the fallback email. We define the hold duration based on local time, from when the reservation is made and the property's check-in time. Same-day and next-day reservations will not qualify.

We understand that increasing the hold duration may cause your number of reservations to pile up, potentially leading to overbooking. That's why we've made this feature optional – if you'd like to activate it, contact us so we can make sure it’s right for you.

New response codes

Sometimes, property partners may not be able to respond to reservations fast enough despite the hold procedures in place. Our newly developed response codes in the Reservations API help you work around this problem by keeping the reservation in the queue until you're able to acknowledge it – or until they timeout within 24 hours. 

To not trigger the fallback procedure, enable this feature and send us an acknowledgement request with the error code 448 (system error) or 450 (unable to process). The affected reservations will remain in your queue, allowing you to acknowledge them at a later time. You’ll also be able to see these reservations in your email notifications, preventing you from having a backlog of reservations.

Communicating post-check-in modifications 

We sometimes send reservation modifications during or after a stay to update or correct various details. This is a normal feature of the Reservations API. However, we understand that you may not be able to support reservation modifications once the check-in date has passed.

In this case, you can disable this feature. When doing so, just indicate that email is the preferred channel for these types of communications, and we'll send your properties the modification information via the contact details we have on-file. Note that this isn't a fallback email but a standard email for non-connected partners. Therefore it doesn't affect fallback metrics.

Explore the Reservations API

What do you think of this page?

Topics
Takeaway
  • Improve your handling of these common problems – downtimes, fallback procedures, system errors and reservation modifications
  • We’ve improved reservation hold procedures to reduce excess fallback communications and give you more time to acknowledge reservations after downtimes
  • New response codes allow you to define response times to affected reservations after system outages or downtimes
  • Your properties can enable or disable post-check-in modifications based on your capabilities and preferences

Subscribe to the monthly Connectivity newsletter

Stay informed with the latest product updates, news and events