Cómo automatizar el alta de un nuevo cliente en una gestoría

Crear la ficha del cliente no significa haber terminado el alta

La gestoría cierra un nuevo cliente y alguien crea su ficha en el software. Desde ese momento aparece como cliente activo. Sin embargo, dos días después siguen faltando documentos, nadie tiene claro si existe autorización para una actuación concreta, el responsable interno todavía no está asignado y las primeras tareas siguen en una hoja o en la cabeza de alguien.

El problema no está en que el software haya creado mal la ficha. Está en haber utilizado esa acción como si representara todo el proceso de incorporación. Una ficha confirma que existe un registro; no confirma que el equipo pueda empezar a trabajar correctamente.

Por eso conviene tratar el alta como un caso con condiciones de completitud. El cliente puede existir en el ERP y, al mismo tiempo, tener pendiente la identificación de un dato, una autorización, un documento, una configuración o una tarea inicial. La automatización debe hacer visibles esas diferencias.

En la guía general sobre automatización para gestorías analizamos distintos procesos repetitivos del sector. Aquí nos centramos únicamente en el momento que va desde la decisión de trabajar con el cliente hasta que el equipo está preparado para empezar.

Qué significa que un cliente esté operativo

No existe una lista universal válida para todas las gestorías. Una asesoría fiscal, una laboral o una gestoría integral pueden necesitar condiciones distintas, y tampoco exige lo mismo un autónomo que una sociedad con empleados. Aun así, resulta útil definir una estructura de referencia.

La expresión alta operativa del cliente sirve para diferenciar el registro administrativo de la capacidad real de trabajar. No significa que absolutamente todo deba estar cerrado. Puede haber tareas posteriores o elementos opcionales. Lo importante es distinguir qué condición bloquea el arranque, qué puede completarse después y qué no es necesario para ese servicio.

Datos recibidos, datos validados y datos pendientes

Una de las separaciones más útiles durante el onboarding es diferenciar solicitado, recibido y validado. Si esas tres situaciones se mezclan, el proceso puede avanzar antes de tiempo.

Que un cliente escriba un NIF en un formulario significa que el dato ha sido recibido. No significa necesariamente que esté validado para el uso que la gestoría vaya a darle. Del mismo modo, disponer de una dirección no confirma por sí solo que sea la dirección que corresponde utilizar en un trámite concreto.

La automatización puede hacer comprobaciones preliminares: formato, longitud, presencia de campos, coincidencias entre fuentes o contradicciones aparentes. También puede señalar que un dato falta o que dos documentos contienen información distinta. La validación definitiva debe apoyarse en las reglas y fuentes adecuadas al dato y al servicio.

Esto evita dos extremos. El primero es considerar válido todo lo que llega. El segundo es diseñar un proceso excesivo donde cualquier campo deba comprobarse contra una fuente oficial aunque el servicio no lo requiera. El nivel de comprobación debe responder a la finalidad y al riesgo operativo de ese dato.

El servicio contratado determina qué información y tareas hacen falta

Un alta también puede fallar cuando la información comercial no se traduce correctamente a trabajo operativo. El cliente puede estar creado, pero el sistema no sabe qué servicios están activos y, por tanto, no sabe qué documentación, autorizaciones o tareas debe exigir.

Una gestoría puede trabajar, por ejemplo, con servicios fiscales, contables, laborales, mercantiles o con trabajos puntuales. Son categorías orientativas, no una clasificación universal. Lo importante es que el sistema represente el alcance contratado de forma suficientemente clara.

Ese alcance condiciona el onboarding. Si el cliente contrata fiscal y contable, no tiene sentido generar automáticamente tareas laborales solo porque forman parte de una plantilla general. Del mismo modo, un servicio adicional puede requerir documentación o permisos que otro cliente no necesita.

El checklist de alta debería derivarse del servicio, no al revés. Primero sabemos qué vamos a hacer para el cliente; después determinamos qué necesitamos para poder hacerlo.

Autorizaciones y representación: saber qué falta antes de iniciar una actuación

En determinadas tareas la gestoría necesita poder actuar en nombre del cliente o disponer de una autorización concreta. Ese requisito no debería quedar escondido en un correo o depender de que alguien recuerde comprobarlo antes de presentar un trámite.

En el ámbito tributario, la Agencia Tributaria dispone de un registro de apoderamientos para actuaciones por Internet en trámites habilitados. Los poderes pueden referirse a trámites concretos o tener un alcance más amplio según los casos previstos. También existe la colaboración social para determinadas actuaciones en representación de terceros. No son conceptos equivalentes ni puede asumirse que todas las gestorías operen exactamente con el mismo mecanismo.

Para el onboarding, la automatización no necesita resolver toda la casuística jurídica. Necesita representar de forma fiable si una autorización es necesaria, cuál es su estado y qué tarea depende de ella.

