Conta Azul × Serasa · 2023–2024
Results
The project started at the end of 2023 as a revenue bet for 2024, with an OKR of R$268k in revenue via a paid add-on model.
My scope had three fronts running at the same time:
The most important decision here was one of product positioning, more than interface: creating the direct check as an independent entry point, without forcing the user to start a sale first. It came from research with people who weren’t using the feature, not from an internal guess.
The challenge had three overlapping layers:
Solving discoverability alone without trust would generate checks and cancellations. Solving trust alone without discoverability would leave revenue stuck. The MVP → research → V2 sequence was exactly the mechanism to attack the three layers in order, each phase learning from the last before widening scope.
The offer’s financial structure made clear that design had to get it right early: R$16.90 per check, a cap of 30 per month, post-paid billing via monthly invoice. That created real tension, because default risk was the main operational risk the team had mapped, and post-paid billing already went in as a temporary solution. The design needed to generate enough trust for the user to agree to pay for something they hadn’t seen yet, and enough volume for the financial model to hold until an eventual shift to prepaid.
This initiative’s structure was deliberately incremental: an MVP to validate willingness to pay before scaling investment; research with three usage profiles to understand why non-users weren’t using it; and a V2 with an expanded entry architecture derived from the research findings.
I launched the MVP with a single entry point, inside the one-off sale creation flow, to control variables and measure conversion under the leanest possible conditions. The 337 unique users and 16% conversion weren’t read as final success, but as a green light to invest in qualitative diagnosis before scaling.
The average score of 4.5/5 in the post-use survey was read as an opportunity: evidence that the problem was discoverability, not satisfaction. Whoever found the feature liked it. V2 was built entirely on top of that diagnosis: removing the contextual barrier and making the check accessible the moment the user actually needs it, before the sale rather than during it.
Every design decision was built on a structured diagnosis phase with four methods.
Problem: How to test interest and willingness to pay before building the full feature?
Design decision: I placed the check at the moment of highest intent: one-off sale creation. A single entry point, a minimal flow, focused on validating whether the user would pay before investing in multiple channels.
Result: 16% conversion and R$8,889 in projected revenue, signal enough to move forward to research and V2.
Problem: Research’s most important insight: the user wants to assess risk before formalizing the sale. The MVP only covered the moment after the decision.
Design decision: Direct check as a new main entry point, with no sale required beforehand. More entry points in customer registration and in the customer summary, to cover every moment where credit risk matters in the actual workflow.
Result: +677% volume. The direct check led every channel and confirmed the research insight.
Breakdown by entry point (V2)
This initiative proved that you can launch a paid, direct-purchase service inside a subscription ERP, with a trust experience good enough to generate consistent revenue. The original OKR was R$268k; the R$213,464 accumulated in the first six months after V2 is a solid proof of concept for the model, even though the potential estimated in prioritization hadn’t yet been reached within the measured window.
The difference between the MVP and V2 wasn’t price, data quality, or trust: it was access architecture. Making the feature discoverable at the right moment multiplied volume by 7.7×. The entry-point breakdown shows the direct check, which didn’t even exist in the MVP, leading every other channel combined in V2. Research predicted exactly this outcome, and V2 confirmed it.
I designed the interaction model (context → verification → confirmation) with reuse in mind from the start. Any future partner integration involving sensitive data plus pay-per-use inside Conta Azul can inherit this structure without rebuilding the trust logic from scratch.
The roadmap called for a V3 of improvements (more complete data such as equity capital and ownership structure, and an evolution of the billing model to reduce post-paid default risk) that hadn’t started within this case’s timeframe. The offer findings documented in research exist as a validated backlog, not as delivery.
A Growth bet with a clear revenue thesis (R$268k OKR, R$16.90 per check), run with a research discipline few Growth teams apply. Integrating credit data into an ERP has existed abroad for years; what changed the game was stopping before V2 to go talk specifically to those who weren’t using it. The product thesis turned into behavioral evidence, and that evidence designed the final architecture.
Two concrete legacies. First: the context → verification → confirmation interaction pattern as a reusable model for any paid add-on inside the product. Second: practical proof that, for low-adoption features, researching people who don’t use the product yields more learning than researching people who already do. That second point changed how the team came to frame adoption problems from then on.
I’d treat post-paid billing risk as a design problem from the MVP itself, not as an operational risk to solve later. Monthly invoice billing with a 30-check cap was designed as a temporary solution, but it went into production with no concrete roadmap for when and how it would evolve. Looking back, potential default was a trust friction just as significant as any interface element, and it deserved the same design attention we gave discoverability. If I did it again, I’d put the billing states (overdue invoice, blocked check, reactivation) in the main flow from V1, not in the V3 backlog.
This case is password-protected. Enter the password to access the full process — or get in touch to request access.