La integración no es un proyecto tecnológico. Es el trabajo de convertir una reserva en una habitación lista sin una llamada telefónica, un mensaje de un huésped en una tarea con un responsable y una avería en una solución con un plazo. Manteniéndose en un alcance estricto, ese trabajo cabe en 30 días en cualquier PMS con una API documentada, y el plan que figura a continuación detalla la secuencia, los responsables y las comprobaciones.

A quién va dirigido este plan

• Responsables de sistemas y directores de TI que necesitan un alcance y un cronograma justificables

• Directores de operaciones y directores generales que buscan obtener valor antes de la temporada alta

• Responsables de pisos y mantenimiento que se preocupan por contar con estados fiables y menos llamadas

Se asume un PMS en la nube con acceso a API, como Mews, Apaleo, Oracle OPERA Cloud, Cloudbeds o Guestline, y un único establecimiento o una propiedad dentro de un grupo utilizada como piloto.

¿Qué debe cumplirse antes del primer día?

Cuatro requisitos, y si falta alguno, el cronómetro aún no ha comenzado.

1. El acceso a la API está concedido, no solo prometido. Responsable: responsable del sistema o director de TI. Duración: prevea de una a dos semanas antes del primer día, ya que este es el paso que los proveedores suelen retrasar. Necesita credenciales, los límites de peticiones (rate limits) documentados y, si se ofrece, un entorno de pruebas (sandbox). Mews publica sus endpoints en la documentación de la API de Mews Connector y Apaleo publica los suyos en apaleo.dev, para que pueda consultar las limitaciones antes de comprometerse con un alcance.

2. Un patrocinador ejecutivo designado. Responsable: director general. Duración: una conversación. Alguien debe poder decir que no a la ampliación incontrolada del alcance en la tercera semana.

3. Una línea base por escrito. Responsable: gobernanta/gobernante general y jefe/a de recepción. Duración: medio día. Registre el tiempo medio actual de preparación de habitaciones, el cumplimiento a tiempo y las llamadas por turno entre recepción y pisos. Sin esto no podrá demostrar que el proyecto ha funcionado.

4. Un alcance para el piloto. Responsable: responsable de pisos. Duración: una hora. Una planta, un turno, un supervisor.

¿La integración debe ser unidireccional o bidireccional?

Elija el modelo que se adapte a su proveedor y a su tolerancia al riesgo, y comience de forma sencilla.

Comience de forma unidireccional si tiene dudas. Añada la escritura en el segundo mes, una vez que el equipo confíe en lo que ve. Sweeply admite ambos modelos en sus más de 20 integraciones con PMS, por lo que la decisión depende de su operativa y no del conector.

El plan de 30 días: ocho pasos con responsable y duración

1. Acordar los casos de uso y congelar el alcance. Responsable: patrocinador ejecutivo. Duración: días 1 y 2. Cuatro casos de uso son el número adecuado para un primer lanzamiento: sincronización del estado de habitaciones, creación de tareas de pisos a partir de las salidas, peticiones de huéspedes convertidas en tareas y traspasos a mantenimiento. Todo lo demás pasa a una lista marcada como «fase dos».

2. Definir los estados en un lenguaje claro. Responsable: gobernanta/gobernante general, junto con el jefe/a de recepción. Duración: días 3 a 5. Ponga por escrito qué significan realmente en su hotel los estados limpia, sucia, en curso, inspeccionada, lista, fuera de servicio y fuera de orden, y qué transiciones están permitidas. La mayoría de los fallos de integración se deben a la falta de esta media página.

3. Mapear habitaciones, tipos de habitación y plantas. Responsable: responsable del sistema. Duración: días 6 a 8. Cree una tabla de referencia canónica y manténgala bajo control de versiones. Cualquier discrepancia posterior se diagnosticará comparándola con esta tabla.

4. Configurar tipos de tareas, prioridades y tiempos de respuesta. Responsable: responsable de pisos y responsable de mantenimiento conjuntamente. Duración: días 9 a 12. Conecte las categorías de peticiones de huéspedes con los tipos de tareas, establezca horas límite y decida a quién se escala una tarea vencida. Los módulos de pisos y mantenimiento de Sweeply se configuran en este paso.

5. Establecer roles, accesos y minimización de datos. Responsable: responsable del sistema, junto con el responsable de protección de datos. Duración: días 13 a 15. Extraiga únicamente los campos que el trabajo requiera, restrinja los datos de los huéspedes a los roles que los necesiten y active los registros de auditoría. Las condiciones de alojamiento, cifrado y tratamiento de datos de Sweeply están publicadas en la página de confianza por si el departamento de compras las solicita.

