Embedded Files
Welcome to Agoda Connectivity Knowledge Based Portal! Here you can find information, tips and tricks, SOP with frequent escalated to Agoda Connectivity Technical Support team.
How to identify if an overbooking is caused by connectivity issues (or) manual override?
How to identify if an overbooking is caused by connectivity issues (or) manual override?
As Channel Managers (CM), you may see some bookings present itself as overbooking and raise a ticket for more details on the issue. Upon analysis of overbooking-related inquiries, however, we found that approximately 58% of them were non-connectivity related, and could have been resolved with preliminary checks by the property or CM. This would help resolve the issues much faster and without having to wait for a response from our Technical Connectivity Support team.
Below are possible scenarios that can be presented as overbooking but not a connectivity related issue, which can be categorized into these 3 buckets.
1.YCS extranet manual update:
Inventory Allotment is set as 0 using API for a certain date range, room type belonging to a property, but YCS still shows availability. This could be due to someone with YCS privilege modifies the allotment manually after the API updates. Agoda would allow booking on such room types.
We request CMs to check if any manual updates have been made on the YCS extranet.
The information could be accessed here in YCS to check if any Front End users update the properties after ARI updates.
2.Allotment made available due to cancellation (Inventory Return)
The CM updates the allotment as 0 for a certain date range & room type. There is a cancellation of booking at Agoda on the same room type for the same date after the CM updated the allotment. It is considered as Inventory Return.
We request CMs to check the booking retrievals & YCS extranet to see if there is any booking cancellation for the same room type and date range.
The information could be accessed here in YCS to check if any cancellation is made on an existing booking after ARI refresh.
Note: Enter the date range wider than the actual date that you would like to validate. This would ensure that the bookings spanning multiple dates are also accommodated.
3.Rate plan is closed for a Room but not Inventory
CM closes a rate plan for a room type for a certain date range. Note that there may be another rate plan that is still associated with the room type, and it would allow our system to process booking. If a CM doesn’t want any booking to be made on a room type for a certain period, we request CM to close the allotment in inventory updates.
We request CMs to check rate plan on a booking that is considered as overbooking and see if it is still active and inventory updates sent on that room type.
4.Calendar Sync option turned on for NHA properties
If a non-hotel accommodation (NHA) property gets activated with the CM, the property should no longer use the Calendar Sync option on Host Manage. This feature is created for NHA properties not associated with the CM to manage its inventory. Any updates sent by the CM through API would get overridden by the Cal Sync updates and would cause allotment errors leading to overbooking.
We request CMs to educate their NHA properties about this.
Example: The below setting must be disabled by the property.
We request CMs to investigate if the bookings fall under the above-described umbrella before reaching out to us for assistance. Doing so would be beneficial for all involved parties by:
· Reducing the turnaround time needed to for a resolution
· Reducing ticket volume to our Technical Connectivity Support team, allowing more time spent on solving issues arising from actual technical root causes
For overbookings falling into the above scenarios, we recommend the CM to inform the property on how to perform preliminary self-checks. However, if the overbooking wasn’t due to any of the above scenarios or if the CM is unable to deduce the root cause, such issues can be raised to the Technical Connectivity Support team by using this Forms.
How to check if Booking has been delivered to Channel Manager System? - Booking Retrieval
How to check if Booking has been delivered to Channel Manager System? - Booking Retrieval
As Channel Managers (CM), you may report that bookings were not sent/pushed to your PMS system and raise a ticket for more details on the issue. Upon analysis, we found that booking retrieval related inquiries is one of the top reported issue while in fact the booking has really retrieved successfully based on the log found from our end.
We would advise CM to do the following preliminary checks as this would help resolve the issues much faster and without having to wait for a response from our Technical Connectivity Support team.
Agoda offer 2 types of booking retrieval
1. Pull spec - GetBookingList and GetBookingDetails
2. Push spec - BookingHints
Steps to do pre-check
1. Check if there is any outage notification sent from Agoda impacting booking retrievals. If yes, we advise the CM partners to re-retrieve all the bookings made on the announced outage window.
2. If there isn't outage from us, then check the GetBookingLists/GetBookingdetails log to check if there is a request covers the booking timestamp. Steps based on the response of your request:
Agoda Response returns 'success' --> check booking ID in your system
Agoda Response returns 'error' --> provide XML request/response logs to our connectivity support team via Forms.
3. CM to check internal system log if there’s any intermittent issue
4. Kindly note that when you retrive the booking and got the response like "There was an internal server error: Get BookingDetails failure response from BAPI with booking ids: XXXXXXXXX errCode: InvalidRequestData errMsg: Booking contains negative memberId, Customers account either remove by GDPR or deactivate account".
This is due to GPDR laws. We (Agoda) provide our customers a way to contact Agoda and wipe out their PII related things (first name / last name , associated with credit card , associated with bookings , etc). So once customer asks for that , backend systems will just mark the member id as negative. Hence, we couldn't return any info as it will be violated GDPR laws. The solution for this case specifically is to manually pull it from the YCS Extranet.
How to pre-check on Booking Rate Calculation?
How to pre-check on Booking Rate Calculation?
Booking Price Dispute
As Channel Managers (CM), you may see some bookings present as lower net rate received and/or incorrect pricing applied and raise a ticket for more details on the issue.
Upon analysis of booking price dispute-related inquiries, we found that approximately 10% of them were non-connectivity related which connectivity portal worked out properly.
This could have been resolved with pre-checks by the property or CM and would help reduce the turnaround time as it would have many touch points.
1. Check the latest Rate updated request to Agoda prior the booking timestamp and ensure that the successful response has returned.
2. Check the system log on YCS Extranet as there could have manual updates:
For example, Rate is set as XXX using CM API for a certain date range, room type belonging to a property, but YCS still shows incorrect rate. This could be due to someone with YCS privilege modifies the rate manually after the API updates. Agoda would allow booking on the most recent update rate.
We request CMs to check if any manual updates have been made on the YCS extranet.
Action Type: Room Rate Category Rate
Useful information of booking pricing breakdown:
How is the total amount (booking) calculated?
Agoda does not send any invoices. We deduct the commission from the total amount paid by guests.
· Reference sell rate (incl. taxes & fees) = Total amount paid by the guest
· Net rate (incl. taxes & fees) = Total amount without commission
On the below screenshot is the voucher which Agoda sent to the property, you can see if there is any other discount applied (promotion, rate channel, etc) which could led into lower net rate that property should get.
For example:
For booking price dispute falling into the above scenarios, we recommend the CM to inform the property on how to perform preliminary self-checks. However, if it wasn’t due to any of the above scenarios or if the CM is unable to detect the root cause, such issues can be raised to the Technical Connectivity Support team by using this Forms to check Rate update. But if it’s for booking pricing breakdown please raised the inquiry via YCS Web Widget “Need Help?” button.
Google Sites
Report abuse