GESTORÍAS · EXPEDIENTES · ATENCIÓN · AUTOMATIZACIÓN CON IA
Cómo automatizar consultas de clientes de una gestoría sobre el estado de sus trámites
Un cliente pregunta: “¿Cómo va lo mío?”. En el software de la gestoría aparece una tarea cerrada, en el correo hay un mensaje nuevo y el portal del organismo no se ha comprobado desde ayer. Responder “está en trámite” sería rápido. El problema es que podría no ser verdad, o ser tan impreciso que no resuelva nada.
Una consulta sobre un trámite solo puede responderse bien cuando el sistema sabe de qué expediente se habla, qué fuente confirma el dato y cuándo se comprobó por última vez.
La automatización puede identificar la pregunta, localizar el expediente, consultar sistemas y preparar una explicación clara. La IA puede entender y redactar; el hecho que se comunica debe proceder de una fuente autorizada. Cuando falta información o dos sistemas se contradicen, reconocer que no puede confirmarse el estado es mejor que inventar progreso.
Este circuito forma parte del mapa más amplio de automatización para gestorías, donde correo, documentación, tareas, expedientes y atención al cliente deben compartir contexto sin confundir una actividad interna con un estado confirmado.
El problema no es responder tarde: es responder con un estado que ya no vale
En muchas gestorías, responder a una consulta de seguimiento parece una tarea pequeña. El cliente pregunta por email, WhatsApp o teléfono; alguien abre el expediente, revisa un correo, pregunta al compañero responsable y contesta. El problema aparece cuando este circuito se repite decenas de veces y cada respuesta depende de reconstruir manualmente qué ha ocurrido.
La dificultad está en la fiabilidad de la información. Una tarea interna puede cerrarse sin que el trámite se haya presentado, y el software interno puede conservar un estado antiguo mientras el portal externo ya muestra otro.
Por eso, automatizar consultas sobre el estado de trámites en una gestoría no consiste en poner un chatbot delante del ERP. Consiste en responder cuatro preguntas: quién pregunta, de qué trámite habla, qué dato está confirmado y si sigue siendo válido ahora.
Qué debe comprobar el sistema antes de responder sobre un trámite
No hace falta convertir esta lógica en una taxonomía complicada. Para un responsable de gestoría basta con pensar en una secuencia de comprobaciones que reduzca el riesgo de contestar desde el contexto equivocado.
1. Quién está preguntando
Identificar al cliente, representante o contacto autorizado con un nivel de seguridad proporcional a la información que se va a mostrar.
2. De qué trámite se habla
Localizar el expediente, solicitud, recurso, alta, modelo u otra actuación concreta. Si existen varios posibles, primero hay que aclararlo.
3. Qué sistema confirma el dato
Determinar si la respuesta depende del software interno, un justificante, un portal oficial, una plataforma de tercero o una revisión profesional.
4. Cuándo se comprobó
Conservar la fecha de consulta o del último evento relevante para distinguir una información reciente de otra que puede haber quedado antigua.
5. Qué significa realmente
Traducir el estado a lenguaje comprensible sin añadir conclusiones que la fuente no contiene.
6. Qué hacer después
Responder si existe evidencia suficiente, crear una tarea si falta una comprobación o escalar cuando el caso necesita criterio humano.
Después conviene registrar qué se respondió, con qué fuente y en qué momento. Así la siguiente persona no tiene que reconstruir el caso desde cero.
Este enfoque aplica al caso concreto de las consultas de seguimiento principios que también aparecen al integrar CRM y ERP sin duplicar información: no todos los sistemas tienen autoridad sobre todos los datos y, cuando existen discrepancias, primero hay que determinar qué está ocurriendo antes de sincronizar o comunicar.
Lo que ha hecho la gestoría y lo que ha ocurrido fuera pueden ser cosas distintas
Uno de los errores más habituales al informar a un cliente es utilizar una sola etiqueta para realidades distintas. “En trámite” puede querer decir que el gestor está revisando documentación, que la presentación ya se realizó, que un organismo la recibió o que existe una actuación externa pendiente de resolución. Agrupar todo bajo la misma expresión hace que el sistema parezca sencillo, pero la respuesta pierde precisión.
Lo que ocurre dentro de la gestoría
Preparar, revisar, pedir una aprobación, generar una presentación, comprobar documentación, subsanar un dato o esperar a que un compañero complete una tarea.
Lo que confirma una fuente externa
Presentado, recibido, en tramitación, requerido, resuelto u otra denominación real que utilice el organismo o plataforma correspondiente.
Entre ambas capas está lo que realmente puede decirse al cliente. Esa explicación debe combinar hechos confirmados y contexto autorizado sin presentar una actividad interna como si fuera progreso oficial.
Ejemplo práctico
La documentación ya está revisada y el equipo ha dejado preparada la presentación. Sin embargo, todavía no existe justificante ni confirmación del sistema correspondiente. La respuesta correcta no es “ya está presentado”. Puede ser: “La documentación está revisada y hemos dejado el trámite preparado para presentación; todavía no consta presentado”.
Esta separación también protege la frontera con la gestión de autorizaciones y aprobaciones pendientes. Un trámite puede estar bloqueado por una decisión del cliente, pero esta entrada no vuelve a explicar cómo pedirla o documentarla: solo utiliza ese estado cuando ya está confirmado y resulta relevante para responder.
Qué sistema confirma cada dato: el ERP no tiene por qué saberlo todo
Una gestoría puede trabajar con un ERP o software sectorial, gestor documental, correo, carpetas compartidas, portales oficiales y plataformas de terceros. El objetivo no es declarar un ganador universal, sino saber qué sistema es competente para confirmar cada dato concreto.
| Fuente | Qué puede confirmar | Qué no conviene asumir |
|---|---|---|
| ERP o software de gestoría | Tareas internas, responsables, fechas, estados definidos por la firma y determinadas actuaciones registradas. | Que cualquier estado interno refleja automáticamente lo que muestra un organismo externo. |
| Gestor documental | Existencia de documentos, versiones, justificantes o evidencias guardadas. | Que un documento preparado ha sido presentado, recibido o aceptado. |
| Correo | Que ha llegado una comunicación, un justificante, un requerimiento o una resolución. | Que todo mensaje nuevo equivale por sí solo a un cambio definitivo del expediente. |
| Portal o sede oficial | El estado administrativo cuando el procedimiento concreto ofrece esa consulta. | Que todos los trámites se consultan igual o que existe una integración automática universal. |
| Plataforma de tercero | La fase que ese proveedor controla realmente. | Que su estado sustituye a los demás sistemas para cualquier pregunta. |
| Persona responsable | Excepciones, actividad no registrada, interpretación profesional o conflictos. | Que una explicación de memoria deba sustituir a la evidencia cuando esta existe. |
La Agencia Tributaria dispone de “Mis expedientes” para consultar determinados estados y documentos; la Seguridad Social ofrece servicios de consulta en procedimientos concretos; y Mi Carpeta Ciudadana permite consultar expedientes de distintas administraciones adheridas. Estos ejemplos muestran que parte del estado puede residir fuera de la gestoría.
Eso no significa que todos esos portales ofrezcan una API pública para automatizar cualquier consulta. Las capacidades reales, los permisos, la representación, la autenticación y las condiciones de uso deben revisarse caso por caso. Una propuesta seria no debería dar por hecho que automatizar un navegador con credenciales es siempre la vía adecuada.
Cómo saber si el estado que tenemos sigue siendo útil para responder
Guardar un estado sin guardar su contexto temporal crea una falsa sensación de precisión. “En tramitación” puede ser correcto y, al mismo tiempo, insuficiente si nadie sabe cuándo se consultó por última vez.
Cuando sea posible, conviene conservar junto al estado:
- Fuente consultada. Qué sistema, portal, mensaje o persona confirmó la información.
- Momento de la comprobación. Cuándo se leyó el estado o se recibió el evento relevante.
- Referencia del trámite. A qué expediente o actuación corresponde.
- Estado recuperado. La denominación original antes de cualquier explicación al cliente.
- Evento que provocó el cambio. Cuando existe y puede identificarse.
- Forma de obtención. Si se consultó directamente o se dedujo de una señal que todavía requiere verificación.
No existe un número universal de horas a partir del cual un estado deje de servir. La tolerancia a la antigüedad debe definirse según el proceso y el riesgo de comunicar un dato que ya haya cambiado.
El correo puede avisar de una novedad sin convertirse en el estado del expediente
En muchas gestorías, gran parte de las novedades entra por email. Puede llegar un justificante, un requerimiento, una confirmación de presentación, una resolución o una incidencia. Automatizar la detección de esos mensajes tiene mucho valor, pero la entrada de correo y la consulta de estado son problemas diferentes.
Gmail permite consultar cambios del buzón mediante su historial y Microsoft Graph ofrece seguimiento incremental de mensajes. Estas capacidades ayudan a detectar que algo nuevo ha ocurrido en el canal, pero no demuestran por sí solas qué efecto tiene sobre el expediente.
Antes de actualizar el estado conviene comprobar:
- Si el mensaje pertenece al cliente y trámite correctos.
- Si el remitente y el contenido son suficientemente fiables para el uso que se pretende darles.
- Si el mensaje describe un cambio real o solo una comunicación intermedia.
- Si hace falta contrastarlo con otra fuente antes de responder al cliente.
El trabajo de automatizar el correo de una gestoría puede encargarse de capturar, clasificar y relacionar mensajes. La entrada 65 empieza después: cuando esos mensajes deben convertirse —o no— en una respuesta fiable sobre el estado de un trámite.
Hecho, estimación y expectativa: tres niveles que no deberían mezclarse
Una respuesta puede sonar convincente y ser incorrecta por una razón muy simple: ha convertido una posibilidad en un hecho. Para evitarlo, conviene que el sistema distinga el grado de certeza de cada frase.
Hecho confirmado
“Consta presentado el 12 de agosto”. Existe una evidencia o fuente autorizada que permite afirmarlo.
Estado confirmado
“El portal muestra el expediente en tramitación”. Describe lo que la fuente muestra en el momento comprobado.
Actuación interna
“Nuestro equipo está revisando la documentación solicitada”. Informa de trabajo real de la gestoría sin atribuírselo al organismo.
Estimación interna
“Esperamos poder presentarlo mañana”, solo si existe una planificación real y se deja claro que no es una confirmación.
Esta distinción es especialmente importante cuando el cliente pregunta “¿cuándo me dirán algo?”. Puede existir un plazo normativo aplicable, una previsión interna o ninguna fecha disponible. Incluso si existe un plazo oficial, explicar un plazo no equivale a prometer el día exacto en que se resolverá el caso concreto.
Qué consultas pueden automatizarse y cuáles deben detenerse
La automatización es más segura cuando la pregunta tiene una respuesta verificable y las fuentes necesarias son accesibles. No todas las consultas merecen el mismo nivel de autonomía.
Respuestas con buen potencial de automatización
- Último estado confirmado.
- Fecha de presentación o recepción registrada.
- Documentación pendiente ya validada como tal.
- Última actuación interna relevante.
- Siguiente acción interna ya asignada.
- Confirmación de que no existe un cambio nuevo, si puede verificarse.
Situaciones que deben escalar
- Identidad o autorización dudosa.
- Varios expedientes plausibles.
- Estados contradictorios.
- Dato antiguo que no puede actualizarse.
- Portal necesario no disponible.
- Resolución que exige interpretación profesional.
- Pregunta sobre plazo sin fecha verificable.
- Información sensible que no debe mostrarse por ese canal.
Si el cliente pregunta “¿falta algo?” y la documentación pendiente está correctamente estructurada y validada, el sistema puede responder qué requisito sigue abierto. El circuito completo para pedir y validar documentos pertenece a la automatización de documentación pendiente en gestorías; aquí solo utilizamos su resultado como parte de la respuesta.
Dónde puede ayudar la IA al responder sobre expedientes y trámites
La consulta suele llegar en lenguaje poco estructurado: “¿Cómo va lo mío?”, “¿ha contestado Hacienda?”, “¿falta algo?”. Aquí la IA aporta valor interpretando la pregunta y convirtiendo información dispersa en una explicación útil.
Entender la pregunta
Distinguir si el cliente pregunta por presentación, documentación pendiente, respuesta del organismo, plazo o resolución.
Encontrar el contexto probable
Utilizar referencias presentes en la conversación para localizar el trámite candidato, sin decidir a ciegas cuando existen varios posibles.
Resumir los últimos eventos
Preparar para el equipo una síntesis de actuaciones, mensajes y cambios confirmados relacionados con el expediente.
Traducir estados
Explicar una etiqueta técnica o administrativa en lenguaje comprensible sin cambiar su significado ni añadir progreso inexistente.
Preparar la respuesta
Redactar un mensaje adaptado al cliente utilizando únicamente hechos y estimaciones que el sistema haya clasificado correctamente.
Detectar que falta una comprobación
Señalar contradicciones, datos antiguos o información ausente y proponer qué fuente debe consultarse antes de responder.
La IA no debería inventar que un trámite avanza porque no haya noticias, predecir una resolución sin base suficiente, fijar una fecha desde conocimiento general, dar por presentada una actuación por similitud textual ni resolver una identidad dudosa por parecido de nombres.
En Yarvia diseñamos esta separación de forma deliberada: la IA interpreta la pregunta y explica el contexto; las reglas determinan qué debe comprobarse; las integraciones recuperan datos autorizados; y una persona interviene cuando falta evidencia o el caso exige criterio profesional.
¿Tu equipo sigue abriendo varias pantallas para contestar “cómo va mi trámite”?
Podemos revisar qué preguntas reciben, dónde está realmente cada estado y qué parte puede automatizarse con IA sin responder desde información antigua.
Chatbot, voz, email o portal: cambia el canal, no la fuente que confirma el dato
La misma arquitectura puede servir a varios canales: chatbot, voz, email, portal de cliente o atención humana.
Ningún canal debería inventar su propia versión del expediente. El canal recoge la pregunta y entrega una respuesta basada en los sistemas que confirman el estado.
En voz o mensajería conviene ser especialmente prudente con la identidad. Que una persona conozca el nombre de un cliente o escriba desde un teléfono habitual no significa que deba poder acceder automáticamente a cualquier información sensible. El nivel de verificación debe corresponder al dato que se vaya a revelar.
Esta es una diferencia importante respecto a una guía genérica de atención multicanal: aquí el centro no son los canales, sino la calidad del estado que alimenta la respuesta.
Qué hacer cuando el ERP y la fuente externa muestran cosas distintas
En un entorno conectado, dos sistemas pueden actualizarse en momentos distintos. Una tarea interna puede cerrarse antes de que el portal refleje el cambio o una actualización externa puede tardar en llegar al ERP.
No hay que elegir siempre el ERP ni siempre el portal. Hay que determinar qué dato se pregunta y qué fuente lo confirma.
Portal actualizado, ERP antiguo
Si el portal autorizado ya muestra un cambio oficial y el ERP todavía conserva el estado anterior, la respuesta puede basarse en el dato externo confirmado y, a la vez, crear una tarea para actualizar o reconciliar el sistema interno.
ERP actualizado, portal sin cambio
Si la gestoría ha terminado una actuación interna pero la fuente externa todavía no refleja el resultado, la respuesta debe explicar ambas cosas: qué ha hecho el equipo y qué sigue sin constar externamente.
No sabemos cuál es el estado actual
Cuando existe una contradicción que no puede resolverse automáticamente, el flujo debe detener la respuesta definitiva, recopilar el contexto y enviar el caso a revisión.
Esta lógica se apoya en los mismos principios que utilizamos al monitorizar automatizaciones en producción: un resultado incierto no debe tratarse como éxito y, cuando una escritura o sincronización puede haber fallado, primero conviene verificar el estado real.
Identidad, autorización y minimización antes de revelar información
Automatizar la consulta no significa mostrar todo lo que la gestoría sabe de un cliente. El sistema debe resolver dos preguntas diferentes: quién es la persona y qué información está autorizada a consultar.
Un representante puede estar autorizado para unos trámites y no para otros. Identificar correctamente a la persona no elimina la necesidad de comprobar qué información puede consultar.
Desde el diseño conviene aplicar medidas prácticas:
- Mostrar solo la información necesaria para responder a la pregunta concreta.
- Evitar replicar expedientes completos en chatbot, logs o notificaciones si basta con un estado resumido.
- Limitar el acceso por rol, cliente, expediente y canal cuando sea necesario.
- No mantener datos personales en más sistemas de los que exige el proceso.
- Escalar cuando la identidad o representación no pueda confirmarse con seguridad suficiente.
La AEPD vincula la protección de datos por defecto con la minimización: limitar la cantidad de datos, la extensión del tratamiento, la conservación y la accesibilidad a lo necesario para la finalidad. En este artículo lo aplicamos como criterio de arquitectura, no como sustituto del análisis jurídico que pueda necesitar cada proyecto.
Ocho situaciones que ponen a prueba una respuesta automática
| Pregunta o situación | Qué hay que comprobar | Respuesta operativa |
|---|---|---|
| “¿Ya está presentado?” | El ERP marca la tarea como terminada, pero no hay justificante ni confirmación. | No darlo por presentado. Comprobar la evidencia correspondiente. |
| “¿Falta algo?” | Existe documentación pendiente validada en el expediente. | Indicar exactamente qué sigue pendiente sin reconstruir todo el circuito documental. |
| “¿Ha contestado el organismo?” | Ha llegado un email nuevo, todavía sin asociar ni interpretar. | Clasificar y comprobar antes de comunicar una resolución. |
| Portal actualizado, ERP antiguo | La fuente externa confirma un nuevo estado. | Responder con el dato confirmado y abrir reconciliación interna. |
| ERP actualizado, portal sin cambio | Existe actuación interna, pero no avance externo confirmado. | Explicar ambos niveles sin equipararlos. |
| Fuente no disponible | No puede recuperarse el dato actual. | Reconocer que no puede confirmarse y crear revisión. |
| Cliente con dos trámites abiertos | “¿Cómo va lo mío?” es ambiguo. | Pedir aclaración antes de mezclar expedientes o revelar información. |
| “¿Cuándo lo resolverán?” | El estado está confirmado, pero no existe fecha verificable. | Explicar lo que se sabe y no convertir una estimación o plazo general en una promesa. |
Qué medir para saber si el sistema de consultas mejora de verdad
La automatización no debería justificarse con una cifra de ahorro inventada. Primero hay que medir cómo se trabaja hoy y qué cambia en el piloto.
Demanda de seguimiento
Consultas de estado por cliente o expediente activo y porcentaje de consultas repetidas sobre el mismo estado.
Resolución
Porcentaje resuelto sin intervención humana, reaperturas y consultas que necesitan más información.
Calidad del dato
Consultas que requieren actualizar o reconciliar estados, fuentes no disponibles y casos de información antigua detectados.
Escalado
Casos derivados por identidad dudosa, conflicto entre sistemas o necesidad de interpretación profesional.
También interesa medir el tiempo mediano de respuesta y el tiempo dedicado a buscar información antes y después del piloto. El marco general se desarrolla en la guía de KPIs para automatización de procesos.
Cómo empezaría Yarvia un proyecto para automatizar estas consultas
El primer paso no sería conectar todos los portales ni desplegar un agente de IA. Empezaríamos por observar cómo se responde hoy.
- Recoger una muestra de preguntas reales. Saber qué pide realmente el cliente: presentación, documentación, estado, plazo, resolución o siguiente acción.
- Inventariar los tipos de trámite. Evitar intentar modelar toda la gestoría desde el primer día.
- Localizar dónde se confirma cada dato. ERP, gestor documental, correo, portal, plataforma de tercero o persona responsable.
- Separar trabajo interno de estado externo. Identificar dónde se producen hoy respuestas ambiguas.
- Revisar cómo se actualiza cada fuente. Manualmente, mediante integración, por mensajes recibidos o mediante consulta periódica.
- Definir identidad y autorización. Qué puede mostrar cada canal y a quién.
- Diseñar respuestas claras. Traducir estados reales sin crear promesas ni conclusiones nuevas.
- Definir excepciones. Qué ocurre cuando falta una fuente, hay contradicción o el cliente tiene varios expedientes.
- Añadir registro. Conservar fuente, momento de consulta y respuesta enviada.
- Medir antes de ampliar autonomía. Tiempo, errores, repetición, escalados y consultas realmente automatizables.
Un piloto puede empezar con pocos tipos de trámite, fuentes accesibles y respuestas de bajo riesgo. En una primera fase, la IA puede trabajar como asistente del equipo: busca contexto, resume y propone una respuesta para validación. La autonomía solo debería ampliarse cuando el proceso demuestre suficiente fiabilidad.
El objetivo no es construir “un chatbot para la gestoría”, sino una atención conectada con expedientes reales que responda cuando puede comprobar y se detenga si no.
Preguntas frecuentes sobre automatizar consultas de trámites en una gestoría
¿Puede un chatbot decir a un cliente cómo va su expediente?
Sí, si puede identificar al cliente y al trámite, consultar una fuente autorizada y traducir el estado sin modificar su significado. Cuando falte información, exista una contradicción o la identidad no sea suficiente, debería pedir aclaración o escalar en lugar de inventar una respuesta.
¿Cómo evitar responder con información desactualizada?
Conviene registrar la fuente y el momento del último estado, definir cuándo necesita volver a comprobarse según el proceso y evitar utilizar datos antiguos como si fueran actuales cuando no pueden refrescarse. No existe un umbral universal válido para todos los trámites.
¿Qué sistema debe utilizarse para consultar el estado de un trámite?
Depende de la información concreta. El software de la gestoría puede confirmar trabajo interno; un gestor documental, determinados justificantes; y un portal oficial o plataforma externa, estados que ese sistema controla. No es necesario que una sola aplicación sea la autoridad para todo.
¿Puede la IA saber si Hacienda o la Seguridad Social han actualizado un expediente?
La IA puede interpretar la pregunta y explicar un estado que haya sido recuperado por una vía autorizada. No debería afirmar por sí sola que un organismo ha cambiado un expediente. La disponibilidad de consultas e integraciones depende del procedimiento, la identificación, los permisos y las capacidades técnicas existentes.
¿Qué ocurre si el ERP y el portal oficial muestran estados distintos?
Hay que determinar qué dato se está preguntando y qué fuente lo confirma. Si la discrepancia puede resolverse, se responde con el dato adecuado y se corrige el sistema desfasado. Si no puede resolverse con seguridad, la respuesta automática debe detenerse y generar revisión.
¿Es suficiente un email para considerar que ha cambiado el estado?
No necesariamente. Un email puede contener una confirmación, un requerimiento, una resolución o simplemente una comunicación intermedia. Antes de actualizar el estado hay que asociarlo al expediente correcto, comprobar su procedencia e interpretar qué efecto tiene realmente.
¿Cómo se protege la información del cliente en una consulta automatizada?
Separando identidad y autorización, limitando la información al expediente necesario, aplicando acceso según rol o relación y evitando duplicar datos personales en sistemas que no los necesitan. El nivel de verificación debería ser proporcional a la sensibilidad de la información mostrada.
DIAGNÓSTICO DE AUTOMATIZACIÓN
Revisar cómo se responde sobre el estado de trámites
Si responder “cómo va mi trámite” exige abrir correos, revisar el ERP, consultar portales y preguntar a varias personas, podemos analizar qué sistema confirma cada dato, dónde puede ayudar la IA y qué consultas pueden automatizarse sin perder fiabilidad.
Revisar cómo se responde sobre el estado de trámitesFuentes
- Agencia Tributaria — Mis expedientes.
Referencia institucional sobre consulta del estado de tramitación de determinados expedientes y documentos presentados electrónicamente, con identificación y representación cuando proceda.
Consultar fuente - Seguridad Social — Carpeta Ciudadana y consulta de solicitudes.
Referencia institucional sobre consulta del estado de determinadas solicitudes y procedimientos, con alcance diferente según el trámite y el modo de acceso.
Consultar fuente - Mi Carpeta Ciudadana — Mis expedientes.
Referencia sobre consulta autenticada de expedientes registrados con distintos organismos y administraciones adheridas.
Consultar fuente - Gmail API — users.history.list.
Documentación técnica que permite consultar cambios del buzón de forma incremental; se utiliza como ejemplo de detección de novedades del canal, no como confirmación de un estado administrativo.
Consultar fuente - Microsoft Graph — message: delta.
Documentación técnica sobre seguimiento incremental de mensajes de correo. Misma frontera: detectar cambios en mensajes no equivale a confirmar el estado de un expediente.
Consultar fuente - AEPD — Protección de datos por defecto.
Criterios institucionales sobre minimización de datos, extensión del tratamiento, conservación y accesibilidad desde el diseño.
Consultar fuente
Las funcionalidades de portales, productos e integraciones pueden cambiar. Antes de implementar una automatización deben verificarse las capacidades vigentes, los permisos, la representación y las condiciones aplicables al sistema concreto.
