Un tablero interno de salud de las cuentas y adopción de funciones que da servicio a tres equipos distintos, pero nadie había documentado cómo trabajaban en realidad, y la confianza en los datos se había perdido. Lideré la investigación que mapeó el proceso real, sacó a la luz los puntos de fricción y validó funcionalidades beta, produciendo una lista priorizada de recomendaciones para el equipo de producto.
Dentro de una de las plataformas CRM más grandes del mundo, un tablero interno de salud de cuenta y adopción de funcionalidad califica cada cuenta con tres parámetros (adopción de producto, expertise y salud técnica). Customer Success Managers, Ejecutivos de Cuenta y Managers de Renovaciones lo usan para monitorear la adopción, preparar conversaciones con clientes y apoyar las renovaciones, mientras una versión para clientes les ayuda a seguir su propia adopción y demostrar Retorno de Inversión.
La plataforma ayuda a tomar decisiones, pero nadie había documentado cómo trabajaban día a día los tres roles, y la confianza en las métricas se había deteriorado. Antes de mejorar algo, el equipo necesitaba una imagen clara del proceso actual, sus dolencias y dónde la información perdía credibilidad.
Las calificaciones muchas veces no reflejaban cómo estaba realmente desempeñándose una cuenta, y la falta de visibilidad sobre cómo funcionaba el modelo les dificultaba a los usuarios tener conversaciones informadas con sus clientes.
Los usuarios validaban los datos por su cuenta fuera de la plataforma antes de ver a un cliente, porque los números no siempre eran precisos.
Los Ejecutivos de Cuenta habían dejado de compartir los reportes autogenerados: los errores del sistema podían reflejarse en su propia competencia profesional.
Para ver la huella de productos individualmente y los términos del contrato, los usuarios cambiaban constantemente entre la plataforma, el CRM como sistema de registro, hojas de cálculo y documentos personales.
Las calificaciones en el tablero podían cambiar 20 puntos sin ninguna acción del cliente, dejando a los equipos sin poder explicar un "logro" o una "caída".
La mayor frustración es la severa desconfianza en la información. Verifico los datos manualmente fuera de la plataforma antes de cada junta con el cliente, porque un "0" podría ser solo un error de medición.
El equipo tenía documentación del producto, pero ninguna imagen de cómo trabajaban realmente los tres roles, y la confianza en los datos se había desgastado. Me fijé tres objetivos: entender el proceso actual y sus puntos de fricción, dar a la organización visibilidad del flujo de principio a fin, y validar las funciones beta para que el equipo que las construía pudiera iterar. Cada actividad respondía una pregunta distinta y alimentaba una lista priorizada de recomendaciones para el equipo de producto.
Empecé analizando un año completo de datos exportados de los canales de soporte para encontrar los problemas más frecuentes y de mayor impacto. Ese análisis fijó las prioridades y dio forma al script de las entrevistas, para que las sesiones 1:1 dieran seguimiento directo a los problemas que los usuarios ya reportaban.
Existía documentación de producto, pero no del proceso del día a día, los retos y las limitaciones de las personas que usaban la plataforma. Corrí 16 entrevistas 1:1 a profundidad (sesiones de 45 minutos) con los tres roles, y las convertí en personas de trabajo construidas sobre tareas reales, no sobre títulos de puesto.
No existía documentación del proceso completo. Mapeado en paralelo con las entrevistas y terminado una vez que concluyeron, un service blueprint de principio a fin trazó el ciclo de vida del cliente a través de los tres roles, sus acciones, herramientas y emociones, dándole a la organización una imagen compartida.
Una evaluación heurística pantalla por pantalla produjo 15 hallazgos, cada uno calificado en una escala de severidad de 0 a 4, mapeado a una heurística de usabilidad y acompañado de una recomendación concreta, ordenados por impacto.
En paralelo, se construían nuevas funciones beta para un evento mayor del cliente. En colaboración con el equipo externo de UX/UI que las diseñaba, construí los prototipos y el script de prueba, recluté usuarios internos y externos, y corrí sesiones remotas no moderadas en una plataforma externa de pruebas de usabilidad con 19 participantes (8 internos, 11 externos). El reporte cualitativo y cuantitativo y sus recomendaciones se presentaron en varias sesiones.
El blueprint trazó el ciclo de vida completo de la cuenta, mostrando en cada paso a qué herramienta recurría cada rol, qué sentía, y en dónde la plataforma le devolvía el trabajo en silencio.
Chequeos de salud rutinarios y seguimiento manual para cubrir brechas de visibilidad, más la búsqueda de métricas de venta adicional en los datos de utilización.
Preparar reviews de cara al cliente, reconciliar datos de adopción contra licencias contratadas y reescribir a mano las presentaciones generadas por IA.
Modelar incrementos de precio en hojas de cálculo, cazar licencias sin uso para proteger la negociación y abrir la conversación de renovación 90 días antes.
El blueprint se convirtió en el artefacto que todos señalaban: producto, ingeniería y dirección por fin mirando el mismo mapa en vez de mirarse entre sí.
La auditoría experta produjo 15 hallazgos en una escala de severidad de 0 a 4, y el análisis de la investigación usó la misma escala. Cada problema de abajo, ya sea de la auditoría o de las entrevistas, llevaba una severidad, una heurística, una recomendación y un impacto declarado, para que priorizar siguiera siendo una conversación sobre evidencia, no sobre opiniones.
Antes de un lanzamiento mayor del cliente, validé el rediseño beta con sesiones remotas no moderadas, con usuarios internos y externos. La recepción general fue positiva: la gente entendió las secciones principales y recibió bien las métricas más actuales y accionables. Las pruebas se enfocaron en tres funciones nuevas.
Probamos dónde colocar el control que lanza una acción asistida por IA en la tabla. La prueba lo resolvió y expuso una brecha de expectativas: la gente esperaba ayuda estática y de autoservicio, así que enrutamos la IA por un único punto de entrada, claramente etiquetado, en vez de repetirlo por fila.
Una sección nueva completa que recomienda funciones por activar, ligadas a los objetivos de negocio que apoya cada una. Fácil de encontrar y valorada por mostrar los objetivos que una función impactaría, con notas claras sobre títulos, terminología y controles por pulir.
Un banner de alerta prominente con una pestaña dedicada de alertas. La función mejor recibida de la ronda, fácil de detectar y de accionar sin perder contexto, con espacio para extenderla a alertas de consumo.
En general, el nuevo diseño gustó. El reporte separó lo que podía salir como base de la fricción que aún vale la pena pulir, para que el equipo que construye las funciones siguiera iterando con evidencia, no con opiniones.
A medida que las empresas crecen, el producto y la experiencia a su alrededor no pueden quedarse quietos: tienen que seguir iterando junto con la organización. Lo que este proyecto me confirmó es que entender lo que los tres roles realmente necesitaban, en vez de asumirlo, fue lo que evitó las soluciones alternas y la desconfianza que se habían acumulado alrededor de la herramienta. Una investigación de esta escala es una inversión pequeña frente a lo que protege: un producto en el que la gente confía lo suficiente para usarlo como se pensó, y el ROI que el producto existe para demostrar en primer lugar.