En
El viaje de la reserva 1: del Fax al XML 2.0, el primer artículo de la particular saga creada por Nacho Marín, Lead Developer en Paraty Tech, concluía con una gran promesa. Esta segunda entrega aspira a cumplirla.
Con
El viaje de la reserva 2: conversaciones entre channels y motores, me he propuesto resolver todas esas dudas que recibo a diario en relación con el modo en que se comunican los channel managers y los motores de reservas. Para ello, he decidido unificarlas en dos cuestiones fundamentales:
- ¿Qué variantes de Channel Managers hay disponibles en el mercado?
- ¿Qué ventajas y desventajas tienen?
Respondiéndolas, espero también ayudarte, en última instancia, a deducir qué channel manager resulta más adecuado para tu motor de reservas. La pregunta del millón...
Dicho esto, como punto de partida, creo que lo más recomendable es categorizar cada tipo de conexión atendiendo a tres aspectos fundamentales:
- El formato de los archivos intercambiados
- La forma en la que se descargan las reservas
- El modo en el que se intercambian precios y disponibilidad
Infografía Paraty Tech, Channels Vs. Motores, ¿Cuál te conviene más?
1. Channel managers atendiendo al formato de los archivos intercambiados
Para ser sincero, el formato de los archivos intercambiados, como tal, carece de importancia llegada la hora de elegir un channel manager u otro, ya que se trata de un factor puramente informático. No obstante, sí considero importante explicar qué tipos fundamentales de formatos hay y cómo interpretarlos, ya que muchas veces te verás incluido, en copia, en cadenas de emails en los que viajan, como adjuntos, este tipo de archivos, y es posible que la información contenida en ellos resulte de tu interés.
La mayoría de los channel managers comparten y reciben la información en lo que se conoce como un
Archivo XML. Este archivo, aunque visualmente pueda resultar poco atractivo, es relativamente fácil de entender por un humano sin conocimientos de programación. Además, tiene una ventaja: los navegadores (Explorer, Chrome, Firefox, Safari, Opera, etc.) los saben leer, y te ayudarán a interpretarlos, coloreándolos y permitiéndote abrir y cerrar sus elementos.
A continuación te muestro un ejemplo de un fragmento del típico Archivo XML:
Otro formato habitual, del que probablemente hayas escuchado hablar pese a ser menos común, es el
Archivo JSON, que tendría una estructura como la que te mostramos a continuación:
2. Channel managers atendiendo a la descarga de las reservas
Otro punto muy interesante, que debes tener en consideración, es el que concierne a la comunicación que se establece entre los motores y los channel managers cuando se descargan las reservas. Aunque quizás tampoco sea determinante como para marcar la decisión de decantarse por un proveedor u otro, sí es fundamental entender qué dos formas tienen los channel managers de recuperar todas las reservas consumadas a través de los diferentes puntos de venta online.
De esta manera, seremos capaces de distinguir dónde ha estado el problema cuando una reserva haya tardado más de lo deseado en volcarse o, en el peor de los casos, ni siquiera haya llegado a hacerlo. Asimismo, estaremos más preparados para lidiar con las explicaciones facilitadas, a este respecto, por parte de los diferentes soportes técnicos implicados en el proceso en cuestión.
Así pues, desde el punto de vista de los motores, existen dos formas de enviar las reservas:
Envío de reservas Pull
En los envíos de reservas de tipo Pull, es el channel manager el que pide, cada x minutos, el listado de reservas realizadas en el día. Esta petición recibe el nombre de Acción Pull.
A favor de este tipo de comunicación hay que decir que es muy complicado que una reserva no sea enviada por un fallo puntual (por ejemplo, un servidor caído), ya que se está solicitando el listado de reservas durante todo el día.
Como contrapartida, la descarga de las reservas no es inmediata. Por ejemplo, si el channel manager las solicita cada 10 minutos, una reserva puede tardar, como máximo, ese tiempo en ser integrada.
Envío de reservas Push
Al contrario del comportamiento recién descrito, en los envíos de reservas de tipo Push las reservas son enviadas inmediatamente después de haberse realizado, sin tiempos de espera, minimizando la probabilidad de posibles situaciones de overbooking.
Sirviéndonos de nuevo de la hipótesis del servidor caído, el principal inconveniente de este tipo de comunicación es que, si no hay configurado un sistema de reintentos, la reserva es algo más propensa a perderse.
En Paraty Tech, en caso de registrar un error, damos solución a esta tipología de incidencia reenviando la reserva hasta en cuatro ocasiones. Si ni siquiera después del cuarto intento conseguimos obtener el OK del channel manager, lanzamos emails de alerta para que la reserva pueda ser gestionada manualmente.
3. Channel managers atendiendo a la comunicación de disponibilidad y precio
Ahora sí, vamos a entrar de lleno en el que considero el aspecto más importante a la hora de decidirse por uno u otro channel manager. Para ello, explicaré los dos tipos de conexión que existen, respecto a la comunicación del estado de la disponibilidad, las restricciones y del precio. Una vez más, como casi siempre sucede en la vida, cada una de ellas tiene sus pros y sus contras. Nos adentramos pues en el complejo mundo de los Channels Pull y los Channels Push.
Channels Pull
Este tipo de channel ofrece, en tiempo real, precios y disponibilidad. Es decir, cada vez que se lleva a cabo una búsqueda en alguna página web (por ejemplo, en el canal oficial de ventas del hotel), el motor de búsqueda le manda una petición al channel, y este le responde con precios y disponibilidad.
Este tipo de conexiones tienen la ventaja de que suelen ser más fáciles de configurar, ya que todo el detalle del producto está cargado en un solo panel de control. En teoría, esto debería reducir el riesgo de errores al haber menos sistemas involucrados. Es más, por esta misma razón, también debería ser más fácil localizar un error, por ejemplo, a la hora de calcular un precio.
Pero, a veces, las fortalezas pueden ser también entendidas como debilidades, y su desventaja principal deriva, precisamente, de su propia naturaleza: al estar todo centralizado en un sistema único (el channel), todos los motores con los que esté conectado, dependen del mismo.
El Channel Pull suele ir acompañado de una mayor lentitud en las búsquedas, ya que el motor, primero, debe enviar una petición (Request), después, esperar a la respuesta (Response), y una vez obtenida, procesarla para mostrársela al cliente.
Otro problema muy habitual de los Channels Pull es la posible pérdida del estado de la disponibilidad, y la razón es muy sencilla. Basta con que los servidores del channel se caigan, para que deje de ofrecer disponibilidad en todos los motores con los que esté conectado, sin que nadie pueda hacer absolutamente nada al respecto.
Por último, y en mi opinión la más importante de las desventajas de los Channels Pull es su escasa flexibilidad. El hotel no tendrá más remedio que limitarse a las funcionalidades que le ofrezca el channel. ¿Que el channel no acepta la opción de promocodes? Entonces será muy complicado que el buscador de tu página web pueda implementarlos. Y así con todo.
Aspirando, como siempre, a seguir tendiendo posibles puentes de colaboración, algo que pasa por tratar de resolver limitaciones como la que acabamos de describir, en Paraty Tech hemos desarrollado una capa intermedia que intercepta los precios del channel antes de mostrarlos, lo que nos permite aplicarles una lógica diferente. Lamentablemente, esto no siempre es posible debido a las medidas de seguridad de este tipo de channels, que suelen incluir una comprobación de precios, y a la hora de enviar la reserva, es posible que sea rechazada si el precio no coincide. Y aunque no fuera así, el mero hecho de tener dos lógicas cargadas en sitios diferentes, aumenta la complejidad del sistema, algo que choca frontalmente justo con la que constituye la principal fortaleza de los Channels Pull: su simplicidad de configuración y sencillez de conexión.
Channels Push
Este tipo de channel mantiene los precios, las restricciones y la disponibilidad actualizadas en los paneles con los que tiene conexión. Normalmente se comunica con los motores de búsqueda cada vez que hay algún cambio (cupo, precio, etc.) o periódicamente, cada cierto intervalo de tiempo. Es decir, existen estructuras idénticas y paralelas cargadas en todos los sistemas que estén interconectados.
Por este motivo, las diferentes webs que estén conectadas a un Channel Push siempre ofrecerán disponibilidad, con independencia de que el channel pueda sufrir un apagón, ya que todo el producto va a estar precargado (y actualizado hasta dicho apagón) en los demás sistemas, que funcionan independientemente del channel.
Además, la velocidad a la hora de mostrar disponibilidad en las diferentes webs es muy superior a las de los Channels Pull, ya que no requiere ningún tipo comunicación entre ambos sistemas.
Por último, ofrecerá también una mayor flexibilidad, pues al tener los precios precargados, permitirá incorporar ofertas sofisticadas, crear paquetes, usar promocodes, implementar tarifas con estructuras complicadas, etc. Todo ello, soporte el channel o no dichas funcionalidades.
Pero entonces, ¿qué inconvenientes tiene un Channel Push? En resumen, fundamentalmente dos. Por un lado, la configuración inicial conllevará más trabajo debido a los famosos mapeos, al disponer de estructuras paralelas cargadas en ambos lados, lo que obliga a que exista una correlación entre los diferentes códigos internos.
Por otro, la resolución de incidencias puede resultar algo más tediosa. Tener precios cargados en varios paneles puede dificultar la tarea de dar con el punto exacto en el que se ha producido el problema al mostrar un precio incorrecto o una disponibilidad errónea.
A este respecto, y ya para terminar, en Paraty Tech hemos implantado un software de auditoría que nos permite recuperar el histórico XML enviado por los Channels Push, y conocer así el día concreto y la hora exacta en la que recibimos un precio, restricción o cupo.
Marta contaba cómo, después de haberse alojado en innumerables ocasiones en el mismo hotel durante años por motivos laborales, le extrañaba, casi molestaba, que nunca le hubieran dado la bienvenida y la hubieran recibido por su nombre. Una calidez que hubiera apreciado tras quince horas de avión, cansada y sucia, que es como acostumbraba a alcanzar su destino.
Lo mejor, el buen rollo entre compañeros y competidores de sector, poder poner cara, por fin, a muchas de las personas que hay detrás de los emails de nuestro día a día, y ver la buena salud de la que goza el sector de la hospitalidad. Lo peor, salir de allí con la sensación de que, aunque se esperan grandes e importantes cambios a muy corto plazo, no termina de decirse nada realmente rompedor e innovador en estas citas, nada que no sepan ya tanto los hoteleros como sus proveedores, lo apliquen en mayor o menor medida. Bueno, a excepción de ese novedoso concepto de sonrisa tecnológica, claro. Es broma…
