Precios dinámicos y RevPAR para alquileres en España

El RevPAR es la métrica que más se cita y la que peor se usa en alquiler vacacional. Une en un número lo que cobras por noche y cuántas noches vendes, y por eso enseña cosas que el precio medio esconde. Aquí tienes cómo leerlo, cómo comparar las formas de fijar precios, de la tarifa fija a los precios dinámicos, y dónde fallan casi todas las operaciones de tarifas, con independencia del software que uses.

Qué mide el RevPAR y qué oculta el ADR

El RevPAR (ingreso por noche disponible) se calcula dividiendo los ingresos por alojamiento entre las noches que el piso estaba disponible para vender. El ADR (tarifa media diaria) solo dice a qué precio se vendieron las noches que sí se ocuparon.

Un ejemplo con números redondos. En un mes de 30 noches disponibles vendes 20 noches a una tarifa media de 100:

| Métrica | Cálculo | Resultado |
|---|---|---|
| Ocupación | 20 noches vendidas entre 30 disponibles | 66,7 % |
| ADR | Ingresos entre noches vendidas | 100 |
| RevPAR | Ingresos entre noches disponibles | 66,7 |

Al mes siguiente subes la tarifa media a 120 y vendes 14 noches. El ADR sube a 120, pero el RevPAR baja a 56. La gráfica del precio medio parece un éxito mientras los ingresos caen.

Por eso, informar del ADR a un propietario sin poner la ocupación al lado es enseñarle media foto.

Cada cambio de precio es una apuesta

Subir la tarifa de una noche aumenta el margen por reserva y el riesgo de que se quede vacía. Bajarla asegura la ocupación, pero puede vender barata una fecha que un viajero de última hora habría pagado más cara. Ninguna dirección es correcta por sí sola. Lo que permite decidir con criterio es saber con cuánta antelación se reserva en tu mercado y cómo cambia esa antelación por temporada.

Cómo comparar la tarifa fija con los precios dinámicos

Hay cuatro maneras habituales de poner precio a las noches. Ninguna es la mejor en abstracto: cada una encaja con un tamaño de cartera y con un tiempo de gestión distintos.

| Forma | Cómo funciona | Ventaja | Riesgo | Encaja con |
|---|---|---|---|---|
| Tarifa fija | El mismo precio todo el año | Sencilla y predecible | Deja ingresos sobre la mesa en temporada alta y vende poco en baja | Un solo piso con demanda muy estable |
| Por temporadas | Precios distintos para alta, media y baja | Recoge el patrón del año | No reacciona a eventos ni a cambios de última hora | Carteras pequeñas con poco tiempo de gestión |
| Por reglas | Ajustes automáticos según antelación, ocupación o día de la semana | Reacciona sin intervención manual | Las reglas envejecen si nadie las revisa | Gestores que conocen bien su mercado |
| Dinámica con datos de mercado | Un algoritmo propone el precio de cada noche con datos de demanda y competencia | Detecta cambios que una persona no ve a tiempo | Depende de la calidad de los datos y de que alguien vigile sus decisiones | Carteras medianas y grandes |

El salto de la tarifa por temporadas a la dinámica no es solo de herramienta. Cambia quién decide: pasas de fijar precios a supervisar decisiones. Si nadie tiene tiempo de revisar lo que hace el algoritmo, una buena configuración por reglas puede rendir más que una dinámica descuidada.

Qué mirar antes de cambiar de forma

Antes de pasar a precios dinámicos, comprueba tres cosas: que tus datos de reservas son fiables, que tus canales reciben los cambios a tiempo y que alguien revisará las excepciones cada semana. Sin eso, el algoritmo optimiza sobre cifras equivocadas.

¿De dónde salen los datos de precios?

Tarifas, disponibilidad, restricciones de estancia y reservas confirmadas tienen que vivir en un único sistema del que beban todos los canales. Con un calendario en el channel manager, otro en el PMS y una hoja de cálculo para las reservas directas, no tienes un problema de precios: tienes un problema de datos que acabará pareciéndolo.

La prueba es inmediata. Consulta la tarifa de una noche dentro de tres semanas. Si tienes que mirar dos sistemas y cuadrarlos a mano, cualquier algoritmo trabajará sobre números equivocados.

El retraso de sincronización cuesta dinero

Las conexiones con los canales son de dos tipos. Las conexiones por API envían cada cambio en el momento y confirman que llegó. Las conexiones por iCal consultan el calendario cada cierto tiempo, a menudo con decenas de minutos de intervalo.

En disponibilidad, ese retraso provoca reservas dobles. En tarifas el daño es más silencioso: bajas el precio para llenar un hueco, el canal tarda en reflejarlo y la reserva se va a otro anuncio mientras tu panel muestra el cambio como aplicado.

Dónde fallan las operaciones de precios

Noches huérfanas

Un hueco de dos noches entre dos reservas, con una estancia mínima de tres noches, no se puede vender nunca. Ningún precio llena esa fecha mientras la restricción siga activa. Estos huecos aparecen en cuanto sube la ocupación y no salen en los informes, porque nunca cuentan como reservas perdidas.

Estancias mínimas que sobreviven a su motivo

La estancia mínima se suele fijar por temporada y después se olvida. El mínimo de cuatro noches que tenía sentido en agosto es el que crea noches huérfanas en noviembre. Revisa los mínimos con un calendario fijo, no los dejes como valores permanentes.

Gastos de limpieza que encarecen las estancias cortas

Un gasto fijo de limpieza pesa entero sobre una reserva de una o dos noches y dispara el precio final muy por encima del anunciado. A menudo es ese recargo, y no la tarifa base que sigues ajustando, lo que bloquea las reservas cortas.

Envíos de tarifas que fallan sin avisar

Las actualizaciones de precio fallan por credenciales caducadas, anuncios desactivados o un mapeo roto tras renombrar una unidad. Lo caro es que esos fallos casi nunca aparecen como errores en los paneles que se miran a diario.

Paridad de tarifas con las plataformas

Qué automatizar y qué decidir tú

Automatiza lo mecánico: detectar huecos en el calendario, revisar las estancias mínimas con un calendario fijo, comprobar que cada envío a los canales llegó y actualizar los precios a diario. Estos fallos ocurren por olvido, no por falta de criterio.

Quédate con el criterio: eventos locales, aperturas o cierres de la competencia, cambios bruscos de oferta o las fechas en que el propietario usa el piso. Ningún software ve esas cosas mirando solo un calendario.

Cómo leer la tendencia del RevPAR sin engañarte

El RevPAR solo se puede comparar consigo mismo cuando el denominador no cambia. Añadir un piso a mitad de mes, bloquear fechas por obras o una estancia del propietario cambian las noches disponibles y mueven el RevPAR sin que tu estrategia de precios haya cambiado.

Antes de sacar conclusiones de un mes a otro, revisa esta lista:

• ☐ Las noches disponibles son las mismas en los dos periodos, o las has ajustado.
• ☐ Los bloqueos del propietario y por obras están fuera del cálculo.
• ☐ Los ingresos son solo de alojamiento, sin limpieza ni otros cargos.
• ☐ Comparas el mismo mes del año anterior además del mes previo.
• ☐ Miras el RevPAR junto a la ocupación y al ADR, nunca solo.

Para quien gestiona precios de varios pisos, en las funciones que estamos construyendo en Klimpy contamos qué parte de este trabajo queremos automatizar. Y si tus llegadas siguen dependiendo de una persona con una llave, la guía del parte de viajeros y su automatización explica cómo encadenar reserva, registro y acceso.