It’s easy to talk about experimentation, user focus, and data-driven decisions. The real impact comes from execution. That’s the idea behind a User Case Day at Minders with Monkey: a full day of in-person work with the client to solve a real problem and ship something live in production.
We don’t show up with a finished plan or a polished deck. We show up with a hypothesis, open the conversation, and build together in real time. The goal is simple: identify a concrete pain point, use Braze as the enabler, and measure results from day one. That’s exactly how we launched in-browser NPS with Braze.
Context: a client ready to go beyond the technical implementation
We started with a client who had already done the technical groundwork.
They had the basics in place—SDK, web tracking, and initial Braze setup. That meant we could skip the “how do we integrate?” conversation and focus on “how do we drive impact with what’s already integrated?”
During the initial diagnosis, everyone aligned on the same issue: NPS existed, but it didn’t help the business make decisions.
The problem with traditional NPS
The team sent NPS surveys by email on a recurring basis. The response rate sat around 3%. While that checked an internal box, it came with clear downsides.
Responses were scarce, feedback arrived out of context, and follow-up actions were hard to scale. In practice, NPS acted like a static metric instead of a continuous source of learning.
The hypothesis: less friction, more context
We asked a simple question: what if NPS stopped going out by email and showed up inside the product—right in the browser—at the moment the user completes a meaningful action?
Our hypothesis was straightforward: better timing plus a frictionless experience would increase responses and improve feedback quality. So we implemented in-browser NPS with Braze during the User Case Day itself, directly inside the user journey (in-browser/in-product).
Building live with the client
We ran the day as a working session with every team in the same room. We didn’t rely on prebuilt flows. Instead, we made decisions together and built the solution step by step.
That setup cut down on back-and-forth, cleared blockers fast, and kept everyone focused on a single outcome.
Implementation: from design to the right technical choice
We first tried quick-build visual components. They worked, but the experience didn’t match the bar for design and usability. Rather than compromise, we switched approaches.
Next, we built the NPS UI in HTML and connected it to Braze through a JavaScript bridge. This gave us the flexibility we needed and let us ship in-browser NPS with Braze with precise control over layout, behavior, and triggering.
Just as important, the client’s frontend team didn’t need to develop anything new. We didn’t add product events or change the application core. We handled the whole flow inside Braze, and the CRM team could run and scale it independently.
What we captured in Braze
From day one, we focused on two essentials: the score and the qualitative comment.
Each browser response created:
-
an event that marked when the user last answered NPS, and
-
persistent attributes for score and comment, which made segmentation far more powerful.
With that structure, the team could go beyond reporting and start activating real journeys based on feedback—one of the biggest wins of in-browser NPS with Braze.
Results: from 3% to 42%
Once we launched the new in-browser NPS, the impact was immediate. Response rate jumped from ~3% to 40%+ and stabilized around 42%.
The channel change helped, but timing did the heavy lifting. NPS stopped feeling like a disconnected survey and became part of the product experience—triggered right after a high-value action.
Why the business model mattered
This client sits between large companies, suppliers, and banks, enabling early payment/receivables advances. In that context, we triggered NPS right after a critical financial operation.
That detail made a difference: users gave feedback when the value of the service felt most obvious. As a result, they responded more often and with better context.
Next step: segmentation and activation from NPS
With higher response volume, NPS turned into a behavioral signal.
High scores flagged high-value profiles with potential to adopt more products. Low scores became early risk alerts, giving the team a chance to intervene before churn.
Continuous experimentation
Shipping the new NPS didn’t end the work—it unlocked a clean experimentation loop.
One early question was placement: where should the in-browser NPS appear on the page to maximize conversion? We tested top vs middle vs bottom using Braze A/B testing. After a few days, the middle placement won clearly. We kept the winner and turned off the other variants.
From there, the team kept testing: layout tweaks, copy changes, design variations, and new hypotheses. The goal shifted from “keep response rate high” to “keep learning what lifts conversion and scale it.”
Key learnings
The User Case Day showed that building together accelerates results, that in-person presence strengthens alignment and trust, and that technology creates impact when it’s applied to solve real problems at the right moment.
More than a finished project, this case kicked off a continuous learning cycle: a way of working where experimentation isn’t random testing, but building, measuring, and evolving consistently.
