Preu per dia o per ocupació? L’impacte de la connectivitat en la teva estratègia d’ingressos (Part 1)

En español, in English, en français, em português.

En la distribució hotelera, l’atenció sol recaure en l’estratègia de preus (“el què”), deixant en segon pla l’arquitectura de connectivitat (“el com”). Tanmateix, la capacitat de maximitzar ingressos depèn directament de la tecnologia que transporta aquests preus.

Tècnicament, existeixen dos estàndards per connectar l’ecosistema hoteler (RMS, PMS, Channel Manager i motor de reserves) amb els canals de venda: PDP (Per Day Pricing-Preu per dia) i OBP (Occupancy Based Pricing-Preu per ocupació). Cap model és intrínsecament superior; són dues vies distintes per assolir un mateix objectiu i amb implicacions operatives diferents.

PDP (Per Day Pricing): el model de preu basat en regles

Aquest model és l’estàndard històric de la indústria, dissenyat per optimitzar l’eficiència operativa i la transmissió de dades.

• Què és exactament? Es basa en un sistema de preu cap: existeix una tarifa principal (la base) i tots els altres preus per a les diferents ocupacions depenen d’ella. No són preus lliures, sinó que es calculen automàticament seguint al primer.
• Com sol funcionar? L’hotel envia un únic preu (sol ser el de l’habitació Doble) des del seu sistema (PMS o Channel Manager). A partir d’aquí, és el Channel Manager el que sol gestionar el càlcul: aplica una regla fixa (exemple: Base + 30€ o Base – 10%) per a generar automàticament els preus de la individual, la triple o els nens. En alguns casos, aquesta regla de càlcul pot estar fins i tot delegada en la pròpia extranet de la OTA.

Per comprendre la limitació del model PDP en referència a la temporalitat, és necessari observar com operen les grans plataformes.

1. Als Channel Managers: el model de preu per dia (PDP) se sol manejar de dues maneres:

• Gestió Manual: control total, però gestió lenta.

Tu decideixes el preu exacte per a cada ocupació (individual, doble, triple). És molt precís, però si canvies el preu principal, els altres no s’actualitzen sols, la qual cosa genera molt més treball.

• Gestió Derivada: rapidesa, però menys flexibilitat.

És l’opció més comuna perquè funciona de manera automàtica. Tu defineixes un preu base i el sistema calcula la resta seguint una regla fixa (per exemple: “sumar 30€” o “afegir un 10%”). El problema és que, a l’ésser una regla rígida, no s’adapta bé als canvis de demanda de cada temporada.

2. I com fan les OTA? En la majoria, la configuració estàndard està dissenyada sota una regla de preu fixa (suplement o descompte) que no varia automàticament amb la demanda estacional. Les OTA que admeten suplements estacionals solen requerir una gestió manual constant que incrementa la càrrega de treball operativa.

Aquest és un exemple de la configuració de variacions per ocupació en l’extranet d’una OTA. El canal permet establir una ocupació base i una reducció fixa per a les ocupacions que estan per sota de l’ocupació base.

Encara que existeixen els overrides (la capacitat de sobreescriure manualment un preu derivat per a una data concreta), tant en els Channel Managers com en les OTA, aquests no solucionen el problema estructural. Funcionen com un pegat per a excepcions puntuals, però dependre d’ells per a una estratègia de revenue dinàmica obligaria a una vigilància constant, caient de nou en l’obligació d’estar pendent permanentment, una cosa impossible de gestionar a mà.

• On es decideix el càlcul? Aquí rau la clau. Encara que el preu base neix al PMS o al Channel Manager, la regla de càlcul sol delegar-se al Channel Manager o, depenent del flux, al propi canal o motor de reservas. Si queda “segrestat” per les regles de la pròpia extranet de l’OTA, limita el control real de l’hoteler sobre el seu propi preu final.

Els RMS més avançats estan dissenyats per calcular preus per ocupació (OBP) de forma independent, però sovint es veuen forçats a exportar en format PDP per limitacions de l’ecosistema (PMS o Channel Manager). En definitiva: la teva estratègia de revenue sempre estarà limitada per l’enllaç més feble de la teva cadena de connectivitat.

