In English, en español, en français.
Na distribuição hoteleira, a atenção costuma recair sobre a estratégia de preços (“o quê”), deixando em segundo plano a arquitetura de conectividade (“o como”). No entanto, a capacidade de maximizar receitas depende diretamente da tecnologia que transporta esses preços.
Tecnicamente, existem dois padrões para conectar o ecossistema hoteleiro (RMS, PMS, Channel Manager e motor de reservas) aos canais de venda: PDP (Per Day Pricing-Preço por dia) e OBP (Occupancy Based Pricing- Preço por ocupação). Nenhum modelo é intrinsecamente superior; são duas vias distintas para alcançar um mesmo objetivo e com implicações operativas diferentes.
PDP (Per Day Pricing): o modelo de preço baseado em regras
Este modelo é o padrão histórico da indústria, desenhado para otimizar a eficiência operativa e a transmissão de dados.
- O que é exactamente? Baseia-se num sistema de “preço mestre”: existe uma tarifa principal (a base) e todos os outros preços para as diferentes ocupações dependem dela. Não são preços livres, mas sim calculados automaticamente seguindo o primeiro.
- Como costuma funcionar? O hotel envia um preço único (geralmente o do quarto Duplo) a partir do seu sistema (PMS ou Channel Manager). A partir daí, é o Channel Manager que costuma gerir o cálculo: aplica uma regra fixa (exemplo: Base + 30€ ou Base – 10%) para gerar automaticamente os preços do individual, do triplo ou das crianças. Em alguns casos, esta regra de cálculo pode estar inclusive delegada na própria extranet da OTA.
Para compreender a limitação do modelo PDP em relação à sazonalidade, é necessário observar como operam as grandes plataformas.
- Nos Channel Managers: o modelo de preço por dia (PDP) costuma ser gerido de duas formas:
– Gestão Manual. controlo total, mas gestão lenta.

Você decide o preço exato para cada ocupação (individual, duplo, triplo). É muito preciso, mas se alterar o preço principal, os outros não se atualizam sozinhos, o que gera muito mais trabalho.
– Gestão Derivada:: rapidez, mas menos flexibilidade.

É a opção mais comum porque funciona de forma automática. Define um preço base e o sistema calcula o resto seguindo uma regra fixa (por exemplo: “somar 30€” ou “adicionar 10%”). O problema é que, por ser uma regra rígida, não se adapta bem às mudanças de procura de cada época.
- E como fazem as OTAs? Na maioria, a configuração padrão é desenhada sob uma regra de preço fixa (suplemento ou desconto) que não varia automaticamente com a procura sazonal. As OTAs que admitem suplementos sazonais costumam exigir uma gestão manual constante que aumenta a carga de trabalho operativa.

Este é um exemplo da configuração de variações por ocupação na extranet de uma OTA. O canal permite estabelecer uma ocupação base e uma redução fixa para as ocupações que estão abaixo da ocupação base.
Embora existam os overrides (a capacidade de substituir manualmente um preço derivado para uma data específica), tanto nos Channel Managers como nas OTAs, estes não resolvem o problema estrutural. Funcionam como um remendo para exceções pontuais, mas depender deles para uma estratégia de revenue dinâmica exigiria uma vigilância constante, caindo novamente na obrigação de estar permanentemente atento, algo impossível de gerir à mão.
- Onde se decide o cálculo? Aqui reside a chave. Embora o preço base nasça no PMS ou no Channel Manager, a regra de cálculo costuma ser delegada ao Channel Manager ou, dependendo do fluxo, ao próprio canal ou motor de reservas. Se ficar “sequestrado” pelas regras da própria extranet da OTA, limita o controle real do hoteleiro sobre o seu próprio preço final.
Os RMS mais avançados são desenhados para calcular preços por ocupação (OBP) de forma independente, mas muitas vezes são forçados a exportar em formato PDP por limitações do ecossistema (PMS ou Channel Manager). Em suma: a sua estratégia de revenue estará sempre limitada pelo elo mais fraco da sua cadeia de conectividade.
- A grande vantagem das tarifas derivadas é a eficiência: gere um único preço e o resto atualiza-se automaticamente em cascata. No entanto, o erro comum é tentar “forçar” o modelo: se acabar por criar tantas tarifas e regimes como ocupações existentes, destrói essa eficiência e termina com um sistema ingovernável, mas com a mesma rigidez de sempre.
- Quais são as suas limitações?
Mapeamento na descida de reservas. Ao delegar o cálculo do preço ao canal ou ao Channel Manager, a “viagem de volta” da reserva é mais complexa.
O efeito cadeia e a sua má notícia: ao mover o preço base, arrasta todos os outros sem querer. Como estas regras costumam ser fixas (por exemplo, o mesmo suplemento de 30€ para todo o ano), não pode adaptar-se à procura real de cada época. Se quiser subir o triplo, é obrigado a subir também o duplo.

