Cómo elegir un booking engine para tu hotel

Un hotel puede pasar meses llevando a un huésped a su propio sitio web en lugar de a una OTA, para perderlo justo en la última pantalla porque el booking engine exige crear una cuenta antes de mostrar el precio total, o borra las fechas seleccionadas en cuanto falla un intento de pago. El marketing hizo su trabajo. El booking engine no. En una cuenta de hotel que asumimos, el sitio antiguo obligaba a los huéspedes a pasar por una serie de pasos extraños y sin relación entre sí antes de que apareciera siquiera el booking engine; simplificar ese recorrido, para que el huésped pasara del anuncio al motor de reservas viendo en todo momento las garantías y las reseñas del establecimiento, valió más que cualquier ajuste dentro del propio motor.

En resumen: un booking engine (el software de checkout integrado en el sitio web del propio hotel, que gestiona la búsqueda de fechas, muestra tarifa y disponibilidad en tiempo real y procesa el pago) no es el sitio web que lo rodea, ni el channel manager que envía las tarifas a las OTA y trae de vuelta las reservas. Elegirlo bien importa más que el diseño que lo rodea, porque es la única parte del sitio que convierte a un visitante en una reserva directa pagada. Hay que evaluarlo como categoría en cinco puntos: el coste real por reserva (tarifa fija frente a porcentaje de comisión, porque la comisión reconstruye silenciosamente el coste de la OTA del que el hotel intenta escapar), el flujo móvil, la fiabilidad de la sincronización con el channel manager, las opciones de pago que esperan los huéspedes, y quién es el propietario legal de los datos del huésped que genera cada reserva.

Este artículo está escrito para el propietario o el director general de un hotel independiente de aproximadamente 50 a 200 habitaciones que está valorando un primer booking engine o el cambio desde uno ya existente. Es una guía de decisión sobre la categoría, no un tutorial paso a paso de configuración, y no va a nombrar ningún producto concreto: la parte útil de esta decisión son los criterios, no la lista de candidatos.

Qué es realmente un booking engine, y entre qué se sitúa

El booking engine es el software integrado en el sitio web del hotel que ejecuta la transacción propiamente dicha: el huésped elige fechas, el motor comprueba la disponibilidad y la tarifa en tiempo real, y cobra el pago. Ese es todo su trabajo. No es el sitio web (las páginas y las fotografías que convencen a alguien de buscar una fecha en primer lugar), y no es el channel manager (la conexión que envía las tarifas y el inventario del hotel a las OTA y a otros canales de venta, y trae de vuelta sus reservas a un único calendario). Son tres trabajos distintos, y un eslabón débil en cualquiera de ellos puede echar por tierra un buen trabajo hecho en los otros dos. Este artículo trata solo del que está en el medio: el checkout.

Por qué esta decisión pesa más que el diseño del sitio que la rodea

Cada libra invertida en empujar a un huésped hacia el sitio propio del hotel, ya sea mejor SEO, búsqueda de pago, o el argumento más amplio de por qué los hoteles pequeños deberían centrarse en las reservas directas, se gasta para llevar a un visitante a un momento muy concreto: el booking engine. Si el trabajo más amplio de aumentar las reservas directas va bien y el booking engine no, el hotel está pagando para mover huéspedes desde un canal que convierte de forma fiable a otro que no lo hace. Ese es el lugar más caro en el que un booking engine puede ser mediocre: el coste de llevar al huésped hasta ahí ya se ha gastado, se complete la reserva o no.

El coste real de una reserva: tarifa fija frente a porcentaje de comisión

Como categoría, los booking engines se cobran de dos formas: una tarifa fija que no varía con el volumen, o una comisión, normalmente un pequeño porcentaje del valor de cada reserva. Ambos modelos son legítimos. El error está en compararlos por el precio de partida en lugar de por lo que cuestan una vez que el canal directo realmente funciona.

