All Connected — cover image

All Connected · Conta Azul · 2022

Unifying the ERP's customer registration to eliminate friction and build the foundation of a connected ecosystem

  • Onboarding
  • Architecture
  • ERP SaaS
  • Banking
  • Platform
Context
Conta Azul wanted to become a hub for Brazilian entrepreneurs, but each product (ERP, payment gateway, Conta PJ) had its own registration flow, with fragmented data and inconsistent experiences.
Problem
56.97% of users abandoned registration. Duplicate fields, different rules per product and visual inconsistency created friction before the user even got to know the product.
Approach
Mapping of all existing flows, evaluation of data providers for automation via CNPJ, and design of a single registration flow, validated in an MVP before full integration.
Result
12.9% reduction in abandonment, +2,107% in payment onboarding, and a technical foundation built for the launch of Conta PJ.

Results

  • +2,107% Payment onboarding 2.19% → 48.33%
  • +292% First invoice issued 1.42% → 5.56%
  • +69% Invoices settled 0.85% → 1.44% · 30d
  • +7.5% Conversion to paying customers 10% → 10.75% · 30d
  • −12.9% Sign-up abandonment 56.97% → 49.6%
  • +37% First sale created 12.76% → 17.5%
Navigate this page

Role

I worked as Senior Product Designer leading strategy and design execution for the unified registration flow. The role covered everything from mapping existing flows and technical compliance requirements to defining the unified UX architecture, prototyping multiple iterations, and validating with stakeholders across product, engineering, compliance and business. The work was simultaneously a UX project and a product architecture initiative.

Strategy

The tension was structural: each Conta Azul product (ERP, payment gateway, the future Conta PJ) had its own registration flow, with fragmented data and distinct rules. Users had to re-register every time they crossed into a new product, and the company accumulated inconsistent data across squads. The goal of becoming a hub for Brazilian entrepreneurs was real, but the infrastructure contradicted that vision at every new onboarding.

Fixing the form would have solved very little. What was at stake was the technical and experiential foundation to launch new products without recreating the same problem. With Conta PJ (business account) approaching, unifying registration stopped being a nice-to-have and became a strategic blocker.

Process

The approach combined structured discovery with iterative design in parallel. I mapped all existing registration flows and analyzed the requirements of ERP, Payments, Banking and KYC systems before proposing any solution. For automation via CNPJ, I evaluated multiple data providers: DataHub was selected for the best combination of speed and quality.

Validation happened in layers: first an MVP focused on Receba Fácil and Invoicing to test the core hypothesis before full integration. Product decisions were made together with the teams, including the mandatory 15-second CNPJ gate to guarantee valid experimental data.

  • Parallel Discovery
  • Vendor Evaluation
  • MVP
  • A/B Testing

Diagnosis

  1. Question: How is each product onboarding users today, and where are the breaking points?

    What was done: Full mapping of the registration flows for ERP, Receba Fácil and Conta PJ, documenting every step, requested field, validation rule and known abandonment point.

    Key finding: Repeated fields across products, inconsistent visual patterns and unnecessary steps in every flow. The same data (CNPJ, company name, address) was requested more than once.

    Artifact: Comparative mapping of the three flows with overlaps and gaps highlighted.

    Comparative mapping of registration flows — ERP, Receba Fácil and Conta PJ
    Comparative mapping of registration flows — ERP, Receba Fácil and Conta PJ

Solution

Problem: Each product started from a different point: email, company data, business type. There was no common baseline.

Design decision: CNPJ was set as the mandatory entry point for every product. Once the CNPJ is confirmed, the DataHub API automatically fills in all available data; the user only sees fields for information that couldn’t be retrieved. Zero repetition. The bureau-data review step lets the user confirm and edit whatever was auto-filled, keeping speed without sacrificing accuracy.

Result: Drastic reduction in fill-out effort and elimination of duplicate data across products.

Impact

  • Technical foundation for Conta PJ

    The unification created the technical and experiential infrastructure that the Conta PJ launch required. Without this project, every new platform product would have repeated the same fragmentation problem.

  • Standardization for future products

    The unified flow established reusable patterns for all subsequent products: new integrations became significantly faster to implement.

  • Centralized data

    Unified customer information across the ecosystem eliminated rework between squads that previously worked on separate systems with inconsistent data.

  • Less duplicated effort across teams

    The initiative eliminated parallel work between teams that maintained different flows for the same problem, freeing up capacity for product evolution.

Reflection

What this project actually was

The goal was to reduce sign-up abandonment, and the path went through product architecture. I treated registration as shared infrastructure, and that’s what unlocked impact across multiple products at once. A series of isolated UX improvements wouldn’t have come close.

The hard part was below the interface: deep dependencies between systems, KYC rules that changed mid-project, latency and inconsistency from external data providers, and teams that disagreed on what “unified” should mean.

What remained afterward

The foundation built here served Receba Fácil, Conta PJ, the financial products that came after, and any other product that needed registration. The project’s legacy lies more in the scalability it unlocked than in the A/B numbers.

What I’d do differently

I’d define success criteria earlier for the full integration, not just for the MVP. The separation between hypothesis validation (MVP) and full architecture created ambiguity about when each decision was “final.” Naming that boundary from the start would have reduced rework in later iterations.

Contact

Let's work together?

Available for full-time · remote · freelance

Open to new projects, opportunities and conversations.