SETORIAL — HOTELARIA

Revenue Management além de ocupação soa bem. Mas o que o artigo não conta?

Todo texto sobre Revenue Management começa do mesmo lugar: “hotéis que otimizam ocupação estão errando a métrica.” É uma afirmação sedutora. E, como a maioria das afirmações sedutoras, é verdadeira em partes — e incompleta nas partes que importam para quem realmente opera um hotel.

Tempo de leitura: 12 min

O argumento que parece óbvio — e por que não é

O exemplo clássico aparece em qualquer apresentação de Revenue Management: 90% de ocupação com tarifa de R$ 180 versus 75% de ocupação com tarifa de R$ 260. O segundo cenário gera mais receita. Conclusão: otimizar tarifa é melhor do que otimizar ocupação.

Isso é matematicamente correto. Mas matematicamente correto não é a mesma coisa que operacionalmente realizável — e é aqui que a maioria dos argumentos de Revenue Management para de andar.

O cenário de 75% de ocupação com R$ 260 de tarifa parte de um pressuposto que raramente é testado: que há demanda suficiente para pagar R$ 260 naquele mercado específico, que o posicionamento e a reputação online do hotel suportam essa tarifa, e que os 25% de quartos vazios são uma escolha — não o resultado de uma tarifa que simplesmente afastou o hóspede.

Quando nenhuma dessas condições é testada, o argumento é uma equação financeira sem fricção com a realidade operacional. E o Revenue Manager que tentou vender R$ 260 em um mercado com teto de R$ 200 sabe exatamente o que acontece: acaba com 55% de ocupação e R$ 143 de RevPAR — pior do que os dois cenários do exemplo.

RevPAR não é a métrica perfeita que parece

O artigo afirma que RevPAR “é a mais difícil de manipular.” Isso é parcialmente verdade. Mas dizer que uma métrica é difícil de manipular não é o mesmo que dizer que ela mede o que você quer medir.

RevPAR mede receita de hospedagem por apartamento disponível. Não inclui custo nenhum. Dois hotéis com RevPAR idêntico de R$ 180 podem ter resultados operacionais completamente diferentes se um deles tem custo por apartamento ocupado de R$ 95 e o outro tem custo de R$ 145. O RevPAR não separa esses dois casos.

O artigo menciona GOPPAR — lucro operacional bruto por apartamento disponível — como métrica superior, e tem razão. Mas o GOPPAR aparece na tabela de métricas e depois some da discussão. Toda a análise quantitativa do artigo usa RevPAR. A tabela que compara cenários de “melhora de 10%” usa RevPAR. O argumento de que “melhora via ADR vai diretamente para a margem” usa RevPAR como proxy de margem — o que só é verdade se os custos variáveis por hóspede forem suficientemente baixos para justificar a premissa.

Isso importa porque a decisão entre ocupação alta e tarifa alta não é só uma questão de receita — é uma questão de estrutura de custo. Um hotel resort com pacote tudo-incluído tem uma estrutura de custo variável por hóspede completamente diferente de um hotel business urbano de serviço limitado. A lógica de que “tarifa alta com ocupação moderada tem margem melhor” se aplica ao segundo e pode não se aplicar ao primeiro.

O custo que o RevPAR ignora: a fidelização

Há um custo que o RevPAR não captura nem de longe: o custo de aquisição do próximo hóspede. Hotéis que priorizam tarifa sobre ocupação em períodos de demanda moderada frequentemente recorrem a OTAs para preencher os quartos restantes — com comissões de 15% a 25%. O RevPAR sobe. A margem real, depois da comissão, pode cair.

Pior: um hotel que vendeu a tarifa mais alta ao hóspede errado — aquele cuja experiência não justificava a tarifa — vai receber uma avaliação negativa no Booking ou no TripAdvisor que vai comprimir o ADR pelos próximos meses. O RevPAR do mês parece ótimo. O RevPAR do trimestre é o preço da decisão.

Pickup funciona — quando você tem histórico para comparar

A seção sobre pickup é tecnicamente correta. Monitorar a velocidade de acumulação de reservas e comparar com o padrão histórico de datas similares é, de fato, uma das ferramentas mais úteis do Revenue Management. O problema está na frase que aparece de forma discreta: “comparar com histórico de datas similares.”

