Optimización del proceso "Dar un parte" en app
Declarar un siniestro es uno de los momentos más críticos en la relación de un usuario con su aseguradora. Es un proceso que se activa en situaciones de estrés, y cualquier fricción tiene un coste alto. Analicé el funnel completo, identifiqué los puntos de abandono y trabajé con producto y desarrollo para priorizar los cambios con mayor impacto en finalización y experiencia.
Contexto
Proceso crítico: el usuario lo activa en un momento de estrés, sin margen para la fricción.
Enfoque
Análisis de funnel paso a paso + identificación de causas + priorización con producto y desarrollo.
Dato
Abandono superior al 80% en la elección del tipo de siniestro.
Por acuerdos de confidencialidad, no comparto capturas de pantalla ni datos internos. Lo que sigue es una descripción fiel del proceso de trabajo y las decisiones tomadas.
El reto
El proceso de declaración de siniestros en la app de MAPFRE tenía varios pasos: tipo de siniestro, datos del vehículo, descripción del incidente, adjuntar documentación y confirmación. El abandono en el primer paso, la elección del tipo de siniestro, superaba el 80%. Los datos mostraban el dónde, pero no el porqué.
Entender qué fallaba en ese punto y por qué era el punto de partida para proponer mejoras con criterio.
Proceso
Qué hice
- Analicé el comportamiento de los usuarios en cada paso del proceso para identificar en qué punto del flujo se producía el mayor abandono y qué patrones se repetían.
- Diagnostiqué las causas de fricción: pasos con demasiada carga de información, campos del formulario que generaban confusión, y puntos donde los usuarios perdían la referencia de en qué parte del proceso estaban.
- Traduje los hallazgos del análisis en propuestas de mejora, las prioricé junto al equipo de producto y desarrollo, y propuse los cambios con mayor impacto en finalización y experiencia.
- Hice seguimiento de los cambios para verificar que los indicadores de finalización y satisfacción mejoraban.
Impacto
Diagnostiqué que el abandono del 80%+ en la elección del tipo de siniestro venía de una arquitectura de la información confusa en el primer paso del flujo, y propuse los cambios para resolverlo. Salí del proyecto antes de la implementación, así que no tengo el dato final — pero sí la causa y la solución definida.
Aprendizaje
Quien declara un siniestro acaba de tener un accidente o está en un momento de mucha tensión. Si la app le obliga a pensar, ya está fallando antes de empezar. Este proyecto me hizo más precisa para distinguir qué fricción se puede mejorar después y qué hay que resolver antes de lanzar.