HOTELES · MANTENIMIENTO · INCIDENCIAS · INTEGRACIONES
Cómo automatizar el mantenimiento en un hotel
Una cerradura falla, una fuga aparece entre dos plantas o una habitación queda pendiente de una reparación antes de la siguiente llegada. Automatizar el mantenimiento no consiste en crear avisos más rápido, sino en conseguir que cada incidencia tenga contexto, prioridad, responsable, verificación y una salida clara para saber si la habitación o el activo pueden volver a utilizarse con normalidad.
La reparación es una parte del proceso, no siempre su cierre. Después de intervenir puede hacer falta comprobar el resultado, actualizar el sistema correspondiente, coordinar limpieza o inspección y confirmar que la habitación vuelve a estar disponible según las reglas reales del hotel.
Por eso conviene separar el seguimiento de la avería del estado de la habitación. Ambos se relacionan, pero no deberían confundirse ni cerrarse automáticamente al mismo tiempo.
La cerradura ya funciona. ¿La incidencia está cerrada?
A las 11:20, recepción detecta que la cerradura electrónica de la habitación 527 no reconoce correctamente una credencial. Hay una llegada prevista para esa tarde. El aviso llega a mantenimiento, un técnico revisa el lector, sustituye un componente y marca el trabajo como terminado.
Si el proceso acaba ahí, todavía faltan preguntas importantes: ¿se ha probado la apertura?, ¿la incidencia había provocado algún cambio en la disponibilidad de la habitación?, ¿ese cambio se ha revertido?, ¿hace falta que otro equipo entre después?, ¿recepción ve ya la información correcta?
Ese punto es el centro de esta guía. En un hotel, una reparación puede terminar técnicamente y dejar una consecuencia pendiente en otro sistema o departamento. El error no está en que mantenimiento haya hecho mal su trabajo. Está en diseñar el proceso como si “técnico terminado” y “caso cerrado” fueran siempre lo mismo.
Una incidencia está realmente resuelta cuando se ha realizado y verificado la intervención necesaria y, cuando afecta a una habitación o servicio, el hotel sabe con certeza qué puede volver a utilizarse y qué sigue pendiente.
Esto no significa añadir burocracia a cada bombilla fundida. La verificación debe ser proporcional al trabajo. Cambiar una pila puede requerir una comprobación simple; una fuga, una cerradura, un cuadro eléctrico o una avería que ha dejado una habitación fuera de uso necesitan otras garantías.
Este proceso forma parte del mapa más amplio de automatización para hoteles, donde reservas, recepción, housekeeping, mantenimiento y atención al huésped deben compartir estados sin convertir una sola herramienta en la fuente de verdad de todo.
La entrada sobre housekeeping y solicitudes de huéspedes explica cómo una necesidad se convierte en trabajo coordinado entre recepción, pisos y mantenimiento. Aquí avanzamos un nivel: nos centramos en lo que ocurre dentro del proceso de mantenimiento una vez existe una incidencia que necesita intervención técnica.
Aviso, incidencia, orden de trabajo y estado de habitación no son la misma cosa
Muchos problemas de integración empiezan cuando todo se llama “ticket”. Un empleado avisa de una fuga, mantenimiento abre un trabajo, recepción retira una habitación de la venta y, al final, cuatro sistemas guardan algo parecido pero no exactamente igual.
| Objeto | Qué representa | Ejemplo | Cuándo puede darse por terminado |
|---|---|---|---|
| Aviso | La señal inicial de que algo puede estar mal. | “La cerradura de la 527 no abre.” | Cuando se convierte en un caso válido, se descarta justificadamente o se pide información. |
| Incidencia | El problema que necesita seguimiento y resolución. | Fallo del lector de cerradura de la habitación 527. | Cuando se cumple la condición definida de resolución y no quedan dependencias pendientes. |
| Orden de trabajo | La intervención concreta asignada a una persona, equipo o proveedor. | Revisar lector, sustituir módulo y probar apertura. | Cuando el trabajo asignado se completa y queda registrado su resultado. |
| Estado de habitación | La condición que utiliza el hotel o su PMS para decidir cómo puede tratarse esa habitación. | Disponible, pendiente de limpieza, fuera de servicio u otra categoría configurada. | No “termina”: cambia cuando cambian las condiciones reales de la habitación. |
Una incidencia puede generar varias órdenes de trabajo. Una misma orden puede afectar a más de una zona. Y una habitación puede seguir sin poder utilizarse aunque la reparación principal haya terminado, por ejemplo porque necesita limpieza posterior o una comprobación adicional.
También ocurre lo contrario: no toda incidencia obliga a retirar una habitación de la venta o del uso. Dependerá del problema, del riesgo, de las alternativas y de las reglas del establecimiento.
Al integrar sistemas, esta separación permite decidir qué herramienta mantiene cada objeto y qué cambios deben propagarse.
El mantenimiento tiene dos recorridos que deben encontrarse al final
Una forma práctica de diseñar el proceso es separar dos líneas. La primera sigue el problema técnico. La segunda sigue la consecuencia que ese problema produce sobre la habitación, zona o servicio.
Recorrido de la incidencia
- Aviso recibido y contextualizado.
- Impacto evaluado.
- Prioridad definida.
- Responsable o proveedor asignado.
- Diagnóstico e intervención.
- Trabajo completado.
- Resultado verificado.
- Incidencia cerrada o reabierta.
Recorrido de la habitación o activo afectado
- Se identifica qué está afectado.
- Se decide si puede seguir utilizándose.
- Se aplica, si procede, una restricción o cambio de estado.
- Se revisan llegadas, ocupación o dependencias.
- Se espera a la reparación o a otros trabajos.
- Se confirma que las condiciones necesarias vuelven a cumplirse.
- Se actualiza el sistema correspondiente.
- La habitación o el activo vuelve al uso previsto.
Estas dos líneas no tienen por qué avanzar al mismo ritmo. Una reparación puede terminar mientras otra habitación sigue afectada, falta una comprobación o el siguiente turno debe validar el resultado.
Por eso conviene definir una condición de cierre por tipo de incidencia. No basta con un botón genérico de “hecho”. La pregunta útil es: ¿qué tiene que ser cierto para que el hotel deje de considerar este problema pendiente?
Oracle Hospitality documenta, por ejemplo, solicitudes de mantenimiento asociadas a habitaciones, con asignación a usuarios, motivo, comentarios, fecha prevista y posibilidad de resolver o volver a abrir la solicitud. Ese producto ofrece una implementación concreta; el principio más general es que el trabajo necesita identidad, responsable, estado e historial.
Priorizar bien no es decidir qué avería “suena más urgente”
Dos incidencias del mismo tipo pueden tener prioridades diferentes. Una cerradura que falla en una habitación vacía sin llegada prevista no produce la misma presión que la misma avería cuando el huésped ya está delante de la puerta o existe una llegada en una hora.
La prioridad debería construirse a partir de impacto y reglas del hotel. Entre los factores que pueden intervenir están:
Seguridad
Si existe riesgo para personas, instalaciones o cumplimiento de procedimientos internos.
Habitaciones afectadas
Una incidencia puede afectar a una habitación, varias, una planta o una zona común.
Ocupación y llegadas
No es lo mismo un problema en una habitación vacía sin uso próximo que en una estancia activa o una llegada inminente.
Disponibilidad de alternativa
Puede haber otra habitación equivalente o no existir una alternativa sencilla.
Dependencias
La reparación puede bloquear limpieza, inspección, apertura de una zona o trabajo de otro equipo.
Tiempo y recurrencia
Un problema repetido o una incidencia que se acerca a un compromiso puede necesitar escalado.
No conviene publicar niveles universales del tipo P1, P2 y P3 con tiempos fijos para todos los hoteles. Cada establecimiento tiene personal, instalaciones, horarios, inventario y criterios diferentes. Lo importante es que la prioridad pueda explicarse y que no dependa exclusivamente de quién llamó más veces.
La IA puede ayudar a interpretar el aviso y proponer datos relevantes, pero las reglas que cambian prioridades, disponibilidad o escalados deberían ser explícitas y auditables. Una frase como “esto es urgente” aporta contexto, pero no debería sustituir por sí sola las reglas del hotel.
Habitación 527: del primer aviso a volver a utilizarla
Volvamos al ejemplo. El objetivo no es convertirlo en una receta universal, sino mostrar cómo se conectan decisiones que normalmente viven en equipos distintos.
11:20 — Aviso. Recepción registra que la cerradura de la 527 no reconoce correctamente una credencial. El sistema identifica habitación, tipo de fallo, hora y origen del aviso.
11:22 — Impacto. Existe una llegada prevista esa tarde. El hotel determina, según sus reglas, que la habitación no debe considerarse disponible para asignación mientras no se compruebe el acceso. Esa decisión pertenece al proceso autorizado del hotel; no a una inferencia libre de la IA.
11:25 — Asignación. La incidencia se envía al técnico que puede atender cerraduras electrónicas. Si la asignación se realiza por especialidad, turno o zona, la lógica debe usar esos datos reales y no un reparto rotatorio ciego.
11:48 — Intervención. El técnico sustituye un módulo y registra qué ha hecho. El trabajo concreto puede considerarse completado.
11:51 — Verificación. Se prueba la apertura con el procedimiento definido. Si la prueba falla, la incidencia vuelve a trabajo; si funciona, la parte técnica puede considerarse resuelta.
11:55 — Reconciliación con la habitación. El sistema comprueba qué condición necesita el hotel antes de volver a tratar la habitación como utilizable: quizá basta con la prueba; quizá ha entrado personal técnico y hace falta revisar o limpiar; quizá el PMS mantiene otra condición pendiente.
12:02 — Cierre. Cuando ya no queda ninguna dependencia, se actualiza el sistema que controla la disponibilidad y se cierra la incidencia con resultado verificable.
¿Y si falta el repuesto?
El caso no debería quedar simplemente “pendiente”. Conviene registrar el motivo, quién debe actuar, fecha estimada si existe y qué decisión necesita operaciones. Si la habitación no puede utilizarse, ese efecto debe quedar visible para quienes gestionan inventario y llegadas.
La automatización puede escalar el problema. No debería decidir por sí sola un cambio de habitación, una compensación o una venta alternativa.
El mismo patrón sirve para una incidencia que afecta a más de una habitación. Una fuga detectada en la 214 puede requerir trabajo sobre una tubería y, durante el diagnóstico, descubrirse humedad en la 114. El alcance inicial cambia. El proceso debe poder relacionar ambas habitaciones con la misma causa sin duplicar una avería como si fueran dos historias independientes.
El trabajo se complica cuando aparecen repuestos, proveedores, permisos y cambios de turno
Los flujos sencillos son fáciles de automatizar porque todo ocurre dentro del hotel y en pocos minutos. Las incidencias que más información pierden suelen ser las que se quedan abiertas durante horas o días.
- El técnico necesita un repuesto que no está disponible.
- La reparación requiere autorización de un responsable.
- Debe intervenir un proveedor externo.
- La habitación está ocupada y no se puede acceder todavía.
- La incidencia afecta a otro departamento.
- El responsable termina turno antes de cerrar el caso.
- La primera reparación no resuelve la causa y el problema reaparece.
- Hay varias habitaciones o zonas afectadas con ritmos distintos de recuperación.
Cuando interviene un proveedor externo, el hotel sigue necesitando un responsable interno del caso. Delegar la reparación no equivale a delegar el seguimiento. Alguien debe saber qué se ha solicitado, cuándo se espera respuesta, qué habitación sigue afectada, qué evidencia se necesita y quién valida el trabajo al terminar.
Los cambios de turno merecen la misma atención. Una incidencia abierta debería sobrevivir al cambio de persona sin depender de una conversación verbal. El nuevo responsable necesita ver contexto, prioridad, dependencias, último paso realizado y siguiente acción.
También conviene distinguir entre reapertura y nueva incidencia. Si la cerradura vuelve a fallar poco después, conservar la relación con el caso anterior ayuda a detectar reparaciones incompletas o causas recurrentes.
Esto conecta con la gestión de automatizaciones en producción: cuando un proceso depende de varios sistemas, proveedores o eventos, también hay que saber qué ocurre cuando un paso no llega, una actualización falla o una integración queda en un estado incierto.
PMS y CMMS pueden tener responsabilidades distintas
El PMS —sistema de gestión hotelera— suele concentrar información de reservas, habitaciones, huéspedes y estados relacionados con la operación del alojamiento. Un CMMS —sistema informatizado de gestión del mantenimiento— está orientado a organizar activos, incidencias, órdenes de trabajo, recursos, históricos y mantenimiento programado.
Eso no significa que todo hotel necesite dos plataformas. Algunos PMS incorporan funciones de mantenimiento; algunas herramientas de operaciones cubren tareas de varios departamentos; y hoteles con instalaciones más complejas pueden necesitar un sistema de mantenimiento específico. La arquitectura debe partir de lo que ya existe y de lo que cada herramienta hace bien.
| Dato o acción | Sistema que puede confirmarlo | Pregunta de diseño |
|---|---|---|
| Reserva y próxima llegada | PMS o sistema de reservas | ¿Hay una estancia o llegada afectada? |
| Condición de la habitación | PMS o herramienta operativa | ¿Puede asignarse, venderse o necesita otra condición? |
| Activo averiado | CMMS, inventario técnico o herramienta de mantenimiento | ¿Qué equipo es y qué historial tiene? |
| Orden de trabajo | CMMS o módulo de mantenimiento | ¿Quién debe intervenir y qué resultado se espera? |
| Proveedor y repuesto | CMMS, compras u otra herramienta | ¿Qué dependencia externa mantiene abierto el caso? |
| Cierre de incidencia | Sistema de mantenimiento definido por el hotel | ¿Qué condición permite cerrar el problema? |
Qué significan OOO y OOS
En algunas plataformas hoteleras aparecen las siglas OOO y OOS, procedentes de Out of Order y Out of Service. Son formas de indicar que una habitación tiene una restricción o no está en condiciones normales de uso, pero su significado exacto cambia según el producto.
En Oracle OPERA Cloud, por ejemplo, una habitación marcada como Out of Order se retira del inventario disponible para asignaciones, mientras Out of Service se utiliza para situaciones temporales que pueden mantenerla en inventario. Mews también diferencia ambos estados y documenta usos distintos para reparaciones menores y periodos más prolongados.
No conviene traducir esas etiquetas a una regla universal del sector. De hecho, Cloudbeds documenta otra separación importante: una habitación puede estar marcada como limpia, sucia o inspeccionada y esa condición de housekeeping no determina por sí sola si está disponible para vender. La lección no es memorizar siglas; es entender qué estado controla cada decisión en el sistema real del hotel.
Cuando varios sistemas comparten información, hay que decidir qué sistema confirma cada dato y cómo se resuelven discrepancias. Este principio se desarrolla de forma transversal en la guía sobre integración entre sistemas y autoridad del dato.
Dónde puede ayudar la IA sin convertirla en técnico, supervisor y director a la vez
El mantenimiento recibe mucha información en lenguaje natural: “la puerta hace un ruido raro”, “sale poca agua”, “la televisión se apaga sola”, “hay humedad debajo de la ventana”. Aquí la IA puede ser muy útil porque transforma mensajes poco estructurados en datos que el proceso puede manejar.
Interpretar el aviso
Extraer habitación o zona, activo probable, síntoma, momento y contexto presente en el mensaje.
Clasificar
Proponer categoría o especialidad para facilitar el enrutamiento, siempre sujeta a reglas y revisión cuando exista ambigüedad.
Resumir historial
Condensar reparaciones previas, reaperturas y notas para que el técnico no tenga que leer todo el expediente.
Detectar recurrencias
Señalar que un activo, una habitación o una causa aparecen repetidamente y merecen revisión.
También puede preparar mensajes internos, traducir descripciones o sugerir qué información falta antes de asignar el caso.
Lo que no debería hacer por sí sola es igualmente importante. La IA no confirma que una avería esté reparada porque el texto “parece positivo”; no decide que una habitación sea segura o esté disponible para vender; no autoriza compras o compensaciones; y no convierte una hipótesis de diagnóstico en un hecho.
Las reglas y las personas autorizadas gobiernan prioridades, permisos, escalados, cambios de estado y decisiones sensibles. La IA ayuda a entender y organizar información; la certeza debe venir de pruebas, sistemas y responsables definidos.
Una automatización útil también sabe cuándo el estado es incierto
El riesgo no aparece solo cuando una avería es grave. También aparece cuando el sistema cree haber ejecutado un paso y no puede demostrarlo.
- El aviso no identifica con seguridad la habitación o el activo.
- Dos incidencias parecen duplicadas, pero la coincidencia no es suficiente.
- El técnico marca terminado y la prueba posterior falla.
- La reparación se completa, pero el PMS sigue mostrando una restricción.
- El PMS actualiza la habitación, pero la herramienta de mantenimiento no recibe el cambio.
- El proveedor confirma una visita sin registrar resultado.
- Falta un repuesto y no existe fecha prevista.
- La incidencia afecta a seguridad o requiere una decisión fuera de reglas.
- El responsable cambia de turno con el caso todavía abierto.
- La integración devuelve un timeout o una respuesta ambigua.
En esos casos no conviene asumir éxito. El diseño debería utilizar estados como “pendiente de verificación”, “bloqueada por proveedor”, “actualización pendiente” o una formulación equivalente que tenga sentido para el hotel. “Error” no es una condición de cierre: es una señal de que alguien o algo tiene que actuar.
La observabilidad del proceso importa especialmente cuando hay automatizaciones que actualizan varios sistemas. Debe poder reconstruirse qué evento llegó, qué acción se intentó, qué sistema respondió y qué parte quedó pendiente. La entrada sobre monitorización de automatizaciones profundiza en esa disciplina técnica.
Medir mantenimiento exige mirar más allá del tiempo de reparación
El tiempo técnico importa, pero puede ocultar trabajo pendiente. Un hotel puede reparar rápido y seguir tardando demasiado en devolver una habitación al uso porque la información no llega a recepción, queda una limpieza pendiente o nadie actualiza el estado correcto.
| Métrica | Qué ayuda a detectar |
|---|---|
| Tiempo aviso → asignación | Cuánto tarda el problema en tener un responsable claro. |
| Tiempo asignación → inicio | Colas, carga, falta de personal o mala priorización. |
| Tiempo de intervención | Duración del trabajo una vez iniciado. |
| Tiempo bloqueado por repuesto/proveedor | Dependencias externas que explican gran parte del ciclo. |
| Tiempo trabajo terminado → verificación | Retrasos entre la reparación y la comprobación real. |
| Tiempo reparación terminada → habitación nuevamente utilizable | Descoordinación entre mantenimiento, PMS, pisos y recepción. |
| Incidencias reabiertas | Reparaciones incompletas, falsas resoluciones o verificaciones insuficientes. |
| Recurrencias por activo o habitación | Problemas repetidos que requieren una acción más profunda. |
| Habitaciones afectadas y duración | Impacto real sobre el inventario y la operación. |
| Discrepancias entre sistemas | Casos donde mantenimiento y PMS no muestran una situación coherente. |
También puede ser útil medir noches-habitación afectadas cuando una habitación ha quedado realmente fuera del inventario vendible. Pero ese dato no equivale automáticamente a ingresos perdidos. Para estimar impacto económico hacen falta demanda que realmente se hubiera podido vender, inventario alternativo y una tarifa razonable para esa fecha.
Lo mismo ocurre con métricas conocidas de mantenimiento como MTTR. Pueden resultar útiles dentro de una organización, pero no conviene convertirlas en un benchmark universal ni medir únicamente el promedio. Una media puede esconder incidencias críticas, dependencias externas y grandes diferencias entre categorías de activo.
Para definir baseline, denominadores, coste de excepción y guardarraíles de forma consistente, conviene apoyarse en el marco de KPIs de automatización de procesos.
Cómo empezar sin intentar automatizar todo el mantenimiento del hotel
Un piloto no necesita cubrir ascensores, climatización, habitaciones, cocina, piscina, instalaciones eléctricas y proveedores desde el primer día. Es más útil elegir un perímetro donde el proceso pueda observarse de principio a fin.
Por ejemplo: incidencias de habitaciones detectadas por recepción y pisos, tres o cuatro categorías frecuentes, un equipo técnico interno, integración con el PMS para consultar habitación y próxima llegada y reglas claras para escalar las excepciones.
- Seleccionar categorías de incidencia con suficiente volumen.
- Definir qué información mínima necesita cada aviso.
- Documentar qué factores cambian la prioridad.
- Asignar responsables por turno, zona o especialidad.
- Definir cuándo una reparación necesita verificación.
- Establecer quién puede cambiar la condición de una habitación.
- Preparar rutas para proveedor, repuesto y autorización.
- Registrar reaperturas y recurrencias.
- Medir antes y después con el mismo criterio.
- Probar fallos de integración y cambios de turno, no solo el recorrido perfecto.
El primer objetivo no debería ser “automatizar el 80 % de las incidencias”, sino conseguir que ningún aviso quede sin responsable, que las excepciones sean visibles y que el cierre tenga un significado claro.
Después se puede ampliar a mantenimiento programado, históricos de activos, repuestos, proveedores o análisis de recurrencia.
Qué revisaría Yarvia antes de automatizar incidencias y mantenimiento
Antes de elegir una herramienta nueva, conviene reconstruir el proceso actual con casos reales. ¿Quién detecta una avería? ¿Dónde la registra? ¿Cómo sabe mantenimiento qué atender primero? ¿Qué ocurre si hace falta un proveedor? ¿Quién decide que una habitación puede volver a utilizarse? ¿Cómo se entera recepción?
También revisaríamos qué cubre ya el PMS, si existe una herramienta específica de mantenimiento, qué integraciones permiten ambos sistemas y dónde se producen actualmente llamadas, WhatsApp, hojas de cálculo o actualizaciones duplicadas.
La salida no tiene por qué ser un CMMS nuevo. Puede ser una integración sobre las herramientas existentes, una capa de orquestación, una mejora de reglas, una interfaz móvil para el equipo, IA para estructurar avisos o una combinación de varias piezas.
El objetivo es que el hotel pueda responder a cuatro preguntas siempre: qué sigue abierto, qué impacto tiene, quién debe actuar y qué falta para cerrarlo.
Automatizar mantenimiento no es acelerar la creación de avisos. Es mantener conectados el problema técnico, la persona responsable y la consecuencia que esa incidencia tiene sobre la operación del hotel.
Preguntas frecuentes sobre automatizar el mantenimiento de un hotel
¿Hace falta un CMMS para automatizar el mantenimiento?
No necesariamente. Un CMMS puede aportar gestión específica de activos, órdenes de trabajo e históricos, pero algunos hoteles pueden cubrir parte del proceso con su PMS o una herramienta operativa. La decisión depende de complejidad, volumen, instalaciones y capacidades de integración.
¿Qué diferencia hay entre OOO y OOS?
Son siglas que utilizan algunos sistemas para Out of Order y Out of Service. Pueden representar grados distintos de restricción o indisponibilidad de una habitación, pero la semántica no es universal. Debe consultarse la documentación y configuración del PMS concreto.
¿Una incidencia puede cerrarse cuando el técnico termina?
En algunos trabajos sencillos, sí, si la propia finalización incluye una comprobación suficiente. En otros casos hace falta verificar el resultado, actualizar la habitación o esperar a otro equipo. La condición de cierre debe definirse según el tipo de incidencia.
¿La IA puede decidir qué avería es urgente?
Puede extraer señales del aviso y ayudar a clasificarlo, pero la prioridad debería gobernarse mediante reglas explícitas basadas en seguridad, impacto, ocupación, llegadas, dependencias y criterios del hotel.
¿Cómo se evita perder incidencias entre turnos?
Con un registro que conserve responsable, estado, último paso, dependencias y siguiente acción. El cambio de turno debe ser una transición del proceso, no una conversación informal que sustituye al historial.
¿Se puede automatizar también el mantenimiento preventivo?
Sí, especialmente cuando existe inventario de activos y periodicidades definidas, pero esta guía se centra en avisos e incidencias que requieren intervención. El mantenimiento programado añade calendarios, contadores, históricos y reglas propias.
Fuentes
- Oracle Hospitality OPERA Cloud — Room Maintenance. Documentación oficial utilizada para contrastar creación, asignación, seguimiento, resolución y reapertura de solicitudes de mantenimiento asociadas a habitaciones. Consultar fuente
- Oracle Hospitality OPERA Cloud — Out of Order / Out of Service. Referencia de producto para explicar que determinados PMS distinguen varios tipos de restricción sobre habitaciones y que sus efectos sobre inventario dependen de la semántica del sistema. Consultar fuente
- Mews — House use, Out of service y Out of order. Documentación oficial de producto utilizada como segundo ejemplo de que OOS/OOO son conceptos implementados por plataforma y no una taxonomía universal del sector. Consultar fuente
- Cloudbeds — Housekeeping room conditions. Documentación oficial utilizada para diferenciar condición de limpieza/inspección y disponibilidad de inventario. Consultar fuente
- IBM — Qué es un CMMS. Referencia para definir de forma comprensible qué función cumple un sistema informatizado de gestión del mantenimiento y diferenciarlo de la gestión hotelera general. Consultar fuente
- Yarvia — Automatizar housekeeping y solicitudes de huéspedes. Referencia interna para mantener la frontera entre solicitudes operativas generales durante la estancia y el proceso técnico de mantenimiento. Consultar fuente
Las capacidades, nombres de estados y efectos sobre inventario pueden variar por producto, versión y configuración. Antes de diseñar una automatización deben comprobarse las reglas reales del PMS, la herramienta de mantenimiento y las integraciones utilizadas por el hotel.
