Cómo automatizar la atención al propietario en una administración de fincas

El problema no es WhatsApp: es que el estado de la gestión viva dentro de la conversación

Un propietario escribe por WhatsApp para preguntar si ya se ha enviado una documentación. Dos horas después manda un correo porque no ha visto respuesta. Al día siguiente llama al despacho. Una persona encuentra el WhatsApp, otra ve el email y una tercera atiende la llamada. El problema no es que existan tres canales. El problema es que cada canal contiene una parte distinta del contexto y nadie sabe con certeza si la solicitud ya está resuelta o si todavía queda trabajo por hacer.

El mismo problema aparece cuando el equipo utiliza el correo como lista de tareas: mensaje leído, mensaje archivado, mensaje reenviado. Ninguno de esos estados demuestra que la gestión haya terminado. El teléfono tampoco conserva por sí solo qué se prometió, qué dato se consultó o qué acción quedó pendiente.

La automatización útil empieza cuando el canal deja de ser el lugar donde se organiza el trabajo. WhatsApp puede seguir siendo una interfaz cómoda sin convertirse en el sistema de gestión; lo mismo ocurre con email, web y teléfono. Detrás debería existir un proceso común que conserve contexto, estado, responsable y siguiente acción.

El mapa general de procesos del despacho está desarrollado en la guía de automatización para administradores de fincas. Aquí el foco es mucho más concreto: qué debe ocurrir entre el mensaje de un propietario y una respuesta o acción correctamente registrada.

Antes de responder, el sistema necesita construir el contexto de la consulta

Para explicarlo de forma sencilla utilizaremos un Mapa de contexto de la consulta: una forma práctica de comprobar qué información necesita el sistema antes de contestar o crear una acción.

No es una metodología estándar del sector. Es un recurso de Yarvia para evitar que una conversación se procese solo por el texto que aparece en pantalla.

No todas las consultas necesitan recorrer todos los pasos. Preguntar por el horario del despacho puede resolverse sin identificar una comunidad. Pedir una copia de un documento o consultar una gestión concreta exige bastante más contexto.

El valor de este mapa está en impedir que el sistema confunda una frase comprensible con una solicitud segura para ejecutar. Entender lo que alguien escribe no significa saber todavía qué puede hacerse con esa petición.

Identificar a una persona no significa autorizar cualquier acceso

Una arquitectura débil trata estas tres cosas como si fueran una sola: “conozco este teléfono, por tanto puedo mostrar cualquier información”. Esa conclusión es peligrosa.

Una misma persona puede estar vinculada a varias comunidades. Un inmueble puede tener más de un titular. Puede existir una representación. El contacto utilizado para recibir avisos puede no tener permiso para una modificación sensible.

Cuando aparece el término autenticación, conviene distinguirlo también de identificación. Identificar es saber quién parece ser la persona; autenticar es comprobar su identidad con el nivel de garantía exigido por la operación. No todas las consultas necesitan el mismo nivel de comprobación.

Por ejemplo, una respuesta pública puede requerir ninguna autenticación adicional. Modificar una cuenta bancaria, entregar determinada documentación o ejecutar una acción sensible puede exigir controles mayores definidos por el despacho.

Qué quiere conseguir realmente el propietario con su mensaje

Para organizar la automatización conviene crear una clasificación práctica de tipos de consulta: agrupar los mensajes según lo que la persona quiere conseguir para activar el proceso correcto.

La lista concreta debe adaptarse a cada administración. Una clasificación orientativa podría incluir:

• Consulta informativa general.
• Consulta sobre el estado de una gestión.
• Solicitud de documento o copia.
• Comunicación de una incidencia.
• Consulta económica o sobre recibos.
• Consulta relativa a una junta o acuerdo.
• Petición de cambio de datos.
• Petición de actuación.
• Queja o conflicto.
• Solicitud urgente o con posible riesgo.
• Asunto fuera del alcance habitual.

La IA puede ser especialmente útil aquí porque los propietarios no escriben utilizando categorías perfectas. Escriben frases como “¿sabemos algo del ascensor?”, “me podéis mandar lo de la reunión” o “otra vez tengo el cargo mal”. El sistema puede interpretar el lenguaje y proponer a qué tipo de consulta corresponde.

Pero clasificar el motivo no concede permiso ni resuelve la petición. Saber que alguien solicita un documento no significa que deba enviarse automáticamente. Solo ayuda a activar el flujo adecuado.

Tres consultas parecidas pueden necesitar niveles de control muy distintos

La mejor forma de entender el valor del contexto es comparar mensajes que, a primera vista, parecen igualmente sencillos.

Estos tres ejemplos muestran por qué una misma interfaz conversacional necesita rutas distintas detrás. La facilidad para formular la pregunta no determina la facilidad para automatizar la respuesta.

