Criar um onboarding de KYC do zero nunca é simples. Fazer isso em um ambiente de alto risco regulatório, com usuários de baixa maturidade digital, celulares básicos e múltiplos parceiros externos? Aí o desafio muda de escala.
Quando começamos a Conta Digital do Ton, o cenário era claro: apenas 30% das pessoas conseguiam concluir o processo. O restante se perdia em um fluxo longo, pouco didático e frágil, exatamente o oposto do que uma conta digital deveria ser.
Nossa ambição era simples de dizer e difícil de executar: transformar um processo burocrático e crítico em uma experiência fluida, intuitiva e resiliente. Um onboarding que se explicasse sozinho. Que funcionasse em qualquer dispositivo. E que mantivesse, em cada etapa, o rigor exigido por antifraude e compliance regulatório.
A solução começou longe das telas. Mergulhamos no comportamento de clientes reais, observando onde surgiam dúvidas, frustrações e abandonos. Instrumentamos cada etapa do funil e deixamos os dados guiarem as decisões. A partir disso, construímos um motor de biometria inteligente, desenhado para se adaptar à realidade do usuário, e não o contrário.
O resultado foi uma virada completa: a conversão saltou de 30% para 95%. Tudo isso sem concessões em segurança ou conformidade regulatória.
Mais do que melhorar números, esse projeto provou um princípio fundamental: quando tecnologia, dados e empatia trabalham juntos, até os processos mais complexos podem se tornar simples.
Problema de negócio e oportunidade
Baixa conversão no onboarding impedia a ativação da conta digital
Alto custo operacional com suporte e reprocessamento manual
Fricção inicial comprometia confiança e LTV do cliente
Oportunidade: transformar o onboarding em uma vantagem competitiva, acelerando ativação, reduzindo CAC indireto e habilitando novos produtos financeiros.
Por que esse projeto era estratégico
Onboarding é o gateway de toda a jornada financeira
Sem KYC aprovado → sem conta → sem monetização
Impacto direto em crescimento, risco, compliance e experiência
2. Contexto e desafios
Situação inicial
Onboarding inexistente para conta digital
Dependência de múltiplos parceiros de KYC
Fluxo técnico complexo, pouco observável
Conversão média: 30%
Principais dores dos usuários
Dificuldade para tirar selfie válida
Documentos antigos, cópias ou mal conservados
Linguagem técnica e mensagens genéricas de erro
Celulares simples, câmeras de baixa qualidade
Baixa alfabetização digital
Limitações técnicas e organizacionais
APIs externas com erros pouco descritivos
Respostas técnicas não orientadas ao usuário final
Time lidando com alto volume de falhas sem visibilidade clara
Pressão regulatória (KYC, AML, Bacen)
Riscos envolvidos
Fraude e abertura indevida de contas
Falso positivo (bloquear cliente legítimo)
Experiência ruim no primeiro contato com a marca
Escalabilidade do suporte humano
3. Objetivos e métricas de sucesso
Objetivos de negócio
Aumentar conversão do onboarding
Reduzir custo operacional de suporte
Manter compliance e antifraude
Objetivos de produto
Criar um onboarding autoexplicativo
Reduzir falhas evitáveis
Tornar o fluxo observável e iterável
KPIs principais
Conversão do onboarding: 30% → 95%
Tempo médio de onboarding
Erros por etapa
Falhas técnicas por parceiro
Taxa de reprocessamento
Tickets de suporte por onboarding
4. Minha atuação como Product Manager
Responsabilidades diretas
Desenho completo do fluxo KYC
Integração com parceiros externos
Definição de métricas e instrumentação
Liderança de discovery contínuo
Interface com risco, jurídico e engenharia
Acompanhamento diário via dashboards
Decisões estratégicas
Priorizar clareza > velocidade
Tratar onboarding como produto, não feature
Criar observabilidade antes de escalar
Investir em mensagens educativas ao invés de apenas regras mais rígidas
Frameworks e métodos utilizados
Discovery contínuo
JTBD (abrir conta para receber e usar dinheiro)
Funil AARRR adaptado ao onboarding
Prioritização por impacto × frequência
Scrum + Kanban (discovery e delivery em paralelo)
Trade-offs importantes
Mais etapas explicativas vs. menos abandono
Customização do fluxo vs. custo técnico
Automatização vs. risco regulatório
5. Time e stakeholders
Estrutura do time
Engenharia mobile e backend
Design de produto
Dados
Risco e compliance
Atendimento e operações
Stakeholders
Liderança de produto
Jurídico e regulatório
Parceiros de biometria
Atendimento ao cliente
Comunicação e alinhamento
Rituais semanais
Dashboards compartilhados
Reviews com risco e jurídico
Feedback direto de clientes
Conflitos e resolução
Risco queria mais bloqueios → dados mostraram falso negativo
Engenharia queria simplificar → testes mostraram impacto em conversão
6. Processo de discovery e delivery
Quando olhei para o onboarding KYC da Conta Digital do Ton, ficou claro que eu não estava diante de um “fluxo com bugs”. Eu estava diante de um problema de produto e de contexto humano: nosso usuário era um microempreendedor/autônomo que precisava abrir conta rápido, mas muitas vezes usava um celular simples, tinha pouca familiaridade com tecnologia e, em alguns casos, vivia em ambientes que tornavam selfie e documento “bons o suficiente” um desafio real.
Meu objetivo no discovery foi responder três perguntas com evidência (não com opinião):
Por que as pessoas falhavam? (comportamento + contexto)
Onde exatamente elas falhavam? (funil + telemetria)
Como “bom” deveria ser o nosso onboarding? (benchmark + competitividade)
A partir disso, executei uma abordagem em três frentes: campo (clientes reais), dados (observabilidade) e mercado (benchmark).
6.1) Campo: WhatsApp + clientes reais (qualitativo rápido e recorrente)
Por que WhatsApp?
Eu percebi que, se eu dependesse apenas de pesquisa formal, eu teria:
baixa velocidade de feedback
pouca proximidade com o “momento da dor”
muita perda de nuance (o problema acontece em segundos, no ambiente real do cliente)
WhatsApp era onde esse público de fato vivia. Era o canal com menor fricção para eles e maior velocidade para nós.
O que eu fiz
Criei grupos de WhatsApp com early adopters (usuários que estavam tentando abrir a conta e topavam ajudar).
Organizei o grupo com regras simples: “manda print/gravação de tela quando travar”, “conta onde você estava e o que tentou fazer” e “se puder, manda foto do ambiente (iluminação/fundo)”
Fiz acompanhamento quase em tempo real. Em alguns momentos, isso significou atender cliente em domingo à noite, não por heroísmo, mas porque era o único jeito de capturar o problema no instante em que ele acontecia.
Que tipo de evidência o WhatsApp trouxe
Prints das mensagens de erro (que geralmente eram técnicas ou genéricas)
Vídeos mostrando: como o cliente posicionava o documento, como ele tirava selfie (muito perto, muito longe, tremendo, com reflexo, etc.), Comentários espontâneos (“não sei o que fazer”, “tá pedindo de novo”, “já fiz 3x”)
Contexto: câmera ruim, iluminação fraca, fundo poluído, documento físico muito antigo
A descoberta mais importante
A grande virada foi entender que o onboarding não falhava apenas por “erro técnico”.
Ele falhava porque o sistema exigia qualidade de entrada (selfie/documento) maior do que o contexto do cliente conseguia entregar, e ainda por cima não explicava como melhorar.
Isso criou um princípio de produto que guiou o resto do projeto:
“Se o cliente está errando, o produto precisa assumir que é nossa responsabilidade explicar como acertar.”
6.2) Visitas presenciais: entendimento do “mundo real” (contexto que dado não mostra)
Eu decidi visitar clientes porque percebi um risco clássico:
o time desenha para um usuário “ideal” que não existe.
O que eu observei nas visitas
Clientes operando em ambientes difíceis:
balcão de loja, rua, feira, oficina
iluminação irregular
pouco tempo e paciência para “fazer direito”
Documento:
guardado de qualquer jeito (dobrado, com reflexo, plastificado, gasto)
Celulares:
básicos, câmeras simples, telas pequenas e baixo desempenho
Pressa e ansiedade: abrir conta era “um meio”, não um fim
O que isso mudou no produto
As visitas reforçaram que:
O fluxo precisava ser didático e tolerante, não apenas “seguro”.
Era essencial reduzir tentativas inúteis (“tente novamente”) e aumentar orientação (“faça assim”).
O onboarding precisava comunicar progresso e estado (“selfie ok, agora falta documento e análise”).
Isso ajudou a transformar o onboarding em uma experiência mais “assistida”, sem depender de humano.
6.3) Dados: observabilidade total do funil (quantitativo para decidir prioridade)
Em paralelo ao qualitativo, eu montei uma operação de observabilidade do onboarding para responder:
Em qual etapa o usuário mais caía?
Quantas tentativas por etapa?
Quais erros vinham do app vs. dos parceiros?
Quais erros eram “recuperáveis” (UX) vs. “inevitáveis” (fraude/documento inválido)?
Como fizemos
Criamos dashboards no Metabase para funil, conversão, tempo e quedas por etapa
Usamos Datadog para erros técnicos (timeouts, instabilidade, falhas de integração)
Eu acompanhava isso quase em tempo real para detectar regressões e “buracos” do fluxo
O que os dados ajudaram a provar
Muitas quedas eram evitáveis com orientação e melhoria de feedback
Havia erros técnicos repetidos por parceiro e por step
O tempo de onboarding estava alto e aumentava com retrabalho
Essa parte foi decisiva porque transformou feedbacks do WhatsApp e visitas em algo mensurável e priorizável.
6.4) Mercado: benchmark competitivo (por que era urgente e qual era a barra)
Além de entender nossos usuários, eu precisava entender uma coisa simples:
“O que é bom nesse mercado? Estamos atrás? Quanto?”
Então eu olhei para o mercado para formar uma referência de competitividade, principalmente em duas dimensões:
(A) Tempo de onboarding (time-to-value)
Quanto tempo o cliente leva, do “quero abrir conta” até “conta ativa”?
Se o concorrente entrega isso em minutos e nós em horas/dias → perdemos confiança e conversão
Para público de microempreendedor, tempo é valor
(B) Conversão (eficiência do funil)
Qual é a taxa de conclusão/ aprovação em players comparáveis?
A intenção do benchmark não era copiar fluxo. Era entender:
a barra mínima de experiência
o quanto a fricção era um “problema nosso” vs. “normal do setor”
Como eu usei isso no case
O benchmark virou munição para:
justificar prioridade executiva (“não é perfumaria, é competitividade”)
definir metas realistas (e agressivas)
sustentar trade-offs com risco e engenharia
Como tudo isso virou decisão de produto: a hipótese do Motor de Biometria
Depois de WhatsApp + visitas + observabilidade + benchmark, eu consolidei uma hipótese central:
Hipótese
Se traduzirmos erros técnicos e falhas de validação em orientações claras e acionáveis, e mostrarmos status do fluxo em linguagem humana, então:
diminuímos repetição de tentativas
reduzimos abandono por frustração
aceleramos tempo total
aumentamos conversão mantendo rigor antifraude
Essa hipótese foi o “porquê” do Motor de Biometria.
E ela não nasceu de brainstorming: nasceu do campo.
“Eu tratei o onboarding como um produto de alta complexidade humana, não como um formulário. O discovery em campo mostrou que o maior inimigo da conversão não era fraude, era falta de orientação.”
7. Solução construída
Descrição da solução
Criação de um motor de biometria inteligente, intermediando APIs técnicas e traduzindo erros em orientações humanas e acionáveis.
Principais funcionalidades
Tradução de erros técnicos para linguagem simples
Feedback imediato por etapa
Status claro do progresso
Reprocessamento orientado
Instrumentação completa do funil
Diferenciais competitivos
UX adaptada ao contexto real do usuário
Redução drástica de erros evitáveis
Alta taxa de aprovação legítima
Escalabilidade sem aumento proporcional de suporte
Arquitetura (alto nível)
App → Motor de Biometria → Parceiros KYC → Camada de decisão → Feedback UX
8. Resultados e impacto
Resultados quantitativos
Conversão: 30% → 95%
Redução massiva de falhas técnicas
Menor volume de tickets
Onboarding mais rápido e previsível
Resultados qualitativos
Clientes mais confiantes
Menos frustração
Melhor percepção da marca
Times mais orientados a dados
Impacto geral
Negócio: mais contas ativas
Usuários: experiência justa e simples
Time: clareza, foco e aprendizado contínuo
9. Aprendizados e próximos passos
O que funcionou bem
Proximidade com clientes reais
Dados + empatia
Observabilidade desde o início
O que faria diferente
Instrumentar ainda antes do MVP
Envolver suporte mais cedo
Testar linguagem com mais variações regionais
Evoluções futuras
Personalização por perfil
Reuso do motor em outros fluxos regulatórios
10. Conclusão
No fim das contas, esse projeto me lembrou algo simples, mas fácil de esquecer: produto não acontece na tela, acontece na vida real das pessoas.
O onboarding da conta digital do Ton não falhava porque as pessoas eram desatentas ou porque a tecnologia era ruim. Ele falhava porque estávamos pedindo demais de um contexto que não existia: celulares simples, pouca luz, pouco tempo, pouca paciência e zero vontade de “entender o sistema”.
Resolver isso não passou por criar regras mais rígidas ou jogar mais inteligência artificial em cima do problema. Passou por ouvir de verdade, olhar dados com curiosidade (e não com ego), atender cliente fora do horário comercial, ir a campo e aceitar que, às vezes, a melhor decisão de produto é explicar melhor, e não complicar mais.
O resultado foi um onboarding que deixou de ser um obstáculo e passou a ser um facilitador. A conversão saiu de 30% para 95%, mas o número mais importante não foi esse. Foi perceber que, quando você respeita o contexto do usuário, o produto começa a trabalhar a favor dele, e não contra.
Se esse case prova alguma coisa, é que bons produtos financeiros para públicos simples exigem mais sofisticação de produto, não menos. E que Product Management, no fim do dia, é menos sobre frameworks bonitos e mais sobre estar disposto a fazer o trabalho que precisa ser feito, mesmo que isso inclua responder WhatsApp num domingo à noite.
