When an Online Travel Agent (OTA) delivers a booking to your hotel it will include profile contact details. Unfortunately, some OTAs, like Booking.com, choose to create and share an alias email address rather than share the guest’s actual address.
This means the alias address must be used for communications, routing correspondence via the OTA’s own systems. This means they have a level of control. For example, they sometimes have an annoying habit of stripping the content of emails, i.e., the stripping and trimming of hyperlinks/URLs so they no longer function. In addition, after the guest's departure these alias addresses no longer function, making it difficult to communicate future offers and generate repeat business.
The obvious challenge presented by this is a barrier to the completion of the Digital Registration process. The hotel sends a communication requesting for that process to be completed, but the guest is unable to access it.
Even when the hotelier attempts to remedy this by acquiring the guest’s real email, if an OTA sends a modification, historically the PMS would fail to match with the existing profile and as a result a new profile would be created. The result is the loss of the genuine email address.
Even if that modification didn’t take place, the next time the guest stays, the system would not find the existing “true” profile, and this would cause a duplicate. Again, because the email address has historically been core to the matching process
Guestline can now help to solve this problem
Now, when we receive one of these alias emails in a booking, Create or Modification message via Distribution, we remove it from the equation. That way we match on the other fields, like name, street, postcode and telephone, so once the “real” email address has been captured, we no longer unlink that profile or overwrite the genuine email. And best of all, we don’t create a duplicate. We’ll therefore only use the masked email address if we can’t make a match to a profile that has a “real” email address.
Comments
0 comments
Article is closed for comments.