Conta Azul × Serasa · 2023–2024
Resultados
Atuei como único designer desta iniciativa — da concepção ao QA — dentro de um time de Growth DN formado por PM (Bruno Brasil Airão), Tech Lead (Marcos Daniel Budtinger), Stakeholder de negócio (Rodrigo Paiva Mendonça) e DM (Thiago Roberto Kolodge). A iniciativa nasceu no final de 2023 como aposta de receita para 2024, com OKR de atingir R$268k de faturamento via modelo de add-on pago.
Meu escopo cobriu três dimensões simultâneas: definição do modelo de interação para uma feature paga dentro de um fluxo transacional sensível à confiança; coordenação e análise da pesquisa com três perfis distintos de usuários pós-MVP; e redesign completo da arquitetura de acesso na V2. A decisão mais importante deste projeto não foi de interface — foi de posicionamento de produto: criar a consulta direta como ponto de entrada independente, sem exigir que o usuário iniciasse uma venda. Essa decisão não veio de hipótese interna — veio de pesquisa com quem não estava usando.
O desafio tinha três camadas sobrepostas: encontrabilidade — como tornar visível uma feature nova sem degradar o fluxo existente; confiança — como fazer o usuário pagar por uma consulta dentro de um produto que ele já assina; e modelo de negócio — como estruturar uma oferta de add-on que pudesse ser replicada para outros parceiros.
Resolver só a encontrabilidade sem resolver a confiança geraria consultas e cancelamentos. Resolver só a confiança sem resolver a encontrabilidade deixaria a receita represada. A sequência MVP → pesquisa → V2 foi o mecanismo para resolver as três camadas de forma ordenada — cada fase aprendendo com a anterior antes de ampliar escopo.
A estrutura financeira da oferta reforçava a necessidade de acertar o design desde o início: R$16,90 por consulta, teto de 30 consultas por mês, cobrança pós-paga via boleto mensal. Esse modelo criava uma tensão real — o risco de inadimplência era o principal risco operacional mapeado pela equipe, e a solução pós-paga foi tratada como temporária desde o início. O design precisava gerar confiança suficiente para o usuário aceitar pagar por algo que ainda não viu; e volume suficiente para que o modelo financeiro se sustentasse antes de uma eventual evolução para pré-pago.
A estrutura desta iniciativa foi deliberadamente incremental: MVP para validar disposição de pagamento antes de ampliar investimento; pesquisa com três perfis de uso para entender por que não usuários não usavam; e V2 com arquitetura de entrada expandida derivada dos achados de pesquisa.
O MVP foi lançado com um único ponto de entrada — dentro da criação de venda avulsa — para controlar variáveis e medir conversão em condições mínimas. Os 337 usuários únicos e a taxa de 16% de conversão não foram tratados como sucesso final: foram tratados como sinal verde para investir em diagnóstico qualitativo antes de escalar.
A avaliação média de 4,5/5 no survey pós-uso não foi acompanhada passivamente — foi lida como evidência de que o problema era encontrabilidade, não satisfação. Usuários que encontravam a feature a valorizavam. O design do V2 foi inteiramente construído sobre esse diagnóstico: remover a barreira de contexto e tornar a consulta acessível no momento em que o usuário real precisa dela — antes da venda, não durante.
Toda decisão de design foi construída sobre uma fase estruturada de diagnóstico com quatro métodos.
Breakdown por ponto de entrada (V2)
Esta iniciativa provou que é possível lançar um serviço pago com compra direta dentro de um ERP de assinatura — com experiência de confiança suficiente para gerar receita consistente. O OKR original era R$268k; os R$213.464 acumulados nos primeiros seis meses após o V2 representam uma prova de conceito sólida para o modelo, mesmo que o potencial estimado na priorização ainda não tenha sido atingido na janela medida.
A diferença entre o MVP e o V2 não foi preço, qualidade de dados ou confiança — foi arquitetura de acesso. Tornar a feature encontrável no momento certo multiplicou volume por 7,7×. O breakdown por ponto de entrada mostra que a consulta direta — o canal inexistente no MVP — liderou todos os outros canais combinados no V2. A pesquisa previu exatamente esse resultado; o V2 o confirmou.
O modelo de interação — contexto → verificação → confirmação — foi projetado para ser replicado. Qualquer futura integração de parceiro que envolva dado sensível + pagamento por uso dentro da Conta Azul pode herdar essa estrutura sem reconstruir a lógica de confiança do zero.
O roadmap incluía uma V3 de melhorias — dados mais completos (capital social, quadro societário), evolução do modelo de cobrança para reduzir o risco de inadimplência pós-pago — que não chegou a ser iniciada dentro do período coberto por este case. Os achados de oferta documentados na pesquisa existem como backlog validado, mas não como entrega.
Uma aposta de Growth com tese de receita clara — R$268k de OKR, modelo de R$16,90/consulta — executada com disciplina de pesquisa que a maioria dos times de Growth não aplica. O que diferenciou este projeto não foi a ideia de integrar dados de crédito num ERP (isso existe em outros mercados há anos), mas a escolha de parar antes do V2 e perguntar especificamente para quem não estava usando. Essa escolha transformou uma tese de produto em evidência de comportamento — e a evidência, não a intuição, definiu a arquitetura final.
Dois legados concretos: (1) o padrão de interação contexto → verificação → confirmação como modelo reutilizável para qualquer add-on pago dentro do produto; e (2) a demonstração operacional de que pesquisa com não usuários é o instrumento mais direto para desbloquear crescimento em features com baixa adoção — não pesquisa com quem já usa. Esse segundo ponto mudou como a equipe enquadrava problemas de adoção subsequentes.
Trataria o risco do modelo pós-pago como problema de design desde o MVP — não como risco operacional a ser resolvido depois. O modelo de cobrança via boleto mensal com teto de 30 consultas foi desenhado como solução temporária, mas entrou em produção sem um roadmap concreto de quando e como evoluiria. Em retrospecto, a inadimplência potencial era uma fricção de confiança tanto quanto qualquer elemento da interface — e merecia a mesma atenção de design que demos à encontrabilidade. Se fizesse de novo, mapearia os estados de cobrança (boleto vencido, consulta bloqueada, reativação) como parte do fluxo principal desde a V1, não como backlog de V3.
Este case é protegido por senha. Insira a senha para acessar o processo completo — ou entre em contato para solicitar acesso.
Disponível para full-time · remote · freelancer
Aberto a novos projetos, oportunidades e conversas.