La IA puede reconocer que un cliente ha enviado un documento que parece relacionado con una autorización, clasificarlo y preparar la revisión. Lo que no debería hacer es dar por válido el alcance de un poder porque encuentra una firma o determinada frase en un PDF. Esa comprobación requiere la fuente, regla o revisión adecuada al caso.

La guía sobre autorizaciones y aprobaciones pendientes de clientes profundiza en solicitudes, recordatorios, aprobación, rechazo y desbloqueo. Aquí las tratamos únicamente como condición de arranque.

La documentación inicial debe formar un expediente de arranque, no una colección de adjuntos

Durante el alta pueden llegar DNI o NIF, escrituras, contratos, certificados, información bancaria, documentación laboral, libros o ficheros anteriores. El conjunto depende del tipo de cliente y de los servicios contratados. Por eso no conviene publicar una lista universal de documentos “obligatorios”.

Lo que sí puede modelarse es el estado de cada elemento: necesario → recibido → identificado → asociado al cliente → validado o pendiente de revisión. El canal por el que llega es secundario. Puede ser correo, portal, formulario, carpeta compartida o software de gestión.

La diferencia importa porque descargar un archivo no completa nada por sí solo. El documento debe poder relacionarse con un cliente, con un requisito y con un estado. Si llega un PDF por correo pero nadie sabe a qué expediente corresponde, el problema documental sigue abierto.

Cuando falta un documento, el proceso entra ya en el terreno desarrollado en cómo automatizar la documentación pendiente de clientes. En la entrada actual basta con detectar que el paquete inicial no está completo y transferir ese pendiente al circuito correspondiente.

Lo mismo ocurre con el correo. Puede ser un canal excelente para recibir información, pero no debería convertirse en el lugar donde vive el estado del onboarding. En nuestra guía sobre automatización del correo de una gestoría desarrollamos esa diferencia con más detalle.

Un cliente puede necesitar configuración en varios sistemas sin convertirse en varios clientes

Según el stack de la gestoría, el nuevo cliente puede requerir alta o configuración en ERP, contabilidad, CRM, gestor documental, portal del cliente, tareas, nóminas u otras aplicaciones. El riesgo aparece cuando cada sistema se trata como una operación aislada.

La automatización debería coordinar escrituras autorizadas y conservar los identificadores creados. Si el ERP confirma que el cliente ya existe, un reintento posterior no debería crear una segunda ficha. Esta propiedad suele denominarse idempotencia: repetir una operación no debe producir un efecto duplicado cuando la primera ejecución ya terminó correctamente.

También conviene definir qué sistema manda en cada dato. Puede haber un sistema principal de cliente y aplicaciones especializadas que reciban una parte de la información. Si dos herramientas pueden modificar de forma independiente el mismo dato sin una regla clara, tarde o temprano aparecerán discrepancias.

Holded puede servir como ejemplo de software donde contactos, documentos, portal y tareas se relacionan dentro de un mismo ecosistema. Odoo ofrece otra combinación posible de contactos, documentos, firma y proyectos. Son ejemplos de producto, no una recomendación universal. La arquitectura debe partir del proceso y del stack existente, no de una herramienta concreta.

El alta debe terminar en responsables y primeras tareas concretas

La incorporación de un cliente no debería acabar en un estado genérico de “completado”. Debe desembocar en trabajo real. Según el servicio, puede ser revisar documentación inicial, preparar una migración contable, solicitar información adicional, configurar un calendario interno o crear las primeras tareas laborales.

Cada tarea debería nacer, como mínimo, con:

• Cliente. A qué relación o expediente pertenece.
• Servicio. Qué parte del alcance contratado la justifica.
• Responsable. Quién debe actuar.
• Fecha o condición. Cuándo debe empezar o qué evento la activa.
• Estado. Qué situación refleja en este momento.
• Contexto. Qué información necesita la persona que la ejecuta.

“Revisar cliente nuevo” es una nota. “Revisar documentación contable inicial de Cliente X antes de iniciar la migración” es una tarea operativa. Esta diferencia es importante para poder supervisar el alta y detectar bloqueos.

Cuando esas obligaciones pasan a repetirse por periodos, fechas y dependencias, dejan de ser parte del onboarding. Ese escenario corresponde a la guía sobre tareas y plazos recurrentes en gestorías.

Qué ocurre cuando un paso falla después de haber avanzado en otros

Los onboardings reales no avanzan siempre en línea recta. Puede existir un cliente antiguo con datos desactualizados, dos contactos para la misma empresa, un documento ilegible, una autorización pendiente, un alta creada en un sistema pero fallida en otro o tareas duplicadas después de un reintento.

La respuesta no debería ser volver a empezar todo el proceso. La automatización necesita conservar qué está resuelto y qué sigue bloqueado. Una excepción útil indica tres cosas: qué falló, qué parte del alta queda afectada y qué acción permite continuar.

Cuándo cerrar realmente el alta y pasar el cliente a operación normal