También explica por qué no tiene sentido diseñar un chatbot únicamente con una lista de preguntas frecuentes. Algunas consultas son puramente informativas; otras exigen consultar estados, crear tareas o aplicar controles de acceso. El valor está en que la automatización sepa distinguirlas antes de actuar.

Responder, crear una tarea, derivar o escalar son cuatro resultados diferentes

Una de las confusiones más costosas en atención es considerar “respondida” una conversación que en realidad deja trabajo pendiente.

Si una consulta comunica una avería, la atención puede identificar el asunto y derivarlo al circuito adecuado. El flujo completo de una incidencia —clasificación, proveedor, seguimiento, autorizaciones y cierre— pertenece al proceso específico de gestión de incidencias en comunidades.

La diferencia importa para las métricas. Un chatbot puede haber respondido a muchos mensajes y, aun así, haber creado una gran cantidad de tareas pendientes que luego nadie sigue. Respuesta automática y resolución operativa no son el mismo indicador.

Dónde puede ayudar especialmente la IA en la atención a propietarios

Un modelo de IA puede entender que “¿ya vino el técnico?” probablemente pregunta por el estado de una actuación. Lo que no sabe por sí solo es si el técnico ha venido. Para responder necesita consultar el sistema que conserva ese estado.

También puede resumir un mensaje conflictivo, identificar que contiene varias cuestiones y preparar el contexto para el administrador. Pero no debería decidir jurídicamente quién tiene razón ni emitir una conclusión vinculante.

Este reparto es importante para contratar una automatización con IA con expectativas realistas: la IA interpreta; los datos, reglas y sistemas autorizados sostienen la respuesta.

IA, regla, API o persona: elegir el mecanismo adecuado para cada tarea

No todo lo automatizable necesita IA.

Una API es, explicado de forma sencilla, un mecanismo que permite que dos sistemas consulten o intercambien datos de forma estructurada. Por ejemplo, una automatización puede recibir una consulta y pedir al software del despacho el estado de un expediente antes de redactar una respuesta.

La integración puede realizarse mediante API u otros mecanismos disponibles. Lo importante no es imponer una tecnología concreta, sino evitar que el modelo de IA tenga que “recordar” datos que deberían consultarse en tiempo real.

WhatsApp, email, teléfono y web: varios canales, un solo proceso

Una atención multicanal coordinada no significa copiar todos los mensajes a todas partes. Significa que una consulta puede empezar en un canal y continuar en otro sin perder identidad, asunto, estado ni responsable.

Si un propietario escribe por WhatsApp y más tarde envía un email sobre el mismo asunto, el sistema debería intentar relacionar ambas interacciones con el contexto existente. Cuando haya un identificador estable, debe utilizarse. Cuando solo exista similitud de texto, la asociación puede proponerse como candidata, pero no conviene fusionar automáticamente dos asuntos distintos.

También debe conservarse el origen de cada interacción. Saber que la pregunta empezó por teléfono y continuó por email puede ser útil para trazabilidad y análisis del servicio.

En correo electrónico existen proveedores que ofrecen APIs y notificaciones de eventos. Gmail, por ejemplo, documenta mecanismos de notificación de cambios del buzón para que una aplicación pueda reaccionar sin revisar constantemente la bandeja. Eso demuestra una capacidad técnica posible, no significa que todos los despachos deban utilizar Gmail ni esa arquitectura concreta.

Qué sistema manda en cada dato

Cuando hablamos de fuente de verdad no hablamos de una herramienta especial. Hablamos del sistema que la empresa considera referencia para un dato concreto.

El reparto depende de las herramientas reales. Un despacho puede centralizar casi todo en una plataforma sectorial y otro repartir funciones entre varias aplicaciones.

La pregunta de arquitectura es sencilla: si dos sistemas muestran datos distintos, ¿cuál debe considerarse correcto? Esa decisión debería estar definida antes de automatizar respuestas.

Qué significa que el sistema fuente no esté disponible y qué debe hacer la automatización

Imaginemos que un propietario pregunta: “¿Está ya cerrada mi solicitud?”. El chatbot entiende perfectamente la pregunta, identifica a la persona y sabe qué expediente consultar. Pero el software donde vive el estado real no responde.

Eso es una indisponibilidad del sistema fuente: la automatización no puede acceder en ese momento al lugar donde está el dato fiable.

La respuesta incorrecta sería utilizar el último estado que quedó guardado en una conversación o dejar que la IA complete la información por contexto. La respuesta correcta depende del proceso, pero puede ser:

• Informar de que no puede verificarse el estado en ese momento.
• Crear una tarea o dejar la consulta en espera.
• Reintentar la consulta automáticamente más tarde.
• Escalar a una persona si el asunto no puede esperar.
• Utilizar una copia de respaldo únicamente si la arquitectura ha definido expresamente su vigencia y límites.

