Qué hace realmente un PMS de hotel (y qué no hace)

Preguntad a cinco personas de un hotel independiente qué hace realmente el property management system y probablemente obtendréis cinco respuestas distintas: el software que hace funcionar la recepción, el que habla con las OTA, el sistema que fija las tarifas de las habitaciones, o simplemente el ordenador del mostrador. Solo una de esas respuestas es correcta, y equivocarse tiene un coste real: planes de marketing construidos sobre la idea de que los datos de los huéspedes viven en un sitio donde en realidad no están, o un cambio de sistema firmado antes de comprobar si años de historial de estancias y direcciones de email se podrían realmente extraer después.

Resumen: el property management system (PMS) de un hotel, el software que hace funcionar el día a día: tomar reservas, asignar habitaciones, seguir el estado del housekeeping y generar la factura, es el registro operativo del hotel. No es una herramienta de marketing, y no es lo mismo que un channel manager, un motor de reservas o el revenue management, aunque los cuatro convivan en el mismo stack y se intercambien datos constantemente. Este artículo explica qué hace realmente un PMS, en qué se diferencia de los tres sistemas con los que más se confunde, cómo encaja el stack en su conjunto, por qué los datos de huésped que contiene condicionan silenciosamente hasta dónde puede llegar el marketing de retención, el error que conviene evitar antes de cualquier cambio de proveedor, y cuándo realmente no hay nada aquí que merezca la pena comprar.

Este artículo está escrito para el propietario o el director general de un hotel independiente de entre 50 y 200 habitaciones aproximadamente que quiere un mapa claro de qué hace el PMS frente a los sistemas que lo rodean. Es un artículo explicativo, no una comparativa de proveedores concretos.

Qué es un PMS

El property management system es el software con el que el hotel gestiona su operativa. En su centro hay tres funciones: las reservas, que recogen cada reserva sea cual sea su origen y la asignan a una habitación; el housekeeping, que sigue qué habitaciones están limpias, ocupadas, fuera de servicio o listas para vender; y la facturación, el folio que registra cargos, pagos y facturas. Todo lo demás en el stack remite a este registro. Si un huésped llama para cambiar una reserva, el cambio ocurre en el PMS. Si el housekeeping marca una habitación como sucia, ese estado vive en el PMS. Si semanas después un huésped reclama un cargo, el folio que resuelve la duda está en el PMS.

Es, en el sentido más literal, el único lugar donde queda escrita la historia operativa del hotel. Merece la pena decirlo con claridad, porque desde el lado del marketing es fácil dar por hecho que el PMS hace más que eso. No es, por sí mismo, una plataforma de relación con el cliente, una web o un motor de precios, aunque muy a menudo esté por debajo de las herramientas que sí hacen esos trabajos.

Qué no es: tres distinciones rápidas

Tres sistemas se confunden constantemente con el PMS, y cada uno merece una aclaración propia.

No es un channel manager. Un channel manager envía tarifas y disponibilidad a las OTA y trae de vuelta las reservas resultantes. El PMS es donde esas reservas aterrizan y se asignan a habitaciones; no es lo que las distribuye en primer lugar. Para el panorama completo de esa capa, ver qué hace realmente un channel manager.

No es un motor de reservas. El motor de reservas es el checkout de la propia web del hotel, el paso con el que un huésped completa una reserva directa. Una reserva directa completada entra en el PMS como reserva confirmada; no nace dentro del PMS.

No es revenue management. El revenue management es un conjunto de decisiones de precio: qué tarifa cobrar, en qué fecha, a qué segmento, bajo qué restricciones. El PMS almacena las reservas y tarifas que produce esa decisión. No las decide él, aunque quien gestione el revenue normalmente estará mirando los datos del PMS, junto con los del channel manager, para tomar esa decisión.

Cómo encajan los cuatro sistemas en el stack

Imaginad el PMS en el centro. El channel manager se sitúa entre el PMS y las OTA, sincronizando tarifas y disponibilidad hacia fuera y trayendo de vuelta las reservas. El motor de reservas se sitúa entre el PMS y la propia web del hotel, tomando una reserva directa y haciéndola pasar como reserva. El revenue management, ya sea un sistema dedicado o una persona con una hoja de cálculo, lee los datos de tarifa y demanda, a menudo a través del PMS o del channel manager, y decide cuál debe ser el próximo precio.

Toda reserva, venga de donde venga, termina en el PMS como reserva. Eso es lo que lo convierte en el sistema de referencia y no en uno más entre iguales: es el único lugar donde las cuatro funciones coinciden realmente en lo que ha ocurrido.

Por qué la calidad de los datos del PMS es también un problema de marketing

Esta es la parte que se pasa por alto desde el lado del marketing. Cada estancia crea un perfil de huésped dentro del PMS: nombre, datos de contacto, fechas, tipo de habitación, tarifa pagada, y a menudo notas sobre preferencias. Multiplicad eso por años de actividad y el PMS acaba sentado sobre algunos de los datos first-party más detallados que el hotel tiene sobre quién se aloja realmente y qué reserva.

