RMS y PMS: ¿debe el Revenue Management convertirse en una simple funcionalidad del PMS?

Nativo, adquirido o independiente: los tres futuros posibles del Revenue Management ante la consolidación del PMS.

¿Conviene elegir un RMS nativo del PMS o apostar por un RMS independiente? La pregunta surge cada vez con más frecuencia, ahora que varios PMS lanzan su propio módulo de Revenue Management. No es solo una cuestión de funcionalidades: es una decisión que condiciona la velocidad de innovación, la visión de producto y, en última instancia, la calidad de las recomendaciones de precios que recibe el hotelero. Estos son los tres escenarios posibles, y por qué integración no significa consolidación.


El regreso de un debate ya conocido en el Hotel Tech

Llevo tiempo dándole vueltas a esta cuestión. No porque piense que los PMS no deberían desarrollar su propio Revenue Management: deberían hacerlo, desde su punto de vista. Y tampoco porque crea que los RMS independientes deban ser protegidos de la competencia. Todo lo contrario. La competencia es sana. Pero cuando observo lo que ocurre en el Hotel Tech, no puedo evitar pensar que quizá estemos repitiendo una historia que ya hemos vivido.

Algunos PMS acaban de anunciar su propio Revenue Management System. Y eso me hizo reflexionar, porque el tema va mucho más allá del lanzamiento de un nuevo módulo por parte de un PMS.

Durante años, el Hotel Tech evolucionó en una sola dirección: la especialización. Creamos sistemas dedicados a la distribución, al CRM, a la reputación, al upselling, a la Business Intelligence y, por supuesto, al Revenue Management. Después llegó la era de la integración. Las API permitieron que todos estos especialistas trabajaran juntos.

Hoy, el movimiento parece ir de nuevo en sentido contrario. Los PMS incorporan cada vez más funcionalidades a su propia plataforma. Y el Revenue Management es una de las funcionalidades más estratégicas, y potencialmente más valiosas, para integrar directamente en la plataforma.

Así que vuelvo siempre a la misma pregunta: ¿se convertirá el RMS en una simple funcionalidad del PMS?

No creo que la respuesta sea tan sencilla como un «sí» o un «no». Porque existen tres maneras muy distintas de imaginar el futuro del Revenue Management.

Construir: cuando el RMS se convierte en una funcionalidad del PMS

La lógica es difícil de rebatir. El PMS ya sabe lo que ocurre en el hotel. Conoce las reservas, el inventario, la ocupación, el ritmo de reservas, los tipos de habitación y los canales. Entonces, ¿por qué un sistema independiente tendría que recuperar toda esa información antes de hacer una recomendación de precios?

Un RMS nativo puede reducir la distancia entre el dato, la decisión y su ejecución. Para muchos hoteles, es una propuesta muy atractiva. Una plataforma. Una interfaz. Un contrato. Una integración menos que mantener.

Y hay una ventaja aún más importante: un RMS sencillo e integrado puede hacer que el Revenue Management sea accesible para hoteles que nunca habrían invertido en una solución independiente sofisticada.

Es algo realmente positivo para el sector. Pero hay otra cara de la historia: un PMS tiene muchas cosas que hacer. El Revenue Management, solo una. Y un RMS no es una funcionalidad que se construye una vez para luego pasar a otra cosa.

El Revenue Management evoluciona constantemente. Los datos cambian. Los modelos cambian. La distribución cambia. El comportamiento de los clientes cambia. La IA cambia lo que es posible hacer. El mejor RMS del futuro no será simplemente el que tenga la lista de funcionalidades más larga, sino el que siga progresando. Todos conocemos RMS que fueron desplazados poco a poco del mercado por no haber sabido innovar de forma continua.

Esa es la primera pregunta que me haría cuando un RMS pasa a ser un módulo más dentro de un PMS: ¿recibirá el mismo nivel de atención cuando las prioridades empiecen, inevitablemente, a competir entre sí?

Ya hemos visto una evolución similar con los Channel Managers. Y precisamente por eso creo que vale la pena plantear la pregunta antes de dar por hecho que lo nativo es necesariamente mejor.

Comprar: cuando el especialista se une a un grupo

El segundo modelo es la adquisición.

En lugar de construir un RMS desde cero, un PMS o un grupo más amplio de Hotel Tech puede simplemente comprar uno. De nuevo, la lógica resulta seductora. Se adquiere una tecnología que costó años de desarrollo. Se adquiere experiencia. Se adquieren clientes. Se gana tamaño y capacidad de distribución. El especialista cuenta con más recursos. El grupo obtiene un producto que ya ha demostrado su valía.

Todos pueden salir ganando.

Pero una adquisición también cambia algo que se subestima con facilidad: ¿quién es el dueño de la visión de producto?

Un RMS independiente puede empezar cada día con una pregunta relativamente sencilla: ¿cómo hacer mejor el Revenue Management?

Una vez integrado en un portafolio más amplio, las preguntas son otras. ¿Cómo encaja con el PMS? ¿Qué debe construirse de forma centralizada? ¿Dónde hay que invertir? ¿Qué producto debe asumir cada funcionalidad? ¿Hasta dónde debe llegar el RMS con respecto a los demás productos del portafolio?

