Hablar de experimentación, enfoque en el usuario y decisiones guiadas por datos es relativamente fácil. Lo que realmente genera impacto es la ejecución. A partir de esa premisa surge el concepto de User Case Day en Minders con Monkey: un día de trabajo dedicado exclusivamente a colaborar con el cliente, de manera presencial, para resolver un problema real y dejar una solución funcionando en producción.

La idea no es llegar con un plan cerrado o una presentación lista. Es llegar con una hipótesis, abrir la conversación y construir juntos, en tiempo real. El objetivo es claro: identificar un dolor concreto, usar Braze como habilitador y medir resultados desde el primer día. Así fue como pusimos en práctica el NPS en el navegador con Braze.

Un cliente listo para ir más allá

El punto de partida fue un cliente que ya había hecho su tarea. La base técnica estaba lista: SDK, web tracking y configuración inicial en Braze. Por eso, la conversación pudo enfocarse en algo más importante: cómo generar impacto real.

Sin embargo, durante el diagnóstico apareció un problema compartido por todos los equipos. El NPS no estaba funcionando como una herramienta útil.

El problema del NPS tradicional

Hasta ese momento, el NPS se enviaba por email de forma periódica. La tasa de respuesta era del 3%. Ese número alcanzaba para cumplir métricas internas, pero tenía tres problemas claros: poco volumen, feedback fuera de contexto y pocas opciones para segmentar o actuar. En la práctica, era un dato estático, no una fuente de aprendizaje.

La hipótesis: menos fricción, más contexto

La pregunta fue simple: ¿qué pasaría si el NPS apareciera directo en el navegador, justo cuando el usuario termina una acción clave? Sin emails, sin esperas.

La idea era clara: mostrar la encuesta en el momento justo podría subir las respuestas y mejorar su calidad. La propuesta se aceptó. Además, se decidió construirla en vivo durante el propio User Case Day.

El User Case Day: construir en vivo, junto con el cliente

El día fue una sesión presencial con todos los equipos en la misma sala. No había nada preparado de antemano. Todo se construyó paso a paso, con decisiones tomadas en conjunto. Así se evitaron idas y vueltas, se resolvieron dudas al momento y todos quedaron alineados.

El primer intento fue con componentes visuales listos para usar. Técnicamente funcionaba, pero el diseño no quedó bien. Por eso se cambió el enfoque: construir el NPS en HTML y conectarlo a Braze con un puente en JavaScript. Eso dio más control sobre el aspecto, el comportamiento y el momento en que aparece.

Además, esta solución no necesitó ayuda del equipo de desarrollo del cliente. No hubo que crear eventos nuevos ni tocar el código principal del producto. Todo quedó dentro de Braze, así que el equipo de CRM puede manejarlo solo.

Qué datos se capturan y para qué sirven

Desde el inicio, el NPS debía registrar dos cosas: la nota y el comentario del usuario. Cada respuesta generaba dos tipos de datos en Braze. Por un lado, un evento con la fecha de la última respuesta. Por otro, atributos fijos con la nota y el comentario. Gracias a eso, es posible crear segmentos más precisos y tomar acciones concretas a partir del feedback.

Alineación con el equipo técnico

Al principio, el equipo técnico tenía dudas. La razón era simple: la solución no necesitaba su participación. Se resolvió con una explicación clara del flujo y de cómo Braze permite este tipo de cambios sin afectar el producto. Por si acaso, se acordó revisar el HTML antes de publicar. Ese paso pequeño dio confianza y no agregó demoras.

Resultados: de 3% a más del 40% de respuestas

Los resultados fueron rápidos. La tasa de respuesta subió del 3% al 42%. El cambio no fue solo de canal, sino de momento. El NPS dejó de ser una encuesta suelta y pasó a aparecer justo después de una acción importante dentro del producto.

También ayudo el tipo de negocio del cliente. Monkey actúa como puente entre empresas, proveedores y bancos para hacer anticipos de pago. Por eso, el NPS aparece justo después de una operación financiera clave. En ese momento, el valor del servicio es más evidente para el usuario. Eso hace que sea más probable que responda y que su comentario sea más útil.

Segunda etapa: del dato a la acción

Con más respuestas, el NPS dejó de ser solo una métrica. Se convirtió en una señal de comportamiento. Los usuarios con notas altas se identifican como perfiles de alto valor, con potencial para usar más productos. Los usuarios con notas bajas son alertas tempranas de riesgo. Así, es posible actuar antes de perder a un cliente.

Experimentación continua

Lanzar el NPS no fue el fin del proceso. Al contrario: fue el inicio de un ciclo de pruebas. Con el flujo activo y generando datos, fue posible mejorar la tasa de respuesta de forma continua.

La primera prueba fue de posición: ¿dónde en la página funciona mejor el NPS? Se probaron tres opciones —arriba, al medio y abajo— con el A/B testing de Braze. El resultado fue claro: la versión al medio tuvo más respuestas. Por eso, esa variante quedó activa y las otras se desactivaron.

A partir de ahí, las pruebas se volvieron parte de la rutina. Cambios de texto, de diseño, de layout. Cada prueba parte de una hipótesis clara y los resultados guían la siguiente decisión. El objetivo ya no es solo mantener un buen nivel de respuestas. Es aprender qué funciona mejor y seguir mejorando.

Principales aprendizajes

Este caso dejó tres lecciones claras. Primero, trabajar juntos en la misma sala acelera los resultados. Segundo, la presencia física genera confianza. Tercero, la tecnología solo crea impacto cuando resuelve un problema real en el momento correcto.

En definitiva, este no fue un proyecto cerrado. Fue el inicio de una forma de trabajar: construir, medir y mejorar de manera constante.