O que aprendi ao ajudar a construir as minhas próprias ferramentas de Revenue Management - sem ser programador.
Há uns meses, ao analisar a segmentação de dois hotéis, percebi que alguma coisa não batia certo.
Os números de grupos pareciam saudáveis. Mas o comportamento das reservas não condizia com o que conhecia do dia a dia: antecedências estranhas, tarifas que não faziam sentido para o segmento em que estavam e um pickup - a evolução das reservas num determinado período - que não contava a história real.
Quando fui investigar, encontrei o problema: centenas de room nights - dormidas em quartos - estavam classificadas no segmento errado, entre Séries e Grupos Pontuais.
O problema que os relatórios não mostram
Quem trabalha com um PMS, o sistema de gestão do hotel, conhece este cenário. A classificação de segmentos pode depender de campos preenchidos à mão, de códigos de mercado herdados, de regras que mudaram ao longo do tempo e de equipas que registam reservas de formas diferentes. A informação entra no sistema e os relatórios continuam a parecer coerentes.
Mas uma Série - grupos recorrentes, com contrato e previsibilidade - e um Grupo Pontual - um evento único, mais volátil - são realidades comerciais distintas. Podem ter antecedência, sensibilidade ao preço e valor estratégico diferentes. Misturá-los é como misturar dois idiomas na mesma frase: a mensagem até parece fazer sentido, mas deixa de traduzir a realidade.
Quando os números somam, mas a leitura falha
Com room nights no segmento errado, o mix de negócio engana, a previsão fica enviesada e o pricing pode reagir ao sinal errado. Parece que dependemos mais de um segmento do que dependemos na realidade. E comparar a evolução de um segmento consigo próprio perde valor se ele inclui reservas que não lhe pertencem.
O mais perigoso é que nada disto precisa de gerar um erro no sistema. Os números continuam a somar.
A tecnologia executou. O conhecimento do negócio definiu a lógica.
Eu não sou programador. Mas conheço o negócio, e foi isso que fez a diferença.
Nestes dois hotéis, sabia que o campo de canal era o mais fiável para identificar a origem real de cada reserva. Usei-o como âncora para reclassificar os dados, com a ajuda de ferramentas de IA e de Excel. Construí um processo que mapeia a forma como cada hotel regista a informação para uma estrutura consistente.
A tecnologia não decidiu a classificação. Executou à escala uma lógica definida a partir do conhecimento do negócio. Com os dados corrigidos, a leitura de mix e de pickup passou a bater certo com o que se vivia na operação.
Quatro aprendizagens que levo comigo
- Desconfia dos dados que “parecem normais”. A anomalia mais cara pode ser aquela que ninguém questiona.
- O conhecimento do negócio continua a ser a parte difícil. As ferramentas de hoje tornam a programação mais acessível, mas saber qual é a regra a aplicar exige contexto e experiência.
- Cada hotel tem a sua linguagem. Padronizar sem respeitar essa diferença pode criar um novo erro. O mapeamento tem de se adaptar ao hotel, e não o contrário.
- Começa pequeno e documenta. Um problema concreto, resolvido e explicado, vale mais do que um grande projeto de “transformação digital” que nunca sai do PowerPoint.
O Revenue Manager do futuro: um tradutor
Costuma dizer-se que o Revenue Manager do futuro será um cientista de dados. Acho que será também um tradutor: alguém que percebe o que o hotel vive no dia a dia e consegue traduzi-lo para dados - e depois traduzir os dados de volta em decisões.
Misturar idiomas pode distorcer a mensagem. Saber traduzir entre eles cria vantagem. Quem dominar essa tradução, com ou sem código, vai fazer a diferença.