Ninguna de estas preguntas es necesariamente mala. De hecho, un grupo más grande puede dar a un RMS más recursos y acelerar su desarrollo. Pero la lógica es distinta. Ya no se optimiza un solo producto. Se optimiza un portafolio.

Y cuando se compra a un especialista, no se compra solo su tecnología. También se compra su visión, su cultura y su manera de tomar decisiones de producto.

La verdadera cuestión es qué ocurre con todo eso con el paso del tiempo.

Seguir siendo independiente: pero estar conectado en todas partes

Existe una tercera vía. El RMS sigue siendo independiente. No aislado. Independiente.

El matiz es importante. Durante mucho tiempo, el principal argumento contra las tecnologías especializadas fue la integración. Los hoteles acababan con demasiados sistemas, demasiadas interfaces y demasiados proveedores.

Esa crítica era legítima. Pero no creo que la respuesta sea necesariamente poner todo bajo el mismo techo. La otra posibilidad consiste en lograr que sistemas independientes funcionen mucho mejor juntos.

Pero hay otro prejuicio que me parece importante cuestionar: independiente no significa «pequeño».

La financiación existe. Un especialista puede tener los medios para construir un producto sólido, invertir en tecnología y expandirse internacionalmente sin pertenecer a un grupo mayor.

Y el tamaño tampoco garantiza una mejor ejecución. En algunos casos, la relación puede incluso ser inversa: cuanto más grande se vuelve una organización, más capas, procesos y dependencias añade, y más difícil puede resultar avanzar con rapidez.

Ser independiente puede significar, simplemente, estar centrado. Centrado al 100 % en un oficio. Desde el primer mensaje de marketing, pasando por la comprensión del proyecto por parte de los equipos de Ventas, y sobre todo en el despliegue, el Account Management y la comprensión de la evolución del sector.

Y esto importa especialmente en Revenue Management, porque la tecnología no puede quedarse quieta. La innovación no es un acontecimiento puntual. Es una necesidad permanente. De hecho, muchos de los mecanismos descritos por las teorías económicas de la innovación apuntan en la misma dirección: la especialización, la concentración y la capacidad de experimentar pueden ser potentes motores de innovación.

Para un RMS, esta capacidad de mantenerse cerca del oficio puede acabar siendo más importante que el tamaño de la empresa que está detrás.

El PMS sigue siendo el sistema operativo. El RMS sigue siendo la capa de inteligencia de Revenue. El Channel Manager sigue siendo la capa de distribución. Y los datos circulan entre ellos.

El hotelero no debería tener que preguntarse qué empresa posee cada pieza tecnológica. Debería preguntarse simplemente si la tecnología funciona. ¿Llegan los datos al lugar adecuado? ¿Están disponibles las recomendaciones en el momento oportuno? ¿Se devuelven las decisiones a los sistemas operativos? Y, cada vez más, ¿pueden automatizarse las acciones?

El objetivo no es tener más software. El objetivo es tener menos fricción.

La integración no es consolidación

La consolidación consiste en reunir productos, empresas o funcionalidades bajo una misma propiedad. La integración consiste en hacer que distintos sistemas funcionen juntos. Se puede tener un único proveedor con cinco productos mal conectados entre sí. Y se pueden tener varios proveedores especializados que funcionan como un solo ecosistema.

Quizá la pregunta correcta para los hoteles no sea: ¿cuántos proveedores tengo?

Sino más bien: ¿cuánta fricción tengo?

Eso cambia por completo la discusión.

Porque si un RMS especializado está profundamente integrado con el PMS, si los datos circulan automáticamente y si las decisiones pueden ejecutarse sin pasos innecesarios, ¿realmente importa que los dos productos pertenezcan a empresas diferentes?

Creo que no.

El Revenue Management es un caso especial

Esta cuestión es especialmente importante para el RMS, porque el Revenue Management es una disciplina que no puede permitirse quedarse quieta. He pasado suficiente tiempo en torno al Revenue Management como para saber que el oficio evoluciona constantemente. Lo que funcionaba hace cinco años no basta necesariamente hoy. Y lo que funciona hoy probablemente no bastará dentro de cinco años.

Pero, en el fondo, siempre buscamos responder a la misma pregunta: para esta fecha y esta unidad, ¿necesito Volumen o ADR?

Y si el diseñador, el editor del RMS, ni siquiera se plantea correctamente esta pregunta, entonces puedes añadir todos los datos que quieras, multiplicar las integraciones o integrar el RMS de forma nativa en un PMS: seguirás sin permitir que el usuario aproveche toda la inteligencia de tu plataforma.

La IA no cambia la manera en que hacemos nuestros análisis. Las matemáticas siguen siendo matemáticas. Lo que sí cambia es nuestra capacidad de escalar y automatizar.

Los equipos de Revenue esperan más transparencia. Los hoteles quieren más automatización, pero también quieren entender por qué se ha tomado una decisión.

Para un RMS independiente, esta presión es intensa. Pero hay algo sano en ella. Un RMS independiente tiene una razón de ser muy clara: hacer mejor el Revenue Management.