OBP (Occupancy Based Pricing): um preço independente para cada ocupação
Este modelo representa a evolução para a granularidade do dado, tratando cada ocupação como um produto independente.
- O que representa este modelo? Quebra a hierarquia de preços derivados. Cada ocupação tem um preço final próprio, único e desvinculado das outras.
- Como funciona este modelo? O sistema não envia instruções de cálculo (“Base + 40€”), mas sim dados absolutos: “Individual: 90€”, “Dupla: 100€”, “Tripla: 130€”.

- Quem tem o controlo do preço final? Reside no sistema que gera o preço (RMS, Channel Manager ou PMS avançado), e é transportada de forma explícita. No entanto, muitas vezes estes preços nascem de cálculos lineares na origem.
No entanto, existe uma diferença crucial na capacidade de intervenção do canal:
- No modelo OBP, as grandes plataformas (OTAs) limitam-se a mostrar o preço exato que lhes envia, sem fazer cálculos por conta própria. Isto garante que o cliente veja exatamente o que você decidiu no seu sistema.
- O motor de reservas como última palavra: um motor de reservas avançado permite intervir. Pode atuar substituindo a lógica de ocupação recebida, substituindo os incrementos lineares do PMS ou do Channel Manager para se adequar às curvas dinâmicas de procura.
O desafio do RMS: os RMS podem calcular e enviar todos estes preços finais, mas precisam de um mapeamento exaustivo de todas as ocupações para que a estratégia seja executada corretamente.
- Que vantagens tem este modelo? Controlo e granularidade. Permite definir estratégias específicas para cada ocupação (elasticidade independente) antes da distribuição.
- Qual é a principal limitação? Densidade de dados e mapeamento (mapping). Exige uma tecnologia capaz de processar um volume de informação muito maior, já que cada ocupação requer o seu próprio identificador único (Rate ID). É como passar de gerir uma única chave para um quarto a gerir uma chave diferente para cada pessoa que entra. Se o canal não for OBP nativo, isto obriga a criar “tarifas espelho” que podem saturar a gestão do inventário.

