BPO Financeiro: O caminho feliz é uma ilusão
Em meio a alta complexidade e regras de negócio rígidas, o erro deixa de ser exceção e passa a ser regra.
Neste projeto, o trabalho não parou na tela. Traduzi como o financeiro de uma empresa realmente funciona para um time que nunca tinha trabalhado com isso, exceto por mim.
Período
Dez/2025 - Mar/2026
Papel
Product Designer
Empresa
OpenCON
Interface
Plataforma Web
Cenário
As empresas brasileiras gastam em média 1.500 horas por ano só pra apurar, declarar e pagar impostos, seis vezes mais que a média mundial. Enquanto isso, o país edita cerca de 37 normas tributárias por dia, uma a cada quarenta minutos.
1600h
1400h
1200h
1000h
800h
600h
400h
200h
0h
Média mundial: 233h
1501h
1025h
920h
889h
834h
664h
632h
624h
Brasil
Bolívia
Venezuela
Líbia
Chade
Gabão
Equador
Camarões
Com a reforma tributária em curso, entre 2026 e 2033 as empresas vão conviver com dois sistemas ao mesmo tempo, e o crédito tributário passa a depender da organização financeira, não só da contabilidade. Isso está aquecendo o mercado de BPO financeiro, que deixou de ser tarefa isolada e passou a caminhar lado a lado com o fiscal.
Responsabilidades
Atuei de forma estratégica em todo o processo ao lado da Product Manager, traduzindo regras de negócio em tela, estruturando o ICP do produto, conduzindo testes, entrevistas e documentação. Também fui responsável por tomar as decisões de fluxo da plataforma, definindo as métricas de sucesso e falando diretamente com os stakeholders.
Restrições
O prazo até o lançamento do MVP era curto, e ao longo do processo novos requisitos foram chegando de forma top-down, o que exigia replanejar sem perder o ritmo do desenvolvimento.
Simultâneo
Exploração
Definição
Ideação
Criação
Ajustes
Desenvolvimento
Dezembro
Janeiro
Fevereiro
Março
Além disso, o produto envolvia uma camada técnica densa — regras de negócio, integrações e fluxos que não podiam ser tratados de forma superficial. Isso exigia que todo o time envolvido no projeto, entendesse essa complexidade em profundidade.
Equipe
O time era pequeno para o tamanho do desafio: Um product manager, eu como designer (e parceiro de negócio da PM ao longo de todo o processo), um dev sênior e dois dev pleno.
Problema
Saldo inicial do projeto era negativo
A plataforma não tinha um BPO estruturado. As funcionalidades financeiras existentes eram rasas e não davam conta do que o usuário precisava, e isso aparecia com clareza nos números. Quase 40% dos usuários ativos mensais abriam pelo menos um chamado relacionado a essas funcionalidades.
O trabalho não se resumia a desenhar um BPO do zero. Era preciso repensar toda a estrutura financeira da plataforma junto com ele.
Processo
A ilusão do caminho feliz
Quanto mais testes eram realizados na plataforma, mais ficava claro que um BPO financeiro não segue um fluxo linear. O contato direto com o cliente, a sincronização de contas bancárias via open finance, a baixa adesão do cliente na hora de se comunicar, tudo isso cria idas e vindas constantes.
Não existe um caminho feliz. Existem vários. E cada um deles precisava ser mapeado, porque o custo de deixar um de fora não era apenas um detalhe visual mal resolvido, mas um erro financeiro real na conta de alguém.
Esse foi o principal replanejamento de mentalidade do projeto. Parar de desenhar pensando em um fluxo ideal e passar a desenhar pensando em todos os fluxos possíveis.
Pesquisa
Analisei dezenas de BPOs financeiros existentes, olhando estrutura, fluxo e posicionamento. Mas quase nada servia direto: o público da OpenCON (MEIs e Simples Nacional) era diferente do atendido pela maioria desses produtos. O trabalho foi filtrar o que fazia sentido adaptar e descartar o resto.
Entrevistas
Conversei com quase 30 profissionais da área, em 6 empresas diferentes. O maior desafio foi que nem os contadores, nem a própria OpenCON sabiam ao certo quem era o ICP, então precisei definir internamente antes de extrair qualquer insight confiável. As primeiras entrevistas saíram enviesadas, com contadores acostumados a clientes maiores, ainda no início ajustei o perfil de quem eu entrevistava.
Planejamento
A tensão real foi sobre o que entraria na primeira versão, e quem sentiu essa dor foram os stakeholders. Eu e a PM tivemos uma conversa direta com eles, mostrando que dar conta de tudo de uma vez não era viável. Não foi bem recebido de início, mas mudou quando mostramos o raciocínio por trás da decisão.
Testes
Nesta etapa entendi que os clientes pequenos e grandes usam o BPO de formas diferentes. Um exemplo simples: a frequência de lançamento de movimentações, que varia de diária para clientes menores a semanal ou até mensal para os maiores. Esse ritmo diferente significava que a tela precisava dar suporte a mais de uma forma de uso, não só a uma.
Ajustes
Nas entrevistas, os contadores diziam confiar no que estava lançado no sistema. Mas os testes mostraram outra fonte da verdade: o extrato bancário, que reflete o que de fato aconteceu. Por isso, inverti a lógica de conciliação — o banco virou a referência, e o lançamento manual passou a precisar se encaixar nele.
Desenvolvimento
O design foi ajustado lado a lado com a engenharia, conforme a implementação revelava novos limites técnicos e de prazo. O histórico de movimentações é o exemplo mais claro: os testes mostraram valor real, mas ficou fora do MVP por não ser inegociável para o MVP funcionar.
Desafio
O trabalho que ninguém viu na tela
Fui o único do time que já tinha trabalhado na área financeira antes, então grande parte do trabalho foi traduzir para o time como o financeiro de uma empresa realmente funciona, antes mesmo de discutir qualquer fluxo de interface.
Um exemplo concreto disso foi a diferença entre data de caixa e data de provisionamento. O fluxo contábil trabalha com uma lógica, o financeiro com outra, e misturar as duas nos relatórios geraria números que pareciam certos na tela, mas não batiam com a realidade de caixa da empresa. Entender e proteger essa diferença desde o início evitou uma bagunça que só apareceria meses depois, quando já seria bem mais cara de corrigir.
Essa tradução não terminou quando o design ficou pronto. No handoff, ficou claro que parte o time não tinha essa mesma bagagem, o que me levou a criar um manual cobrindo não só as telas, mas as regras de negócio por trás delas, pra que o time conseguisse montar o fluxo sozinho sem depender de mim pra cada dúvida.
2
1
3
4
Resultado
O que os números confirmaram
Queda nos chamados relacionados ao financeiro.
Nos 90 dias após o MVP, chamados sobre funcionalidades financeiras caíram de 40% para 16% dos usuários ativos (dado via Mixpanel), validando a decisão de mapear caminhos alternativos em vez de um fluxo único.
Conclusão do fluxo de sincronização bancária
A sincronização via open finance não existia antes do projeto. Nos primeiros 90 dias, apenas 28% dos usuários que ativaram o BPO completaram o funil de conexão bancária, medido por funil no Mixpanel.
Adoção do BPO entre o público elegível
42% dos usuários MEI e Simples Nacional elegíveis ativaram o BPO financeiro dentro dos primeiros 90 dias de disponibilidade, acompanhado pelo evento de ativação de feature no Mixpanel.
40% → 16%
Queda nos chamados sobre funcionalidades financeiras
28%
Conclusão do funil de sincronização bancária
42%
MEIs e Simples Nacional que ativaram o BPO Financeiro
Aprendizado
A próxima barreira não é técnica
O produto continua evoluindo: já implementamos histórico de uploads, open finance e sugestão por IA, sempre pensando em como melhorar a experiência. Uma das frentes atuais é justamente aumentar a adesão ao open finance.
A sincronização bancária, com apenas 28% de conclusão, revelou algo que só ficou visível na prática: o receio do cliente final em conectar a própria conta ao sistema. Nos mostrando que a próximo desafio não é uma barreira técnica, é uma barreira de confiança.