El cierre del onboarding debería responder a condiciones verificables, no a una percepción general de que “ya está casi todo”. Si la gestoría no define ese momento, el alta puede quedarse abierta durante semanas o cerrarse demasiado pronto mientras continúan apareciendo tareas de arranque.

Una forma práctica de resolverlo es separar tres grupos. Las condiciones de activación son las que deben estar resueltas para comenzar el servicio con control. Las tareas posteriores pueden seguir abiertas después del alta porque no impiden trabajar. Y los elementos opcionales solo se solicitan cuando existe una necesidad concreta.

Por ejemplo, una autorización necesaria para presentar un trámite puede ser condición de activación para esa actuación. Una formación sobre el portal del cliente puede ser una tarea posterior. Un documento que solo sería útil si el cliente contrata otro servicio no debería convertirse en un pendiente obligatorio del alta actual.

El sistema puede representar esta diferencia mediante una matriz sencilla: condición, estado, fuente que la confirma, responsable y acción que desbloquea. De ese modo, el cierre deja de depender de que alguien revise mentalmente una lista de correos y carpetas.

Este criterio también mejora la transición entre equipos. El responsable que recibe al cliente puede ver qué está confirmado, qué sigue pendiente, quién lo está gestionando y qué primeras tareas ya están abiertas. No necesita reconstruir el contexto preguntando a comercial, administración y compañeros.

La fecha de cierre del alta también debe quedar registrada para distinguir el periodo de incorporación de la gestión ordinaria.

Cuando el onboarding termina, las obligaciones periódicas y los expedientes posteriores deben continuar en sus propios circuitos. Así se evita que el alta se convierta en un contenedor permanente de cualquier tarea futura del cliente.

Arquitectura de referencia para una gestoría

Para explicar el sistema a dirección basta con separar cinco zonas. No es un stack obligatorio, sino una forma de entender dónde vive cada responsabilidad.

El principio más importante es sencillo: el estado del alta debe vivir en un sistema gestionable. La bandeja de correo o una hoja auxiliar pueden participar, pero no deberían ser el único lugar donde alguien pueda averiguar qué falta para empezar.

Gmail API y Microsoft Graph permiten recuperar mensajes y adjuntos cuando existen los permisos adecuados. Son ejemplos técnicos de que el correo puede alimentar un flujo de onboarding. La integración no termina al descargar el archivo: todavía hay que identificarlo, asociarlo al cliente y actualizar su estado operativo.

Pedir solo lo que hace falta para el servicio contratado

Un onboarding tiende a acumular información “por si acaso”. Puede parecer práctico pedir desde el principio todos los documentos que la gestoría utiliza en cualquier servicio, aunque ese cliente no los necesite. Ese enfoque aumenta el volumen de datos y dificulta saber qué es realmente obligatorio.

La AEPD recuerda que la protección de datos por defecto exige limitar cantidad, extensión del tratamiento, conservación y accesibilidad a lo necesario para la finalidad. Aplicado al alta, esto significa que el paquete de datos y documentos debe derivarse del servicio contratado y del proceso real.

La IA añade una precaución adicional. Un modelo puede extraer muchos más datos de un documento de los que el proceso necesita. Que pueda hacerlo no significa que deba convertir cada dato detectado en un campo permanente del CRM. La extracción debe estar acotada a la finalidad y mantener revisión cuando la exactitud tenga impacto.

Qué indicadores utilizar para medir el proceso de alta

No existe un tiempo de alta válido para todas las gestorías y todos los tipos de cliente. Una sociedad con varias áreas de servicio puede necesitar un proceso muy distinto al de un autónomo con un alcance limitado. Por eso conviene definir primero cómo funciona el proceso actual y utilizar indicadores que permitan seguir su evolución.

Algunas métricas útiles son:

• Tiempo desde la decisión de trabajar con el cliente hasta el alta operativa.
• Altas cerradas con condiciones críticas todavía pendientes.
• Datos o documentos pendientes por cliente.
• Tiempo bloqueado por autorizaciones.
• Altas con responsable asignado desde el inicio.
• Altas con primeras tareas creadas correctamente.
• Incidencias por clientes duplicados.
• Incidencias por configuración incompleta entre sistemas.
• Retrabajo detectado durante los primeros días.

Estas métricas no demuestran por sí solas que una automatización sea buena. Sirven para entender dónde se atasca el proceso y comparar el antes y el después con definiciones estables.

Preguntas frecuentes sobre el alta de clientes en gestorías

Antes de automatizar más tareas, conviene revisar cómo se incorpora hoy un nuevo cliente

Si el alta actual depende de correos internos, checklists informales, carpetas compartidas y comprobaciones manuales, podemos revisar el proceso completo desde la decisión de trabajar con el cliente hasta que el equipo está preparado para empezar.

El diagnóstico permite identificar qué condiciones deben controlarse, qué información puede interpretar la IA, qué validaciones necesitan reglas o fuentes fiables, qué sistemas deben intercambiar datos y dónde aparecen excepciones que hoy quedan ocultas.