Vista 360 del cliente en seguros: qué se necesita realmente para construirla

En resumen: en seguros, la vista 360 del cliente no es una funcionalidad que se compra con un CRM, sino una arquitectura de datos que se construye por debajo de él. Lo difícil no es mostrar la información del asegurado en una pantalla, sino determinar con certeza que cinco registros dispersos en sistemas distintos corresponden a la misma persona.

El mismo asegurado, cinco identidades

Una misma persona puede ser, al mismo tiempo, titular de una póliza de autos, asegurado dentro de un colectivo de gastos médicos, beneficiario en una póliza de vida, reclamante en un siniestro abierto y prospecto en el CRM de un agente. Son cinco registros en cuatro o cinco sistemas, cada uno con su propia llave primaria y su propia definición de "cliente". Ninguno sabe de la existencia de los demás.

Cuando la dirección pide una vista 360, el proyecto suele arrancar por la interfaz: un CRM nuevo, un portal, un tablero. Meses después el tablero existe, pero muestra cinco personas donde hay una. No falló en la pantalla; falló mucho antes, en una capa que nadie miró.

Qué es un cliente 360 y qué no es

Un cliente 360 es un registro único, confiable y gobernado de cada asegurado: identidad resuelta, pólizas de todos los ramos, historial de siniestros, estado de cobranza e interacciones de servicio, todo referido a la misma persona, con una sola versión válida de cada dato.

Lo que no es: una pantalla. Buena parte de la conversación del mercado lo presenta como una funcionalidad —un módulo de CRM, una ficha unificada— y eso confunde el resultado con el medio. La ficha es la superficie donde se consume el registro unificado, no lo que lo produce. Un CRM excelente alimentado con identidades fragmentadas devuelve, con muy buen diseño, información equivocada.

Por qué en seguros cuesta más que en otras industrias

El core está diseñado alrededor de la póliza, no de la persona. Los sistemas administrativos se construyeron para emitir, endosar y renovar contratos. El asegurado existe como un campo dentro de la póliza, no como una entidad con vida propia. Reconstruir a la persona a partir de sus contratos va contra el diseño original. Y cuando la relación la sostiene un agente, buena parte del contexto del cliente vive fuera de esos sistemas.

Cada ramo suele tener su propia plataforma. Autos, vida, gastos médicos y daños operan con lógicas técnicas y regulatorias distintas, a menudo sobre plataformas distintas heredadas de adquisiciones. Unificar al cliente implica cruzar fronteras que no son solo técnicas: cada ramo tiene su propio dueño del dato. A eso se suma que parte de esa información —los antecedentes de salud en gastos médicos— es sensible y no puede consolidarse con los mismos criterios de acceso que un teléfono.

No existe una llave confiable para unir los registros. En teoría, CURP y RFC deberían resolver el problema. En la práctica se capturan de forma parcial o inconsistente, con errores de dedo, homónimos, apellidos maternos omitidos y domicilios de hace una década. La unificación no es un JOIN; es un problema de inferencia.

Las tres capas que lo hacen posible

Conectividad sobre lo que ya existe. El primer requisito es extraer datos y metadatos del core legacy, del ERP, de las plataformas de siniestros y de los canales digitales sin reemplazarlos ni degradar la operación. Ninguna aseguradora puede detener la emisión para construir una vista de cliente.

Resolución de identidad y golden record. Es el corazón del problema y lo que ningún proveedor de interfaz resuelve. Consiste en definir las reglas —deterministas donde hay llaves confiables, probabilísticas donde no— que deciden que cinco registros son una persona, y en preservar la jerarquía de roles: titular en una póliza, asegurada en otra, beneficiaria en una tercera. Esas relaciones son información valiosa, no ruido por eliminar. El resultado es un registro maestro con una regla explícita de qué fuente gana en cada atributo.

Calidad y gobierno desde el origen. Validar y normalizar en tránsito, no limpiar después: un golden record construido sobre datos sucios consolida el error y lo vuelve más difícil de detectar, porque ahora tiene apariencia de verdad única. El linaje —saber de qué sistema viene cada atributo y quién lo tocó— resuelve además el cumplimiento: no se puede atender una solicitud de derechos ARCO —acceso, rectificación, cancelación u oposición— si no se sabe en cuántos sistemas vive esa persona. En un registro unificado, el consentimiento deja de ser un documento archivado y se convierte en un atributo del cliente, consultable por finalidad.

Qué se desbloquea y por dónde empezar

Con la identidad resuelta, tres cosas cambian. La persistencia se vuelve gestionable: la cancelación se anticipa con contexto completo en lugar de detectarse en el recibo vencido. La venta cruzada deja de ser una campaña a ciegas: en un mercado donde, según la AMIS, la penetración del seguro ronda el 3% del PIB frente al 8% de los países de la OCDE, el cliente con mayor probabilidad de contratar un segundo producto casi siempre ya está en la cartera, invisible como persona. Y la suscripción gana precisión, porque el historial completo —incluidos los siniestros de otros ramos— alimenta tanto el pricing como la detección de patrones anómalos.

Es también la condición de entrada a la hiperpersonalización que las mayores aseguradoras del país ya anunciaron como apuesta: ningún motor de recomendación ni de pricing dinámico funciona sobre una identidad fragmentada. Es el patrón que Gartner anticipó al predecir que las organizaciones abandonarían la mayoría de los proyectos de IA sin datos listos para IA. El modelo rara vez es el problema.

El orden importa. Empezar por la superficie produce tableros elegantes sobre datos irreconciliables; empezar por la capa de datos permite que cualquier superficie posterior —CRM, portal, app del agente— trabaje sobre la misma verdad. En Arkon acompañamos ese punto de partida con un data assessment que evalúa el estado actual de la arquitectura y traza la ruta hacia un registro unificado sin reemplazar el core. Es una conversación técnica, sin compromiso.

Preguntas frecuentes sobre vista del cliente 360 en seguros

¿Qué es un cliente 360 en seguros?

Es un registro único y gobernado de cada asegurado que reúne identidad, pólizas de todos los ramos, siniestros, cobranza e interacciones de servicio en una sola versión confiable. No es una pantalla ni un módulo de CRM: es la capa de datos que permite que esas interfaces muestren información correcta.

¿Se puede lograr una vista 360 sin reemplazar el core de pólizas?

Sí, y normalmente es el único camino viable. Una capa de conectividad y orquestación extrae datos y metadatos de los sistemas actuales, resuelve la identidad del cliente y entrega el registro unificado a las aplicaciones que lo consumen, todo sin detener la emisión ni migrar el core.

¿Qué diferencia hay entre un CRM y un golden record de cliente?

El CRM gestiona la relación comercial y muestra información; el golden record decide cuál es la información correcta. Un CRM puede consumir un golden record, pero no puede generarlo: no tiene acceso a los sistemas donde vive el dato de origen ni las reglas para reconciliar registros duplicados entre ramos.