• El gran avantatge de les tarifes derivades és l’eficiència: gestiones un únic preu i la resta s’actualitza automàticament en cascada. No obstant això, l’error comú és intentar “forçar” el model: si acabes creant tantes tarifes i règims com a ocupacions existeixen, destrueixes aquesta eficiència i acabes amb un sistema ingovernable, però amb la mateixa rigidesa de sempre.
• Quines són les seves limitacions?

Mapatge en la baixada de reserves. En delegar el càlcul del preu al canal o al Channel Manager, el “viatge de tornada” de la reserva és més complex.

L’efecte cadena i la seva mala notícia: en moure el preu base, arrossegues a tots els altres sense voler. Com aquestes regles solen ser fixes (per exemple, el mateix suplement de 30€ per a tot l’any), no pots adaptar-te a la demanda real de cada temporada. Si vols pujar la triple, estàs obligat a pujar també la doble.

OBP (Occupancy Based Pricing): un preu independent per a cada ocupació

Aquest model representa l’evolució cap a la granularitat de la dada, tractant cada ocupació com un producte independent.

• Què representa aquest model? Trenca la jerarquia de preus derivats. Cada ocupació té un preu final propi, únic i desvinculat de les altres.
• Com funciona aquest model? El sistema no envia instruccions de càlcul (“Base + 40€”), sinó dades absolutes: “Individual: 90€”, “Doble: 100€”, “Triple: 130€”.

• Qui té el control del preu final?: resideix en el sistema que genera el preu (RMS, Channel Manager o PMS avançat), i es transporta de forma explícita. No obstant això, sovint aquests preus neixen de càlculs lineals en origen.

Tanmateix, existeix una diferència crucial en la capacitat d’intervenció del canal:

• En el model OBP, les grans plataformes (OTA) es limiten a mostrar el preu exacte que els envies, sense fer càlculs pel seu compte. Això garanteix que el client vegi exactament el que tu has decidit en el teu sistema.
• El motor de reserves com a última paraula: un motor de reserves avançat permet intervenir. Pot actuar sobreescrivint la lògica d’ocupació rebuda, reemplaçant els increments lineals del PMS o el Channel Manager per adequar-se a les corbes dinàmiques de demanda.

El repte de l’RMS: els RMS poden calcular i enviar tots aquests preus finals, però precisen d’un mapatge exhaustiu de totes les ocupacions perquè l’estratègia s’executi correctament.

• Quins avantatges té aquest model? Control i granularitat. Permet definir estratègies específiques per a cada ocupació (elasticitat independent) abans de la distribució.
• Quina és la principal limitació? Densitat de dades i mapatge. Exigeix una tecnologia capaç de processar un volum d’informació molt major, ja que cada ocupació requereix el seu propi identificador únic (Rate ID). És com passar de gestionar una sola clau per a una habitació a gestionar una clau distinta per a cada persona que hi entra. Si el canal no és OBP natiu, això obliga a crear “tarifes mirall” que poden saturar la gestió de l’inventari.

Quant treball extra suposa cada model?

La diferència rau en el volum de dades a supervisar:

• En PDP (Gestió per excepció) i utilitzant tarifes derivades: es supervisen 10 preus base (per a un hotel de 10 tipologies). Les variacions s’apliquen soles.
• En OBP (Gestió per producte): es supervisen 10 habitacions x 4 ocupacions = 40 preus finals independents.

El efecte multiplicador: aquest nombre pot créixer de forma combinatòria en creuar-lo amb els diferents règims (Només Allotjament, Esmorzar inclòs, Mitja Pensió) i polítiques de cancel·lació (Flexible, No Reemborsable).

La balança de l’operativa

Escenari: hotel de 10 tipologies x 4 ocupacions x 2 règims x 2 pol·lítiques de cancelació:

El risc de la falsa agilitat

Sense automatització, la granularitat del OBP es converteix en una vulnerabilitat operativa. La probabilitat d’error humà fa que el control manual sigui inviable.

Molts hotels intenten “escapar” de la rigidesa del PDP creant desenes de tarifes independents en el seu PMS. El resultat és el pitjor dels mons:

• Perden l’agilitat del PDP (ja no s’actualitza en cascada).
• No guanyen la intel·ligència del OBP (segueixen sense visió per ocupació).
• Hipertròfia d’inventari: centenars de tarifes que mapear i supervisar una a una.

Quadre comparatiu d’arquitectures

Què canvia?	PDP (Preu per dia)	OBP (Preu per ocupació)
Enfocament	Gestió d’habitacions: l’ocupació és un atribut secundari.	Gestió de productes: cada combinació és un ítem únic.
Lògica de preus	Derivada: tarifa base + regles fixes.	Explícita: preus finals exactes.
Revenue Management	Vinculat: modificar la base altera totes les ocupacions.	Independent: optimització elàstica per ocupació.
Manteniment	Supervisió de regles: requereix vigilar el càlcul.	Gestió massiva de preus finals.
Connectivitat	Agregació de tarifes: simplifica l’inventari, però limita la diferenciació.	Nativa: connexió directa de l’inventari real.
Consistència	Interpretativa: risc de disparitat per càlcul extern al canal.	Exacta: el canal mostra la dada particular.
Perfil d’ús	Hotels que prioritzen l’agilitat de càrrega i manteniment automatitzat.	Hotels amb inventaris complexos o estratègies de revenue granulars.

Per què el model tradicional continua sent el més usat?

Encara que el sistema per ocupació (OBP) és més exacte, el model de preu per dia (PDP) continua sent el més comú per pura practicitat:

• Costum i estabilitat: durant anys, es va preferir que la connexió fora ràpida i no donés errors abans que entrar en els detalls de cada preu.
• Disseny dels canals: les grans plataformes (com Booking o Expedia) estan fetes perquè aquest model funcioni bé. Per a la majoria d’hotels, és una solució robusta i fàcil de manejar, mentre que el model per ocupació queda com el següent pas per als qui busquen una precisió total.

Exemple real: els diners que deixes de guanyar per una tecnologia rígida

Supòsit: habitació Doble a 300 € en temporada alta.

• Escenari A: model PDP (regla estàtica). El suplement de 3a persona és fix al Motor/Canal (+ 30 €).

– Preu Final Triple: 330 €

– Conseqüència: per pujar la Triple, pujaries la Doble i perdries competitivitat. O pitjor: et veuries obligat a tancar la venda de l’habitació triple per no malvendre, perdent ocupació total simplement per la rigidesa del sistema.

• Escenari B: model OBP (Estratègia dinàmica). Es detecta alta demanda familiar. Es fixa la Triple en 375 €, mantenint la Doble intacta.

– Preu Final Triple: 375 €

– Conseqüència: Es captura un valor addicional de 45 € per habitació/nit.

Projecció financera: 

Assumint una ocupació mitjana del 100% i extrapolant aquesta diferència a un inventari de 20 habitacions durant 60 dies de temporada alta, el diferencial d’ingressos bruts puja a 54.000 €. En el model PDP, aquest ingrés no es captura a causa de la limitació de la regla general; en OBP, és el resultat directe d’una decisió de tarificació puntual. I més important, en PDP, en pujar el preu de la triple, pot ser que et “surtis de mercat” en la doble (que és la que se sol vendre més). 

I això només és en una tipologia, el marge és exponencial si es tenen en compte la resta d’ocupacions, règims, tarifes…

L’equilibri entre arquitectura i estratègia

Al final, l’elecció entre PDP i OBP no és una qüestió de quina és millor tecnologia, sinó de quin nivell de granularitat pot absorbir l’operativa de l’hotel sense perdre el control. Mentre el PDP ofereix un entorn de gestió simplificada i àgil, l’OBP obre la porta a una segmentació precisa per ocupació.

La pregunta clau per a l’hoteler avui no és només quina triar, sinó com superar la barrera tècnica que els separa: És possible assolir la precisió d’ingressos de l’OBP amb l’agilitat operativa del PDP? Podem automatitzar la complexitat perquè deixi de ser un fre?

En la segona part, analitzarem com està evolucionant la connectivitat per integrar ambdues filosofies i eliminar la fricció entre la càrrega de dades i l’estratègia de revenue.