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 no era la interfaz. Era entender la dimensión verdadera del problema y decidir qué no construir todavía.

Dibujo: una persona de traje, parada sobre planillas y una calculadora, mira un edificio cuyos pisos están numerados del 1 al 5.

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.

No era un producto: era un parche.


Cuando me metí a fondo con el PO a analizar el scope real del proyecto, lo primero que quedó claro es que no se trataba de mejorar pantallas: se trataba de 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 no se perdió: 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. No es la solución final. Es la solución correcta para este momento.

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 no es el producto en sí, sino el proceso de entender dónde estaba realmente el problema. 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 caro de este caso fue no diseñarla el primer día: si la hacía, resolvía el síntoma y el problema real quedaba intacto, esperando 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 apareció que eran tres, con incentivos distintos y a veces opuestos. Tuve que volver atrás y rehacer el mapeo completo. La lección no fue "investigá más": fue que cuando un pedido viene de un solo rol, casi nunca hay un solo rol.
Esta es la decisión de la que más orgulloso estoy y la que menos se ve. Elegir un puente pragmático en vez de bloquear todo el desarrollo en el problema más difícil no aparece en ninguna captura. Es la diferencia entre una v2 en piloto en cuatro meses y una v1 perfecta que nunca sale.
corrección La v1 salió trunca y la defendí igual. Ahí aprendí a distinguir entre acotar el scope y entregar la mitad de algo: la diferencia es si lo que entregás se sostiene solo. La v1 no se sostenía; la v2 sí, con menos features.
← Singular About →