Conta Azul × Serasa · 2023–2024
Resultados
O projeto nasceu no fim de 2023 como aposta de receita para 2024, com OKR de R$268k de faturamento via modelo de add-on pago.
Meu escopo teve três frentes ao mesmo tempo:
A decisão mais importante aqui foi de posicionamento de produto, mais do que de interface: criar a consulta direta como ponto de entrada independente, sem obrigar o usuário a iniciar uma venda. Ela veio da pesquisa com quem não estava usando, não de um palpite interno.
O desafio tinha três camadas sobrepostas:
Resolver só a encontrabilidade sem a confiança geraria consultas e cancelamentos. Resolver só a confiança sem a encontrabilidade deixaria a receita represada. A sequência MVP → pesquisa → V2 foi justamente o mecanismo para atacar as três camadas em ordem, cada fase aprendendo com a anterior antes de ampliar o escopo.
A estrutura financeira da oferta deixava claro que o design tinha que acertar desde cedo: R$16,90 por consulta, teto de 30 por mês, cobrança pós-paga via boleto mensal. Isso criava uma tensão real, porque o risco de inadimplência era o principal risco operacional que a equipe tinha mapeado, e o pós-pago já entrou como solução temporária. O design precisava gerar confiança suficiente para o usuário topar pagar por algo que ainda não viu, e volume suficiente para o modelo financeiro se sustentar até uma eventual virada 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.
Lancei o MVP com um único ponto de entrada, dentro da criação de venda avulsa, para controlar as variáveis e medir conversão nas condições mais enxutas possíveis. Os 337 usuários únicos e os 16% de conversão não foram lidos como sucesso final, e sim como sinal verde para investir em diagnóstico qualitativo antes de escalar.
A nota média de 4,5/5 no survey pós-uso foi percebida como oportunidade: evidência de que o problema era encontrabilidade, não satisfação. Quem achava a feature gostava dela. O V2 foi construído inteiro em cima desse diagnóstico: tirar a barreira de contexto e deixar a consulta acessível no momento em que o usuário de fato precisa dela, antes da venda e não durante.
Toda decisão de design foi construída sobre uma fase estruturada de diagnóstico com quatro métodos.
Problema: Como testar o interesse e disposição de pagamento antes de construir a feature completa?
Decisão de design: Coloquei a consulta no momento de maior intenção: a criação de venda avulsa. Um ponto de entrada só, fluxo mínimo, foco em validar se o usuário pagaria antes de investir em vários canais.
Resultado: 16% de conversão e R$8.889 projetados em receita, sinal suficiente para avançar para a pesquisa e a V2.
Problema: O insight mais importante da pesquisa: o usuário quer avaliar risco antes de formalizar a venda. O MVP só cobria o momento após a decisão.
Decisão de design: Consulta direta como novo ponto de entrada principal, sem precisar de venda antes. Mais pontos no cadastro e no resumo do cliente, para cobrir todos os momentos em que o risco de crédito importa no fluxo real de trabalho.
Resultado: +677% de volume. A consulta direta liderou todos os canais e confirmou o insight da pesquisa.
Breakdown por ponto de entrada (V2)
Esta iniciativa provou que dá pra lançar um serviço pago com compra direta dentro de um ERP de assinatura, com uma experiência de confiança boa o bastante para gerar receita consistente. O OKR original era R$268k; os R$213.464 acumulados nos primeiros seis meses depois da V2 são uma prova de conceito sólida do 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 o volume por 7,7×. O breakdown por ponto de entrada mostra a consulta direta, que nem existia no MVP, liderando todos os outros canais somados no V2. A pesquisa previu exatamente esse resultado, e a V2 confirmou.
Desenhei o modelo de interação (contexto → verificação → confirmação) já pensando em reúso. Qualquer integração futura de parceiro que envolva dado sensível mais pagamento por uso dentro da Conta Azul pode herdar essa estrutura sem refazer a lógica de confiança do zero.
O roadmap previa uma V3 de melhorias (dados mais completos como capital social e quadro societário, e uma evolução do modelo de cobrança para reduzir o risco de inadimplência do pós-pago) que não chegou a começar dentro do período deste case. Os achados de oferta documentados na pesquisa existem como backlog validado, não como entrega.
Uma aposta de Growth com tese de receita clara (R$268k de OKR, R$16,90 por consulta), tocada com uma disciplina de pesquisa que poucos times de Growth aplicam. Integrar dados de crédito num ERP já existe lá fora há anos; o que mudou o jogo foi parar antes da V2 e ir conversar justamente com quem não estava usando. A tese de produto virou evidência de comportamento, e foi essa evidência que desenhou a arquitetura final.
Dois legados concretos. Primeiro: o padrão de interação contexto → verificação → confirmação como modelo reutilizável para qualquer add-on pago dentro do produto. Segundo: a prova prática de que, em features com baixa adoção, pesquisar com quem não usa rende mais aprendizado do que pesquisar com quem já usa. Esse segundo ponto mudou como a equipe passou a enquadrar problemas de adoção dali em diante.
Trataria o risco do pós-pago como problema de design já no MVP, e não como risco operacional para resolver depois. A cobrança via boleto mensal com teto de 30 consultas foi desenhada como solução temporária, mas entrou em produção sem um roadmap concreto de quando e como evoluiria. Olhando pra trás, a inadimplência potencial era uma fricção de confiança tão grande quanto qualquer elemento de interface, e merecia a mesma atenção de design que demos à encontrabilidade. Se fizesse de novo, colocaria os estados de cobrança (boleto vencido, consulta bloqueada, reativação) no fluxo principal desde a V1, não no backlog da V3.
Este case é protegido por senha. Insira a senha para acessar o processo completo — ou entre em contato para solicitar acesso.