Un sistema para cambiarlo todo
Persat tenía la tecnología para liderar la gestión de campo. Le faltaba diseño y una visión de producto para aprovecharla al máximo.
El punto de partida
Persat es un SaaS de gestión de campo: coordina vendedores, técnicos, logística de entregas e inspectores en calle, y usa un algoritmo de ruteo propio para optimizar sus recorridos. Cuando lo agarré, el producto tenía dos problemas al mismo tiempo, y ninguno se resolvía solo arreglando pantallas.
El primero era visual y estructural. Los seis módulos activos —clientes, rastreo satelital, mantenimiento preventivo, entregas, formularios digitales y órdenes de trabajo— se habían construido cada uno con su propia grilla, sus propios componentes y su propia lógica de interacción. No había design system, así que no había nada compartido entre pantallas: cada módulo era, en la práctica, un producto distinto adentro del mismo producto.
El segundo era de producto. No existía un criterio para decidir qué módulo priorizar para crecer, ni una forma de medir si los cambios que se lanzaban funcionaban. Se avanzaba por pedido o por intuición, sin datos que confirmaran o descartaran nada después del release.
Mi trabajo fue resolver las dos cosas a la vez: definir hacia dónde tenía que crecer el producto y cómo íbamos a medirlo, además de darle una base visual consistente. También rediseñé la web del producto, alineada al mismo sistema.
Empezar por la base: el design system
Antes de tocar cualquier módulo, decidí resolver primero la base: diseñé el design system desde cero, de forma autónoma, definiendo componentes, estados, espaciados y patrones de interacción documentados en Figma. Lo pensé escalable desde el día uno y con soporte nativo de modo claro y oscuro, porque sabía que la app iba a seguir creciendo y que cada módulo nuevo debía apoyarse en la misma base en vez de inventar la suya. Una vez definido, lo fui llevando al resto de la aplicación, módulo por módulo.
Decidir qué construir primero
El roadmap sumaba módulos nuevos todo el tiempo, y esa no era una decisión que me tocara solo ejecutar en pantallas: había que definir qué construir primero. Lideré un relevamiento completo de la app, entrevistas con usuarios y un benchmark de la competencia. Con esa información evalué qué módulos podían atraer usuarios nuevos, cuáles resolvían los dolores más urgentes de los que ya estaban, y qué ofrecía el mercado que Persat todavía no. Ese trabajo, con un enfoque de design thinking, es el que definió qué mejorar primero y qué construir después, en vez de avanzar módulo por módulo por intuición.
Home y módulos
Con seis módulos activos, el punto de entrada tenía que ordenar el acceso a todos sin que ninguno compitiera por atención. Rediseñé el home como el punto de partida del sistema aplicado a un caso real, resolviendo jerarquía, densidad de información y consistencia entre web y mobile.
Bandeja de entrada y tableros
Actualicé la bandeja de entrada de formularios, uno de los módulos más usados y que los clientes más iban a valorar, organizando todo tipo de formularios por carpetas para que dejaran de vivir en flujos separados y sin relación entre sí. A partir de un análisis de cómo los equipos gestionaban ese trabajo, detecté que no tenían una forma real de llevar el proceso: terminaban recurriendo a otras aplicaciones o a pizarras manuales para no perder el hilo. Para resolverlo, sumé una vista tipo kanban dentro de la misma bandeja, que le permite a cada cliente armar su propio flujo de trabajo y controlar el avance de cada formulario sin salir de Persat.
Persat IA
Persat ya contaba con un algoritmo propio de ruteo. Junto con el equipo, evalué qué otras capacidades de IA podíamos aprovechar y cómo llevarlas a más módulos de la aplicación, para que no se quedara solo en optimizar recorridos sino que ayudara a los clientes a ser más eficientes en otras áreas del negocio. De ahí surgió un chat conversacional dentro de Persat IA: además de tirar estadísticas de forma proactiva sobre el negocio, permite hacer preguntas puntuales sobre performance y sobre cualquier otra operación dentro de la plataforma.
Medir para seguir mejorando
Lanzar un cambio no era el final del trabajo. Implementé Amplitude para trackear ingresos a bandeja, formularios completados por día y distribución de cambios de estado, y así saber si cada mejora funcionaba en la realidad o solo en la teoría, antes de decidir el siguiente paso.
El resultado
Persat pasó de no tener design system a tener una base consistente que hoy sostiene seis módulos activos y sigue creciendo. Desde que implementamos el nuevo sistema, la experiencia de uso mejoró de forma notable: el NPS subió 2 puntos y la cantidad de usuarios activos creció de forma sostenida. Esa mejora en la experiencia se tradujo directamente en el negocio — las ventas aumentaron 15% después de las mejoras implementadas en los módulos, en gran parte porque los clientes que ya usaban Persat empezaron a usarlo más, y eso atrajo clientes nuevos.
Aprendizajes
Empezar por el design system en lugar de por el módulo más urgente fue la decisión más difícil de defender y la que más rindió: cada rediseño posterior costó una fracción del primero, porque ya había piezas y patrones sobre los que apoyarse.
El otro aprendizaje fue sobre el criterio para priorizar. Ordenar el roadmap con relevamiento, entrevistas y benchmark en vez de por pedido puntual cambió la conversación con el equipo: dejamos de discutir preferencias y empezamos a discutir evidencia.
Medir fue clave. Amplitude nos permitió monitorear cada cambio a medida que salía y corregir sobre la marcha, en vez de esperar al próximo release para enterarnos de un problema. Ver que los usuarios adoptaban los módulos nuevos más rápido y los usaban más fue la validación real de todo el trabajo, y lo confirmaron los números de experiencia: NPS, CSAT y CES mejoraron después del rediseño.