Datas similares do ano anterior. Em 2024 versus 2023. Em 2023 versus 2022. Em 2022 versus 2021 — quando metade das propriedades estava operando com restrições de capacidade por protocolos sanitários. Em 2021 versus 2020, quando muitos hotéis estavam fechados.

O pickup é tão bom quanto o histórico com o qual é comparado. Para hotéis com menos de três a quatro anos de operação estável, o histórico de pickup por data é ruidoso o suficiente para gerar mais confusão do que clareza. Para propriedades em mercados com alta volatilidade — cidades com calendário de eventos irregulares, destinos de negócios com projetos sazonais, regiões afetadas por fatores externos como câmbio e conectividade aérea — a linha de base histórica pode ser uma referência enganosa.

Um Revenue Manager que viu o pickup de um fim de semana específico aparentemente fraco — abaixo do histórico do ano anterior — e baixou a tarifa, sem saber que o evento que gerou demanda no ano anterior não se repetiria naquele ano, fez uma análise de pickup correta. Chegou à conclusão errada porque a premissa de comparabilidade não se sustentava.

Pickup também pode criar armadilha de tarifa

Há um fenômeno menos discutido sobre pickup que qualquer Revenue Manager experiente já viveu: a armadilha da demanda canibalizada.

O pickup está forte para uma data específica. O Revenue Manager aumenta a tarifa. As reservas continuam chegando — mas são reservas de hóspedes que teriam comprado de qualquer forma, só que agora pagam mais. As reservas incrementais — aquelas que só existiriam a uma tarifa menor — pararam de chegar porque a tarifa subiu além do que esse segmento aceita. O resultado: ocupação levemente menor, ADR maior, RevPAR marginalmente superior.

O problema é que o Revenue Manager não tem como saber, em tempo real, se o pickup que parou de crescer após o aumento de tarifa indica que a demanda foi captada — ou que foi afastada. Essa distinção exigiria um experimento controlado que nenhum hotel consegue rodar sem comprometer receita real.

Segmentação: certa na teoria, difícil na prática brasileira

A tabela de segmentação do artigo original é correta: corporativo transiente reserva tarde e paga mais; lazer individual reserva com antecedência e é sensível a preço; grupos fecham com meses de antecedência. Nada de novo para quem trabalha com Revenue Management há mais de dois anos.

O que a tabela não mostra é a dificuldade de implementar essa segmentação em operações reais — especialmente no mercado hoteleiro brasileiro, onde particularidades locais complicam a aplicação direta de frameworks desenvolvidos no mercado norte-americano ou europeu.

Comece pelo corporativo. No Brasil, o hóspede corporativo paga mais — mas quase sempre negocia tarifa anual em contrato com benefícios embutidos: café da manhã, estacionamento, early check-in. A tarifa bruta parece alta. A tarifa líquida, depois dos custos desses benefícios, é outra conversa. O ADR que aparece no relatório não é o ADR que chega no caixa.

Depois considere o booking window. O viajante brasileiro de lazer reserva com antecedência menor do que os modelos clássicos de Revenue Management assumem — e isso não é detalhe. Comprime a janela de intervenção tarifária e reduz o benefício prático de análises de pickup de 60 a 90 dias, que foram desenhadas para mercados onde a decisão de viagem acontece com mais tempo.

E a sensibilidade a preço. A penetração de OTAs com cultura de comparação é profunda. O hóspede de lazer que encontra tarifa R$ 30 mais baixa numa propriedade razoavelmente equivalente a 800 metros troca. A fidelização de marca que justifica parte do pricing premium em mercados como o norte-americano ou o europeu ainda está sendo construída aqui.

Variáveis exógenas: o problema não é identificá-las

A seção sobre variáveis exógenas no artigo original lista fontes úteis: calendário de eventos, feriados, comportamento de concorrentes, dados climáticos. Tudo certo. O problema é que o artigo trata a identificação dessas variáveis como o desafio principal — quando na prática, o desafio é quantificá-las.

Saber que há um congresso de 3.000 pessoas a 400 metros do hotel é fácil. A pergunta que o Revenue Manager precisa responder é: quantos desses 3.000 participantes vão buscar hospedagem no meu hotel, em qual mix de categorias, com qual antecedência e a qual elasticidade de tarifa? Essa pergunta é fundamentalmente diferente de “há um evento na cidade”.

