Palabras Clave: Fricción Operativa, Alfabetización Financiera, KPIs de Journey, Estandarización de Procesos.

En mi experiencia, casi todos los bancos y retailers financieros ya “hicieron su propia app” y “digitalizaron sus canales”. Sin embargo, cuando uno mira con detenimiento el NPS, la adopción y el uso real de ciertas funcionalidades, el resultado es menos de lo esperado por los stakeholders. Hay quienes pueden pensar que el problema es falta de presupuesto o de proyectos, sin embargo, la realidad evidencia otro problema, el foco: se diseñan productos para cumplir requisitos internos, no para resolver los momentos en que el cliente realmente sufre.

Voy a resumir en cinco principios lo que he visto que funciona cuando se quiere que un producto digital efectivamente mueva el NPS.

1. Partir desde los momentos de verdad, no desde el backlog

En todos los bancos y retailers con los que he trabajado se repiten los mismos “momentos de verdad”: alta de cuenta o tarjeta, problemas con cargos, bloqueos y desbloqueos, dificultades de pago, renegociaciones, cobros sorpresivos.  Todos tienen puntos de fricción que pueden cambiar radicalmente la percepción de un cliente, por lo que en lugar de partir de un backlog interminable, que pasa si partimos de una pregunta simple: 

“¿En qué 3–4 momentos, si los hiciéramos radicalmente mejores, el cliente cambiaría su opinión sobre nosotros?”

Cuando el backlog se organiza alrededor de esos momentos concretos, el impacto en NPS es visible. Cuando se organiza alrededor de “lo que pidió cada área”, el resultado es una app llena de secciones que casi nadie usa.

2. Medir donde de verdad duele: no basta con saber el NPS

Todos repetimos que “lo que no se mide no se puede mejorar”, pero casi nadie baja eso a nivel de journey. El NPS es un buen termómetro, pero es demasiado grueso para guiar decisiones de producto. 

En los proyectos que hemos tenido mejores resultados, fue por la definición de métricas muy concretas asociadas a flujos clave, por ejemplo:

- porcentaje de clientes que completa el alta digital sin abandonar

- tiempo total para resolver un reclamo típico 

- cuántos inician un proceso en la app y terminan llamando al call center 

- en cuántos pasos se puede completar una acción frecuente (pagar, bloquear, renegociar)

Es importante considerar el stack correcto para realizar la medición para no perder ningún insight. Si medimos a ese nivel, las discusiones cambian: dejamos de hablar en abstracto de “mejorar la experiencia” y empezamos a decidir sobre qué optimizar y qué dejar de hacer.

3. Diseñar para el cliente real, no para el usuario ideal del diagrama

En los comités se habla del “usuario” como si fuera alguien informado, con buena conexión y tiempo. En la práctica, una parte relevante de la base tiene baja alfabetización financiera y digital, usa teléfonos de gama media o baja y se conecta con planes prepago. 

Por eso, insisto en tres reglas que suelen parecer obvias, pero pocas veces se cumplen:

- lenguaje radicalmente simple y directo 

- pedir la menor cantidad posible de datos en cada interacción 

- tolerancia al error: permitir volver atrás sin perder todo, guardar estado, reintentar ante fallas de red

El criterio que uso es simple: si una persona promedio no puede completar el flujo sin ayuda, el problema no es el cliente, es el diseño.

4. Hacer de la voz del cliente un hábito, no un hito del proyecto

He visto muchos proyectos con una gran investigación inicial que después se convierte en un PDF o una PPT muerta. En la práctica, lo que funciona es incorporar la voz del cliente como rutina ligera y continua:

- entrevistas breves ligadas a un flujo específico 

- testeos de usabilidad rápidos antes de liberar cambios relevantes

- mecanismos de feedback dentro de la app ligados a acciones concretas (“¿fue fácil hacer esto?”)

No se trata de montar un laboratorio permanente, sino de asegurar que el producto tenga un proceso básico de observar–ajustar–volver a observar.

5. Tener un responsable de proteger la experiencia (aunque sea impopular)

Si nadie tiene el mandato explícito de proteger la experiencia del cliente, la fragmentación interna termina ganando. Cada área agrega campos, disclaimers, pasos y políticas “por si acaso”, hasta que el flujo se vuelve inusable. 

En los proyectos que han salido mejor, existe una figura (CPO, dueño de journey, comité reducido) con la autoridad de decidir: “esto agrega fricción al cliente, no va”, aun cuando sea incómodo para algunas áreas. Esa instancia decide con datos de uso, riesgo y NPS esperado, no solo por jerarquía.

Cuando se alinean los cinco elementos anteriores, el producto deja de ser un contenedor de funcionalidades y se convierte en un verdadero motor de satisfacción y lealtad. Y eso sí se ve en el NPS.