Solo como ejemplo numérico: tomemos un hotel que hace 50 reservas directas al mes, con un valor medio de £180 por reserva, en un booking engine que cobra un 3% de comisión. Eso son £9.000 en reservas y £270 de comisión, una cifra lo bastante pequeña como para parecer irrelevante junto al coste de puesta en marcha de una tarifa fija. Si el mismo canal directo crece hasta 200 reservas al mes con la misma media de £180, la comisión sobre £36.000 en reservas es de £1.080. La comisión creció exactamente al ritmo del propio éxito del hotel. Una tarifa fija se mantiene igual: cuesta lo mismo con 50 reservas que con 200, así que el incentivo para seguir haciendo crecer el canal directo se mantiene intacto en lugar de reducirse a medida que funciona.

En cada cuenta de este tipo existe un punto de cruce: un volumen de reservas directas a partir del cual la comisión deja de ser el modelo más barato. El error es no saber más o menos dónde está ese punto antes de firmar un contrato de varios años, y no revisarlo a medida que el canal crece: en las cuentas que analizamos, esa cuenta suele hacerse una sola vez, al principio, cuando el volumen es más bajo y la comisión parece naturalmente la mejor opción.

El flujo móvil, y los pasos donde se pierden las reservas

La mayoría de las sesiones de booking engine que vemos empiezan en un móvil, y por eso el flujo móvil no es una versión secundaria del checkout de escritorio: es el checkout que la mayoría de los huéspedes van a encontrar primero. Los pasos que hacen perder una reserva en móvil rara vez son dramáticos: una búsqueda de fechas que no muestra el precio total hasta tres pantallas después, un selector de habitaciones que recarga la página y borra las fechas elegidas, un checkout que exige una cuenta antes siquiera de aceptar una tarjeta, una tarifa que cambia cuando la conversión de moneda o una resort fee aparecen en el último paso, después de que el huésped ya se ha comprometido mentalmente con una cifra.

Nada de esto es exclusivo de los hoteles. La investigación de checkout de largo recorrido de Baymard Institute en todo el ecommerce sitúa la complejidad entre las razones documentadas más frecuentes por las que una selección completada nunca llega a ser una compra, y su investigación específica sobre alojamientos de viaje cubre el propio flujo de reserva. La lección práctica: antes de firmar nada, hacer una reserva desde un móvil, en el sitio actual del hotel si existe, y contar las pantallas y los campos entre elegir una habitación y confirmar el pago. Si esa cifra avergonzaría al hotel en caso de que un huésped se quejara por ello, hay que arreglarla antes de preocuparse por cualquier otra cosa de esta lista.

La sincronización de tarifas y disponibilidad con el channel manager, donde se esconde el fallo

Un booking engine puede tener un diseño impecable y aun así fallar en su único trabajo si la tarifa y la disponibilidad que muestra no son lo que el hotel pretendía vender. Lo que hace un channel manager es enviar las tarifas y el inventario del hotel a las OTA y mantenerlos actualizados a medida que se venden las habitaciones. El booking engine necesita tomar los datos de esa misma imagen en tiempo real, no de una hoja de tarifas separada actualizada a mano, ni de una sincronización nocturna que deja horas en las que ambos pueden no coincidir.

Aquí es donde los hoteles independientes con los que trabajamos se ven sorprendidos con más frecuencia, porque el síntoma nunca parece técnico. Parece una queja de un huésped, o una reserva que llega a una tarifa que el hotel no creía estar ofreciendo ese día. Antes de elegir o renovar un booking engine, conviene preguntar directamente con qué frecuencia se actualiza la conexión con el channel manager, y qué ocurre con una reserva hecha en el hueco entre dos actualizaciones. "Se sincroniza" no es una respuesta. "Cada quince minutos, y esto es lo que pasa si dos canales venden la misma última habitación en esa ventana" sí lo es.

Las opciones de pago que los huéspedes realmente esperan antes de dar su tarjeta

Antes bastaba con aceptar tarjeta, y cada vez es menos suficiente. Los huéspedes que reservan desde mercados distintos esperan ver el precio en su propia moneda sin tener que convertirlo ellos mismos, y una opción de wallet le ahorra al huésped teclear un número de tarjeta en el teclado del móvil, que es justo el paso donde se atascan los checkouts móviles. Nada de esto necesita una recomendación de producto, solo una pregunta concreta durante la evaluación: qué monedas, qué redes de tarjeta y qué wallets admite hoy el booking engine, no en una futura hoja de ruta.