Eventos diferentes geram impactos completamente distintos no mesmo destino. Um congresso médico de 3.000 pessoas com perfil corporativo, cobrindo dois dias de semana, gera um padrão de demanda. Um show de música com 3.000 pessoas num sábado gera outro. Uma maratona com 3.000 corredores num domingo de manhã gera um terceiro — inclusive com comportamento de check-out antecipado que afeta a rotatividade do dia. O calendário de eventos diz que há 3.000 pessoas. Não diz qual é o impacto real no hotel.

Isso não invalida o argumento de que variáveis exógenas devem ser incorporadas ao processo de Revenue Management. Invalida a ideia de que a incorporação é mais simples do que é. Ela exige calibração histórica — correlacionar eventos passados com seus impactos reais na demanda do hotel, para que eventos futuros similares possam ser estimados com alguma precisão. Sem esse histórico calibrado, a incorporação de variáveis exógenas é mais ruído do que sinal.

O problema de escala que o artigo silencia

O artigo menciona que um hotel de 150 apartamentos com múltiplas categorias e seis canais de distribuição precisa tomar decisões para 2.160 combinações de categoria × canal × data — todos os dias. Isso é verdade. E a conclusão do artigo é que sistemas de Revenue Management automatizam esse processo.

Verdade também. Mas há uma premissa silenciosa nessa conclusão: que o hotel tem os dados estruturados necessários para alimentar esses sistemas com qualidade suficiente para gerar recomendações confiáveis.

No mercado hoteleiro brasileiro, especialmente em propriedades independentes e redes regionais menores, a realidade dos dados é frequentemente assim: histórico de reservas em PMS com qualidade variável de preenchimento de campos, integração parcial entre PMS e channel manager, dados de segmentação de hóspede incompletos ou ausentes, e histórico de tarifas praticadas misturado com tarifas publicadas que não foram vendidas.

Um sistema de Revenue Management alimentado com esses dados não produz recomendações melhores do que um Revenue Manager experiente com um bom relatório de pickup manual. Às vezes produz recomendações piores — porque o algoritmo não sabe distinguir dado confiável de dado ruidoso da mesma forma que uma pessoa com contexto consegue.

Premissa do artigo original	A realidade que complica
Demanda suficiente para suportar tarifa alta existe no mercado	Depende do posicionamento, reputação e teto de tarifa do mercado local — não é uma variável controlável pelo RM
RevPAR é difícil de manipular e captura resultado real	RevPAR não inclui custo; dois hotéis com mesmo RevPAR podem ter resultados operacionais opostos
Pickup é comparável com histórico de datas similares	Requer histórico estável de pelo menos 3 anos; mercados voláteis ou hotéis jovens têm base de comparação enganosa
Segmentação por booking window e sensibilidade a preço é direta	O mercado brasileiro tem booking window mais curto e sensibilidade a preço mais alta do que os modelos clássicos de RM assumem
Variáveis exógenas incorporadas ao modelo melhoram a previsão	Sem calibração histórica por tipo de evento, a incorporação adiciona ruído antes de adicionar sinal
Sistemas de RM automatizam bem o processo em escala	Dados mal estruturados nos PMS brasileiros comprometem a qualidade das recomendações automáticas

Os números de 8% a 18% de melhora de RevPAR

O artigo afirma que “Revenue Management maduro consegue melhoras de RevPAR de 8% a 18% no primeiro ano para propriedades que estavam operando de forma intuitiva.” Pode ser verdade. Mas há algumas perguntas que esse número deixa sem resposta.

Melhora em relação a qual baseline? Se o hotel estava precificando sistematicamente abaixo do mercado — com tarifa rack absurdamente baixa por conservadorismo ou por falta de acompanhamento de concorrentes — qualquer ajuste para o nível de mercado vai gerar melhora expressiva de RevPAR. Isso não é Revenue Management sofisticado. É correção de precificação básica.

A melhora de RevPAR em propriedades que já tinham algum nível de Revenue Management estruturado — por menor que fosse — é materialmente diferente. Hotéis que já monitoravam pickup, já usavam alguma forma de pricing dinâmico por antecedência, já segmentavam minimamente corporativo de lazer, têm ganhos marginais menores e mais difíceis de atribuir exclusivamente ao sistema de RM.

