HOTELES · RECEPCIÓN · RESERVAS · OPERACIONES · EXPERIENCIA DE HUÉSPED
Automatización para hoteles: reservas, recepción, atención al huésped y operaciones
Un hotel puede tener webchat, teléfono, email, PMS, formularios y aplicaciones distintas y seguir obligando al huésped a repetir lo mismo. La automatización útil empieza cuando cada interacción actualiza la operación correcta.
Un hotel no necesita automatizar conversaciones aisladas. Necesita que cada interacción actualice la operación correcta.
El huésped ve una sola experiencia. El hotel suele gestionarla desde varios sistemas y departamentos: reservas, recepción, housekeeping y solicitudes de huéspedes, mantenimiento, restauración, CRM, telefonía, email o herramientas de mensajería.
La automatización aporta valor cuando conecta esas capas y evita que una petición tenga que ser reinterpretada, copiada y perseguida manualmente en cada paso.
La pregunta útil no es “¿podemos poner IA en el hotel?”, sino qué evento debe actualizar qué sistema, qué tarea debe generarse y cuándo debe intervenir una persona.
El huésped no sabe cuántos sistemas tiene el hotel. Solo sabe que ya explicó lo mismo dos veces.
Una persona pregunta por web si puede llegar después de medianoche. Horas más tarde llama porque no ha recibido confirmación. Al día siguiente envía un email con una petición adicional para la habitación. Cuando llega al hotel, recepción no ve parte de ese contexto y vuelve a preguntarle.
Desde la perspectiva del huésped, ha mantenido una única relación con el hotel.
Desde la perspectiva interna pueden haber intervenido un chatbot, una bandeja de entrada, una herramienta de reservas, un PMS, una nota manual y dos personas de distintos turnos.
El problema no es necesariamente que falten herramientas. Puede ser justo lo contrario: hay suficientes herramientas, pero el estado no viaja correctamente entre ellas.
Digitalizar canales sin integrar estados puede multiplicar pantallas, no reducir trabajo.
Por eso la automatización hotelera no debería empezar enumerando chatbots, agentes de voz o asistentes de IA. Debería empezar dibujando el recorrido operativo: qué pregunta o solicita el huésped, qué dato necesita el equipo, dónde vive ese dato y qué acción tiene que ejecutarse después.
En algunos casos la respuesta será automática. En otros habrá que consultar un sistema. En otros se generará una tarea. Y en situaciones sensibles o excepcionales la mejor automatización será llevar el contexto correcto a una persona.
Qué es un PMS y por qué aparece continuamente cuando se habla de automatización hotelera
PMS son las siglas de Property Management System, que puede traducirse como sistema de gestión hotelera o sistema de gestión del establecimiento.
Es una de las aplicaciones centrales de muchos hoteles porque concentra información y operaciones relacionadas con la estancia: reservas, perfiles de huésped, habitaciones, check-in y check-out, disponibilidad operativa, pagos y, dependiendo de la solución, tareas de housekeeping, incidencias u otras funciones.
Oracle describe su OPERA Cloud PMS como una plataforma diseñada específicamente para operaciones hoteleras que centraliza datos y contempla, entre otras capacidades, reservas, perfiles, pagos, movilidad e integraciones mediante APIs abiertas.
Eso no significa que todo deba vivir en el PMS.
Un hotel puede utilizar un CRM para relación comercial, un channel manager para distribución, un motor de reservas para venta directa, una herramienta de mantenimiento, un sistema de restauración, una plataforma de mensajería o soluciones específicas de housekeeping.
Lo importante no es elegir un único software que “mande sobre todo”, sino definir qué sistema es autoridad para cada tipo de información o decisión.
| Entidad / decisión | Posible sistema de referencia | Qué debe evitarse |
|---|---|---|
| Reserva confirmada | PMS / CRS / motor de reservas según arquitectura. | Que un chatbot la “dé por confirmada” sin validación del sistema. |
| Perfil y preferencias | PMS, CRM o sistema definido. | Copias divergentes sin criterio de actualización. |
| Estado de habitación | PMS / housekeeping. | Notas manuales que no actualizan operación. |
| Incidencia técnica | Herramienta de mantenimiento / task management. | Que quede únicamente en un chat o llamada. |
| Conversación | Canal o plataforma de atención. | Confundir el canal con la fuente final de verdad. |
Esta lógica conecta con una decisión más amplia: cuándo conviene adaptar procesos a una herramienta y cuándo preservar el proceso mediante integración o automatización a medida. La guía sobre SaaS, integración o automatización a medida desarrolla ese criterio.
Los seis momentos del viaje operativo del huésped
Para detectar oportunidades sin convertir el proyecto en una colección de automatizaciones aisladas, resulta útil seguir la estancia de principio a fin.
Pre-reserva
Preguntas sobre habitaciones, servicios, ubicación, horarios, políticas, disponibilidad general o características del hotel.
Reserva y pre-estancia
Confirmaciones, datos previos a la llegada, solicitudes especiales, información práctica y preparación del contexto. Cuando la estancia corresponde a varias habitaciones y servicios coordinados, conviene tratar aparte la gestión de grupos, reservas y servicios adicionales.
Llegada
Check-in, identificación de la reserva, estado de habitación, depósitos, llaves, instrucciones y excepciones.
Estancia
Peticiones del huésped, housekeeping, mantenimiento, restauración, información local, incidencias y coordinación.
Salida
Check-out, cargos, facturación, transporte, equipaje, incidencias abiertas y cierre operativo.
Post-estancia
Encuestas, reseñas y recuperación de incidencias, fidelización, reactivación y actualización de preferencias.
En cada momento conviene responder cuatro preguntas:
- ¿Qué necesita el huésped?
- ¿Qué información necesita el hotel para responder o actuar?
- ¿Qué sistema tiene autoridad sobre esa información?
- ¿La siguiente acción puede automatizarse o debe escalarse?
El objetivo es mantener continuidad. Una petición realizada antes de la llegada no debería desaparecer cuando empieza la estancia. Una incidencia ocurrida durante la estancia no debería perderse al hacer check-out. Y una preferencia validada puede tener valor en futuras reservas si la política de datos y el sistema lo permiten.
Canal ≠ fuente de verdad
El huésped puede contactar por teléfono, webchat, email, formulario, WhatsApp u otro canal disponible. Cada uno tiene ventajas distintas, pero ninguno debería decidir por sí solo el estado real de una operación.
Un asistente puede explicar el horario del desayuno utilizando una base de conocimiento fiable. Pero si responde a una pregunta sobre una reserva concreta, necesita consultar el sistema correspondiente.
Una llamada puede generar una solicitud de cuna. Pero esa petición debería convertirse en un dato o tarea accesible para quien debe ejecutarla.
Un email puede contener una petición de late check-out. Pero recibir el email no significa que la petición esté autorizada.
Canal
Recibe o entrega una interacción: teléfono, email, webchat, mensajería, mostrador.
Fuente de verdad
Conserva el estado que el hotel considera operativo y verificable para una entidad concreta.
Esta diferencia es importante para agentes de voz y chatbots. La guía sobre agentes de voz para empresas explica por qué una conversación no llega a producción solo por entender bien el lenguaje: necesita herramientas, contexto, transferencia humana y verificación.
En un hotel, esa necesidad es todavía más visible porque una respuesta puede afectar a una reserva, una habitación, una petición operativa o una incidencia.
Dónde encajan las reservas sin convertir este artículo en una guía de distribución hotelera
Las reservas son una pieza central de la experiencia, pero aquí las tratamos dentro del recorrido general del hotel, sin entrar todavía en su arquitectura técnica en profundidad.
La distinción que sí necesitamos establecer es sencilla:
Responder una pregunta sobre una reserva no es lo mismo que crear, modificar o confirmar una reserva.
Oracle documenta que OPERA Cloud permite crear, actualizar, copiar y cancelar reservas, consultar disponibilidad y tarifas, trabajar con depósitos, perfiles y asignaciones de habitación. Es decir, una reserva no es un mensaje de texto: es una entidad operativa conectada con inventario, huésped, condiciones y estancia.
Por eso un chatbot puede explicar una política general sin consultar nada, pero para afirmar que hay disponibilidad a una tarifa determinada o que una reserva ha sido modificada necesita obtener una respuesta válida del sistema que corresponda.
Regla de diseño: la conversación puede iniciar la intención; el sistema autorizado debe confirmar la operación.
La guía sobre automatización de reservas hoteleras desarrolla disponibilidad, tarifa, confirmación, cambios, cancelaciones, PMS, CRS y motor de reservas con más profundidad. Aquí nos interesa únicamente entender que las reservas condicionan otras etapas del viaje y no deben tratarse como una conversación desconectada.
Recepción no es solo un mostrador: es un nodo de decisión
En recepción convergen información comercial, operación, incidencias, ocupación, preferencias y expectativas del huésped.
Eso hace que muchas propuestas de “automatizar recepción” estén mal formuladas desde el principio.
La pregunta no debería ser:
“¿Cómo sustituimos recepción?”
Sino:
“¿Qué tareas repetitivas podemos resolver antes de que lleguen a recepción y qué contexto podemos entregar cuando sí hace falta una persona?”
ITH ha planteado en 2026 la recepción como un punto donde confluyen microdecisiones y contexto operativo. Aunque su artículo tiene una orientación editorial y comercial propia, refleja una realidad reconocible del sector: recepción no solo ejecuta check-ins; también coordina prioridades, excepciones y decisiones rápidas.
Automatizar alrededor de recepción puede incluir:
- Responder preguntas repetitivas antes de que lleguen al mostrador;
- Identificar automáticamente la reserva asociada a una llamada o conversación cuando exista base legal y técnica;
- Preparar información previa a la llegada;
- Crear tareas para otros departamentos;
- Avisar de cambios relevantes;
- Priorizar incidencias;
- Registrar contexto para el siguiente turno;
- Escalar a una persona cuando la situación requiere criterio.
La automatización buena no elimina el contexto humano. Evita que las personas tengan que reconstruirlo desde cero.
Qué es housekeeping y por qué forma parte de la experiencia aunque el huésped casi nunca vea el sistema
Housekeeping es el término habitual en hotelería para el área de pisos, limpieza y preparación de habitaciones. Incluye tareas como limpieza, puesta a punto, cambios de ropa, reposición de suministros, preparación para nuevas llegadas y determinadas solicitudes relacionadas con la habitación.
No es simplemente “limpieza”. Es una función operativa conectada con el estado real de cada habitación y con la experiencia del huésped.
Oracle documenta, por ejemplo, que una reserva puede incorporar horarios solicitados de limpieza, servicio de cobertura, instrucciones de habitación, prioridades y tareas programadas de housekeeping.
Eso demuestra por qué una petición como:
“Por favor, que limpien la habitación después de las 15:00”
No debería quedarse como una frase en un chat.
Debe transformarse, cuando corresponda, en información o tarea visible para el equipo que la ejecuta.
Capturar una petición no equivale a resolverla.
La misma lógica se aplica a mantenimiento. Si un huésped informa de que el aire acondicionado no funciona, el trabajo no termina cuando el chatbot responde “gracias por avisarnos”.
Hay que crear una incidencia, identificar la habitación, asignar responsable, determinar prioridad, registrar resultado y saber si el problema quedó cerrado.
De petición del huésped a tarea cerrada
Una de las mejores formas de evaluar automatización hotelera es seguir una solicitud hasta el final.
Por ejemplo:
Ese patrón sirve para almohadas, amenities, horarios de limpieza, incidencias técnicas, equipaje, transporte o muchas solicitudes operativas.
La diferencia entre un chatbot y una automatización de operación está precisamente ahí: la automatización continúa después de entender el mensaje.
El cambio de turno también es un problema de integración
En un hotel, el contexto no solo cambia de sistema. También cambia de persona y de turno.
Una solicitud puede empezar por la mañana, seguir abierta por la tarde y necesitar una decisión del turno de noche. Si la información relevante vive únicamente en la memoria de quien recibió la petición, en una nota informal o en un chat interno difícil de consultar, el problema reaparece aunque todos los sistemas estén digitalizados.
Por eso una automatización hotelera debería distinguir entre conversación, tarea, estado y contexto de relevo.
Un relevo útil no consiste en copiar todo lo ocurrido durante el turno. Consiste en que el siguiente equipo pueda ver qué sigue abierto, qué prioridad tiene, qué se prometió al huésped y qué acción está pendiente.
Ejemplo: un huésped informa a las 17:30 de una incidencia en la habitación. Mantenimiento interviene, pero la reparación queda pendiente de una pieza. A las 23:00 el turno de noche no necesita releer toda la conversación; necesita saber que la incidencia sigue abierta, qué solución temporal se ofreció y qué debe ocurrir por la mañana.
Este tipo de continuidad es especialmente importante en hoteles porque la operación no se detiene al terminar una jornada administrativa. Una arquitectura bien diseñada puede generar resúmenes de pendientes, conservar trazabilidad y mantener responsables claros sin obligar a cada turno a reconstruir el historial desde múltiples canales.
La automatización aquí no sustituye el briefing entre equipos. Hace que ese briefing parta de estados verificables y no de memoria fragmentada.
Verde, ámbar o rojo: una forma sencilla de decidir qué automatizar
No todas las interacciones requieren el mismo nivel de autonomía.
Una matriz sencilla puede ayudar durante el diagnóstico. No es universal ni sustituye el análisis del hotel, pero obliga a diferenciar riesgo y variabilidad.
VERDE — Automatización directa
Preguntas repetitivas, información estable, tareas reversibles y acciones con reglas claras y sistema verificable.
ÁMBAR — Automatización con control
Casos donde hay contexto, excepciones, impacto operativo o necesidad de consultar varias fuentes antes de actuar.
ROJO — Escalado humano
Conflictos, compensaciones, seguridad, situaciones sensibles, decisiones comerciales excepcionales o acciones difíciles de revertir.
| Interacción | Posible nivel | Por qué |
|---|---|---|
| Horario del desayuno | Verde | Información estable si la fuente está actualizada. |
| Solicitar almohada adicional | Verde/ámbar | Puede crear tarea si hay disponibilidad y reglas claras. |
| Late check-out | Ámbar | Puede depender de ocupación, tarifa o autorización. |
| Queja por ruido | Ámbar/rojo | Necesita contexto y puede requerir decisión humana. |
| Compensación económica | Rojo | Impacto comercial y criterio. |
| Problema de seguridad | Rojo | Debe escalarse de forma inmediata según protocolo. |
Reglas primero cuando bastan; IA cuando hay variabilidad real
Un hotel puede beneficiarse de IA sin convertir cada workflow en un agente.
Si la condición es:
“Cuando una habitación pase a lista, avisar a recepción”
No hace falta un modelo de lenguaje para decidirlo.
Si el sistema debe entender una petición escrita de formas muy diferentes —“¿podríais subir dos almohadas más?”, “necesitamos un cojín extra”, “faltan almohadas”— la IA puede ayudar a interpretar intención y contexto.
La arquitectura puede combinar:
Reglas y workflows
Estados, horarios, vencimientos, asignaciones, condiciones de negocio, tareas conocidas y comprobaciones deterministas.
IA y agentes
Lenguaje natural, ambigüedad, clasificación, resumen, selección contextual de herramientas o situaciones con múltiples caminos posibles.
El criterio no debe ser “usar más IA”, sino utilizar el mecanismo más simple que resuelva el problema con suficiente control.
Esta diferencia será el centro de una futura pieza específica sobre workflow frente a agente de IA.
Arquitectura orientada a eventos: que el sistema reaccione cuando ocurre algo
Muchas automatizaciones funcionan comprobando periódicamente si algo ha cambiado.
Por ejemplo: cada cinco minutos consultar si una habitación ya está lista.
Otra forma es trabajar con eventos.
Un evento es simplemente un cambio relevante que puede disparar una acción:
- Reserva creada;
- Reserva modificada;
- Huésped próximo a llegar;
- Check-in realizado;
- Habitación marcada como lista;
- Habitación fuera de servicio;
- Incidencia creada;
- Check-out realizado.
Oracle documenta “Business Events” en OPERA Cloud precisamente para activar mensajes hacia sistemas externos cuando ocurren determinados cambios en módulos como reservas, perfiles, disponibilidad, tarifas, housekeeping o estancias.
Explicado sin jerga: en vez de que una automatización pregunte continuamente “¿ha cambiado algo?”, el sistema puede avisar “ha ocurrido este cambio; actúa ahora”.
Eso permite construir cadenas como:
Habitación lista → actualizar estado → avisar a recepción → continuar check-in
O bien:
Incidencia de mantenimiento cerrada → actualizar tarea → retirar bloqueo → informar al responsable.
No todos los sistemas permiten el mismo nivel de eventos ni todas las arquitecturas necesitan tiempo real. El valor está en reconocer que una operación hotelera puede diseñarse alrededor de cambios de estado, no solo de tareas programadas.
Privacidad y permisos: no todos los departamentos necesitan ver lo mismo
Un hotel puede acumular información de contacto, identificación, preferencias, estancias, pagos, incidencias y solicitudes.
Que exista técnicamente no significa que deba circular completa por todos los sistemas o llegar a todos los departamentos.
La AEPD recuerda en su documentación sobre protección de datos por defecto que deben limitarse cantidad de datos, extensión del tratamiento, conservación y accesibilidad a lo necesario.
Traducido a operación:
- Housekeeping puede necesitar saber una instrucción de habitación sin acceder a toda la ficha del huésped;
- Mantenimiento necesita habitación, incidencia y prioridad, no necesariamente información comercial;
- Un chatbot no debería exponer datos de reserva sin controles adecuados;
- Las preferencias que se conservan deben tener una finalidad clara;
- Las integraciones deben utilizar permisos acordes a lo que realmente necesitan hacer.
Diseñar bien la automatización implica reducir movimiento innecesario de datos, no replicarlos por comodidad.
Interoperabilidad: tener datos no basta si no llegan donde se toman las decisiones
El sector turístico está avanzando en iniciativas de intercambio estructurado de datos. SEGITTUR e ITH anunciaron en junio de 2026 una colaboración para integrar datos hoteleros en la Plataforma Inteligente de Destinos, y SEGITTUR mantiene iniciativas relacionadas con espacios de datos y normalización orientadas a interoperabilidad.
No significa que la arquitectura interna de un hotel deba copiar esos proyectos.
La enseñanza aplicable es más sencilla: el valor del dato depende también de que pueda circular de forma controlada y útil entre los actores que lo necesitan.
En un hotel, la interoperabilidad práctica puede ser tan concreta como:
- Que una reserva actualice el perfil correcto;
- Que una solicitud del huésped cree una tarea;
- Que housekeeping vea una instrucción relevante;
- Que una incidencia cambie el estado de una habitación;
- Que el check-out cierre tareas pendientes o genere seguimiento;
- Que recepción no tenga que copiar manualmente información de un sistema a otro.
Cómo diagnosticar oportunidades de automatización en un hotel
El análisis puede empezar sin comprar ninguna herramienta nueva.
- Elegir un momento del viaje. Por ejemplo, pre-estancia o estancia.
- Listar interacciones reales. Preguntas, solicitudes, incidencias y tareas repetitivas.
- Identificar canales. Teléfono, email, web, recepción, aplicaciones.
- Identificar sistemas de referencia. Qué aplicación tiene autoridad para cada dato o estado.
- Detectar transcripciones manuales. Dónde alguien copia información entre pantallas.
- Separar respuesta de acción. Qué casos terminan al informar y cuáles exigen una tarea.
- Clasificar verde / ámbar / rojo. Qué puede automatizarse, qué necesita control y qué debe escalar.
- Definir excepciones. Qué ocurre cuando falta información, el sistema no responde o la solicitud no puede cumplirse.
- Medir el ciclo completo. No solo tiempo de respuesta, también tiempo hasta resolución.
Este diagnóstico ayuda a evitar proyectos que empiezan por una herramienta concreta.
La pregunta no es “¿dónde podemos poner un chatbot?”. Puede ser:
“¿Qué interacciones repetitivas consumen tiempo, pierden contexto o generan errores porque atraviesan demasiados sistemas?”
La guía sobre automatización documental con IA desarrolla un principio parecido aplicado a documentos: entender una entrada no equivale a completar el proceso. En hotelería ocurre lo mismo con las conversaciones.
Qué métricas importan más que el número de conversaciones automatizadas
Un chatbot puede atender miles de mensajes y no mejorar la operación si las solicitudes terminan igualmente en una bandeja que alguien debe revisar.
Por eso conviene medir resultados más próximos al proceso:
- Tiempo desde petición hasta resolución;
- Porcentaje de solicitudes resueltas sin transferencia;
- Transferencias correctamente contextualizadas;
- Incidencias reabiertas;
- Peticiones duplicadas;
- Tiempo de respuesta por canal;
- Tiempo de ejecución de housekeeping o mantenimiento cuando proceda;
- Errores por información desactualizada;
- Número de sistemas que una persona debe consultar para resolver un caso;
- Y satisfacción del huésped en los puntos donde tenga sentido medirla.
No todas las métricas son necesarias en todos los hoteles. El objetivo es comprobar si se reduce fricción tanto para el huésped como para el equipo.
Dónde suele aparecer el mayor potencial
No hay una lista universal, pero determinados patrones merecen atención:
| Patrón | Señal | Oportunidad |
|---|---|---|
| Preguntas repetidas | Recepción responde lo mismo por varios canales. | Base de conocimiento + atención automatizada. |
| Peticiones sin trazabilidad | Se anotan en papel, chats o memoria. | Conversación → tarea → estado → cierre. |
| Información fragmentada | El contexto está en varias pantallas. | Integración y vista contextual. |
| Llamadas perdidas | Picos de demanda o atención fuera de horario. | Agente de voz con integración y transferencia. |
| Copiado manual | Datos repetidos entre sistemas. | Sincronización e integración. |
| Decisiones recurrentes | El equipo aplica reglas conocidas a mano. | Workflow con reglas y excepciones. |
| Excepciones mal escaladas | El huésped repite el problema varias veces. | Contexto persistente + routing. |
Automatizar un hotel no significa convertirlo en un hotel sin personas
Hospitalidad y automatización no son conceptos opuestos.
Un mal proceso puede obligar al huésped a repetir información, esperar respuestas o comprobar varias veces si una petición se ha atendido. Un buen sistema puede reducir precisamente esas fricciones y dejar más capacidad humana para situaciones donde importan empatía, criterio y capacidad de resolver excepciones.
La automatización útil no busca que todos los contactos sean automáticos. Busca que los contactos sencillos no consuman recursos innecesarios y los complejos lleguen a la persona adecuada con el contexto preparado.
Por eso un hotel no necesita automatizar conversaciones aisladas.
Necesita que cada interacción actualice la operación correcta.
¿Tu hotel tiene muchos canales y sistemas, pero el equipo sigue moviendo información manualmente entre ellos?
Podemos mapear reservas, recepción, atención al huésped y operación para detectar qué interacciones conviene automatizar, qué sistemas deben integrarse y dónde debe mantenerse la decisión humana. También puedes consultar nuestras soluciones de automatización para hoteles.
Mapear procesos del hotelFuentes
- Oracle Hospitality — OPERA Cloud Property Management.
Descripción oficial de OPERA Cloud PMS, sus funciones de gestión hotelera, centralización de datos, movilidad e integraciones.
Consultar fuente - Oracle Hospitality — Reservations.
Documentación oficial sobre creación, actualización y cancelación de reservas, disponibilidad, depósitos, perfiles y asignaciones de habitación.
Consultar fuente - Oracle Hospitality — Reservation Housekeeping and Task Schedule.
Documentación oficial sobre horarios de limpieza, instrucciones de habitación, solicitudes de servicio y tareas asociadas a reservas.
Consultar fuente - Oracle Hospitality — Configuring Business Events.
Referencia oficial sobre eventos de negocio que disparan mensajes hacia sistemas externos en módulos como reservas, perfiles, tarifas y housekeeping.
Consultar fuente - Instituto Tecnológico Hotelero — La recepción como sistema de decisión.
Artículo sectorial publicado el 13 de marzo de 2026 sobre contexto operativo, decisiones y papel de la recepción. Se utiliza como fuente de contexto sectorial, no como evidencia neutral de mercado.
Consultar fuente - SEGITTUR — Integración de datos hoteleros en la Plataforma Inteligente de Destinos.
Nota del 30 de junio de 2026 sobre colaboración con ITH para integrar datos hoteleros y convertirlos en información útil para decisión y competitividad.
Consultar fuente - SEGITTUR — Espacio de Datos de Turismo.
Referencia institucional sobre intercambio voluntario, estructurado y controlado de datos entre actores del sector turístico.
Consultar fuente - Agencia Española de Protección de Datos — Protección de datos por defecto.
Referencia oficial sobre minimización de cantidad de datos, extensión del tratamiento, conservación y accesibilidad.
Consultar fuente
Las capacidades de PMS, plataformas hoteleras, APIs e integraciones cambian con el tiempo. Antes de diseñar una implantación deben verificarse la documentación vigente, la arquitectura real del hotel, sus sistemas de referencia, permisos y procesos operativos.