Quanto trabalho extra supõe cada modelo?
A diferença reside no volume de dados a supervisionar:
- Em PDP (Gestão por exceção) e utilizando tarifas derivadas: supervisionam-se 10 preços base (para um hotel de 10 tipologias). As variações aplicam-se sozinhas.
- En OBP (Gestão por produto): supervisionam-se 10 quartos x 4 ocupações = 40 preços finais independentes.
O efeito multiplicador: este número pode crescer de forma combinatória ao cruzá-lo com os diferentes regimes (Só Alojamento, Pequeno-almoço incluído, Meia Pensão) e políticas de cancelamento (Flexível, Não Reembolsável).
A balança da operativa
Cenário: hotel de 10 tipologias x 4 ocupações x 2 regimes x 2 políticas de cancelamento:
| Modelo PDP (eficiência) | Modelo OBP (controlo) |
| 10 preços base. | 160 preços independentes. |
| Atualiza o “Preço Base” e o sistema faz o resto. | Cada combinação requer um preço específico. |
| Vantagem: rapidez extrema, mapeamento simples e controlo total do “preço mãe”. | Pontos fortes: máxima rentabilidade por ocupação e flexibilidade total segundo a procura. |
| O custo: rigidez. Se quiser mudar o suplemento de uma criança apenas para agosto, não pode. | O custo: carga de trabalho massiva. O risco de erro humano multiplica-se por 16. |
O risco da falsa agilidade
Sem automatização, a granularidade do OBP torna-se uma vulnerabilidade operativa. A probabilidade de erro humano torna o controlo manual inviável.
Muitos hotéis tentam “escapar” da rigidez do PDP criando dezenas de tarifas independentes no seu PMS. O resultado é o pior dos dois mundos:
- Perdem a agilidade do PDP (já não se atualiza em cascata).
- Não ganham a inteligência do OBP (continuam sem visão por ocupação).
- Hipertrofia de inventário: centenas de tarifas para mapear e supervisionar uma a uma.
Quadro comparativo de arquiteturas
| O que muda? | PDP (Preço por dia) | OBP (Preço por ocupação) |
| Abordagem | Gestão de quartos: a ocupação é um atributo secundário. | Gestão de produtos: cada combinação é um item único. |
| Lógica de preços | Derivada: tarifa base + regras fixas. | Explícita: preços finais exatos. |
| Revenue Management | Vinculado: modificar a base altera todas as ocupações. | Independente: otimização elástica por ocupação. |
| Manutenção | Supervisão de regras: exige vigiar o cálculo. | Gestão massiva de preços finais. |
| Conectividade | Agregação de tarifas: simplifica o inventário, mas limita a diferenciação. | Nativa: conexão direta do inventário real. |
| Consistência | Interpretativa: risco de disparidade por cálculo externo no canal. | Exata: o canal mostra o dado particular. |
| Perfil de uso | Hotéis que priorizam a agilidade de carga e manutenção automatizada. | Hotéis com inventários complexos ou estratégias de revenue granulares. |
Porque é que o modelo tradicional continua a ser o mais usado?
Embora o sistema por ocupação (OBP) seja mais exato, o modelo de preço por dia (PDP) continua a ser o mais comum por pura praticidade:
- Costume e estabilidade: durante anos, preferiu-se que a ligação fosse rápida e não desse erros antes de entrar em detalhes de cada preço.
- Desenho dos canais: as grandes plataformas (como Booking ou Expedia) estão feitas para que este modelo funcione bem. Para a maioria dos hotéis, é uma solução robusta e fácil de gerir, enquanto o modelo por ocupação fica como o passo seguinte para quem procura uma precisão total.
Exemplo real: o dinheiro que deixa de ganhar por uma tecnologia rígida
Suposto: Quarto Duplo a 300 € em época alta
- Cenário A: modelo PDP (regra estática) O suplemento de 3ª pessoa é fixo no Motor/Canal (+ 30 €).
– Preço Final Triplo: 330 €
– Consequência: para subir a Tripla, você subiria a Dupla e perderia competitividade. Ou pior: você ver-se-ia obrigado a fechar a venda do quarto triplo para não vender abaixo do valor, perdendo ocupação total simplesmente pela rigidez do sistema.
- Cenário B: modelo OBP (Estratégia dinâmica) Deteta-se alta procura familiar. Fixa-se a Tripla em 375 €, mantendo a Dupla intacta.
– Preço Final Triplo: 375 €
– Consequência: Captura-se um valor adicional de 45 € por quarto/noite.
Projeção financeira:
Assumindo uma ocupação média de 100% e extrapolando esta diferença para um inventário de 20 quartos durante 60 dias de época alta, o diferencial de receitas brutas ascende a 54.000 €. No modelo PDP, esta receita não é capturada devido à limitação da regra geral; em OBP, é o resultado direto de uma decisão de tarifação pontual. E mais importante, em PDP, ao subir o preço da tripla, pode ser que você “saia do mercado” na dupla (que é a que costuma vender mais).
E isto é apenas numa tipologia, a margem é exponencial se tivermos em conta as restantes ocupações, regimes, tarifas…

O equilíbrio entre arquitetura e estratégia
No final, a escolha entre PDP e OBP não é uma questão de qual é a melhor tecnologia, mas de que nível de granularidade a operação do hotel pode absorver sem perder o controle. Enquanto o PDP oferece um ambiente de gestão simplificada e ágil, o OBP abre a porta a uma segmentação precisa por ocupação.
A pergunta-chave para o hoteleiro hoje não é apenas qual escolher, mas como superar a barreira técnica que os separa: É possível alcançar a precisão de receitas do OBP com a agilidade operativa do PDP? Podemos automatizar a complexidade para que deixe de ser um travão?
Na segunda parte, analisaremos como está a evoluir a conectividade para integrar ambas as filosofias e eliminar a fricção entre a carga de dados e a estratégia de revenue.


