Modelo de Carpeta Única del Cliente y buenas prácticas – Athento

En el sector financiero, asegurador o de servicios, uno de los objetivos más comunes es lograr una gestión documental centralizada por cliente. Esto permite consultar, mantener y controlar la documentación del cliente desde distintos canales, procesos o aplicaciones.

Athento permite implementar el modelo de "Carpeta Única" o "Expediente de cliente", en el cual se deben tener en cuenta los siguientes elementos y buenas prácticas que, según la experiencia de Athento, han sido clave para una implementación exitosa.

Definir metadatos clave o esquema canónico

Lo más importante para implementar la carpeta única es definir un metadato clave que identifique al cliente de forma unívoca. En la mayoría de los casos, este metadato corresponde al número de identificación del cliente, o incluso puede ser el ID del cliente proveniente de un sistema externo (CRM, core bancario, etc.).

Con los metadatos clave se creará un formulario tipo "Expediente" del cliente. Este tipo documental funcionará como un contenedor lógico para todos los documentos asociados a ese cliente.

Se recomienda que el tipo de metadato clave sea uno, pero en caso de haber varios, se recomienda que sean máximo 4 o los que llamamos canónicos, algunos recomendados son el ID del cliente, tipo de cliente, nombre, identificador único del cliente en el core, etc.

Los tipos de metadatos clave deberán estar activos en todos los tipos documentales creados a los cuales se desea vincular al expediente/carpeta cliente., independientemente del team o espacio, para ello se utiliza la funcionalidad de la biblioteca de campos (Marketplace).

Athento utiliza relaciones documentales (tipo “padre-hijo”) en las cuales el tipo documental del expediente cliente corresponderá al padre y los documentos individuales (contratos, formularios de vinculación, actas, etc.) serán los hijos, facilitando la estructura jerárquica clara, navegación y auditoría.

El ID del cliente funcionará como filtro principal para búsquedas, reglas, automatizaciones y consultas API en la herramienta.

Identificar los tipos documentales transversales vs. específicos de producto

Para el modelo es necesario clasificar correctamente los tipos documentales para determinar su comportamiento dentro del expediente del cliente, para ello se recomienda definir los tipos documentales entre transversales y específicos.

Documentos transversales:

Son todos aquellos documentos que pueden reutilizarse en varios productos o procesos, además son los que identifican cómo tal al cliente, cómo por ejemplo; Documento de identidad, Certificación de ingresos, Declaración de impuestos, entre otros.

Documentos específicos:

Son documentos que solo aplican al contexto de un producto o servicio contratado y normalmente cambian con cada solicitud y su reutilización es nula, por ejemplo: Póliza de vida, Formulario de alta de producto,Análisis de riesgo de inversión etc.

Esta clasificación se realiza a través de diccionarios que contendrán la lógica de cada tipo documental en el team de Cliente. Esta información puede consultarse vía API.

Definiciones transversales de Vigencias

Para cada uno de los tipos documentales se debe establecer la vigencia de los documentos, especialmente de aquellos que se reutilizan o transversales. La vigencia de los documentos acorde al negocio deberá definirse una duración uniforme sin importar el producto o servicio, el cual será aplicado en el team.

La fecha de fin de vigencia se calculará en base a dos características del documento, ya sea desde la fecha de creación del documento, o una fecha del documento en sí.

Las vigencias de manera general, se realizan a través de diccionarios que contendrán la lógica de cada tipo documental en el team de Clientes. Esta información puede consultarse vía API.

Dentro de Athento utilizamos el ciclo del documento en el que se establecen estados como “Vigente”, “Vencido”, “Archivado”.

Actualización de documentos

Los documentos pueden ser actualizados en Athento. La aplicación por defecto cuenta con un sistema de control de versiones. ¿Cómo funcionan las versiones en Athento?

Organización o estructura lógica de los documentos

Se recomienda almacenar toda la documentación de los clientes en un mismo equipo, especialmente si la consulta de los documentos re realiza mediante la interfaz del software. Si la consulta se hace vía API, los usuarios de servicio pueden hacer consultas transversales a los teams o equipos.

Si se requiere separar procesos en diferentes teams o equipos, la documentación del cliente, una vez terminado el proceso, debería quedar vinculada al expediente del cliente. Para ello, puede ayudarse de automatismos que vinculen el documento mediante datos clave, que creen una copia (sin duplicar el binario), o que muevan de ubicación los documentos una vez finalizados los procesos transaccionales.

Gobierno documental recomendado

Para garantizar la sostenibilidad del modelo de carpeta única, es imprescindible contar con un modelo de gobierno documental que abarque los siguientes aspectos

Mantenimiento de diccionarios: gestionar y actualizar los diccionarios de tipos documentales a medida que se implementen nuevos procesos.
Continuar con la uniformidad de campos, utilizando los campos comunes o canonicos establecidos, para los nuevos formularios.
Estructuras lógicas dentro del expediente: Dentro del expediente, pueden generarse subestructuras de carpetas. Estas subestructuras pueden generarse de forma automática, mediante plantillas, de manera que la organización de la documentación sea homogénea entre expedientes. De forma frecuente, se utilizan subcarpetas que agrupen los documentos relacionados con la contratación de un producto expecífico. Estas carpetas pueden ser folders normales o formularios tipo folderish. ¿Cómo crear una jerarquía de carpetas a partir de una plantilla?
Grupos y permisos: Definir que usuario u aplicaciones pueden consultar y/o,actualizar según el proceso o negocio. Athento permite los permisos por objeto a nivel de carpeta o de documento individual. Estos permisos se pueden asignar de forma dinámica. En cualquier caso, recuerde que es vital un diseño de grupos y permisos que sean sostenibles en el tiempo. Diseños complejos de permisos tienen un impacto directo en el performance de la aplicación.
Escalabilidad en nuevos espacios: Si desea implementar el modelo en nuevos espacios, active los automatismos desde la consola de Administración que ya se encuentran en uso en el equipo origen. De esta manera, si necesita hacer cambios en un automatismo, no tendrá que hacerlo manualmente para cada espacio.