6. Hacer una prueba piloto en una planta y un turno. Responsable: responsable de pisos. Duración: días 16 a 20, con tres a cinco días en funcionamiento real. Observe los turnos reales en lugar de leer informes. Registre cada desajuste en el mapeo y cada momento en que un camarero o camarera de pisos dude.

7. Corregir y celebrar un punto de decisión (go / no-go). Responsable: patrocinador ejecutivo. Duración: días 21 a 24. Compare el tiempo de disponibilidad y el cumplimiento a tiempo durante el piloto con la línea base previa al primer día. Si las cifras no han mejorado, averigüe el motivo antes de escalar el problema.

8. Escalonar el despliegue y estabilizar. Responsable: director general, con un responsable por departamento. Duración: días 25 a 30, más dos semanas de comprobaciones diarias. Implemente planta por planta o edificio por edificio, revise el estado de la API y las tareas vencidas cada mañana y mantenga un registro visible de incidencias para consolidar la confianza.

Merece la pena leer dos implementaciones publicadas junto con este plan. STAYERY pasó de las hojas de cálculo a la programación automatizada de limpiezas de estancias intermedias en Apaleo (caso de estudio de STAYERY), y Volkshotel Amsterdam mantuvo 196 habitaciones y un equipo de 33 nacionalidades funcionando durante una migración de Mews (caso de estudio de Volkshotel).

¿Qué datos tienen que coincidir realmente?

Cuatro objetos concentran casi todo el riesgo. Acuerde sus campos antes de configurar nada.

Escriba las transiciones de estado permitidas como una secuencia, por ejemplo: sucia a en curso, a limpia, a inspeccionada, a lista; y manténgalas breves. Cada estado adicional es un estado en el que hay que formar a alguien.

¿Cómo saber si está funcionando?

Haga un seguimiento semanal de cinco métricas durante los primeros dos meses, y luego mensual:

• Porcentaje de habitaciones asignadas automáticamente en lugar de manualmente

• Tiempo medio de disponibilidad de las habitaciones respecto a la línea base previa a la integración

• Tasa de cumplimiento a tiempo en peticiones de huéspedes y órdenes de trabajo de mantenimiento

• Tasa de errores de la API y latencia media

• Llamadas por turno entre recepción y pisos

La última es la cifra que el personal percibe primero. Entre los clientes de Sweeply, el tiempo de coordinación suele reducirse alrededor de un 20 %, y esa es la capacidad que el proyecto realmente devuelve.

¿Qué suele fallar y cómo solucionarlo rápidamente?

Tres fallos representan la mayoría de las incidencias de soporte. Las discrepancias de estado, donde el PMS muestra una habitación lista y pisos la muestra sucia, se solucionan con un proceso diario de conciliación que compara ambas listas de habitaciones y señala las diferencias en lugar de sobrescribirlas en silencio. Los fallos en la entrega de webhooks se solucionan con reintentos con retardo progresivo más esa misma conciliación como red de seguridad. Los cambios de campos por parte del proveedor tras una actualización de la API se solucionan versionando la tabla de mapeo, lo que permite ver qué ha cambiado y revertir la situación.

Mantenga por escrito una vía de escalado, incluyendo lo que el proveedor de su PMS necesita para investigar: marca de tiempo, endpoint, identificador de la solicitud y la habitación afectada.

Cuándo 30 días no es el plan adecuado

Este esquema asume condiciones que no todos los establecimientos tienen, y es mejor saberlo en la semana cero.

• PMS local (on-premise) sin API, o con acceso a interfaces de pago. La integración aún puede merecer la pena, pero el plazo lo marcará el proceso comercial de su proveedor, no este plan. Obtenga el presupuesto de la interfaz antes de planificar cualquier otra cosa.

• Múltiples instancias de PMS en un grupo. Realice primero una propiedad de principio a fin. Gestionar cuatro propiedades en tres versiones de PMS en paralelo convierte un plan de 30 días en uno de seis meses.

• Propiedades muy pequeñas. Por debajo de unas 25 habitaciones con una sola persona de limpieza, una lista de tareas compartida aportará la mayor parte del beneficio y un proyecto de integración formal supondrá una carga innecesaria.

• Casos en los que Sweeply no es la respuesta. Sweeply es una capa operativa sobre el PMS, no un PMS, una plataforma de integración ni una licencia de middleware. Si lo que necesita es un flujo de datos de propósito general entre sistemas de finanzas, TPV y BI, se trata de una herramienta diferente y de otro proyecto.

Inicie la conversación sobre el mapeo

Reserve una llamada con nuestro equipo de ventas indicando el nombre y la versión de su PMS, el número de habitaciones y su fecha prevista de puesta en marcha. Le confirmaremos si la integración es compatible y le indicaremos cuál de los cuatro objetos anteriores requiere tareas de mapeo en su caso.