modo raíz · lo rojo son medidas, lo verde es criterio · tecla R
03 · UX complejo · Fintech · Estrategia de producto

Mis Resultados: del parche al producto

Un módulo para gestionar performance comercial en bancos. El reto real estaba antes de la interfaz: entender la dimensión verdadera del problema y decidir qué no construir todavía.

Los bancos tienen equipos comerciales grandes, con metas, rankings e incentivos que cambian todos los meses. Gestionar todo eso es un caos: planillas de Excel, configuraciones manuales, información dispersa. Nadie tiene una visión clara de su propio desempeño en tiempo real.

La primera versión de esta plataforma existía, pero estaba diseñada para resolver los problemas puntuales de un banco específico. Sin módulo administrador, la configuración de objetivos y metas debía hacerse a mano cada mes, con un costo enorme que asumía internamente el equipo de soporte.

Lo que había en producción era un parche.

Cuando me metí a fondo con el PO a analizar el scope real del proyecto, lo primero que quedó claro fue la escala: había que construir una plataforma que pudiera implementarse en cualquier banco, con reglas de negocio distintas, estructuras organizacionales distintas y modelos de incentivos distintos.

El análisis nos llevó a definir tres perfiles de usuario con necesidades completamente diferentes: el Vendedor, que quiere saber cómo va respecto a sus objetivos; el Supervisor, que necesita ver el desempeño de su equipo; y el Administrador, que configura las reglas del sistema.

Feature map del Vendedor: un árbol de tres ramas que entra entero en una pantalla. Vendedor
Feature map del Administrador: un árbol del mismo tipo con decenas de nodos que se extienden a lo ancho y en cuatro niveles. Administrador
Los dos feature maps al mismo tamaño. El contraste habla solo: uno es acotado y directo; el otro es el corazón del problema.

El módulo administrador resultó ser ese corazón. Sin él, el sistema no puede escalar: alguien siempre tiene que configurar algo a mano. Pero diseñarlo correctamente era enormemente complejo, y acá está la diferencia con cualquier sistema de incentivos tradicional.

Un sistema de loyalty para una tienda de ropa es relativamente directo: vendiste X, cumpliste la meta. En banca las reglas son otra cosa. Si el objetivo de un ejecutivo es vender 15 tarjetas en el mes y vendió 15, pero 3 clientes cancelaron, su resultado real es 12. Y ese es el caso más simple. Si además 3 de esas tarjetas las vendió un ejecutivo de call center a clientes que figuran en su cartera, la cuenta puede ser media tarjeta, una entera o ninguna, según la regla del banco.

Cada banco tiene su propia versión de esa lógica. Cubrir todos los casos sin que la interfaz del administrador se volviera inmanejable era el desafío real del producto.

Pantalla de administración: a la izquierda, una biblioteca de seis ítems y cuatro grupos de productos plegados; a la derecha, tres columnas —solo la primera con contenido— donde cada ficha lleva su umbral y su peso.
El sidebar de configuración de un solo objetivo: tramos, candados, aceleradores, tarifarios y modelos de incentivos cruzados. Cada nodo es una pantalla, y todo tiene que convivir sin que el usuario se pierda.

Se vendió el proyecto para implementarlo en un banco grande de Perú. El scope era ambicioso, el tiempo ajustado, y las partes no encontraron la flexibilidad necesaria para avanzar. El proyecto quedó trunco.

Tablero de wireframes: decenas de pantallas en gris conectadas con flechas y agrupadas por flujo.
Los wireframes de la v1: la arquitectura de información antes de las pantallas. Ese trabajo terminó sirviendo igual: es lo que permitió acotar bien la versión siguiente.

Cuando arrancó la v2, la pregunta fue cómo avanzar sin repetir el mismo error.

Empezar por donde hay más valor inmediato y menos riesgo de complejidad infinita.

Se priorizó Mis Resultados, el visualizador de performance para vendedores y supervisores, el módulo que más impacto tiene en el día a día del usuario comercial. Y para el administrador, en esta primera instancia, se optó por templates de Excel que mapean la configuración directamente al sistema: un puente pragmático que permite operar sin bloquear todo el desarrollo en el problema más difícil.

Configurador: pestañas de Objetivos y Períodos, y una tabla con fecha de creación, nombre, identificador, categoría, unidad de medida y un interruptor por fila.
El configurador MVP: Excel como interfaz de administración. Es la solución correcta para esta etapa.

3 países de implementación
3 perfiles de usuario
4 meses de v2 a piloto
v3 iteraciones del producto

Una plataforma que permite a los equipos comerciales de un banco ver su performance en tiempo real —objetivos, resultados, rankings, estado de incentivos— sin depender de reportes manuales ni de alguien que actualice una planilla.

Pantalla del Vendedor: su foto, ranking y cumplimiento total a la izquierda; al centro, una columna por objetivo con la meta arriba y el avance marcado en verde, azul o rojo.
La pantalla principal del Vendedor: objetivos del mes, progreso en tiempo real y estado de incentivos, sin pedirle nada a nadie.
Vista de ranking: cuatro indicadores arriba —cumplimiento propio, posición, promedio y diferencia con el primero— y debajo la lista de posiciones con foto, porcentaje y variación. Ranking del equipo
Vista del Supervisor: la distribución del equipo en diez deciles y, debajo, la ficha de cada persona a cargo con su cumplimiento. Vista del Supervisor
Los tres perfiles cubiertos con el mismo sistema: cada uno ve la dimensión del desempeño que le toca resolver.

Lo más valioso de este caso fue el proceso de entender dónde estaba realmente el problema, más que el producto en sí. La v0 resolvía síntomas. La v1 encontró la dimensión real del desafío. La v2 tomó la decisión más difícil: acotar el scope con criterio, sin perder de vista hacia dónde tiene que ir el sistema.

Hoy está en producción en Panamá, en implementación en Chile, y próximamente en Brasil.

El pedido entró como una pantalla: «necesitamos una vista de resultados». Lo más difícil del caso fue no sentarme a dibujarla el primer día. Si la hacía, resolvía el síntoma y el problema de fondo quedaba intacto, esperando para volver a aparecer en el ticket siguiente.
corrección Subestimé el tamaño del problema y perdí tiempo por eso. Arranqué mapeando un rol y a mitad de camino me di cuenta de que eran tres, con incentivos distintos y en algunos casos opuestos. Tuve que volver atrás y rehacer el mapeo entero. Ahora, cuando un pedido llega de un solo rol, lo primero que pregunto es quién más lo va a usar.
De todo el caso, esta es la decisión que más me gusta y la que menos se ve. Haber elegido un puente pragmático, en vez de frenar el desarrollo entero contra el problema más difícil, no aparece en ninguna captura. Pero es lo que hizo que hubiera una v2 en piloto a los cuatro meses.
corrección La v1 salió trunca y la defendí igual. Me llevó un tiempo entender la diferencia entre acotar el alcance y entregar la mitad de algo: lo que acotás bien se sostiene solo, lo otro necesita que expliques por qué está incompleto. La v1 no se sostenía. La v2 sí, y tiene menos cosas.
← Singular About →