Si deja de hacerlo, los hoteles tienen muy pocas razones para seguir utilizándolo. Esto crea un incentivo muy fuerte para seguir invirtiendo, experimentando y evolucionando.

Para mí, este es uno de los argumentos más sólidos a favor de la especialización. No porque un especialista sea automáticamente mejor, sino porque su supervivencia depende de su capacidad para mantenerse a la vanguardia de su oficio.

Y llega la siguiente capa de integración

Los agentes de IA y protocolos como MCP podrían cambiar la forma en que los programas interactúan entre sí.

El reto ya no es simplemente hacer pasar un dato de A a B. Se trata de dar a un sistema acceso al contexto adecuado, a la experiencia adecuada y a las acciones adecuadas.

Imagina un agente de IA que analiza la situación actual de un hotel. Puede acceder al contexto operativo desde el PMS. Puede preguntar al RMS por qué ha cambiado la demanda. Puede entender la recomendación. Puede explicársela al Revenue Manager. Y, cuando está autorizado, puede ejecutar la decisión.

Acabas de imaginar Revbell hoy y mañana.

En ese mundo, el RMS no necesita convertirse en el PMS. Debe ser extremadamente bueno en Revenue Management y capaz de poner esa experiencia a disposición del resto del ecosistema. Es una visión de la integración muy diferente.

Entonces, ¿se convertirá el RMS en una simple funcionalidad del PMS?

Para algunos hoteles, quizá.

Un RMS nativo puede hacer el Revenue Management más sencillo, más accesible y más fácil de usar. Eso es un valor real. Pero no significa que todos los RMS deban convertirse en funcionalidades del PMS.

Siempre habrá hoteles para los que el Revenue Management sea demasiado estratégico, demasiado complejo y demasiado dinámico como para tratarlo como una simple casilla que marcar. Y creo que ahí es donde el mercado se dirige hacia un equilibrio interesante.

El PMS puede gestionar el flujo de trabajo operativo. El RMS puede gestionar la inteligencia de Revenue. El Channel Manager puede gestionar la distribución.

Los especialistas pueden seguir siendo especialistas. Y la tecnología puede lograr que el conjunto se perciba como una única plataforma.

Este es el modelo en el que creemos en Revbell

En Revbell hemos elegido seguir siendo especialistas. No porque pensemos que los hoteles necesitan más sistemas. Todo lo contrario.

Creemos que el Revenue Management merece una empresa cuya atención esté dedicada por completo al Revenue Management.

Pero ser especialista no significa estar desconectado. Nuestro RMS está, y debe seguir estando, profundamente conectado al PMS. Debe recuperar automáticamente los datos correctos. Debe devolver las decisiones directamente al flujo de trabajo operativo.

Y debe seguir evolucionando al ritmo del sector.

Para nosotros, la independencia no consiste en mantenerse al margen del ecosistema. Consiste en tener la libertad de seguir haciendo avanzar un oficio.

Independent by design. Integrated by default.

Quizá ese sea, en definitiva, el futuro del Hotel Tech. No una plataforma que lo haga todo. No un conjunto de especialistas desconectados. Sino un ecosistema en el que cada componente pueda ser excelente en su ámbito, y que al mismo tiempo dé al hotelero la sensación de utilizar una única pila tecnológica coherente.

Y para el Revenue Management, creo que esta distinción será cada vez más importante.

FAQ

  • Fermé

    No necesariamente. Conviven tres modelos: el PMS construye su propio módulo de RMS, el PMS adquiere un RMS especialista, o el RMS sigue siendo independiente y, al mismo tiempo, está profundamente integrado con el PMS. Para los hoteles con un Revenue Management sencillo, un módulo nativo puede ser suficiente. Para el resto, un RMS especializado sigue siendo la opción más adecuada.

  • Fermé

    La consolidación consiste en reunir varios productos bajo una misma propiedad. La integración consiste en hacer que distintos sistemas funcionen juntos, independientemente de quién sea su propietario. Un único proveedor puede tener productos mal conectados entre sí, y varios proveedores especializados pueden funcionar como un solo ecosistema.

  • Fermé

    Depende de la madurez y la complejidad del Revenue Management del hotel. Un RMS nativo simplifica el acceso a los datos y reduce el número de contratos que gestionar. Un RMS independiente, en cambio, garantiza una innovación continua, ya que su supervivencia depende por completo de su capacidad para mantenerse a la vanguardia del Revenue Management.

  • Fermé

    El principal riesgo es la priorización: un PMS gestiona numerosas funcionalidades, mientras que un RMS especializado tiene un único objetivo. Cuando el Revenue Management pasa a ser un módulo más entre muchos, puede recibir menos atención e inversión en cuanto las prioridades internas empiezan a competir.

  • Fermé

    Los agentes de IA y protocolos como MCP podrían cambiar la forma en que el PMS, el RMS y el Channel Manager intercambian información. En lugar de limitarse a transferir datos, un agente de IA podrá acceder al contexto operativo, consultar al RMS sobre sus recomendaciones y, si está autorizado, ejecutar directamente una decisión de precios.