Central de reservas online

Agencias, Webs de turismo, Asociaciones
Hoteles, Apartamentos, Casas rurales

ALO - Integración con sistemas externos de afiliación
El catálogo de alojamiento gestionado directamente por ALO se puede complementar con catálogos externos, por ejemplo proporcionados por sistemas de afiliación (booking.com, hotel.info, laterooms.com..). En este documento comentamos diferentes opciones de integración.

Central de reservas. Integración con sistemas de afiliados XML

Hay varias opciones de integración que dependen de la central de reservas externa y de la funcionalidad concreta de la web gestionada con ALO.

Supongamos una web turística que gestiona un catálogo de alojamientos para España. Puede haber zonas geográficas en las que todavía no incluye una oferta importante y quiere complementarla con una oferta de alojamientos externa, a través de un sistema de afiliación.

Vamos a suponer también que trabajamos por ejemplo con booking.com, que ofrece un sistema de afiliación muy conocido con diversas opciones de integración.

Veremos estas diferentes posibilidades de integración, desde la más sencilla (deep links) hasta la más compleja (catálogo XML).

Trabajando con deep links.

Esta opción la soporta directamente ALO. Por ejemplo, queremos completar la oferta para una determinada zona, con hoteles de booking.com 

Podemos crear fichas de alojamientos 'ficticios' en ALO, con deep links hacia landing pages de resultados en booking.com, por ejemploun link hacia una ciudad en la que la oferta directa de ALO está incompleta.

En la zona pública, para el usuario final, aparecerán listados en primer lugar las fichas reales de ALO (las que gestionamos directamente y generan comisión directa). Y al final aparecerán las fichas 'ficticias' que llevan al sistema de afiliación.

Cuando el usuario realiza una búsqueda por fechas (desde / hasta), el resultado de ALO mostrará por defecto, en la implementación habitual, sólo los alojamientos que tienen disponibilidad para esas fechas. Igualmente se podrían añadir al final las fichas con deep links (de las que no se conoce la disponibilidad en ese momento).

Trabajando con booking.com como marca blanca (iframe)

En este caso tenemos dos bases de datos (dos centrales de reserva) trabajando por separado en la
misma web. Por un lado están los alojamientos gestionados directamente por ALO. Por otro lado los alojamientos gestionados por el sistema de afiliación.

En esta opción de trabajo, lo que puede interesar es separar las zonas de influencia de cada sistema. Por ejemplo, supongamos que queremos centrar nuestro catálogo directo en Madrid, mientras que la oferta para el resto de España la ofrecemos a través del sistema de afiliación.

Lo que queremos hacer es determinar, justo cuando el cliente realiza la búsqueda, cuál de las dos centrales de reserva vamos a utilizar y ofrecer al cliente. En esta modalidad no se pueden mezclar los resultados.

La decisión se toma en la caja de búsqueda del usuario, en función del destino (país, provincia, ciudad..). Siguiendo el ejemplo, si el usuario busca alojamiento en Madrid se le mostrarán los resultados gestionados directamente por ALO. Para otras zonas se le mostrarán los resultados del catálogo externo.

Hay que tener en cuenta que la personalización de los resultados del sistema externo normalmente se realiza a través de hojas de estilo, que podemos adaptar para que la integración gráfica sea lo más homogénea posible. Pero no se puede controlar el contenido en sí, puesto que se trata realmente de una página externa incrustada en nuestra web.


Trabajando con el catálogo externo a través de una API XML

Esta sería la opción más flexible y la que conseguiría una mejor integración con la imagen y la operativa de la web final. Dentro de esta modalidad habría bastantes opciones de integración y el coste de desarrollo también dependerá del grado de integración.

Con esta opción tendríamos por un lado la base de datos de ALO con su motor de disponibilidad, y por otro lado la base de datos externa con su propio motor de disponibilidad. Toda la parte de comunicación interna con el catálogo externo se tiene que desarrollar aparte. Normalmente irá como una aplicación independiente, aunque también se puede desarrollar como módulo de ALO.

Los resultados de las búsquedas quedan totalmente integrados. El usuario no distingue visualmente entre hoteles de ALO y hoteles del catálogo externo. Pueden ir incluso mezclados en los resultados de las búsquedas. Para el usuario final es totalmente transparente.

A la hora de hacer la reserva el usuario no abandona la web, todo el proceso se lleva a cabo desde la propia central. Si se trata de un alojamiento ALO, la reserva puede finalizar por ejemplo con el pago de una fianza en una pasarela de pago online (esto depende de los modelos de comercialización con los que trabaje la central, los sistemas de pago que haya integrado, etc.). Y si se trata de un alojamiento de booking.com puede finalizar solicitando al cliente el número de tarjeta de crédito, siguiendo la operativa de booking.com


Desde el punto de vista de los costes de desarrollo:

Usar una integración XML implica desarrollar toda la parte de automatización (conexión con el sistema externo, base de datos local..) e integrar todos los procesos en la zona pública. Tiene un coste mayor, pero una vez en marcha es todo automático.

Utilizando deep links no habría que desarrollar nada más, ya vendría integrado en ALO. El usuario en este caso ve claramente cuándo es redirigido a la web de booking.com.

Las opciones intermedias (iframe, etc.) supondrían soluciones de compromiso, con un coste de integración relativamente bajo, que pueden funcionar bien en determinados casos.