HOTELES · POST-ESTANCIA · AUTOMATIZACIÓN · IA
Cómo automatizar el seguimiento post-estancia de un hotel
El check-out termina la estancia, pero puede dejar asuntos abiertos. Una encuesta, una reclamación, una recuperación de servicio y una solicitud de reseña no son la misma conversación. Automatizar bien el post-estancia exige saber qué sigue pendiente antes de enviar el siguiente mensaje.
El error no es enviar una encuesta demasiado pronto. Es que cada sistema actúe como si el check-out significara lo mismo para todos.
Un proceso post-estancia fiable comprueba qué sigue abierto: feedback, incidencia, recuperación y comunicaciones previas. La IA puede interpretar texto libre y preparar contexto; las reglas deciden qué comunicación procede y qué acciones requieren autorización.
El check-out no siempre cierra el trabajo del hotel
Un huésped abandona el hotel a las once. A las dos horas recibe una encuesta automática. Mientras tanto, recepción mantiene abierta una reclamación sobre un cargo, marketing tiene programado un correo genérico de agradecimiento y, al día siguiente, otra herramienta envía una petición de reseña. Cada acción puede ser razonable por separado. Juntas, pueden transmitir que el hotel no sabe lo que está ocurriendo.
La alternativa no es añadir más reglas aisladas a cada email. Es tratar el post-estancia como un proceso con estados. Antes del siguiente contacto, la automatización debe saber si la estancia está cerrada en el sistema, si hay un caso abierto, si el huésped ya respondió, si existe una recuperación en curso y qué mensajes se han enviado. El reloj puede indicar cuándo revisar; el estado debe indicar qué hacer.
La entrada general sobre automatización para hoteles recorre el viaje completo del huésped. Aquí nos quedamos deliberadamente después de la salida: escuchar, resolver, recuperar y gestionar la reputación sin mezclar esas funciones.
Cuatro conversaciones distintas después de la salida
Una de las decisiones más útiles es dejar de hablar de “el seguimiento post-estancia” como si fuera una sola conversación. En realidad, el hotel puede estar gestionando cuatro finalidades diferentes.
1. Escuchar
Feedback interno. Saber cómo fue la estancia y detectar información que pueda requerir actuación. Una valoración o un comentario no se convierte automáticamente en incidencia.
2. Resolver
Incidencia o asunto pendiente. Existe un problema concreto que necesita propietario, siguiente acción y condición de cierre, aunque la estancia ya haya terminado.
3. Recuperar
Recuperación de servicio. El hotel decide intervenir de forma específica ante una experiencia problemática: revisar, explicar, disculparse, corregir o aplicar una acción autorizada.
4. Reputación y relación
Reseña pública, respuesta y CRM. Solicitar una reseña de forma neutral cuando proceda, responder a contenido publicado y conservar solo la información útil y justificada para futuras interacciones.
El mismo huésped puede pasar por varias de estas conversaciones. Lo importante es que cada una tenga una finalidad, un responsable y una salida clara. Una encuesta respondida no cierra por sí sola una reclamación; una disculpa enviada no significa que la recuperación esté completada; una reseña publicada no autoriza a copiar todo su contenido al perfil del huésped.
Antes del siguiente mensaje, comprobar qué estados siguen abiertos
No hace falta construir una máquina de estados gigantesca. Sí hace falta evitar que todo quede reducido a “estancia finalizada”. Como mínimo, el proceso debe poder consultar algunos objetos relacionados.
| Objeto | Preguntas que debe responder | Ejemplo de siguiente acción |
|---|---|---|
| Estancia | ¿El check-out está confirmado? ¿La estancia está cerrada según el sistema? | Iniciar revisión post-estancia. |
| Feedback | ¿Se solicitó? ¿Se recibió? ¿Contiene algo accionable? | Registrar, clasificar o abrir revisión. |
| Incidencia | ¿Existe? ¿Está abierta, asignada, resuelta o reabierta? | Continuar resolución y evitar mensajes incompatibles. |
| Recuperación | ¿Se ha decidido intervenir? ¿Hay acción autorizada o respuesta pendiente? | Asignar, aprobar, comunicar o cerrar. |
| Comunicación | ¿Qué se envió ya? ¿Hay recordatorios programados? | Enviar, cancelar o deduplicar. |
| Reseña | ¿Se solicitó de forma neutral? ¿Existe una reseña que necesite respuesta? | Solicitar conforme a política o preparar respuesta. |
La regla práctica es sencilla: antes de automatizar un mensaje, comprobar los estados que pueden volverlo incorrecto. Si hay una reclamación abierta, puede ser absurdo enviar “esperamos que todo haya sido perfecto”. Si el huésped ya completó la encuesta, no tiene sentido mantener tres recordatorios activos. Si existe una acción de recuperación pendiente de aprobación, conviene que el sistema no prometa una solución que todavía no está autorizada.
El check-out puede ser el disparador sin depender de una lista de Excel
En muchos equipos el seguimiento empieza con una exportación diaria: alguien descarga los check-outs, limpia la lista y la entrega a marketing o recepción. Ese mecanismo puede funcionar, pero añade retrasos, trabajo manual y riesgo de duplicados.
Los sistemas hoteleros actuales pueden ofrecer APIs o eventos que permiten reaccionar a cambios de estado. Cloudbeds, por ejemplo, documenta comunicación posterior a la salida y webhooks cuando una reserva pasa a estado checked_out. Esto no significa que todos los PMS funcionen igual ni que deban utilizar esa misma etiqueta. Sirve para ilustrar un patrón: cuando el sistema confirma la salida, la automatización recibe el evento y empieza a comprobar qué procede.
El evento no debe activar directamente una cadena ciega de emails. Su función es abrir el proceso. A partir de ahí, la automatización consulta otros estados y aplica las reglas del hotel. En propiedades con varios sistemas, el reto suele estar menos en detectar el check-out que en coordinar qué aplicación conoce una incidencia, cuál gestiona el CRM y cuál ha enviado ya una comunicación.
Feedback interno: escuchar no significa abrir una incidencia por cada comentario
Una encuesta post-estancia puede producir una puntuación, varias respuestas estructuradas y texto libre. Ese material es útil precisamente porque no todo significa lo mismo. “El desayuno podría empezar antes” puede ser una sugerencia; “la habitación estaba fría” puede requerir contexto; “me cobraron un consumo que no hice” sí puede necesitar una revisión concreta.
Un buen flujo separa clasificar de actuar. Primero identifica el tipo de comentario, el tema y si existe suficiente información. Después decide si basta con registrar un dato agregado, si hay que pedir aclaración, si debe buscarse un caso ya abierto o si procede crear una incidencia nueva.
También conviene evitar el extremo contrario: guardar cada frase como una nota permanente del huésped. Un comentario sobre una avería pertenece principalmente al caso de servicio y al aprendizaje operativo. No es una característica del cliente. Si todo acaba en el CRM, el perfil se llena de contexto antiguo, inferencias y detalles que luego aparecen en situaciones donde ya no aportan nada.
Una incidencia puede venir de la estancia o descubrirse después
Hay dos situaciones especialmente importantes. La primera es que la incidencia ya exista antes del check-out. En ese caso, el seguimiento post-estancia debe encontrarla y continuarla, no crear una copia. La segunda es que el problema aparezca por primera vez en el feedback: el huésped cuenta algo que nunca quedó registrado durante la estancia.
En ambos casos, la automatización debería buscar primero si existe un caso relacionado. Puede utilizar identificadores de estancia, reserva, huésped, habitación, fecha o referencias del sistema para reducir duplicados. Si encuentra una incidencia abierta, añade el nuevo contexto y mantiene el responsable. Si no existe y el comentario exige actuación, crea o deriva un caso según las reglas definidas.
El detalle de cómo pisos, recepción o mantenimiento ejecutan ese trabajo pertenece al proceso operativo durante la estancia, que desarrollamos en la guía sobre housekeeping y solicitudes de huéspedes. En esta fase interesa el relevo: feedback recibido → caso localizado o creado → responsable → seguimiento → cierre.
Ejemplo: problema descubierto tras la salida
Un huésped escribe: “El aire acondicionado no funcionó durante la noche y al final no dije nada porque salíamos temprano”. La IA puede detectar el tema y resumir el mensaje. Las reglas comprueban si existía una incidencia asociada a esa habitación y estancia. Si no existe, el sistema crea una revisión para operaciones y conserva el vínculo con el feedback original. La IA no decide que la avería está confirmada ni que deba existir una compensación.
Recuperación del huésped: resolver una mala experiencia sin convertirla en una campaña
En este contexto, recuperar al huésped significa recuperación de servicio: gestionar de forma específica una experiencia problemática. No es sinónimo de “mandarle una promoción para que vuelva”. Antes de pensar en marketing, el hotel tiene que decidir si existe algo que reconocer, revisar o corregir.
La recuperación puede incluir una disculpa, una explicación, una llamada, una acción correctiva o una compensación. Pero esas acciones no deberían quedar al criterio libre de una IA. El hotel debe fijar qué puede hacer cada perfil, qué necesita aprobación y qué límites existen. Una devolución, un descuento, una noche futura o cualquier compromiso económico tienen consecuencias que requieren reglas y trazabilidad.
Recuperar el contexto
Qué ocurrió, qué se hizo durante la estancia, qué dice ahora el huésped y qué información está verificada.
Determinar la acción permitida
Respuesta, revisión, llamada, corrección o propuesta de compensación dentro de las reglas.
Obtener aprobación cuando proceda
Las acciones sensibles quedan pendientes hasta que una persona o regla autorizada las valide.
Comunicar y registrar
El huésped recibe una respuesta coherente con lo realmente aprobado y el sistema conserva el resultado.
Cerrar con una condición real
No basta con que el email se haya enviado. El proceso termina cuando se cumple la salida definida para ese tipo de recuperación.
Solicitar reseñas sin crear un filtro de huéspedes satisfechos
Existe una práctica muy extendida: primero se pregunta al huésped cómo fue la estancia; si responde con una puntuación alta, se le manda a Google; si la puntuación es baja, se le lleva a un formulario privado. Puede parecer una forma lógica de proteger la reputación, pero no es una buena regla para diseñar el proceso.
La política actual de Google Maps prohíbe desaconsejar reseñas negativas y solicitar reseñas positivas de forma selectiva. También prohíbe ofrecer incentivos a cambio de reseñas o pedir una valoración concreta. Google sí permite solicitar reseñas que reflejen una experiencia auténtica y facilita enlaces o códigos QR que pueden compartirse, por ejemplo, en emails de agradecimiento o WhatsApp.
La puntuación interna no debe convertirse en una puerta de acceso a Google. Si se automatiza la solicitud, hay que usar criterios neutrales y respetar la política vigente de la plataforma.
La diferencia importante
Feedback interno sirve para calidad y operación. Reseña pública la publica el huésped en una plataforma externa bajo las reglas de esa plataforma. La encuesta interna no debe convertirse en un sistema de cribado de quién “merece” recibir el enlace público.
Cuando la reseña pública llega antes que la encuesta
El recorrido real no siempre respeta el orden que diseña el hotel. Un huésped puede publicar una reseña desde el taxi, antes de abrir la encuesta interna. Ese escenario muestra por qué reputación e incidencias deben estar conectadas, pero no fusionadas.
Si la plataforma o la herramienta de reputación detecta una nueva reseña, la automatización puede clasificar su tema, buscar contexto mínimo y generar una tarea de revisión. Si el contenido menciona un problema operativo, el sistema puede comprobar si existe una incidencia relacionada. Si no existe suficiente certeza para vincular reseña y estancia, no debe inventar esa relación.
La respuesta pública también necesita límites. Puede prepararse un borrador, pero no conviene exponer fechas, número de habitación, cargos, información médica o detalles internos que el huésped no haya hecho públicos. En casos sensibles, una persona debe revisar la respuesta antes de publicarla.
Dónde puede ayudar la IA en el post-estancia
Este proceso tiene una zona especialmente adecuada para IA: el lenguaje libre. Encuestas abiertas, emails, conversaciones, reseñas y reclamaciones llegan con formas muy distintas. Convertir ese texto en contexto útil es un trabajo que tradicionalmente exige leer, resumir y clasificar de forma manual.
La IA puede clasificar feedback por tema, resumir comentarios largos o multilingües, extraer datos presentes en el mensaje, detectar posibles duplicados semánticos, agrupar patrones recurrentes y preparar borradores de respuesta basados en hechos verificados. También puede ayudar a identificar cuándo falta información y conviene pedir una aclaración antes de actuar.
Donde no debería tener libertad es en las consecuencias. No debe cerrar una incidencia porque el tono parece satisfecho, autorizar una compensación, inferir consentimiento para marketing, convertir una queja en una preferencia permanente o decidir que solo los huéspedes positivos recibirán una solicitud de reseña.
Patrón Yarvia: IA interpreta y asiste → reglas consultan estados y permisos → una persona autoriza cuando hay impacto sensible → el sistema ejecuta y verifica.
PMS, CRM, incidencias, reputación y mensajería: no todos deben guardar lo mismo
No existe una arquitectura hotelera universal. El objetivo no es imponer herramientas, sino definir qué responsabilidad tiene cada sistema y qué información necesita compartir.
PMS
Puede confirmar estancia, fechas, salida, perfil y otros datos operativos según producto y configuración.
CRM
Puede gestionar relación, segmentos, historial comunicacional y preferencias justificadas según la arquitectura.
Incidencias u operaciones
Mantiene casos, responsables, estados y condiciones de cierre cuando el PMS no cubre esa función o no es el lugar adecuado.
Feedback y reputación
Puede enviar encuestas, recibir respuestas, monitorizar reseñas o facilitar solicitudes, siempre sujetas a las reglas de cada plataforma.
En la práctica, esas funciones pueden repartirse entre soluciones especializadas. Por ejemplo, Shiji ReviewPro y TrustYou trabajan sobre feedback, encuestas y reputación hotelera, mientras que Revinate combina capacidades de datos de huésped, CRM y gestión de feedback. Se citan como ejemplos del ecosistema, no como una arquitectura recomendada: un hotel puede utilizar otras herramientas o concentrar varias funciones en una misma plataforma.
La automatización u orquestador se sitúa entre esas piezas para coordinar eventos, consultar estados, evitar mensajes incompatibles y mantener referencias comunes. La mensajería —email, WhatsApp u otros canales— sirve para comunicar; no debería convertirse por sí sola en el registro definitivo de que una incidencia está resuelta.
Cuando varios sistemas escriben sobre el mismo proceso, aparece el riesgo de duplicados y contradicciones. Para profundizar en autoridad, sincronización y control entre aplicaciones, la referencia transversal es nuestra guía sobre integración entre sistemas empresariales.
Qué guardar en el perfil del huésped y qué debería quedarse en el caso
El post-estancia produce información valiosa, pero eso no significa que todo deba convertirse en memoria permanente. Oracle OPERA Cloud, por ejemplo, diferencia perfiles, preferencias y registros de estancia. Esa separación es útil como idea de diseño: una preferencia del huésped no es lo mismo que una avería que ocurrió en una habitación concreta.
La IA añade otra precaución: una inferencia no es un hecho. Si un modelo interpreta que un huésped “prefiere hoteles silenciosos” a partir de una queja puntual por ruido, eso no debería convertirse automáticamente en una característica estable de su perfil.
Evitar encuestas duplicadas y comunicaciones que se contradicen
Los fallos más visibles del post-estancia suelen ser pequeños: dos encuestas para la misma estancia, un recordatorio después de que el huésped ya respondió, una petición de reseña que se repite o un email promocional mientras existe una reclamación abierta. El problema de fondo es que cada herramienta mantiene su propia agenda.
Para reducirlo conviene usar identificadores de estancia, huésped, comunicación y caso cuando la arquitectura lo permita. Si un evento de check-out se procesa dos veces, el segundo intento debe poder reconocer que la acción ya se ejecutó. Si una encuesta fue respondida, los recordatorios pendientes deben cancelarse. Si un caso cambia de estado, las comunicaciones incompatibles deben revisarse.
Mensaje enviado no significa proceso cerrado
Cada conversación post-estancia necesita una condición de salida. Sin ella, las automatizaciones se convierten en secuencias que siguen activas aunque el asunto real ya haya cambiado.
| Proceso | Puede considerarse terminado cuando… |
|---|---|
| Feedback | Se recibió y clasificó, o se cerró según la política interna; cualquier elemento accionable quedó relacionado con un caso. |
| Incidencia | Se cumple la condición real de cierre, existe resultado registrado y no quedan dependencias pendientes. |
| Recuperación | La acción aprobada se ejecutó y comunicó, y el seguimiento adicional quedó resuelto o asignado. |
| Solicitud de reseña | Se envió de forma neutral conforme a la política aplicable o se decidió no utilizar ese canal por una regla neutral y documentada. |
| Respuesta pública | La respuesta se publicó o el caso se escaló/archivó según la política del hotel. |
Esta separación evita falsos positivos. Un email de disculpa puede estar enviado mientras la compensación sigue pendiente. Una incidencia puede aparecer como “resuelta” en una herramienta mientras el huésped comunica que el problema continúa. Una reseña puede tener borrador preparado y seguir esperando revisión.
Cinco escenarios que prueban si el diseño funciona
1. Estancia sin incidencias
El check-out activa el proceso y no existe caso abierto. Se envía la comunicación prevista; si se solicita una reseña pública, se hace de forma neutral y sin usar la valoración interna como filtro.
2. Incidencia abierta antes del check-out
La estancia termina con una reclamación todavía en curso. El sistema evita comunicaciones incompatibles y mantiene responsable y seguimiento hasta el cierre.
3. El feedback descubre un problema nuevo
La IA clasifica y resume el comentario. El flujo busca casos previos y crea uno si procede, sin inventar la causa ni decidir compensaciones.
4. La reseña negativa llega antes que la encuesta
El hotel detecta la reseña, recupera solo el contexto necesario y prepara una respuesta. No expone datos privados ni condiciona la gestión a que el huésped cambie o retire la reseña.
5. El mismo check-out llega dos veces
El sistema reconoce que la comunicación ya fue programada y evita repetirla. La segunda señal no duplica encuestas ni casos.
Qué medir para saber si el post-estancia está mejor coordinado
La puntuación media de las reseñas puede ser importante para el hotel, pero no basta para evaluar la automatización. Si el establecimiento ya utiliza indicadores como NPS (Net Promoter Score), orientado a medir la disposición a recomendar, o CSAT (Customer Satisfaction Score), centrado en la satisfacción declarada, pueden seguir formando parte del cuadro de mando de experiencia. No sustituyen las métricas operativas del proceso post-estancia: conviene medir también aquello que está bajo control directo del equipo y de la automatización.
Algunos indicadores útiles son el porcentaje de estancias con comunicación post-estancia ejecutada correctamente, tasa de respuesta al feedback interno, porcentaje de respuestas que generan o relacionan una incidencia, tiempo desde feedback accionable hasta asignación, tiempo de recuperación hasta cierre, casos reabiertos, comunicaciones duplicadas, errores de identificación, calidad de clasificación tras revisión, temas recurrentes por departamento y tiempo de respuesta a reseñas públicas cuando el hotel lo gestione.
No tiene sentido publicar un benchmark universal de “buena” tasa de respuesta o de mejora de rating. La comparación útil empieza por medir la situación actual y comprobar si el nuevo proceso reduce errores, tiempos y trabajo manual. Para construir esa línea base y valorar costes de excepción, puede utilizarse el marco de KPIs de automatización de procesos.
Cómo revisar el seguimiento actual después del check-out
Un diagnóstico práctico puede reconstruir una estancia real y seguirla durante varios días después de la salida. Conviene identificar qué evento inicia el proceso, qué sistemas reciben la información, qué encuestas se envían, dónde se registran respuestas, quién ve una queja, quién puede aprobar una recuperación, qué plataforma solicita reseñas y qué información termina en el perfil.
El resultado puede ser una mejora de configuración, una integración, un workflow, una capa de IA o una combinación. La IA tiene especial valor cuando el volumen de texto libre obliga a leer, clasificar y resumir manualmente. La automatización tradicional aporta control para eventos, estados, permisos, aprobaciones y deduplicación.
Un buen post-estancia no consiste en contactar más veces
La automatización puede hacer que el hotel responda antes, detecte incidencias que antes quedaban enterradas en encuestas y reduzca tareas manuales. Pero el objetivo no debería ser aumentar el número de mensajes. Debería ser que cada mensaje tenga sentido respecto al estado real del huésped y del caso.
Eso exige separar escuchar, resolver, recuperar y gestionar reputación. También exige que la IA se utilice para lo que hace bien —interpretar lenguaje, resumir y encontrar patrones— sin darle autoridad sobre compensaciones, cierre de casos o políticas de reseñas.
Cuando el diseño es correcto, el hotel deja de actuar por secuencias rígidas y empieza a coordinar el post-estancia con contexto. El check-out dispara el proceso; los estados deciden la siguiente acción.
Preguntas frecuentes sobre automatización post-estancia en hoteles
¿Se puede automatizar la solicitud de reseñas de Google después del check-out?
Sí. Google permite solicitar reseñas que reflejen experiencias auténticas y facilita enlaces o códigos QR para compartirlos. La automatización debe evitar incentivos, presión sobre la puntuación y selección de clientes únicamente porque se espera una reseña positiva.
¿Es correcto pedir reseñas solo a huéspedes que han dado una valoración interna alta?
No es una buena práctica para Google. Su política prohíbe solicitar reseñas positivas de forma selectiva y desaconsejar las negativas. La encuesta interna puede servir para calidad y recuperación, pero no debería funcionar como filtro de acceso a la reseña pública.
¿Qué ocurre si el huésped comunica una incidencia después de abandonar el hotel?
El sistema debería comprobar si ya existe un caso relacionado con la estancia. Si existe, añadir el nuevo contexto; si no existe y el comentario requiere actuación, crear o derivar una incidencia con responsable y condición de cierre.
¿Puede la IA responder automáticamente a reseñas de huéspedes?
Puede clasificar la reseña, recuperar contexto, resumir y preparar un borrador. En respuestas sensibles conviene mantener revisión humana, especialmente si existen acusaciones graves, datos personales, compensaciones o riesgo reputacional.
¿Qué información del feedback conviene guardar en el CRM?
Solo la que tenga una finalidad clara. Una preferencia validada puede resultar útil; una avería puntual pertenece principalmente al histórico del caso. Las inferencias de IA no deberían guardarse automáticamente como hechos permanentes.
¿Qué sistemas hay que conectar para automatizar el post-estancia?
Depende de la arquitectura del hotel. Habitualmente se revisan PMS, CRM, feedback/reputación, incidencias y mensajería. Algunas plataformas agrupan varias funciones. La clave es definir qué sistema confirma cada estado y qué información necesita intercambiarse.
¿Qué comprueba hoy tu hotel antes de escribir a un huésped después del check-out?
En Yarvia analizamos eventos de salida, PMS, CRM, encuestas, incidencias, recuperación, reputación y comunicaciones para diseñar automatizaciones con IA que reduzcan trabajo manual sin perder contexto ni control.
Revisar el seguimiento después del check-outFuentes
- Google Maps — Política de contenido aportado por usuarios.
Política oficial utilizada para la regla sobre reseñas auténticas, incentivos y prohibición de solicitar reseñas positivas de forma selectiva.
Consultar fuente - Google Business Profile — Crear un enlace o código QR para solicitar reseñas.
Documentación oficial que confirma que las empresas pueden compartir solicitudes de reseña mediante enlaces o códigos QR, incluidos canales como email o WhatsApp, sin incentivos.
Consultar fuente - Cloudbeds Developers — Guest Communication / Reputation management.
Referencia técnica para comunicación post-departure, reservas en estado checked_out, notas y programación de comunicaciones.
Consultar fuente - Cloudbeds Developers — Webhooks.
Documentación utilizada como ejemplo de integración basada en cambios de estado de reserva, incluido reservation/status_changed y checked_out.
Consultar fuente - Oracle Hospitality OPERA Cloud — Profiles.
Referencia de producto utilizada para distinguir perfil, preferencias y otros datos asociados al huésped sin asumir que todo feedback deba convertirse en información permanente del perfil.
Consultar fuente - Oracle Hospitality OPERA Cloud — Business Events: Stay Records.
Ejemplo de eventos e integración relacionados con registros de estancia y sistemas externos.
Consultar fuente - Shiji ReviewPro — Reputation.
Ejemplo de plataforma hotelera especializada en encuestas, feedback, reputación y gestión de casos.
Consultar fuente - TrustYou — Customer Experience Platform.
Ejemplo de plataforma hotelera para centralizar, analizar y responder a feedback y reseñas, además de gestionar encuestas post-estancia.
Consultar fuente - Revinate — Guest Feedback / Guest Data.
Ejemplo de solución hotelera que combina gestión de feedback y reputación con capacidades de datos y perfiles de huéspedes.
Consultar fuente - AEPD — Protección de datos por defecto.
Referencia institucional para minimizar cantidad, alcance, conservación y accesibilidad de los datos personales utilizados en el proceso.
Consultar fuente
Las políticas de plataformas y las APIs pueden cambiar. Antes de actualizar este artículo conviene comprobar la documentación vigente de Google y de los proveedores hoteleros utilizados como ejemplo.