También debe evitarse un error más sutil: enviar primero una confirmación al propietario y descubrir después que la escritura en el sistema falló. Cuando una acción tiene consecuencias, conviene verificar que realmente se completó antes de comunicarla como realizada.

Privacidad: qué información puede viajar por el canal

Las comunidades de propietarios tratan datos personales y están sujetas a la normativa de protección de datos. La AEPD señala que, cuando existe un administrador de fincas contratado, la comunidad actúa como responsable del tratamiento y el administrador como encargado en los tratamientos que realiza por cuenta de aquella.

Esto no significa que exista una tabla universal de “datos permitidos por WhatsApp” y “datos prohibidos por email”. La pregunta correcta es qué dato pretende comunicarse, para qué finalidad, quién lo solicita, qué relación existe y qué medidas de seguridad son adecuadas.

La Ley de Propiedad Horizontal atribuye al administrador funciones de gestión y custodia documental. Pero esa custodia no equivale a un derecho automático a entregar cualquier archivo completo a cualquier persona que se identifique como propietaria.

La AEPD recuerda que la documentación de una comunidad puede contener información de terceros y que el acceso debe analizarse con criterios de pertinencia, necesidad y proporcionalidad según la finalidad.

Para la automatización, esto se traduce en decisiones de diseño:

• Minimizar los datos incluidos en mensajes y notificaciones.
• No duplicar documentación sensible innecesariamente dentro de prompts, logs o paneles.
• Comprobar identidad, relación y autorización antes de entregar información contextual.
• Utilizar enlaces o entornos más controlados cuando sea preferible no enviar el contenido completo por el canal.
• Escalar solicitudes documentales o de acceso que no estén claramente modeladas.

El artículo no sustituye el análisis jurídico de cada despacho. El objetivo es evitar una arquitectura que trate “propietario identificado” como permiso universal.

Excepciones que deben detener o limitar la respuesta automática

Un sistema de atención fiable se diseña también para los casos en los que no puede responder de forma segura.

Cada excepción debería tener cuatro elementos: motivo, responsable, siguiente acción y condición de salida. Si solo se crea una bandeja de “casos especiales”, la automatización desplaza el problema sin resolverlo.

Cómo medir si la atención está realmente bajo control

El volumen de mensajes automatizados no demuestra por sí solo una mejora.

Algunas métricas útiles son:

• Tiempo hasta identificación suficiente.
• Tiempo hasta primera respuesta útil.
• Consultas resueltas con información autorizada sin intervención humana.
• Consultas que generan una tarea posterior.
• Consultas derivadas a incidencias u otros procesos.
• Escalados por motivo.
• Consultas reabiertas.
• Contactos repetidos por falta de estado.
• Errores de identificación detectados.
• Respuestas corregidas por información desactualizada.
• Solicitudes sin responsable.
• Tiempo hasta resolución cuando existe un criterio real de cierre.
• Intervención humana por causa.

Conviene separar tiempo de respuesta y tiempo de resolución. Una respuesta inmediata puede ser excelente para acusar recibo y, al mismo tiempo, no aportar ninguna mejora al tiempo que tarda la gestión en terminar.

Reducción de llamadas, satisfacción o ahorro económico solo deberían atribuirse al proyecto si existen datos comparables que lo demuestren.

Cómo empezar con un piloto de atención al propietario

Intentar que un chatbot “atienda todo” desde el primer día mezcla demasiadas categorías, permisos y excepciones.

Una primera fase asistida puede ser suficiente: la IA clasifica, recupera contexto y prepara la respuesta; una persona valida los casos más sensibles. Después se puede ampliar por tipo de consulta, comunidad, canal o acción.

Qué revisaría Yarvia para mejorar la gestión de las consultas

• Por qué canales entran actualmente las consultas.
• Cómo se identifica a la persona y su relación con la comunidad.
• Qué consultas se repiten y cuáles generan más trabajo posterior.
• Dónde vive el estado real de cada gestión.
• Qué datos pueden recuperarse mediante integración.
• Qué documentación necesita reglas de acceso específicas.
• Qué partes del lenguaje puede interpretar la IA.
• Qué decisiones deben quedar en manos del equipo.
• Qué ocurre si faltan datos o un sistema no responde.
• Cómo se crean tareas y quién es responsable de cerrarlas.
• Cómo se evita duplicar un asunto cuando cambia el canal.
• Qué métricas permiten saber si la atención mejora de verdad.

Si vuestro equipo atiende consultas por WhatsApp, email y teléfono pero todavía necesita buscar quién es el propietario, a qué comunidad pertenece, qué información puede recibir y qué tarea queda después de cada mensaje, se puede diseñar una capa de atención conectada con los sistemas que ya utilizáis.

Revisar cómo gestiona el despacho las consultas