design+code
Los hoteles eligen su sistema de gestión hotelera (PMS) pensando en la recepción. Después descubren, normalmente a mitad de un proyecto web, que esa misma decisión fijó sin hacer ruido los límites de lo que puede ser el proceso de reserva. Te explicamos cómo se relacionan las dos cosas y qué comprobar antes de firmar cualquiera de los dos contratos.
El PMS lo elige el equipo de operaciones. Los criterios son la gestión de tarifas, el housekeeping, la auditoría nocturna, los informes y el esfuerzo de formación del equipo. Son los criterios correctos para quienes usan el sistema todos los días.
La web llega después, a menudo uno o dos años más tarde, con otra agencia y sin nadie de aquella conversación inicial en la sala. Y es entonces cuando alguien pregunta si el proceso de reserva puede vivir en la propia web en lugar de mandar a los huéspedes a un dominio de terceros. La respuesta la marcó una decisión tomada mucho antes, por personas a las que nadie hizo esa pregunta.
No defendemos que la web deba condicionar la elección del PMS. Ahí debe mandar operaciones. Lo que defendemos es saber qué estás comprando en la parte de distribución al mismo tiempo que lo compras en la parte operativa.
El motor de reservas es la pieza que toma la disponibilidad y las tarifas del PMS, se las muestra al huésped y registra la reserva de vuelta. Casi nunca es algo que se construya desde cero, porque tiene que gestionar inventario en tiempo real y cobrar, y equivocarse ahí sale caro de una forma en que una página de marketing nunca lo hace.
La cuestión no es si lo construyes. Es cuánto de él puedes controlar. Hay tres niveles en la práctica, y el PMS decide cuál tienes a tu alcance.
El primero es un motor alojado en el dominio del proveedor. El huésped hace clic en Reservar y aterriza en booking.vendor.com. Funciona, lo mantiene otro y es lo que usan la mayoría de los alojamientos pequeños. Lo que pierdes es la última parte del embudo: el diseño se rompe, el dominio cambia y tu analítica necesita trabajo extra para seguir al huésped al cruzar esa frontera.
El segundo es ese mismo motor integrado en tu página, normalmente en un iframe o un widget por script. Visualmente se parece más a tu web. Pero las limitaciones de maquetación son reales, y heredas el comportamiento responsive que haya decidido el proveedor.
El tercero es un front end a medida conectado a una API de reservas. Diseñas cada pantalla, la URL nunca sale de tu dominio y la analítica queda limpia de principio a fin. Para eso, el PMS tiene que ofrecer una API de reservas, y cuesta bastante más construirlo y mantenerlo, porque el proveedor cambiará esa API y tendrás que adaptarte.
Mews es API-first y publica una API abierta con una API específica para el motor de reservas, además de un motor alojado y un amplio marketplace de integraciones. Si un proceso de reserva a medida está sobre la mesa, este es el tipo de sistema que lo hace posible.
Apaleo lleva esa misma postura más lejos. Está pensado como una capa central de datos alrededor de la cual se construye, lo que encaja con un establecimiento que ya sabe que quiere montar su propio stack en lugar de aceptar un paquete cerrado.
Cloudbeds reúne el PMS, el channel manager, el motor de reservas y los pagos en un solo producto. Es una ventaja real para un establecimiento sin socio técnico, porque hay un único proveedor y un único soporte. La contrapartida es que trabajas sobre todo dentro de su marco. Cloudbeds sí ofrece una API para conectar un motor de reservas de terceros, pero ir por ese camino significa sortear el paquete que elegiste precisamente por su sencillez.
Little Hotelier, de SiteMinder, está pensado para alojamientos pequeños, casas de huéspedes y B&B. Es sencillo a propósito, y sencillo significa que la parte que puedes personalizar es pequeña.
Oracle Opera es lo que usan la mayoría de las grandes cadenas. La integración pasa por la plataforma de integración de hostelería de Oracle, que es muy completa y no encaja con el presupuesto ni con los plazos de un establecimiento independiente.
Aquí describimos categorías, no hacemos una recomendación. El sistema adecuado depende de cuántas habitaciones tienes, de si hay alguien técnico implicado después del lanzamiento y de cuánto de tu negocio llega directo en lugar de a través de las OTA. Una casa de huéspedes de diez habitaciones que recibe la mayoría de sus reservas desde Booking.com no necesita una API abierta. Un grupo con tres establecimientos y una estrategia real de reserva directa, probablemente sí.
Cinco cosas, y basta con un email al proveedor.
¿Puede el proceso de reserva funcionar en nuestro propio dominio y, si es así, cómo? ¿Hay una API pública de disponibilidad, tarifas y reservas, y el acceso está incluido o se paga aparte? ¿Podemos personalizar el motor más allá de cambiar un logo y dos colores? ¿Qué pasa con nuestra analítica y con la gestión del consentimiento cuando un huésped pasa de la web al proceso de reserva? Y ¿cómo se exponen los planes de tarifas y las promociones? Porque una landing para una oferta concreta solo es posible si esa oferta es accesible desde fuera del sistema.
Esa última es la que más se pasa por alto. Una página de campaña que no puede enlazar directamente a la tarifa correcta con las fechas ya rellenadas es una página que pierde huéspedes justo en el momento en que habían decidido comprar.
Cuando el proceso de reserva está alojado fuera, la función de la web cambia. Deja de ser el lugar donde ocurre la transacción y pasa a ser el lugar donde se toma la decisión. Las habitaciones tienen que estar fotografiadas y descritas lo bastante bien como para que el huésped ya haya elegido antes de hacer clic. El paso al motor debería estar a una sola acción desde cualquier punto de la web. Y ese traspaso debería llevar todo el contexto posible: establecimiento, tipo de habitación, fechas y tarifa.
Además, la medición hay que configurarla a conciencia, porque por defecto tu analítica pierde al huésped en la frontera entre dominios y acabas sin poder decir qué páginas generaron ingresos. El seguimiento entre dominios no es complicado, pero no se hace solo, y nos hemos encontrado muchas webs de hotel en las que nunca se había configurado.
Nada de esto convierte un motor alojado en una mala elección. Solo significa que la limitación se conoce antes de empezar el diseño, en lugar de descubrirse durante el desarrollo.
Hacemos webs de hoteles y hostelería e integramos el sistema de reservas que el establecimiento ya utilice, sea cual sea. No vendemos ningún PMS y no tenemos motivos para preferir uno u otro. Lo que sí preguntamos, desde el principio, es qué sistema es y qué expone, porque esa respuesta determina lo que podemos diseñar.
Si estás eligiendo un PMS y quieres tener claras las implicaciones para la web antes de comprometerte, o ya tienes uno y quieres saber qué se está dejando por el camino tu web actual, escríbenos a bonjour@dellamattia.com.