¿Precio por día o por ocupación? El impacto de la conectividad en tu estrategia de ingresos (Parte 1)

In English, en català, en français, em português.

En la distribución hotelera, la atención suele recaer en la estrategia de precios (“el qué”), dejando en segundo plano la arquitectura de conectividad (“el cómo”). Sin embargo, la capacidad de maximizar ingresos depende directamente de la tecnología que transporta estos precios.

Técnicamente, existen dos estándares para conectar el ecosistema hotelero (RMS, PMS, Channel Manager y motor de reservas) con los canales de venta: PDP (Per Day Pricing-Precio por día) y OBP (Occupancy Based Pricing-Precio por ocupación). Ningún modelo es intrínsecamente superior; son dos vías distintas para lograr un mismo objetivo y con implicaciones operativas diferentes.

PDP (Per Day Pricing): el modelo de precio basado en reglas

Este modelo es el estándar histórico de la industria, diseñado para optimizar la eficiencia operativa y la transmisión de datos. 

• ¿Qué es exactamente? Se basa en un sistema de precio jefe: existe una tarifa principal (la base) y todos los demás precios para las diferentes ocupaciones dependen de ella. No son precios libres, sino que se calculan automáticamente siguiendo al primero.
• ¿Cómo suele funcionar? El hotel envía un único precio (suele ser el de la habitación Doble) desde su sistema (PMS o Channel Manager). A partir de ahí, es el Channel Manager el que suele gestionar el cálculo: aplica una regla fija (ejemplo: Base + 30€ o Base – 10%) para generar automáticamente los precios de la individual, la triple o los niños. En algunos casos, esta regla de cálculo puede estar incluso delegada en la propia extranet de la OTA.

Para comprender la limitación del modelo PDP en referencia a la temporalidad, es necesario observar cómo operan las grandes plataformas.

1. En los Channel Managers, el modelo de precio por día (PDP) se suele manejar de dos maneras:

• Gestión Manual: control total, pero gestión lenta.

Tú decides el precio exacto para cada ocupación (individual, doble, triple). Es muy preciso, pero si cambias el precio principal, los demás no se actualizan solos, lo que genera mucho más trabajo.

• Gestión Derivada: rapidez, pero menos flexibilidad.

Es la opción más común porque funciona de forma automática. Tú defines un precio base y el sistema calcula el resto siguiendo una regla fija (por ejemplo: “sumar 30€” o “añadir un 10%”). El problema es que, al ser una regla rígida, no se adapta bien a los cambios de demanda de cada temporada.

2. ¿Y cómo hacen las OTA? En la mayoría, la configuración estándar está diseñada bajo una regla de precio fija (suplemento o descuento) que no varía automáticamente con la demanda estacional. Las OTA que admiten suplementos estacionales, suelen requerir una gestión manual constante, que incrementa la carga de trabajo operativa.

Este es un ejemplo de la configuración de variaciones por ocupación en la extranet de una OTA. El canal permite establecer una ocupación base y una reducción fija para las ocupaciones que están por debajo de la ocupación base.

Aunque existen los overrides (la capacidad de sobrescribir manualmente un precio derivado para una fecha concreta), tanto en los Channel Managers como en las OTA, estos no solucionan el problema estructural. Funcionan como un parche para excepciones puntuales, pero depender de ellos para una estrategia de revenue dinámica, obligaría a una vigilancia constante, cayendo de nuevo en la obligación de estar pendiente permanentemente, algo imposible de gestionar a mano.

• ¿Dónde se decide el cálculo? Aquí reside la clave. Aunque el precio base nace en el PMS o en el Channel Manager, la regla de cálculo suele delegarse en el Channel Manager o, dependiendo del flujo, en el propio canal o motor de reservas. Si queda “secuestrado” por las reglas de la propia extranet de la OTA, limita el control real del hotelero sobre su propio precio final.

Los RMS más avanzados están diseñados para calcular precios por ocupación (OBP) de forma independiente, pero a menudo se ven forzados a exportar en formato PDP por limitaciones del ecosistema (PMS o Channel Manager). En definitiva: tu estrategia de revenue siempre estará limitada por el eslabón más débil de tu cadena de conectividad.

