Cómo renovar tu CRM empresarial sin paralizar las operaciones

La renovación del CRM de una empresa casi nunca empieza por una pantalla mal diseñada. Empieza cuando se aprueba una solicitud de suscripción por correo electrónico y esta nunca llega al expediente de la póliza. Cuando los agentes de atención al cliente crean cuentas duplicadas porque es más rápido que arreglar la que ya existe. Cuando en una auditoría de Solvencia II te preguntan quién cambió un factor de calificación en marzo, y la respuesta está dispersa entre Salesforce, la plataforma de pólizas y una hoja de cálculo en el portátil de alguien.

Para saber cómo reestructurar el CRM de una empresa, lo primero es interpretar bien esos fallos. Se trata de problemas operativos y de control de datos, no de un retraso en la configuración.

Para una aseguradora, Salesforce Financial Services Cloud ofrece una base operativa sólida para gestionar las relaciones con asesores, corredores y clientes particulares. Pero no va a resolver la falta de claridad sobre quién toma las decisiones de suscripción, las reglas incoherentes sobre la «fuente de verdad» ni los procesos de aprobación basados en excepciones que nadie ha dejado por escrito. Una reestructuración tiene que abordar estos tres aspectos, o no servirá de nada.

Empieza la remodelación del CRM de la empresa definiendo los límites del flujo de trabajo

La primera decisión no es si volver a implementar Salesforce, pasarte a Zoho o encargar un software a medida. Es dónde debe empezar y acabar el CRM.

Piensa en la suscripción de seguros comerciales. Un corredor presenta un riesgo. El departamento de operaciones comprueba que esté todo completo. Un suscriptor evalúa la exposición al riesgo, un suscriptor sénior aprueba todo lo que supere la autoridad delegada y el sistema de gestión de pólizas emite la póliza. Salesforce podría ser la herramienta ideal para la comunicación con los corredores, la recepción de solicitudes, las colas de trabajo, las tareas y el registro de aprobaciones. La plataforma de pólizas sigue siendo la referencia para el cálculo de primas, la emisión y las modificaciones.

Esa división hace un trabajo de verdad. Si copias todos los atributos de las pólizas en Salesforce, te estás creando una deuda de sincronización, además de una pantalla que parece fiable pero no lo es. Si eliminas demasiado contexto operativo, los usuarios vuelven al correo electrónico. La pregunta práctica es: ¿qué usuario necesita qué datos para tomar qué decisión, y qué sistema se hace responsable del registro después?

Resuelve esto a nivel de flujo de trabajo antes de tocar ni un solo campo. Para cada etapa, define el evento desencadenante, la documentación necesaria, quién toma la decisión, el sistema de registro, la acción posterior y la ruta de excepción. Esto último suele ser precisamente donde el CRM actual ya falla.

Establece unos valores de referencia mientras estás en ello: tiempo medio desde la presentación hasta el cierre, tasa de derivación, solicitudes devueltas por falta de información, tasa de cuentas duplicadas y porcentaje de aprobaciones realizadas fuera del CRM. Si la remodelación no modifica esas cifras ni explica por qué cambian, lo único que has hecho ha sido reorganizar una interfaz.

Rediseña el modelo de datos con la trazabilidad como eje central

La mayoría de los sistemas CRM heredados son como sedimentos: importaciones antiguas, soluciones provisionales locales, integraciones obsoletas y campos añadidos para un informe que ya nadie usa. Es necesario eliminarlos. Pero eso no es una estrategia de datos.

Primero establece un modelo claro para las partes, las relaciones, las solicitudes, las políticas, las reclamaciones, los intermediarios y el consentimiento. Después, haz lo más complicado: indica la fuente oficial para cada uno y redacta las reglas de supervivencia. El nombre legal puede proceder de un servicio de datos maestros, la relación con el corredor del CRM, y la cobertura y la prima de la plataforma de pólizas. El consentimiento suele necesitar su propio ciclo de vida regulado, sobre todo cuando el consentimiento para el marketing, el consentimiento para la gestión de la póliza y la base legal se han tratado discretamente como si fueran lo mismo.

Para cada entidad compartida, asigna un responsable y decide qué pasa en caso de conflicto. Un agente actualiza la dirección de contacto en Salesforce; la integración nocturna trae un valor diferente desde el portal. ¿Cuál prevalece? ¿Puede un usuario de operaciones anularlo? ¿Se registra esa anulación como un evento auditable? Estas respuestas determinan si alguien confía en el sistema al cabo de un año.

Adapta las normas de calidad de los datos al riesgo real. Hacer que todos los campos sean obligatorios en la fase inicial solo porque, más adelante, algún proceso los necesite, no hace más que enseñar a los usuarios a introducir valores provisionales, y tus informes acabarán sufriendo las consecuencias. Exige datos solo cuando una decisión dependa de ellos: los detalles de la exposición pueden ser opcionales en el borrador de un corredor, pero deben ser obligatorios antes de que un suscriptor acepte la solicitud para su revisión.

Controles de diseño para Solvencia II, el RGPD y el día a día

Los controles solo funcionan cuando se aplican en el proceso de trabajo. Solvencia II exige a las aseguradoras que demuestren una gobernanza eficaz y la trazabilidad de las decisiones importantes, y un proceso de aprobación con una marca verde no cumple ese requisito.

El registro debe incluir el límite de autoridad delegada vigente en ese momento, el proceso seguido, la persona que lo aprobó, la documentación revisada, las marcas de tiempo y cualquier justificación de la excepción. Cuando los límites cambien el próximo trimestre, la aprobación del trimestre anterior debe poder explicarse según la norma que se aplicaba entonces. Crea la matriz de autorizaciones como datos de referencia regulados con fechas de vigencia, en lugar de una lógica dispersa entre flujos, fórmulas y la hoja de cálculo de un administrador.

