Visualizador de Estado de Solicitud
Estrategia de comunicación proactiva multi-canal (App + WhatsApp Business + Push) que informa al cliente en tiempo real sobre el estado de su solicitud de crédito, eliminando la 'caja negra' entre solicitud y desembolso.
- Empresa
- Aviva Crédito
- Mi rol
- Product Designer
- Periodo
- feb 2026
- WISMO rate: −50% en contactos de estatus (baseline: 54% con 5+ diarios)
- Eficiencia operativa: <15 min/agente/día (baseline: ~31 min) −52%
Resultados
Reducción de ~31 a <15 minutos/agente/día en atención reactiva de estatus (~2.4 hrs/agente/día liberadas para ventas y cobranza). Eliminación de la necesidad de contacto reactivo: el cliente conoce su estado antes de preguntar. Alcance del cliente en su canal preferido (WhatsApp, Push, App) en lugar de esperar a que abra la app.
Métricas clave
- WISMO rate: −50% en contactos de estatus (baseline: 54% con 5+ diarios)
- Eficiencia operativa: <15 min/agente/día (baseline: ~31 min) −52%
- Time-to-sign: −15% desde aprobación hasta firma de contrato
- Resolución de docs sin escalada: >60% re-suben sin contactar promotor (baseline: ~0%)
- Rate límite WA: máx. 2 mensajes/día/cliente
- Latencia endpoint estado: <200ms
Problema
Los clientes de Aviva experimentaban una 'Caja Negra' entre la solicitud de crédito y el desembolso. Encuesta a 102 promotores/managers (Abril–Mayo 2026): 54% recibía 5+ contactos diarios exclusivamente para preguntar '¿cómo va mi solicitud?'; 85% reportó fricción en 'documentos en revisión'; 83% en 'espera de contrato'; ~31 minutos/agente/día perdidos en consultas de estatus; 98% no tenía la información que el cliente pedía. El 75% dedicaba 3+ minutos por cliente explicando el estatus. Frases verbatim más repetidas: '¿cuándo me mandan el contrato?', '¿cuándo me depositan?', '¿ya llevo X días sin respuesta?'. Sentimiento dominante: incertidumbre de tiempo, no solo de estatus.
Research
Encuesta Ola 2 a promotores/managers, n=102 (Abr–May 2026): 54% recibe 5+ contactos diarios solo por estatus; 8% dedica casi toda su jornada (20+ contactos/día); 63% estima >50% de sus dudas son sobre estatus/documentos; 75% dedica 3+ min/cliente en estatus; 24% pierde >40% de su jornada; ~31 min/agente/día estimado; 98% no tiene el dato que el cliente pide (más solicitado sin respuesta: fecha estimada del contrato, 56%). Tres patrones de confusión ante rechazo: dónde subir el doc, qué foto falló, motivo técnico del rechazo.
Solución
Estrategia de comunicación proactiva multi-canal: (1) Componente visual in-app — tracker de pasos con línea de tiempo (Kiosco → Documentos → Contrato → Desembolso), botones de acción contextuales y pantalla de detalle; (2) WhatsApp Business — mensajes transaccionales en cada cambio de estado con deep link directo; (3) Push Notifications — triggers en cambios críticos. Un único endpoint de backend alimenta los tres canales. Casos: happy path no-digital (cliente recibe WAs sin abrir app), acción requerida (doc rechazado, deep link directo para re-subir), cliente ansioso (ve estado en app sin contactar soporte).
Aprendizajes
1. El cliente no solo quiere saber su estatus — quiere saber cuándo: el verbatim más repetido en la encuesta fue sobre tiempos estimados, no sobre pasos del proceso. Diseñar para incertidumbre de tiempo es tan importante como diseñar para incertidumbre de estatus.
2. Un único endpoint de backend para tres canales (app, WhatsApp, Push) es una decisión de arquitectura que habilita el diseño omnicanal: sin esa decisión técnica, los tres canales hubieran sido tres proyectos separados y el cliente podría recibir información inconsistente.
3. El 98% de los promotores sin la información que el cliente pide es un dato de producto, no de operaciones: el problema no era que el equipo no quisiera ayudar, sino que el sistema no les daba el dato. La solución no era capacitar al equipo, era dar visibilidad al cliente directamente.
- El canal primario debe ser donde está el cliente, no donde queremos que esté: El componente in-app fue el primero que se diseñó, pero los datos mostraron que el cliente no-nativo digital no abre la app de forma proactiva. WhatsApp — donde el cliente ya está — se convirtió en el canal primario del sistema.
- Un endpoint, triple alcance: La decisión arquitectónica de construir un único endpoint que alimenta los tres canales simultáneamente fue la mayor palanca del proyecto. Permitió justificar el esfuerzo de backend con impacto triplicado.
- Los templates de WA son constraints de diseño: Los mensajes de WhatsApp Business deben ser aprobados por Meta como templates estructurados. Esto limita la creatividad del copy pero garantiza la entrega. Diseñar dentro de los constraints de Meta es parte del trabajo de producto.
- El frontend al 95% no es el 95% del proyecto: El componente in-app llevaba semanas 'casi listo' esperando el endpoint de backend. El 5% restante es el backend, y es lo que activa todo. Los proyectos no se completan en paralelo — se completan cuando el cuello de botella se resuelve.
Próximos pasos
1. Medir reducción en contactos reactivos de estatus post-lanzamiento — la métrica clave es pasar de ~31 a <15 minutos/agente/día en atención de estatus.
2. Expandir el tracker de pasos al flujo de renovación — los clientes recurrentes pasan por un proceso similar y actualmente tienen la misma 'caja negra'.
3. Validar la fecha estimada de contrato como dato mostrable en la app: fue la información más solicitada sin respuesta (56% de promotores), y aún depende de que el área legal confirme si es publicable.