• La gran ventaja de las tarifas derivadas es la eficiencia: gestionas un único precio y el resto se actualiza automáticamente en cascada. Sin embargo, el error común es intentar “forzar” el modelo: si acabas creando tantas tarifas y regímenes como ocupaciones existen, destruyes esa eficiencia y terminas con un sistema ingobernable, pero con la misma rigidez de siempre.
• ¿Cuáles son sus limitaciones? 

Mapeo en la bajada de reservas. Al delegar el cálculo del precio al canal o al Channel Manager, el “viaje de vuelta” de la reserva es más complejo. 

El efecto cadena y su mala noticia: al mover el precio base, arrastras a todos los demás sin querer. Como estas reglas suelen ser fijas (por ejemplo, el mismo suplemento de 30€ para todo el año), no puedes adaptarte a la demanda real de cada temporada. Si quieres subir la triple, estás obligado a subir también la doble.

OBP (Occupancy Based Pricing): un precio independiente para cada ocupación

Este modelo representa la evolución hacia la granularidad del dato, tratando cada ocupación como un producto independiente.

• ¿Qué representa este modelo? Rompe la jerarquía de precios derivados. Cada ocupación tiene un precio final propio, único y desvinculado de las demás.
• ¿Cómo funciona este modelo? El sistema no envía instrucciones de cálculo (“Base + 40€”), sino datos absolutos: “Individual: 90€”, “Doble: 100€”, “Triple: 130€”.

• ¿Quién tiene el control del precio final? Reside en el sistema que genera el precio (RMS, Channel Manager o PMS avanzado), y se transporta de forma explícita. No obstante, a menudo estos precios nacen de cálculos lineales en origen.

Sin embargo, existe una diferencia crucial en la capacidad de intervención del canal:

• En el modelo OBP, las grandes plataformas (OTA) se limitan a mostrar el precio exacto que les envías, sin hacer cálculos por su cuenta. Esto garantiza que el cliente vea exactamente lo que tú has decidido en tu sistema.
• El motor de reservas como última palabra: un motor de reservas avanzado permite intervenir. Puede actuar sobrescribiendo la lógica de ocupación recibida, reemplazando los incrementos lineales del PMS o el Channel Manager para adecuarse a las curvas dinámicas de demanda.

El reto del RMS: los RMS pueden calcular y enviar todos estos precios finales, pero precisan de un mapeo exhaustivo de todas las ocupaciones para que la estrategia se ejecute correctamente.

• ¿Qué ventajas tiene este modelo? Control y granularidad. Permite definir estrategias específicas para cada ocupación (elasticidad independiente) antes de la distribución.
• ¿Cuál es la principal limitación? Densidad de datos y mapeo. Exige una tecnología capaz de procesar un volumen de información mucho mayor, ya que cada ocupación requiere su propio identificador único (Rate ID). Es como pasar de gestionar una sola llave para una habitación a gestionar una llave distinta para cada persona que entra. Si el canal no es OBP nativo, esto obliga a crear “tarifas espejo” que pueden saturar la gestión del inventario.

¿Cuánto trabajo extra supone cada modelo?

La diferencia radica en el volumen de datos a supervisar:

• En PDP (Gestión por excepción) y utilizando tarifas derivadas: se supervisan 10 precios base (para un hotel de 10 tipologías). Las variaciones se aplican solas.
• En OBP (Gestión por producto): se supervisan 10 habitaciones x 4 ocupaciones = 40 precios finales independientes.

El efecto multiplicador: este número puede crecer de forma combinatoria al cruzarlo con los diferentes regímenes (Solo Alojamiento, Desayuno incluido, Media Pensión) y políticas de cancelación (Flexible, No Reembolsable).

La balanza de la operativa

Escenario: hotel de 10 tipologías x 4 ocupaciones x 2 regímenes x 2 políticas de cancelación:

El riesgo de la falsa agilidad

Sin automatización, la granularidad del OBP se convierte en una vulnerabilidad operativa. La probabilidad de error humano hace que el control manual sea inviable.

Muchos hoteles intentan “escapar” de la rigidez del PDP creando decenas de tarifas independientes en su PMS. El resultado es el peor de los mundos:

• Pierden la agilidad del PDP (ya no se actualiza en cascada).
• No ganan la inteligencia del OBP (siguen sin visión por ocupación).
• Hipertrofia de inventario: cientos de tarifas que mapear y supervisar una a una.

Cuadro comparativo de arquitecturas

¿Qué cambia?	PDP (Precio por día)	OBP (Precio por ocupación)
Enfoque	Gestión de habitaciones: la ocupación es un atributo secundario.	Gestión de productos: cada combinación es un ítem único.
Lógica de precios	Derivada: tarifa base + reglas fijas.	Explícita: precios finales exactos.
Revenue Management	Vinculado: modificar la base altera todas las ocupaciones.	Independiente: optimización elástica por ocupación.
Mantenimiento	Supervisión de reglas: requiere vigilar el cálculo.	Gestión masiva de precios finales.
Conectividad	Agregación de tarifas: simplifica el inventario, pero limita la diferenciación.	Nativa: conexión directa del inventario real.
Seguridad en el precio	Interpretativa: riesgo de disparidad por cálculo externo en el canal.	Exacta: el canal muestra el dato particular.
Perfil de uso	Hoteles que priorizan la agilidad de carga y mantenimiento automatizado.	Hoteles con inventarios complejos o estrategias de revenue granulares.

¿Por qué el modelo tradicional sigue siendo el más usado?

Aunque el sistema por ocupación (OBP) es más exacto, el modelo de precio por día (PDP) sigue siendo el más común por pura practicidad:

• Costumbre y estabilidad: durante años, se prefirió que la conexión fuera rápida y no diera errores antes que entrar en detalles de cada precio.
• Diseño de los canales: las grandes plataformas (como Booking o Expedia) están hechas para que este modelo funcione bien. Para la mayoría de hoteles, es una solución robusta y fácil de manejar, mientras que el modelo por ocupación queda como el siguiente paso para quienes buscan una precisión total.

Ejemplo real: el dinero que dejas de ganar por una tecnología rígida

Supuesto: habitación Doble a 300 €  en temporada alta.

• Escenario A: modelo PDP (regla estática). El suplemento de 3ª persona es fijo en el Motor/Canal (+ 30 €).

– Precio Final Triple: 330 €

– Consecuencia: para subir la Triple, subirías la Doble y perderías competitividad. O peor: te verías obligado a cerrar la venta de la habitación triple para no malvender, perdiendo ocupación total simplemente por la rigidez del sistema.

• Escenario B: modelo OBP (Estrategia dinámica). Se detecta alta demanda familiar. Se fija la Triple en 375 €, manteniendo la Doble intacta.

– Precio Final Triple: 375 €

– Consecuencia: se captura un valor adicional de 45 € por habitación/noche.

Proyección financiera: 

Asumiendo una ocupación media del 100% y extrapolando esta diferencia a un inventario de 20 habitaciones durante 60 días de temporada alta, el diferencial de ingresos brutos asciende a 54.000 €. En el modelo PDP, este ingreso no se captura debido a la limitación de la regla general; en OBP, es el resultado directo de una decisión de tarificación puntual. Y más importante, en PDP, al subir el precio de la triple, puede que te “salgas de mercado” en la doble (que es la que se suele vender más)

Y esto solo es en una tipología, el margen es exponencial si se tienen en cuenta el resto de ocupaciones, regímenes, tarifas…

 El equilibrio entre arquitectura y estrategia

Al final, la elección entre PDP y OBP no es una cuestión de cuál es mejor tecnología, sino de qué nivel de granularidad puede absorber la operativa del hotel sin perder el control. Mientras el PDP ofrece un entorno de gestión simplificada y ágil, el OBP abre la puerta a una segmentación precisa por ocupación.

La pregunta clave para el hotelero hoy no es solo cuál elegir, sino cómo superar la barrera técnica que los separa: ¿Es posible alcanzar la precisión de ingresos del OBP con la agilidad operativa del PDP? ¿Podemos automatizar la complejidad para que deje de ser un freno?

En la segunda parte, analizaremos cómo está evolucionando la conectividad para integrar ambas filosofías y eliminar la fricción entre la carga de datos y la estrategia de revenue.