CONTPAQi® – Internal Licensing CRM · 2025
Plataforma interna operativa para gestión masiva de licencias.
Contexto
Plataforma interna de gestión utilizada por áreas operativas (Activaciones, Soporte, Ventas, Marketing etc.) para la consulta, edición y administración de licencias.
Mi rol
Product Designer (Lead Scope). Estrategia end-to-end centrada en Gobernanza, Arquitectura y validación con datos (PostHog).
Impacto
Autonomía operativa: +30%. Búsquedas exitosas: 62% → 88%. Reducción del Time-to-Task en flujos críticos: de 1:40 min a 35s.
🎯 Problema & Objetivos
El sistema legacy obligaba a los usuarios a consultar hasta 4 sistemas externos para validar una sola licencia. La búsqueda era frágil (zero-results por errores de dedo) y la falta de permisos adecuados generaba un cuello de botella masivo en el equipo de Soporte Técnico Interno.
- Centralizar la verdad: Consolidar toda la data de la licencia en una sola vista "360°".
- Democratizar la operación: Redefinir la matriz de roles para dar autonomía a equipos internos.
- Búsqueda Inteligente: Implementar patrones predictivos tolerantes a errores humanos.
🏢 Contexto & Constraints
- Tipo de producto: Plataforma interna de Operaciones (Internal CRM / Licensing).
- Usuarios Primarios (Internal Staff): Agentes de Activaciones, Soporte Técnico y Gestión Comercial.
- Beneficiarios Finales: Red de distribuidores y despachos contables (reducción de tiempos de espera).
- Limitantes técnicas: Ecosistema legacy fragmentado, deuda técnica en backend y múltiples fuentes de datos no integradas.
- Limitantes de negocio: Procesos operativos manuales arraigados y alta resistencia al cambio en equipos internos.
- Equipo: Liderazgo de Diseño + PM, 3 Backend Devs, 2 Frontend Devs.
👤 Mi rol & equipo
Mis responsabilidades
- Discovery: Investigación cualitativa con equipos operativos clave.
- Gobernanza: Matriz de roles para descentralizar la operación.
- Arquitectura: Optimización de búsqueda y navegación compleja.
- Design Systems: Evolución de componentes para escalabilidad.
- Telemetría: Plan de tracking de KPIs en PostHog.
- Stakeholders: Alineación entre Negocio, Tech y Ops.
Colaboración
- Product Trio: Definición de roadmap junto a PO y Tech Lead.
- Ingeniería: Colaboración técnica con 5 devs (Back/Front) y QA.
- Dirección: Alineación estratégica con Innovación.
- Operaciones: Co-creación con líderes de Soporte y Activaciones.
🔄 Proceso & Estrategia
Discovery
- Entrevistas contextuales con equipos operativos clave (Soporte, Ventas, Activaciones).
- Auditoría de Deuda de UX en el sistema legacy.
- Análisis de patrones en tickets de soporte (detectando dependencias y cuellos de botella).
- Mapeo del ecosistema técnico (conexiones con Salesforce, Excel, Mi Gestión, Market Place).
Definition
- Matriz de Gobernanza: Definición granular de roles y permisos por área.
- Priorización estratégica (MoSCoW) alineada con Product Trio.
- Definición de flujos de autonomía (qué puede resolver el usuario sin escalar).
- Hipótesis de mejora operativa basadas en datos.
Design
- Arquitectura de Información orientada a tareas masivas y búsqueda.
- Wireframing acelerado con IA (Figma Make).
- Implementación de Design System corporativo para consistencia y velocidad.
- Prototipado de alta fidelidad para validación técnica y usuario final.
Validation & Data
- Pruebas de usabilidad con escenarios reales de resolución de tickets.
- Estrategia de Telemetría: Plan de tracking en PostHog conectado a KPIs operativos.
- Validación de factibilidad técnica con Ingeniería (Hand-off con contexto).
- Iteración basada en métricas de Time-to-Task y tasas de error.
🖼️ Visuales del proceso
Capturas representativas del proceso de diseño y entregables clave.
💡 Decisiones clave de producto
Búsqueda Predictiva "Fuzzy Search"
Por qué: El 40% de las consultas fallaban por errores de dedo o falta de datos exactos (zero-results). Reemplazamos la búsqueda exacta por patrones flexibles y autocompletado.
Impacto: Búsquedas exitosas pasaron de 62% a 88%.
Dashboard Operativo "Role-Based"
Por qué: Soporte y Ventas necesitan datos opuestos. Un dashboard genérico generaba ruido cognitivo. Diseñamos vistas personalizadas basadas en la matriz de gobernanza.
Impacto: Reducción de 1:40m a 0:35s al anticipar tareas críticas (widgets) y eliminar navegación profunda.
Descentralización vía Gobernanza
Por qué: El 30% de los tickets eran tareas repetitivas bloqueadas por falta de permisos. Implementamos una matriz de roles que empodera a los agentes para resolver sin escalar.
Impacto: Aumento del 30% en autonomía operativa (casos resueltos sin Soporte).
Telemetría como Requisito de Diseño
Por qué: "Lo que no se mide, no se mejora". Definí el plan de tracking en PostHog desde la fase de wireframes para medir comportamiento real, no opiniones.
Impacto: Capacidad de iterar basada en tasa de error y tiempos de tarea, no en intuición.
📊 Resultados & Métricas
62% → 88%
Búsquedas exitosas
1:40 → 0:35
Time-to-task promedio
+30%
Incremento en autonomía operativa
-50%
Tasa de Error. Reducción de fallos críticos en el flujo de activación.
100%
Cobertura telemetría flujos clave
📚 Aprendizajes y próximos pasos
Lo que aprendí
Aprendí que en herramientas internas, mi competencia no es otro software, sino Excel y los procesos manuales. Si el sistema no es más rápido que el "workaround" actual en hoja de cálculo, los usuarios no lo adoptarán. Integrar Figma Make para generar wireframes preliminares redujo el tiempo de maquetado, permitiéndonos iterar más rápido con los stakeholders.
Lo que haría diferente
Invertiría más tiempo inicial definiendo la Matriz de Permisos con el equipo técnico antes de trazar la arquitectura de información. Definir quién puede ver qué es la base de la navegación; hacerlo después nos obligó a reestructurar flujos enteros, no solo pantallas.
Próximos pasos
El análisis de sesiones en PostHog evidenció patrones de alta repetición manual (ej. 15 bloqueos sucesivos en minutos). El siguiente release priorizará Acciones Masivas para eliminar esa fricción repetitiva en usuarios avanzados.