8 de Octubre de 2009 · 6 min de lectura
Entendemos como motores de reservas aquella tecnología que nos permite poner a disposición de terceros (vías web, xml, etc) nuestra disponibilidad de habitaciones, permitiendo que se pueda hacer la reserva. El términio es muy amplio y la solución técnica que le podemos dar no es única. En este artículo trataré de explicar un poco qué alternativas tenemos a la hora de elegir un motor de reservas y los condicionantes que nos pueden llevar a elegir una solución u otra. A la hora de elegir una solución debemos plantearnos el porqué lo hacemos: si queremos una solución para salir del paso o queremos una solución que nos de flexibilidad. Si necesitamos vender sólo nuestro producto o bien necesitamos, como en el caso de las agencias, vender disponibilidad de camas de un gran número de proveedores. Veamos las principales alternativas: Página estática Listamos las posibilidades en nuestra web y el cliente rellena un formulario. Todo el proceso se realiza manualmente y no hay control de cupo y sí un procesamiento totalmente manual de la reserva. Pongo esta opción por completitud, pero es la menos aconsejable, pero obviamente es la más rápida de desarrollar y mantener. El iframe Un iframe es una página dentro de una página. Es la solución que cuesta menos de poner en producción ya que se limita a unas pocas líneas de código HTML dentro de nuestro portal web. Si no tenemos portal obviamente habrá que crearlo. Es la solución que presenta más desventajas desde el punto de vista de la hipoteca tecnológica (el precio que pagamos a la larga por elegir una solución), de dependencia del proveedor y por posicionamiento. Hay que tener en cuenta que es el proveedor del iframe el que tienen el motor de reservas y lo aloja en sus servidores. Nosotros no tenemos control alguno sobre ni sobre el iframe ni nuchas veces sobre los resultados que aparecen. El grado de integración que podemos tener con el iframe es mínimo, ya que recordémoslo, se trata de una página que no es nuestra y que por tanto tendremos únicamente lo que el proveedor del iframe nos proporcione. En tema de posiciamiento de nuestra web el iframe representa un gran problema, ya que recordémoslo nuevamente, el iframe no forma parte de nuestra página, y por tanto no vamos a poder posicionar nuestro portal de modo tant eficiente como si todo el contenido fuese nuestro. En resumen:
Servicios XML El motor de reservas sigue estando controlado por un proveedor externo pero este nos proporciona un interfaz xml con el que comunicar con él. Algunos proveedores XML pueden servirnos todo su contenido o bien únicamente contenido con contrato o cupo propio, por lo que también pueden ser una solución para cadenas y pequeños TTOO que no deseen mantener un motor propio. El desarrollo de la aplicación web es más costoso ya que se necesita hacer una transformación entre los datos que nos suministra el proveedor (texto en XML) y la web y normalmente añadirle reglas de negocio para la presentación de resultados y precios. Se deben aplicar optimizaciones adicionales para agilizar los tiempos de respuesta de nuestra web y añadir una capa adicional de código que nos independice el XML del proveedor de las funcionalidades de nuestra web, de este modo si cambiamos de proveedor XML sólo tendremos que cambiar una pequeña parte de la web. El grado de integración que podemos tener en nuestro portal web es muy alto, ya que el proveedor se limita a ofrecernos información de disponibilidad y nosotros decidimos qué y como lo presentamos. El posicionamiento por tanto no está limitado por la tecnología XML que utilizamos. El grado de depenencia con el proveedor es alto, pero tomando algunas precauciones (como la de añadir una capa de procesamiento intermedia) podríamos dado el caso, cambiar de proveedor sin tener que empezar totalmente de cero. También estamos limitados por la interfaz de acceso que nos proporcione el proveedor (la API XML) y por el flujo que tenga del proceso de compra. En resumen: Motor propio a medida Tener un motor propio nos da control total sobre nuestro producto. Podemos elegir qué y cómo vamos a vender y cómo vamos a poner nuestro producto en la web o si vamos a permitir conexiones de terceros. El motor puede estar optimizado para nuestro tipo de negocio, de modo que se tendría un motor con optimizaciones diferentes para hoteles de costa que para hotels de nieve. Al estar desarrollado a medida podemos alcanzar cotas de rendimiento y adaptación mucho más altas que en cualquiera de los dos casos anteriores. Mantener un motor propio nos permite desarrollar nuevos productos e ir construyendo nuestra plataforma de venta a medida. Todo esto tiene un coste, y no es tan solo el precio, tener un motor a medida propio sólo tiene sentido si pensamos invertir en la web al 100% y junto con el área de marketing ir desarrollando nuevas vías de negocio y fidelización de clientes. Es importante que mantengamos el control del código fuente del motor (del programa), en caso contrario no tendríamos la flexibilidad que estamos buscando y mantendríamos una dependencia alta con el proveedor. Por ejemplo, si nuestro departamento de programación no tiene tiempo para desarollarlo de manera interna, podemos externalizar el desarrollo y asegurarnos de que el proveedor transfiere el código fuente y el conocimiento de cómo está hecho a nuestros desarrolladores. El motor será todo lo complicado o sencillo que nuestro negocio requiera. Puede ser una simple tabla con las camas o un completo sistema de disponibilidad y ofertas. En resumen: Independientemente de la solución que elijamos, tenemos que verificar que podemos acceder a las estadísticas de reservas, que podemos exportar los datos que introducimos y ver si hay alguna posibilidad de que el sistema elegido se pueda comunicar con nuestro backoffice de gestión principal. Éste es uno de los problemas principales: la venta web no se comunica con el backoffice de gestión y eso hace que haya un trabajo manual y rutinario que se podría evitar. A la hora de cambiar el backoffice convendría pedir siempre al vendedor sobre las posibilidades de importación de datos de venta y facturación del mismo. Un backoffice que permita la importación de datos en un formato estándard (texto plano, csv o xml por ejemplo) nos permitirá en un futuro integrar mejor las reservas que vengan de la web sin que tengamos que tener un programa que lo haga todo, pero eso es un tema que dejaré para otro día. Cada una de estas opciones representa una apuesta mayor en la comercialización web y una implicación mayor de nuestros departamentos de IT (o de los partners que tengamos) y de los departamentos de marketing y ventas. Cuanto mayor es la apuesta mayor es el riesgo, pero también son mayores los beneficios. Desde la blogosfera actualmente hay un movimiento importante contra el recorte ministerial en I+D, la frase que apunta Ricardo Galli también nos puede servir como conclusión en este apunte: "Desde la revolución agraria las sociedades más desarrolladas no fueron las que podían comprar las herramientas, sino las que tenían los conocimientos y recursos para construirlas. Por ello en los países más desarrollados aproximadamente el 80% de la financiación de I+D proviene de fondos públicos. EEUU invierte en I+D casi el triple del PIB que España, la media europea es el doble, y algunos paises europeos casi cuatro veces más. Las tijeras no generan atajos." Para comprar sólo necesitas dinero, pero te quedas sin el conocimiento. Desde el punto de vista de control de negocio y mínima hipoteca tecnológica mis soluciones preferidas son el XML y el motor propio, pero obviamente cada uno conocerá mejor que nadie su situación. Espero que este apunte pueda servir para valorar las alternativas y encontrar la que mejor se adapte a las necesidades de cada negocio. Nota: apunte publicado también en hosteltur
Volver al blog