La otra cuestión de pago que importa más de lo que parece a primera vista es la estructura del depósito. Algunas reservas necesitan el pago íntegro por adelantado para quedar garantizadas, otras funcionan mejor con un pequeño depósito y el resto pendiente a la llegada, y la flexibilidad del booking engine en este punto puede decidir si un huésped reserva directamente o se va a una OTA porque allí las condiciones parecían menos comprometedoras. Cómo se trata legalmente un depósito varía según el mercado, así que conviene comprobar los detalles con quien gestione los contratos del hotel en lugar de darlo por hecho.

A quién pertenecen realmente los datos del huésped que genera una reserva directa

Todo el argumento comercial para hacer crecer el canal directo descansa en algo que una reserva de OTA no le da a un hotel: el correo electrónico propio del huésped, recogido con consentimiento y utilizable para un upsell antes de la estancia, una solicitud de reseña, o una oferta de regreso más adelante. Un booking engine que no puede exportar ese registro de huésped de forma limpia, en un formato que los propios sistemas del hotel puedan usar de verdad, limita silenciosamente ese potencial, sin importar cuántas reservas directas procese.

Antes de firmar hay que hacer tres preguntas concretas. ¿Puede el hotel exportar la lista completa de huéspedes, incluidas las reservas históricas, en un formato utilizable en cualquier momento? ¿Sigue siendo accesible ese dato si el hotel cambia de proveedor en algún momento? ¿Y quién figura como responsable de esa información de los huéspedes? La propiedad y la responsabilidad aquí varían según el contrato y el mercado, así que conviene preguntarlo directamente a quien esté proponiendo el booking engine en lugar de dar la respuesta por supuesta.

El escenario más costoso: pagar tráfico que termina en una tarifa peor que la de la OTA

La versión más cara de esto ocurre así. Un hotel invierte en búsqueda de pago o SEO para atraer a un huésped desde una OTA hasta su propio sitio. El huésped busca las mismas fechas y la misma habitación en ambos, y el booking engine del hotel muestra un precio más alto que Booking.com para la habitación idéntica. Ningún huésped diagnostica un problema de sincronización; lo que se lleva es la idea de que el hotel intentó cobrar más por reservar directamente, cierra la pestaña, y reserva en la OTA en su lugar, llevándose con él el coste de la comisión.

Esto no es un caso raro. Es el resultado mecánico de una sincronización desactualizada, una tarifa que alguien olvidó actualizar, o un booking engine y un channel manager que nunca llegaron a conectarse correctamente desde el principio. Cada libra gastada en ese tráfico produjo exactamente ese resultado. Comprobar que la tarifa que muestra el hotel coincide con la que muestran las OTA para las mismas fechas y habitación, de forma regular y no solo en el lanzamiento, es una comprobación barata, y una que casi nunca se hace.

Cuándo cambiar de booking engine es un error

Nada de lo anterior significa que el booking engine sea automáticamente el problema. Si la paridad de tarifas con las OTA ya está rota por motivos ajenos al booking engine, como un channel manager mal conectado o una tarifa cargada a mano de forma inconsistente, o si el sitio web tiene problemas básicos como páginas lentas, una navegación móvil rota o ningún botón claro de reservar ahora, cambiar de booking engine no va a arreglar nada de eso. Simplemente traslada los mismos problemas a un software nuevo, al coste de una migración, mientras las causas reales se quedan exactamente donde estaban.

El orden correcto es arreglar primero la paridad de tarifas y la mecánica básica del sitio web, y solo después mirar a fondo el propio booking engine. Un hotel que hace esto al revés suele acabar de vuelta aquí dieciocho meses después, habiendo cambiado de booking engine sin haber cambiado nada de lo que los huéspedes realmente experimentan.

Si no está claro cuál de estos es el problema en una cuenta concreta, para eso sirve una auditoría bien hecha. Reserva una auditoría gratuita y obtén una respuesta clara sobre dónde se está rompiendo realmente la cadena de reservas directas antes de gastar dinero en un motor nuevo.