Lo que aprendí al contribuir a crear mis propias herramientas de Revenue Management, sin ser programador.
Hace unos meses, al analizar la segmentación de dos hoteles, me di cuenta de que algo no cuadraba.
Los números de grupos parecían positivos. Pero el comportamiento de las reservas no coincidía con lo que conocía del día a día: antelaciones extrañas, tarifas que no tenían sentido para el segmento asignado y un pickup - la evolución de las reservas en un período determinado - que no contaba la historia real.
Al investigar, encontré el problema: cientos de room nights - noches de habitación - estaban clasificadas en el segmento equivocado, entre Series de Grupos y Grupos Puntuales.
El problema que los informes no muestran
Quien trabaja con un PMS, el sistema de gestión del hotel, conoce este escenario. La clasificación de segmentos puede depender de campos rellenados a mano, códigos de mercado heredados, reglas que han cambiado con el tiempo y equipos que registran reservas de formas distintas. La información entra en el sistema y los informes siguen pareciendo coherentes.
Pero una Serie de Grupos - grupos recurrentes, con contrato y previsibilidad - y un Grupo Puntual - un evento único, más volátil - son realidades comerciales distintas. Pueden tener diferente antelación, sensibilidad al precio y valor estratégico. Mezclarlos es como mezclar dos idiomas en una misma frase: el mensaje parece tener sentido, pero deja de reflejar la realidad.
Cuando los números suman, pero la interpretación falla
Con room nights en el segmento equivocado, el mix de negocio resulta engañoso, la previsión queda sesgada y el pricing puede reaccionar a la señal equivocada. Parece que dependemos más de un segmento de lo que realmente dependemos. Y comparar la evolución de un segmento a lo largo del tiempo pierde valor si incluye reservas que no le corresponden.
Lo más peligroso es que nada de esto tiene por qué generar un error en el sistema. Los números siguen sumando.
La tecnología ejecutó. El conocimiento del negocio definió la lógica.
No soy programador. Pero conozco el negocio, y eso fue lo que marcó la diferencia.
En estos dos hoteles, sabía que el campo de canal era el más fiable para identificar el origen real de cada reserva. Lo utilicé como referencia para reclasificar los datos, con ayuda de herramientas de IA y Excel. Construí un proceso que adapta la forma en que cada hotel registra la información a una estructura consistente.
La tecnología no decidió la clasificación. Ejecutó a escala una lógica definida a partir del conocimiento del negocio. Con los datos corregidos, la lectura del mix y del pickup pasó a coincidir con lo que se vivía en la operación.
Cuatro aprendizajes que me llevo
- Desconfía de los datos que «parecen normales». La anomalía más cara puede ser la que nadie cuestiona.
- El conocimiento del negocio sigue siendo la parte difícil. Las herramientas actuales hacen más accesible la programación, pero saber qué regla aplicar exige contexto y experiencia.
- Cada hotel tiene su propio lenguaje. Estandarizar sin respetar esa diferencia puede crear un nuevo error. El mapeo tiene que adaptarse al hotel, y no al revés.
- Empieza por algo pequeño y documéntalo. Un problema concreto, resuelto y explicado, vale más que un gran proyecto de «transformación digital» que nunca sale del PowerPoint.
El Revenue Manager del futuro: un traductor
Se suele decir que el Revenue Manager del futuro será un científico de datos. Creo que también será un traductor: alguien que entiende lo que vive el hotel en su día a día y sabe traducirlo a datos, para después traducir esos datos de nuevo en decisiones.
Mezclar idiomas puede distorsionar el mensaje. Saber traducir entre ellos crea una ventaja. Quien domine esa traducción, con o sin código, marcará la diferencia.