Hosts who have their property on multiple OTA portals (Airbnb, booking, Vrbo, etc.) have the problem of avoiding the overbooking phenomenon (multiple bookings for the same days) due to bookings made by different customers on two different portals. Let’s take an example: a customer books our property on Airbnb. At this point, Airbnb makes those dates unavailable to other customers. But the other portals don’t know anything about this reservation and one of their customers may make a reservation for dates that overlap with those already occupied. In this way, you have more reservations that it is impossible to manage and this is called overbooking.
The portals provide hosts with a tool that should help them avoid these events. The problem is only partially solved and we will soon see why. But first, let’s describe how it works. Each portal gives hosts a “secret” link from which they can download their property’s availability calendar. And it gives the possibility to import calendars from other portals. Using these tools it is therefore possible to have each portal download the availability of the other portals and block the dates that are already booked.
Everything would be beautiful but unfortunately, this system does not always work. The reason is very simple: the portals synchronize with each other at time intervals that each portal chooses. If it were a question of a few seconds, there would probably be no problems because it is unlikely that two bookings will occur on two different portals for the same day within a few seconds. Unfortunately, however, the interval with which the portals synchronize their calendars with those of the other portals is several hours. It goes without saying that in this way the probability of having overlapping bookings increases considerably.
But why do the portals carry out this update with such a long interval? We can hypothesize that it could be a problem related to resources; updating millions of calendars at very short intervals can require a lot of resources (but we are talking about multinational portals for which this hypothesis is not very likely). Instead, it is much more probable that they have chosen this path to discourage their hosts from inserting their structure into the portals of their competitors. Furthermore, since penalties are foreseen for cancellations by the hosts, the economic problem is therefore reflected exclusively on the host who will have to cancel one of the two reservations.
But for some time the iCal link has also been requested by third-party property management, revenue management and channel manager systems. It is almost always information that if we don’t provide it won’t let us continue. Even in cases where it is not necessary. For example, if we simply want to access the data of a certain area why should we necessarily insert the link of our calendar? The answer is simple; for these services, access to booking calendars (which only hosts can give them) has a very high value because the data that allows them to provide the service to customers comes from there. Without that data, they would have nothing to offer.
However, there is a problem relating to data ownership. The link to our calendar is called “secret” because we must only give it to those we trust. The link is the same for everyone and access, once given, cannot be revoked. This means that in the future, if we decide not to use a service we used to use and to which we have given this link, we will not be able to revoke access to our calendar and potentially the site could continue to access the calendar and use the data of our reservations, perhaps to the advantage of the competition. We have the same problem, for example, with collaborators who need to know the reservations of our properties. If one day we stop collaborating, they may continue to access our calendar and there is nothing we could do to prevent it.
Some services would solve this problem, such as the icalproxy.com site which allows you to create links to your calendars (even multiple links for the same calendar) to give and disable them at will. In this way, we could for example create different links to the same calendar for different services and selectively disable access to those sites that we no longer use. But almost no channel manager or revenue management portal accepts links other than those directed to OTA portals. How how? Perhaps precisely because they want to maintain the ability to access the calendars of their clients’ properties even if they stop being clients? However, for other situations (collaborators, cleaning team, etc.) it works without problems.