El RGPD exige algo diferente. La minimización de datos y la limitación del almacenamiento no se pueden cumplir con una simple limpieza anual. Define el evento que pone en marcha el plazo de conservación —caducidad de la cotización, rescisión de la póliza, cierre de la reclamación, fin de la retención legal— y, a continuación, establece un procedimiento de eliminación que respete los litigios activos y los archivos posteriores. Shield, la seguridad a nivel de campo y la supervisión de eventos respaldan este modelo. No eligen la política por ti.

Sé sincero: los sistemas estándar ya disponibles funcionan bien. Las aprobaciones estándar y Flow gestionan bien el enrutamiento acotado. Un motor de derivación que evalúe cientos de condiciones relacionadas con productos, zonas geográficas, capacidad y tratados, con lógica versionada, es más seguro si se trata de un servicio de reglas diseñado específicamente para eso. El CRM debería presentar la decisión y conservar las pruebas sin fingir que es él quien realiza el cálculo.

Menos migraciones, más conciliaciones

Una reconstrucción del CRM no te obliga a conservar todos los registros antiguos. El historial tiene su razón de ser cuando sirve de apoyo para la atención al cliente, la retención, el análisis o la resolución de disputas. Pero te sale caro cuando genera identidades duplicadas y una confianza errónea en los informes.

Clasifica los datos de cuatro formas: registros operativos activos, historial conservado, datos de referencia y residuos eliminables. Los registros activos se mueven. El historial suele pertenecer a un archivo controlado con un procedimiento de recuperación, no a cada maquetación de página. Los datos de referencia necesitan un control de propiedad y de autorización. Los residuos solo se eliminan una vez que los departamentos jurídico, de cumplimiento normativo y el departamento comercial hayan firmado la orden de eliminación.

Ensaya la migración centrándote en los resultados del negocio, en lugar de en el recuento de filas. Una buena prueba comprueba que cada solicitud pendiente tenga un responsable, que cada agente activo esté asociado a la entidad jurídica correcta, que cada aprobación en curso conserve su documentación y que la gente pueda ponerse a trabajar desde la primera mañana tras la transición. La coincidencia en el recuento de filas nunca sacará a la luz un eslabón perdido entre una solicitud y su póliza anterior.

Haz que la experiencia de usuario (UX) sea un elemento fundamental, no solo un adorno superficial

Los suscriptores y los gestores de siniestros evitarán usar un CRM que ralentice el trabajo rutinario. Eso rara vez se debe a resistencia al cambio. Normalmente significa que la pantalla se adapta al modelo de datos en lugar de adaptarse al trabajo.

Crea páginas de registros en función de la siguiente decisión. Un suscriptor que abre una solicitud quiere tener a la vista en su área de trabajo los datos de riesgo, el historial del corredor, su nivel de autoridad, avisos sobre información que falta y las aprobaciones correspondientes, y no ochenta campos ordenados por titularidad del objeto. Un equipo de siniestros quiere ver el estado de las reservas, las pruebas de cobertura, los datos de los proveedores, los controles de pago y una cronología clara.

Haz pruebas con situaciones cronometradas antes de terminar el desarrollo. ¿Cuánto tiempo se tarda en clasificar una solicitud, derivar una excepción, encontrar una justificación para la aprobación o solucionar un problema de calidad de los datos? Anota cada momento en el que alguien tiene que recurrir al correo electrónico o a una hoja de cálculo. Esos momentos te permiten detectar una integración que falta o una regla de validación innecesaria más rápido que cualquier comité directivo.

Usa la IA solo cuando la decisión se pueda controlar

La IA ayuda de verdad a extraer datos de las solicitudes, clasificar la correspondencia, resumir las notas de las reclamaciones y proponer las próximas acciones. En las operaciones reguladas, no debe convertirse en un responsable de la toma de decisiones imposible de rastrear en lo que respecta a la elegibilidad, la fijación de precios o los resultados de las reclamaciones.

Para cualquier flujo de trabajo asistido por IA, define el conjunto de datos de entrada, el resultado permitido, el umbral de confianza, el revisor humano, el registro de auditoría y la vía de escalado. Un modelo que señale la falta de un documento resulta útil cuando un gestor lo confirma. Un modelo que reclasifica un riesgo sin avisar supone un riesgo de gobernanza. Dependiendo de la zona geográfica y del caso de uso, la Ley de IA de la UE, las disposiciones del RGPD sobre la toma de decisiones automatizada y tu propia política de riesgos de modelos pueden tener consecuencias.

Un asistente basado en Claude puede resumir la correspondencia larga sobre reclamaciones o destacar las cláusulas relevantes de la póliza —limitado a los documentos aprobados, registrados y con las referencias visibles para el gestor—. Nunca debe inventarse una interpretación de la cobertura ni eludir la autoridad delegada.

Considera la transición como la primera prueba de funcionamiento

La reestructuración estará lista cuando la empresa pueda gestionar sus casos más complicados, no cuando los paneles de control parezcan estar terminados. Ensaya con solicitudes incompletas, anulaciones de autorización, agentes duplicados, reclamaciones reabiertas, cortes en la integración y solicitudes de los interesados. Cada uno de ellos necesita un responsable designado, un comportamiento esperado y una ruta de recuperación.

La pregunta clave para un director de sistemas de información es muy sencilla. Tras esta reestructuración, ¿puede un suscriptor tomar una decisión fundamentada más rápido? ¿Y puede la empresa explicar esa decisión meses después sin tener que reconstruirla a partir de correos electrónicos? Si es así, el CRM se ha convertido en una tecnología con un propósito claro, en lugar de ser un sistema más con el que la gente tiene que lidiar.