O range de 8% a 18% também não diz nada sobre a distribuição dos resultados. Quantas propriedades ficaram abaixo de 8%? Quantas tiveram RevPAR igual ou pior depois da implementação — porque a tentativa de subir tarifa resultou em ocupação menor do que o previsto, sem compensação suficiente no ADR? Qualquer range de resultado sem distribuição é uma média sem contexto.

O que o cético não está dizendo

Vale ser honesto sobre até onde vai essa crítica.

Ocupação como única métrica de sucesso é, de fato, insuficiente. Isso não é controverso. Um hotel que nunca verificou se poderia vender a tarifa mais alta sem perder ocupação está deixando dinheiro na mesa — a questão é quanto dinheiro, em quais condições e com qual esforço de implementação.

RevPAR é uma métrica melhor do que taxa de ocupação isolada. Isso também não é controverso. O argumento não é que RevPAR é inútil — é que RevPAR sozinho é insuficiente, e que o artigo original usa RevPAR como proxy de resultado enquanto nomeia GOPPAR como métrica superior e depois o abandona na análise.

Pickup é uma ferramenta genuinamente útil. O argumento não é que pickup não funciona — é que funciona melhor quando o histórico de comparação é confiável, e que a interpretação do sinal de pickup requer contexto que o dado bruto não fornece.

O que o cético está dizendo, no fundo: Revenue Management bem executado é mais difícil do que qualquer artigo de 3.000 palavras consegue capturar — incluindo este. Os frameworks de referência foram construídos em mercados com características distintas do hoteleiro brasileiro. Os dados que essas abordagens assumem raramente estão disponíveis com a qualidade necessária. E o hotel que tenta implementar Revenue Management sofisticado sem antes resolver qualidade de dado, estrutura de distribuição e posicionamento de produto está construindo sobre areia.

Isso não é argumento contra Revenue Management. É argumento por honestidade sobre o ponto de partida.

Então, por onde começa?

Não com o sistema. Não com o modelo de pickup automatizado. Não com a integração de variáveis exógenas via scraping de eventos.

Começa com três perguntas que a maioria dos hotéis brasileiros não consegue responder com dados disponíveis em menos de uma hora:

Qual é o teto de tarifa real do meu mercado — não o que eu gostaria de cobrar, mas o que a demanda disponível no meu segmento aceita pagar, medido pelas reservas que eu perco quando aumento tarifa? Sem esse número, qualquer discussão sobre otimizar RevPAR via ADR é especulação.
Qual é o custo variável real por hóspede adicional na minha operação — incluindo café da manhã, amenities, energia, comissão de canal e custo de limpeza? Sem esse número, a comparação entre RevPAR de 90% de ocupação e 75% de ocupação não pode ser convertida em comparação de margem.
Os dados de reserva no meu PMS estão estruturados de forma que eu consiga calcular pickup histórico por data, por segmento e por categoria de quarto com confiabilidade? Se não estão, o Revenue Management que vou fazer é manual e baseado em intuição — o que pode ser razoável, dependendo do tamanho e da complexidade da propriedade.

Revenue Management sofisticado é real, funciona e gera resultado. Só não funciona da forma linear e garantida que os argumentos de venda sugerem. A maioria das propriedades que implementaram Revenue Management com resultado expressivo fez isso de forma incremental — primeiro entendendo o mercado, depois estruturando os dados, depois testando ajustes tarifários com hipóteses claras, e só então automatizando o que já estava funcionando manualmente.

O caminho contrário — comprar o sistema, esperar o resultado — costuma produzir uma implementação cara de uma ferramenta que ninguém usa com confiança porque ninguém entende por que ela recomenda o que recomenda.

Revenue Management funciona. A questão é se a sua operação tem as condições para fazê-lo funcionar — e qual é o próximo passo realista para construir essas condições.

O EpiphanyAI é a plataforma de IA Auditável da Direção e Sentido. Se você já tentou implementar Revenue Management e ficou com a sensação de que a ferramenta não entregou o que prometeu, vale entender por quê — antes de tentar de novo.

→ Fale com um especialista

Continue lendo:

Direção e Sentido Estratégia e Inovação — Mais de 20 anos transformando dados em decisões.

Revenue Management além de ocupação. O que o artigo não conta