Ese conjunto de datos es la materia prima de la que depende todo el marketing de retención: una oferta para huéspedes recurrentes, un upsell previo a la llegada, una solicitud de reseña tras la estancia, una newsletter sencilla para quienes realmente se han alojado. Nada de esto funciona sin una lista limpia y exportable de quién se alojó, cuándo, y si dio su consentimiento para ser contactado. En las cuentas que gestionamos, este lado se infravalora sistemáticamente: los hoteles invierten en el lado de la captación (paid media, SEO) y tratan la lista de huéspedes dentro del PMS como algo secundario, cuando en las cuentas que gestionamos suele ser de las audiencias más baratas de alcanzar, precisamente porque esos huéspedes ya conocen el hotel.

Un PMS que no puede exportar esos datos de forma limpia, o que solo los exporta en un formato con el que nadie del equipo puede realmente trabajar, pone un techo firme a lo que el email marketing podrá lograr ahí. El plan de marketing está bien; es la materia prima de la que depende la que queda encerrada dentro de un sistema que nadie comprobó.

El error típico: perder años de historial de huéspedes en un cambio

La versión más cara de este problema aparece en el momento de cambiar de proveedor de PMS. Las habitaciones y las tarifas migran, y el nuevo flujo de trabajo de recepción se prueba y se aprueba. Lo que a menudo no se comprueba hasta que ya es tarde para arreglarlo es el historial de huéspedes: años de registros de estancia, emails y preferencias que están en el sistema antiguo, y si todo eso realmente pasa al otro lado en una forma utilizable.

A veces la exportación del proveedor antiguo es una hoja de cálculo limitada a un puñado de campos. A veces la exportación completa existe, pero solo con un coste adicional, o solo dentro de una ventana breve tras finalizar el contrato. A veces existe completa y simplemente nadie del hotel la abre ni revisa su contenido antes de que se desactive la cuenta antigua. Sea cual sea el caso, el resultado después es el mismo: años de relaciones con huéspedes que podrían haber alimentado una campaña de retorno se pierden, y una vez desmantelado el sistema antiguo no hay forma de recuperarlos.

La solución no cuesta nada y lleva una tarde: antes de firmar nada con un nuevo proveedor, pedid al proveedor actual una exportación completa de los datos de huéspedes, en un formato sencillo que podáis abrir vosotros mismos, y comprobad que realmente contiene lo que creéis que contiene. Hacedlo mientras el contrato antiguo sigue vigente, no después de que el cambio ya haya ocurrido.

Qué significa realmente tener datos de huésped "limpios"

Limpio no significa un sistema más sofisticado. Significa que se cumplen cuatro cosas sobre lo que sale del PMS: los datos de contacto son lo bastante completos como para poder usarse, es decir, una dirección de email, no solo un nombre; el estado del consentimiento queda registrado, de modo que se sabe quién aceptó ser contactado y quién no; el historial de estancias está vinculado al huésped correcto en lugar de duplicado en varios perfiles casi idénticos; y todo ello se puede exportar en un formato que una persona, no solo el proveedor del software, pueda abrir y leer.

Los perfiles duplicados o fragmentados son el fallo que vemos con más frecuencia: el mismo huésped registrado tres veces con variaciones leves de grafía o distintos canales de reserva, lo que hace que el historial de estancias parezca más pobre de lo que es y hace que cualquier oferta personalizada parezca un error en cuanto llega dos veces a la misma bandeja de entrada.

Propiedad de los datos y derechos de exportación: conviene leerlos antes de firmar

A quién pertenecen realmente los datos de huésped dentro de un PMS, y a qué tiene derecho un hotel al salir, varía según el contrato y según el mercado. No es algo que deba darse por hecho en ningún sentido; merece la pena leer la cláusula correspondiente en vuestro propio contrato, o preguntarlo directamente al proveedor, en lugar de descubrir la respuesta durante una migración. Los propios huéspedes también tienen derechos sobre sus datos conforme a la normativa europea de protección de datos, incluido, en algunas circunstancias, el derecho a recibirlos en un formato portable. Es una cuestión distinta de lo que vuestro proveedor os debe contractualmente, pero conviene tenerla presente al gestionar cualquier exportación.

Dónde encaja la calidad de los datos del PMS dentro del plan de marketing más amplio

Nada de esto sustituye a una estrategia de marketing; está por debajo de ella. La estrategia de marketing de un hotel suele tratar la captación (conseguir que nuevos huéspedes encuentren y reserven el hotel) y la retención (conseguir que huéspedes pasados vuelvan) como dos trabajos separados, y el PMS se sitúa claramente del lado de la retención. El trabajo de captación puede tener éxito o fracasar en gran medida al margen de lo que contenga el PMS. El de retención no: necesita la lista de huéspedes que produce el PMS antes incluso de poder empezar.

Cuándo aquí no hay nada que comprar

Si el sistema actual ya exporta datos de huéspedes limpios en un formato que el equipo sabe usar, no hay nada que cambiar. Este artículo es deliberadamente un mapa de cómo encaja el stack, no un argumento para sustituir nada dentro de él. Cambiar de PMS es disruptivo: reciclaje del personal, una ventana de migración, el riesgo descrito más arriba. Merece la pena hacerlo cuando el sistema actual realmente no puede hacer el trabajo (sin exportación utilizable, estado de housekeeping poco fiable, facturación que nunca acaba de cuadrar), no como una actualización por defecto solo porque exista una opción más reciente.

Si vuestra configuración actual está poniendo silenciosamente un techo a lo que puede hacer vuestro marketing es una pregunta que se puede comprobar, y comprobarlo forma parte de lo que cubre una auditoría gratuita.