Para un responsable de siniestros cuenta una sola cosa: cuánto dura el camino del aviso al pago y cuántas personas tienen que tocarlo por el camino. Cada día de retraso significa mayor coste de servicio y menor satisfacción del cliente, y cada paso manual es un sitio donde un expediente puede atascarse. La gestión de siniestros es hoy un proceso de datos y decisiones, no solo de papel, así que su eficiencia depende del software que la soporta.
Por nuestra experiencia, lo difícil no es diseñar el formulario de entrada, sino unir todo el camino en un único flujo medible: del FNOL, pasando por la resolución, hasta conciliar el pago con finanzas. No tenemos un caso de éxito en este terreno que enseñarte, pero sí algo igual de concreto: ingenieros que construyen sistemas de proceso, integraciones y capa de datos, más competencias de IA dentro del Grupo RITS. Reforzamos al equipo de la aseguradora con las personas que hacen este trabajo.
¿Por qué duele tanto la gestión de siniestros?
La mayoría de los retrasos no vienen de decisiones difíciles, sino del cambio de contexto. Un perito salta entre el sistema de pólizas, una bandeja de correo, una hoja de cálculo y el portal de un taller, reescribiendo los mismos datos varias veces. La información sobre un siniestro se dispersa entre canales y el responsable no ve en un solo sitio qué expediente está incumpliendo su SLA.
Encima de eso se apilan tres dolores que se repiten en todos los proyectos:
- no hay una única fuente de verdad sobre el expediente, así que el estado depende de a quién preguntes,
- las reglas viven en la cabeza de los peritos veteranos y no en el sistema,
- la conciliación manual de pagos y recobros se va separando de los libros de finanzas.
Cada uno por separado se sobrevive. Juntos construyen un proceso que no puede escalar sin añadir personas.
¿Cómo debe ser la declaración digital de siniestro (FNOL)?
Un buen FNOL (first notice of loss, primer aviso de siniestro) quita trabajo al perito antes incluso de que abra el expediente. En lugar de una llamada y un reteclear, el cliente o el agente rellenan un formulario o una app que valida los datos y abre el expediente al instante. Diseñamos ese momento para que ocurra automáticamente todo lo posible, y una persona intervenga solo donde hace falta su criterio.
En la práctica construimos un canal de entrada que:
- guía al declarante paso a paso, adaptando las preguntas al tipo de siniestro,
- valida la póliza y la cobertura en tiempo real, antes de que el expediente entre en una cola,
- abre el expediente automáticamente con número, categoría y una prioridad inicial,
- acepta adjuntos (fotos, documentos, grabaciones) y los archiva contra el expediente.
Así el perito recibe un expediente completo y no un aviso en bruto que haya que perseguir.
¿Qué es un motor de workflow y de resolución de siniestros?
El corazón del sistema es un motor de proceso que sabe qué debe pasar en cada etapa. Lleva el expediente por el registro, la peritación, la decisión y el pago, haciendo cumplir reglas y plazos. La clave está en que las reglas de negocio se puedan cambiar sin reescribir código, porque en siniestros cambian a menudo, siguiendo a los productos y a la regulación.
Un motor así es dueño de las etapas y las transiciones entre ellas, de las reglas de resolución (qué se puede liquidar automáticamente y qué necesita a una persona), de los umbrales de aprobación y las vías de escalado y de la medición del SLA en cada paso. Cuando un expediente se acerca al incumplimiento, el sistema lo escala por sí mismo y lo pone delante del responsable antes de que lo haga un cliente descontento. Eso traslada el esfuerzo del equipo de vigilar el proceso a resolver expedientes.
¿Cómo usar el reconocimiento de imagen para peritar daños?
Aquí entra la capa de IA, pero en un papel sensato. El reconocimiento de imagen puede preperitar fotos de daños, señalar incoherencias y proponer una valoración, acelerando el trabajo del perito. Lo tratamos como una pista, no como un veredicto: el modelo sugiere y nosotros dejamos la decisión y la responsabilidad en una persona. Ese enfoque encaja bien con los reguladores y con el sentido común operativo.
Es una competencia que realmente tenemos en el Grupo RITS, donde trabajamos con modelos, datos y soluciones de LLM y visión por computador. No tenemos un despliegue de siniestros en producción que contar, pero sí personas que diseñan y entrenan esos modelos y saben conectar su salida al proceso como apoyo a la decisión, no como una caja negra.
¿Cómo coordinar la red de talleres y proveedores?
Un siniestro rara vez acaba en una transferencia. Lo más habitual es que exija coordinar talleres, peritos y proveedores, cada uno trabajando en su propio sistema. Unimos esa red mediante APIs y un portal para que el encargo, el estado y la liquidación circulen entre las partes sin correos ni llamadas.
Normalmente construimos dos cosas a la vez: integraciones con los sistemas de los partners que tienen API y un portal de proveedores para los que no, donde pueden aceptar un encargo, añadir una valoración y fotos y confirmar la finalización. Para el perito eso significa una única vista del estado de la reparación; para la dirección, datos comparables de tiempo y coste en toda la red.
¿Cómo mantener el control de pagos y recobros?
El último tramo, el seguimiento de pagos y recobros, decide si el proceso se cierra financieramente. Es donde las hojas de cálculo y el cuadre manual hacen más daño, porque el pago vive en el sistema de siniestros y el apunte en el de finanzas. Por eso construimos una conciliación que compara uno con otro y saca a la luz las discrepancias antes de que crezcan.
En esta capa automatizamos un registro de pagos ligado al expediente y al libro mayor, la gestión y el seguimiento de los recobros como una vía aparte con su propio SLA, y la conciliación con el sistema financiero con un informe de diferencias. El resultado es fácil de medir: menos correcciones manuales al cierre de mes y una imagen clara de cuánto recuperamos de verdad.
¿Qué competencias aportamos a un proyecto de siniestros?
No cubrimos puestos «por si acaso», sino contra un tramo concreto del proceso. Para un proyecto de siniestros solemos montar:
- un arquitecto de solución que ate proceso, datos e integraciones en una sola arquitectura,
- desarrolladores backend que construyan el motor de workflow, las reglas y las APIs,
- especialistas de integración que conecten el sistema de pólizas, finanzas y la red de proveedores,
- ingenieros de IA y datos (competencia del Grupo RITS) cuando entra en juego el reconocimiento de imagen o la analítica.
Esa mezcla permite que un equipo se haga dueño de todo el camino, y no de una sola pantalla, y haga crecer el sistema por etapas.
¿Cómo lo hacemos en RITS?
Trabajamos como partner nearshore desde Polonia que suma competencias justo donde le faltan al equipo de la aseguradora. Aunque no podamos enseñar un caso de éxito de siniestros, aportamos personas con experiencia en sistemas de proceso, integraciones y capa de datos y, a través del Grupo RITS, también competencias de IA, LLM y visión por computador. Verificamos las competencias antes de empezar y formamos el equipo en torno al proyecto, no en torno a quien esté libre.
Lo más habitual es hacerlo como software a medida construido por nuestro equipo y, cuando hay huecos que tapar rápido, como refuerzo de equipo. Las diferencias entre estos enfoques las tratamos en nuestro artículo sobre modelos de colaboración en TI.
¿Por dónde empezar a agilizar la gestión de siniestros?
Empieza por el tramo que más duele, normalmente el FNOL o la conciliación de pagos, y mide cuánto tarda hoy y dónde espera el expediente. Eso define el alcance de la primera fase, las integraciones que necesitas y los perfiles a cubrir. Es mejor cerrar un tramo de principio a fin que sustituirlo todo a la vez.
¿Vas a agilizar tu gestión de siniestros? Hablemos - ajustamos el equipo y la arquitectura a tu proceso de siniestros.