Discovery concluído, escopo priorizado entregue em produção. Rateio nativo + Relatórios por Centro de Custo foram a primeira frente liberada, usada por clientes do PRO desde o release e parte da conversão de novos clientes vindos da migração.
Conta Azul
Como transformei um pedido represado há 4+ anos no Portal de Ideias em um discovery acionável para o Financeiro 2.0, destravando 4 frentes de roadmap.
challenge.
Pedido represado há mais de 4 anos no Portal de Ideias, recorrente em NPS e Zendesk. No plano PRO, ratear uma nota fiscal exigia quebrar em vários lançamentos manuais, sem cobrir Conciliação nem Vendas e Compras. A maioria desistia e mantinha planilha paralela em Excel, conferida diariamente com a Conta Azul.
how I solved.
Discovery em 4 camadas, cada uma filtrando a próxima:
• Escuta de canais: Zendesk, Portal de Ideias e NPS agrupados por vocabulário e intensidade. • Benchmark de 6 concorrentes: Omie, Quickbooks, Zeropaper, VHsys, ERP4Me e Vexpenses. • Matriz CSD: separou o que sabíamos do que precisávamos perguntar, evitando entrevista pra confirmar hipótese óbvia. • 7 entrevistas em profundidade com perfis distintos (contabilidade, TI, ensino, financeira sem fins lucrativos).
A síntese virou mapa de jornada com fricção organizada em 4 frentes priorizadas, prontas pro roadmap.
results.
A primeira frente (rateio nativo + relatórios por Centro de Custo) foi pro ar e:
• -14% de churn no grupo que migrava pra outro ERP por falta da feature. • NPS alto logo no release, virou argumento ativo de conversão de clientes vindos da concorrência. • CSAT do Financeiro subiu após o release.
-14%
churn de migração
clientes que iam pra outro ERP por falta da feature
NPS ↑
alto no release
feature usada como argumento na conversão de migração
CSAT ↑
módulo Financeiro
satisfação subiu após o release
4 → 1
frentes priorizadas
rateio + relatórios entraram primeiro
activities.
-14%
Redução de churn
↑
NPS / CSAT do Financeiro
4
Frentes priorizadas
4+
Anos de pedidos represados
context.
Conta Azul, uma das maiores plataformas de gestão financeira para PMEs no Brasil. Atuei no time do módulo Financeiro (contas a pagar/receber, conciliação bancária e relatórios).
Product Designer responsável pelo discovery ponta a ponta: objetivos, planejamento, benchmark, entrevistas, síntese e apresentação executiva pra produto, engenharia e liderança.
Discovery completo dentro da iniciativa Financeiro 2.0, da escuta dos canais à síntese priorizada que virou base do roadmap.
PMEs olham o DRE cruzando Categoria (tipo de gasto) com Centro de Custo (departamento). Sem a feature, o cliente ou fazia contabilidade paralela no Excel ou migrava pra concorrentes como a Omie.
methodology.
Cada etapa filtrava a próxima: escuta provou o volume, benchmark mostrou o estado-da-arte, matriz CSD evitou entrevista pra confirmar hipótese óbvia, e só então as entrevistas foram a campo com roteiro afiado.
Leitura sistemática de Zendesk, Portal de Ideias e NPS, agrupando por vocabulário, frequência e intensidade da dor.
Análise comparativa de Omie, Quickbooks, Zeropaper, VHsys, ERP4Me e Vexpenses no fluxo completo de rateio.
Organização do que tínhamos em Certezas, Suposições e Dúvidas, base pro roteiro das entrevistas.
7 conversas com clientes de perfis distintos pra entender o jeito real (e quase sempre manual) como faziam rateio hoje.
Mapa da jornada do rateio cobrindo cadastros, lançamentos, conciliação, edição e análise, com pontos de fricção priorizados.
Apresentação organizada por frente de oportunidade, num formato que dava pra puxar pro roadmap sem rodada de tradução.
discovery.
O ponto de partida foi entender por que um pedido tão antigo continuava represado, e o que estava escondido por trás dos comentários repetidos de Zendesk, Portal de Ideias e NPS. O discovery foi distribuído nos seguintes passos:
Li sistematicamente comentários de Zendesk, Portal de Ideias e NPS sobre rateio, categorias e centros de custo. Agrupei por intensidade, vocabulário e frequência, o suficiente pra confirmar o volume, mas não pra explicar o porquê.
Mapeei como Omie, Quickbooks, Zeropaper, VHsys, ERP4Me e Vexpenses resolvem rateio em todo o fluxo (cadastro → lançamento → conciliação → relatórios). Identifiquei padrões (rateio por % vs valor absoluto), atalhos de UX e gaps competitivos.
Separei o que já tínhamos como certeza, o que era suposição (precisava validar) e o que era dúvida real. Isso evitou que eu fosse a campo só pra confirmar hipóteses antigas.
Conversei com 7 clientes de perfis bem distintos: empresa de desenvolvimento de software, consultoria empresarial, partner de tecnologia, instituição de ensino, escritório de contabilidade, empresa de prevenção a fraudes e instituição financeira sem fins lucrativos. A diversidade foi proposital, pra entender se a dor era transversal. Era.
Pra ratear uma única despesa entre dois Centros de Custo, o cliente precisava quebrar o lançamento em vários manualmente, perdia a visão única do financeiro e ainda assim não conseguia ratear na Conciliação nem em Vendas e Compras. Lançamentos automáticos de impostos vinham sem Centro de Custo e precisavam ser editados um por um. A consequência era previsível:
• Alto custo de tempo: semanas perdidas manutenindo planilha paralela em Excel, conferida diariamente com a Conta Azul. • Baixa padronização: cada cliente tinha um jeito próprio de contornar o problema. • Risco de erro: intervenção manual em cada lançamento. • Perda de rastreabilidade: rateios feitos fora do sistema não voltavam pros relatórios. • Barreira de uso: clientes que não dominavam Excel simplesmente abandonavam o campo Centro de Custo.
impacto real
Um escritório de contabilidade com 40 clientes mantinha 40 planilhas paralelas com regras próprias (% de faturamento, valor absoluto, número de funcionários), cruzava tudo manualmente no fim do mês e ainda entregava DRE incompleto. Cenário replicado em centenas de contas, o motivo de 'pedimos há 4 anos' ter virado dor de relacionamento com o produto.
Antes de ir a campo, estruturei um roteiro de entrevista mapeando todos os pontos do fluxo financeiro que precisava entender com o cliente, do cadastro à análise, com perguntas-chave por etapa, hipóteses pra validar, contextos pra ligar e os possíveis cenários de rateio (por Centro de Custo, por Categorias, DRE, Vendas + Financeiro). O objetivo era sair de cada conversa com clareza sobre *onde* a dor acontecia, não só *que* ela existia.
insight forte das entrevistas
Um padrão ficou muito forte na síntese: o problema não era só fazer o rateio. Os relatórios eram igualmente críticos. Os próprios clientes pediam, com todas as letras: *'Rateio de contas por centro de custo é um impedimento. Melhores relatórios também é outro'* e *'sistema de compras e centro de custos / rateio incompletos + poucas opções em customização de relatórios'*. Sem rateio refletido em relatórios confiáveis (DRE por Centro de Custo, Orçado x Realizado, Fluxo de Caixa mensal), a feature não fechava o ciclo, e essa virou uma regra inegociável do escopo.
user journey.
Mapa ponta a ponta do fluxo de rateio em 6 fases (Cadastro, Importação, Conciliação, Novo Lançamento/Rateio, Visualizar/Editar e Análise), cruzando *atividades*, *dores*, *oportunidades* e *touchpoints*. Diagnóstico visual que deixou óbvios os gargalos e onde valia investir esforço de design.
principais insights
Três insights estruturaram a priorização: o rateio manual é o maior gargalo e fonte de erro, a jornada é fragmentada e não permite visão consolidada e relatórios e análises não atendem à necessidade de gestão. Foram esses três pontos que sustentaram a conversa com Engenharia e Produto e viraram critério pra decidir o que entrava no escopo da primeira entrega.
benchmark.
Mapeei seis ERPs no fluxo ponta a ponta (cadastro → lançamento → conciliação → relatórios) pra extrair padrão, não impressão. O recorte abaixo é a versão sintética da análise, três pontos críticos que tinham que entrar (rateio %, rateio valor absoluto, refletido em relatório por Centro de Custo) e dois que diferenciavam de fato (rateio na conciliação, rateio em vendas e compras).
| Concorrente | Rateio por % | Rateio por valor | Em relatórios | Em conciliação | Em vendas/compras |
|---|---|---|---|---|---|
| Omie | Sim | Sim | Parcial | Sim | Sim |
| QuickBooks | Sim | Sim | Sim | Não | Parcial |
| VHsys | Sim | Não | Parcial | Não | Não |
| ERP4Me | Sim | Parcial | Parcial | Não | Não |
| Zeropaper | Não | Não | Não | Não | Não |
| Vexpenses | Sim | Sim | Sim | - | - |
| Conta Azul (antes) | Não | Não | Não | Não | Não |
o que extraí do benchmark
Dois padrões claros: (1) rateio por % + por valor absoluto era baseline, todo concorrente sério tinha; ficar fora disso era abertura ativa pra perder cliente. (2) Só Omie cobria conciliação e venda/compra de ponta a ponta, e era, não por acaso, o concorrente mais citado nas entrevistas como destino da migração. O gap competitivo da Conta Azul não era falta de uma feature, era falta de cobertura do fluxo inteiro.
prioritization.
As 4 frentes mapeadas (Conciliação, Novo Lançamento/Rateio, Visualizar/Editar e Relatórios) não cabiam todas na primeira release. Pra defender a sequência com produto e engenharia, cruzei três critérios, volume de dor nas entrevistas + canais, impacto em retenção (lost de migração) e esforço de engenharia, e cheguei numa P0 inegociável: rateio nativo + relatórios por Centro de Custo. Foi a combinação que apareceu junto em quase toda entrevista ("se o relatório não reflete o rateio, não resolve") e a que destravava o maior pedaço do lost.
critérios de decisão
Volume de dor
Frequência e intensidade nas entrevistas + Zendesk + Portal de Ideias + NPS.
Impacto em retenção
Quanto da frente estava vinculada a lost de migração (clientes ativamente olhando pra concorrência).
Esforço de engenharia
Custo relativo de implementação e dependências com outros módulos do Financeiro.
frentes priorizadas
Rateio nativo + Relatórios por CC
Apareceu junto em 7/7 entrevistas. Era o que sustentava decisão de negócio ("sem relatório, não resolve") e o que mais empurrava cliente pra Omie.
impacto
Alto
esforço
Médio
Rateio na Conciliação
Eliminava o pior retrabalho recorrente, mas dependia da fundação do rateio nativo estar em produção primeiro.
impacto
Alto
esforço
Alto
Centro de Custo em Vendas e Compras
Fazia o dado nascer completo na origem; ganhava força combinado com a P0, mas não era bloqueador isolado.
impacto
Médio
esforço
Médio
Visualizar / Editar (parcelas e impostos automáticos)
Cobria casos de borda críticos pra escritórios de contabilidade, mas com menor volume de menção nas entrevistas, entrava em ondas seguintes.
impacto
Médio
esforço
Alto
a decisão defendida
A defesa com a liderança foi simples: entregar P0 isolada já reduziria lost de migração, e cada frente seguinte ampliaria CSAT sem reabrir a discussão de escopo. Foi exatamente esse caminho que a engenharia puxou pro roadmap.
proposed solution.
A proposta consolidada do discovery foi tratar rateio como um conceito de primeira classe no Financeiro, disponível na Conciliação, no Novo Lançamento, em Vendas e Compras e refletido nos Relatórios. O cliente deveria conseguir ratear uma despesa por % ou por valor absoluto, em um único lançamento, com a visualização proporcional clara nas parcelas e nos lançamentos automáticos de impostos.
A base de clientes precisava de uma feature que reduzisse a fricção em todo o ciclo financeiro:
prototype decisions.
O protótipo navegável tinha dezenas de telas, mas três decisões respondiam à maioria das perguntas que apareceriam em revisão. Cada uma resolve uma regra de negócio específica do rateio, não é só visual.
Por que aninhar e não criar uma aba separada: as entrevistas mostraram que a leitura natural do gestor é *"quanto gastei em Material de Escritório, e desses, quanto foi do Financeiro vs Comercial"*, categoria primeiro, centro de custo depois. Manter a hierarquia (categoria pai → CC filhos, com valor e AV%) preservou esse modelo mental e eliminou a dobra de telas. As abas de Categorias e Centro de Custo no topo dão a inversão da visão pra quem analisa pelo recorte de departamento, sem duplicar dado.
Por que um resumo dedicado e não voltar pra tela cheia: rateio é uma operação de alto risco contábil, errar um percentual contamina relatório, DRE e fluxo de caixa por meses. O Resumo da Despesa dá uma checagem final antes do *Concluir*, com valor absoluto e percentual lado a lado em cada linha. Mostrar os dois ao mesmo tempo evita o erro clássico de *"45% disso aqui dá quanto, mesmo?"*, o usuário não precisa fazer conta mental pra confiar no que tá assinando.
**Por que rateio acontece *dentro* de uma Categoria, e não no nível da despesa inteira: essa foi a regra de negócio que mais demorou pra estabilizar no discovery. Contabilidade real funciona assim: uma despesa pode ter várias categorias (ex.: nota fiscal com Material de Escritório + Material de Limpeza), e o rateio por Centro de Custo é por categoria, porque cada categoria tem um destino contábil diferente. O modal abre a partir da categoria selecionada, mostra o valor total daquela categoria, permite ratear por % ou valor absoluto na mesma tela (com input vinculado, mexe num, atualiza o outro) e mantém visível o Restante do rateio e o Total rateado**. Isso fecha o ciclo: enquanto o restante não for 0%, o *Concluir* não libera, o sistema garante a integridade contábil que antes dependia da disciplina do usuário.
usability test.
Antes de levar o protótipo pra engenharia, rodei um teste de usabilidade estruturado com 10 tarefas que cobriam o fluxo completo: criação do lançamento, rateio por categoria, divisão entre departamentos, edição, visualização do rateio e análise de pagamentos cruzando período, categoria e centro de custo. O roteiro seguia a métrica PURE (Pragmatic Usability Rating by Experts), que avalia facilidade de uso em uma escala de 0 a 3, onde quanto menor, melhor.
9,4/10
nota geral de usabilidade
Foram avaliadas 10 tarefas relacionadas ao fluxo de lançamento, rateio por departamento e análise de pagamentos.
1,12/3
PURE médio
Escala 0-3, quanto menor, melhor
100%
Taxa de conclusão
Todas as tarefas foram finalizadas
Produto fácil de usar, com fluxo compreensível e baixa fricção.
Percepção geral
avaliação por tarefa
Criar um lançamento de compra e dividir o valor entre duas categorias: materiais de escritório e materiais de limpeza.
PURE
1,1
Leitura
A tarefa foi compreendida com facilidade. A lógica de dividir o valor por categorias ficou clara para os usuários.
Dividir a primeira categoria entre três departamentos da empresa.
PURE
1,1
Leitura
Os usuários conseguiram entender a relação entre categoria e centro de custo/departamento sem grande esforço.
Inserir os departamentos Financeiro, Comercial e Recursos Humanos na divisão.
PURE
1,0
Leitura
A seleção/inclusão dos departamentos foi direta e intuitiva.
Adicionar valores específicos para cada departamento: Financeiro, Comercial e Recursos Humanos.
PURE
1,2
Leitura
A tarefa foi concluída com sucesso. Houve apenas uma atenção maior para conferir valores e percentuais.
Repetir a divisão de departamentos para a categoria de materiais de limpeza.
PURE
1,0
Leitura
Depois de realizar a tarefa anterior, os usuários já demonstraram aprendizado do padrão de uso.
Remover o departamento Recursos Humanos da divisão de materiais de limpeza.
PURE
1,2
Leitura
A tarefa foi concluída, mas exigiu uma pequena tomada de decisão sobre onde editar ou excluir o departamento.
Visualizar como ficou o rateio dentro do lançamento.
PURE
1,1
Leitura
A tabela de rateio ajudou a validar o lançamento e deu segurança para o usuário conferir o resultado.
Acessar a Análise de Pagamentos e comparar Julho e Agosto de 2021 usando categoria, material de limpeza e centro de custo Financeiro.
PURE
1,3
Leitura
Foi a tarefa com maior complexidade por envolver filtros e análise cruzada de informações, mas ainda assim foi concluída com sucesso.
Visualizar uma análise total de um período para o setor de Recursos Humanos.
PURE
1,2
Leitura
A tarefa foi entendida, mas exige clareza nos filtros de período e departamento para evitar dúvidas.
Interpretar o resultado final da análise e confirmar se os dados apresentados fazem sentido para a tomada de decisão.
PURE
1,0
Leitura
Os usuários conseguiram compreender o resultado e identificar o valor da análise para acompanhamento dos gastos.
síntese da análise
Alta facilidade de uso nas tarefas de criação, divisão por categorias e rateio entre departamentos. Curva de aprendizado positiva: após as primeiras tarefas, os usuários repetiam o padrão com mais segurança. As telas de análise (filtros combinados por período, categoria e centro de custo) foram as mais complexas, mas todas foram concluídas com sucesso.
conclusão
PURE médio 1,12/3, conclusão 100%, nota geral 9,4/10. Ponto de atenção: hierarquia visual dos filtros combinados nas telas de análise. Fluxo geral aprovado pra seguir pro desenvolvimento.
prototype.
results.
antes
Ratear despesa
✗ Quebrar em múltiplos lançamentos manuais
Conciliação
✗ Sem rateio, campo Centro de Custo pulado
Vendas e Compras
✗ Sem campo de Centro de Custo
Impostos automáticos
✗ Editados um por um, manualmente
Relatórios
✗ Sem filtros por Centro de Custo
Realidade do cliente
✗ Planilha Excel paralela conferida todo dia
Horas por mês perdidas em retrabalho manual
depois
Ratear despesa
✓ 1 lançamento, por % ou valor absoluto
Conciliação
✓ Rateio nativo, dado nasce completo
Vendas e Compras
✓ Centro de Custo desde a origem
Impostos automáticos
✓ Rateio aplicado automaticamente
Relatórios
✓ DRE, Fluxo de Caixa e Orçado x Realizado por CC
Realidade do cliente
✓ Confiança nos relatórios do produto
Dados financeiros íntegros, decisão de negócio com base no produto
out of scope.
Três coisas que apareceram nas entrevistas mas não entraram na primeira release: (1) rateio automático por regra salva (ex.: "toda despesa de aluguel cai 40/30/30"), alto valor, mas dependia de um modelo de regras que não existia no Financeiro e abriria uma frente de produto inteira; (2) rateio em múltiplos níveis hierárquicos de Centro de Custo (CC pai com filhos), pedido por escritórios grandes, mas baixa frequência na base e custo alto de modelagem; (3) edição em lote de rateios históricos, risco contábil alto e fluxo de auditoria não estava pronto. As três viraram backlog explícito com critério de reabertura, não silêncio.
conclusion.
O Rateio deixou de ser pedido represado e virou base concreta do Financeiro 2.0. O discovery mostrou que a dor não era feature isolada, era estrutural, atravessava todo o fluxo e empurrava clientes ativamente pra concorrência. O trabalho recolocou o usuário no centro da decisão do roadmap e deu ao time uma leitura clara de onde investir esforço pra impactar retenção e satisfação.
key takeaways.
Canais existentes mostram a ponta do iceberg. Zendesk, NPS e Portal de Ideias me deram o *quanto*, mas só entrevista qualitativa revelou *como*: planilhas paralelas, conferência diária com a Conta Azul, rateio por % de faturamento e regras contábeis que ninguém registra em ticket.
Pedido represado vira dor de relacionamento. Quando o usuário diz 'pedimos há 4 anos', já não é só dor de feature, virou dor de relacionamento com o produto. Isso muda completamente a urgência da entrega e o tom da conversa com a liderança.
Discovery vira conversa de retenção. Vários entrevistados já estavam pesquisando concorrentes (Omie aparecia muito nas falas). O discovery deixou de ser conversa de UX e virou conversa de retenção e receita, o que destravou prioridade de roadmap.
CSD + benchmark antes do campo. Cruzar matriz CSD com benchmark antes das entrevistas economiza tempo de campo. Você chega na conversa perguntando só o que ainda não sabe, não o que dava pra deduzir lendo a tela do concorrente.
Formato da entrega faz parte do trabalho. Apresentar a síntese organizada por frente da jornada (e não por insight solto) faz produto, engenharia e liderança saírem da mesma sala com as decisões tomadas.
skills demonstrated.
Definição de problema, planejamento de pesquisa, escuta de canais, benchmark competitivo, matriz CSD
Entrevistas em profundidade, recrutamento de perfis diversos, síntese qualitativa, mapa de jornada
Priorização por frente, conexão entre dor de usuário e métrica de negócio (lost, satisfação)
Apresentação executiva, tradução de pesquisa em roadmap acionável pra produto, engenharia e liderança
Trabalho lado a lado com PM, engenharia, customer success e time de pesquisa
Protótipos navegáveis no Figma pra validar fluxo proposto e dar tangibilidade à entrega do discovery
stack.
thanks for reading.
Quer entender melhor como conduzo discovery? Vamos conversar.
Ver mais casesOutros cases
