Como um User Case Day elevou o NPS da Monkey de 3% para 42%

Falar sobre experimentação, foco no usuário e decisões baseadas em dados é fácil. O que gera impacto de verdade é a execução. A partir dessa ideia surge o conceito de User Case Day na Minders com a Monkey: um dia de trabalho dedicado a colaborar com o cliente, pessoalmente, para resolver um problema real e deixar uma solução funcionando em produção.

A ideia não é chegar com um plano fechado. É chegar com uma hipótese, abrir a conversa e construir juntos, em tempo real. O objetivo é claro: identificar uma dor concreta, usar o Braze como ferramenta e medir resultados desde o primeiro dia.

Um cliente pronto para ir além da base técnica

O ponto de partida foi um cliente que já havia feito sua parte. A base técnica estava pronta: SDK, web tracking e configuração inicial no Braze. Por isso, a conversa pôde focar em algo mais importante: como gerar impacto real a partir dessa base.

No entanto, durante o diagnóstico surgiu um problema claro e compartilhado por todos os times: o NPS não funcionava como uma ferramenta útil.

O problema do NPS tradicional

Até então, o NPS era enviado por e-mail, de forma periódica, para a base de usuários. A taxa de resposta era de cerca de 3%. Esse número bastava para cumprir métricas internas, mas mostrava três problemas claros: volume baixo, feedback fora de contexto e poucas opções para segmentar ou agir. Na prática, era um dado fixo, não uma fonte de aprendizado.

A hipótese: menos fricção, mais contexto

A pergunta foi simples: o que aconteceria se o NPS aparecesse direto no navegador, no momento em que o usuário termina uma ação importante? Sem e-mails, sem espera.

A ideia era clara: mostrar a pesquisa no momento certo poderia aumentar as respostas e melhorar sua qualidade. A proposta foi aceita. Além disso, decidiu-se construí-la ao vivo, durante o próprio User Case Day, colocando o NPS direto no navegador com Braze.

O User Case Day: construir ao vivo, junto com o cliente

O dia foi uma sessão presencial com todos os times na mesma sala. Não havia nada preparado com antecedência. Tudo foi construído passo a passo, com decisões tomadas em conjunto. Assim, foi possível evitar idas e vindas, resolver dúvidas na hora e alinhar todo o grupo.

O primeiro caminho foi usar componentes visuais prontos. Funcionava do ponto de vista técnico, mas o resultado não atendia às expectativas de design. Por isso, mudou-se a abordagem: construir o NPS em HTML e conectá-lo ao Braze com uma ponte em JavaScript. Essa escolha deu mais controle sobre o visual, o comportamento e o momento de exibição.

Além disso, essa solução não precisou da ajuda do time de desenvolvimento do cliente. Não foi necessário criar novos eventos no produto nem mexer no código principal. Tudo ficou dentro do Braze, então o time de CRM pode operar e crescer a solução de forma independente.

Quais dados foram capturados e como foram organizados

Desde o início, ficou claro que o NPS precisava registrar duas coisas: a nota e o comentário do usuário. Ambos eram essenciais para avaliação interna e para ações futuras. Cada resposta gerava dois tipos de dados no Braze: um evento com a data da última resposta e atributos fixos com a nota e o comentário. Graças a isso, foi possível criar segmentos mais precisos e agir a partir do feedback real.

Alinhamento com o time técnico

No início, o time técnico tinha dúvidas. A razão era simples: a solução não precisava deles. O ponto foi resolvido com uma explicação clara do fluxo e de como o Braze permite esse tipo de mudança sem afetar o produto. Por precaução, ficou acordado revisar o HTML antes de publicar. Esse passo pequeno deu confiança ao time sem gerar atrasos.

Resultados: de 3% para mais de 40% de respostas

Os resultados foram rápidos. A taxa de resposta subiu de 3% para mais de 40%, ficando em torno de 42%. A mudança não foi só de canal: foi de momento. O NPS deixou de ser uma pesquisa solta e passou a aparecer logo após uma ação importante dentro do produto.

O modelo de negócio do cliente também foi decisivo. A Monkey atua como ponte entre grandes empresas, fornecedores e bancos para facilitar antecipações de pagamento. Por isso, o NPS aparece logo após uma operação financeira importante. Nesse momento, o valor do serviço é mais claro para o usuário. Isso aumenta tanto a chance de resposta quanto a qualidade do feedback.

Segunda etapa: do dado à ação

Com mais respostas, o NPS deixou de ser só uma métrica. Passou a funcionar como um sinal de comportamento. Usuários com notas altas são identificados como perfis de alto valor, com potencial para usar mais produtos. Já usuários com notas baixas viram alertas de risco. Assim, é possível agir antes de perder um cliente.

Experimentação contínua como prática

Lançar o NPS não foi o fim do processo. Pelo contrário: foi o início de um ciclo de testes com hipóteses claras, experimentos controlados e decisões baseadas em dados. Com o fluxo ativo e gerando volume, ficou possível melhorar a taxa de resposta de forma contínua.

O primeiro teste foi de posição: onde na página o NPS funciona melhor? Foram testadas três opções — topo, meio e final — com o A/B testing da Braze. O resultado foi claro: a versão no meio teve mais respostas. Por isso, essa variante ficou ativa e as outras foram desativadas.

A partir daí, os testes viraram rotina. Mudanças de texto, de design, de layout. O objetivo deixou de ser só manter um bom nível de respostas. Passou a ser aprender o que funciona melhor e seguir evoluindo com o tempo.

Principais aprendizados

Este caso mostrou três coisas. Primeiro, trabalhar juntos na mesma sala acelera os resultados. Segundo, a presença física gera confiança. Terceiro, a tecnologia só cria impacto quando resolve um problema real no momento certo.

Em resumo, este não foi um projeto encerrado. Foi o início de uma forma de trabalhar: construir, medir e melhorar de forma constante.

Vamos conversar?