Arquitetura de dados de receita: o desenho em 30 dias

A arquitetura de dados de receita é o desenho que diz em qual sistema mora cada entidade da operação comercial, como conta, contato, negócio, pedido, contrato e ticket, qual chave identifica o mesmo cliente em todos os sistemas, para onde cada dado viaja e com que frequência. Sem esse desenho, cada área responde pela própria versão da verdade, e a diretoria passa a reunião discutindo qual número está certo. O custo chega ao caixa: na pesquisa de cultura e alfabetização em dados da Forrester de 2023, mais de um quarto dos profissionais de dados e analytics que apontam a má qualidade dos dados como obstáculo estimaram perder mais de 5 milhões de dólares por ano, e 7% falaram em 25 milhões ou mais (Forrester, 2024). Desenhar a arquitetura não exige comprar sistema. Exige que a diretoria decida, entidade por entidade, quem é dono, e sustente a decisão no dia em que uma área quiser editar o que pertence a outra.

Num exemplo hipotético, o diretor comercial apresenta R$ 2,4 milhões de receita nova no trimestre, a soma dos negócios ganhos no CRM. O financeiro mostra R$ 1,9 milhão no ERP, porque R$ 300 mil foram assinados na última semana e ainda não faturaram, e outros R$ 200 mil têm a primeira parcela prevista para o trimestre seguinte. A planilha do pós-venda traz R$ 2,2 milhões, porque exclui dois contratos de R$ 100 mil que os clientes cancelaram durante a implantação e que o CRM ainda mostra como ganhos. Os três números estão corretos pela regra de cada área, e a reunião gasta quarenta minutos reconciliando. O Gartner aponta a inconsistência entre fontes, resultado de dados guardados em silos com sobreposições e lacunas, como o problema de qualidade de dados mais difícil de enfrentar (Gartner, 2024).

O que é arquitetura de dados de receita?

Arquitetura de dados de receita é o conjunto de decisões que organiza a informação de marketing, vendas, financeiro e pós-venda em torno das mesmas entidades. Entidade, nesse contexto, é cada tipo de coisa que a operação registra e conta: a empresa cliente, a pessoa com quem você fala, a oportunidade em negociação, o pedido faturado, o contrato assinado e o chamado aberto. O desenho tem cinco partes: o sistema dono de cada entidade, os sistemas que a leem, a chave que liga os registros, a frequência das sincronizações e a camada onde a diretoria consome os números.

A escolha das ferramentas fica em outro documento: em stack de vendas eu trato das camadas, do dado que cada ferramenta devolve ao CRM e do critério para cortar licenças. A arquitetura vale para qualquer combinação de ferramentas e responde a outra pergunta: quando o mesmo cliente aparece em seis sistemas, qual registro vale, como você sabe que é o mesmo cliente e em quanto tempo uma mudança chega aos outros.

Quais sistemas entram na arquitetura de dados?

Entram todos os lugares onde alguém registra informação que depois vira número de diretoria. O CRM guarda o relacionamento comercial, a automação de marketing guarda origem do lead e consentimento, e o ERP guarda cadastro fiscal, pedidos, notas e pagamentos. A ferramenta de atendimento guarda chamados, e o sistema do produto, quando a empresa vende software ou serviço com uso medido, guarda quem usa e quanto.

Duas peças costumam ficar fora do mapa e são as que mais distorcem o resultado. A primeira são as planilhas: a carteira do pós-venda e o controle de comissões funcionam como sistemas, com dono e regra própria, e a arquitetura decide se cada uma vira fonte oficial, migra para um sistema ou sai de circulação. A segunda é o BI, a camada de análise que cruza os sistemas e publica os painéis. O BI só lê e não é dono de entidade nenhuma, e a correção feita direto no painel some na próxima carga.

Qual é a fonte da verdade de cada entidade?

Fonte da verdade, ou sistema de registro, é o sistema onde a entidade nasce, onde as alterações oficiais acontecem e cuja versão prevalece quando dois sistemas discordam. A regra que sustenta o desenho é um dono por entidade, ou por grupo de atributos dentro dela. Os outros sistemas leem e podem exibir a informação, sem editar. A tabela abaixo é o instrumento que eu levo para a primeira reunião com a diretoria e que as lideranças preenchem com os sistemas da própria empresa.

Entidade	O que representa	Sistema dono	Sistemas que leem	Chave	Frequência
Conta	A empresa cliente ou prospect	CRM para dados comerciais; ERP para razão social, CNPJ e endereço fiscal	Automação, atendimento, produto e BI	ID mestre do cliente, com CNPJ	Na criação e diária
Contato	A pessoa na empresa cliente	CRM; automação para consentimento	Automação, atendimento e conversação	E-mail corporativo	Contínua
Negócio	A oportunidade em negociação	CRM	BI e propostas	ID do negócio no CRM	Contínua
Pedido	O que foi vendido e vai ser faturado	ERP	CRM e BI	Número do pedido, com ID do negócio de origem	No ganho e diária
Contrato	Vigência, valor, reajuste e condições	Ferramenta de assinatura ou jurídico, com cópia no ERP	CRM, ERP, atendimento e BI	Número do contrato, com ID mestre do cliente	Na assinatura
Ticket	O chamado aberto pelo cliente	Ferramenta de atendimento	CRM e BI	ID do ticket, com ID mestre do cliente	Diária
Uso do produto	O que o cliente faz no produto ou serviço	Sistema do produto	CRM, atendimento e BI	ID mestre do cliente	Diária
Fatura e pagamento	Nota emitida, vencimento e baixa	ERP	CRM, atendimento e BI	Número da nota, com número do pedido	Diária

Cada linha leva minutos para preencher e às vezes uma semana para aprovar, porque encerra uma disputa entre áreas. Comece pelas entidades que aparecem nos números da diretoria.

Quando a entidade tem dois donos

A conta é o caso clássico de dono dividido. O ERP manda nos atributos fiscais, porque a nota sai com a razão social e o CNPJ que o financeiro validou, e o CRM manda nos atributos comerciais, como segmento, porte, dono da carteira e estágio do cliente. A divisão funciona quando está escrita atributo por atributo e a integração respeita a direção: o vendedor encontra a razão social bloqueada no CRM e pede a correção ao financeiro. Sem essa trava, a carga seguinte devolve o valor antigo, e o time conclui que o sistema não funciona.

Pedido e contrato contam receitas diferentes

O contrato diz quanto o cliente se comprometeu a pagar e por quanto tempo, e alimenta a receita contratada e a renovação. O pedido diz o que vai ser faturado e quando, e alimenta a receita faturada e o caixa. A diretoria precisa dos dois números com nomes diferentes, e a arquitetura liga cada pedido ao contrato e ao negócio de origem, para você explicar a diferença sem montar planilha. O percurso do negócio ganho até o primeiro pagamento está detalhado em lead to cash.

Como definir a chave única do cliente?

A chave única do cliente é o identificador que permite afirmar que o registro do CRM, o cadastro do ERP, a conta da ferramenta de atendimento e o usuário do produto são a mesma empresa. Sem ela, o BI cruza os sistemas pelo nome, e “Grupo Alfa Ltda.”, “Alfa” e “ALFA INDUSTRIA” viram três clientes. No B2B brasileiro, o CNPJ é o ponto de partida natural, e ele sozinho não resolve o problema.

Os oito primeiros caracteres do CNPJ identificam a empresa, os quatro seguintes identificam o estabelecimento e os dois últimos são dígitos verificadores. Um cliente com matriz e quatro filiais tem cinco CNPJs, e a diretoria precisa decidir se conta um cliente ou cinco. Grupos econômicos complicam mais, porque empresas com raízes diferentes podem responder ao mesmo comprador. Eu recomendo criar um ID mestre do cliente, gerado por um único sistema, em geral o CRM ou o ERP, e uma tabela de correspondência que guarda, para cada ID mestre, os identificadores do mesmo cliente em cada sistema. O CNPJ entra como atributo validado, a raiz agrupa os estabelecimentos e um campo de grupo econômico liga as empresas que compram juntas.

O formato do campo também pede revisão agora. A Receita Federal começou a atribuir, a partir de julho de 2026, o CNPJ alfanumérico às novas inscrições, e os números já existentes continuam válidos sem alteração (Receita Federal, 2024). Um campo de CNPJ configurado para aceitar só números, ou uma integração que trata o CNPJ como número, recusa o cadastro de clientes abertos depois dessa data. Para contatos, a chave é o e-mail corporativo, e as regras de cadastro e deduplicação que mantêm essas chaves limpas estão em qualidade de dados no CRM.

Com que frequência cada sistema deve sincronizar?

A frequência certa depende do tempo que a decisão apoiada naquele dado aguenta esperar. Tempo real custa mais, quebra com mais facilidade e só se paga quando alguém age sobre o dado em minutos.

Padrão	Como funciona	Quando usar	Exemplo na operação
Por evento	O sistema dono envia a mudança no momento em que ela acontece	A próxima pessoa precisa agir em minutos	Lead novo que entra na fila do SDR; negócio ganho que cria o pedido no ERP
A cada hora	Uma rotina busca as alterações da última hora	A informação orienta o trabalho do dia	Chamado crítico aberto que aparece no registro da conta para o vendedor
Diária	Uma carga noturna leva o dia inteiro de uma vez	A decisão acontece na reunião da semana ou do mês	Pagamentos, inadimplência e uso do produto para o BI e o CRM
Fotografia de fechamento	O BI congela os números num horário combinado	O número oficial do período precisa ser o mesmo para todos	Receita do mês congelada no primeiro dia útil às 10h

A última linha resolve uma divergência que pouca gente percebe: se o comercial tira o relatório às 9h e o financeiro às 15h, os dois números diferem pelo que entrou no meio do caminho. A fotografia publicada no BI, com horário escrito, dá à diretoria um número oficial por período.

O que acontece quando não há arquitetura de dados?

A divergência na reunião de diretoria tem três causas, e cada uma pede uma correção diferente. A primeira é a definição: “cliente ativo” significa contrato vigente para o pós-venda, fatura paga nos últimos noventa dias para o financeiro e negócio ganho para o comercial. A segunda é a chave, que leva o mesmo cliente a aparecer duas vezes numa base e nenhuma na outra. A terceira é o tempo, com sistemas sincronizados em horários diferentes ou sem sincronização nenhuma. A arquitetura ataca as duas últimas, e a definição de cada indicador fica registrada na matriz de métricas, como descrevo em métricas de RevOps.

O efeito mais caro aparece nas decisões. A diretoria adia a contratação porque não confia na previsão, e o marketing perde verba porque não consegue provar a receita por origem. Quando o número da tela diverge da planilha da véspera, a liderança volta à planilha, e o dashboard comercial passa a decorar a sala.

A inteligência artificial encarece a falta de desenho. O agente que resume a conta antes da ligação lê CRM, ERP e atendimento, e se a chave não liga os três, ele resume metade do cliente com toda a confiança. Numa pesquisa com 1.203 líderes de gestão de dados feita em julho de 2024, 63% das organizações disseram não ter, ou não saber se têm, as práticas de gestão de dados adequadas para IA, e o Gartner prevê que, até 2026, as organizações vão abandonar 60% dos projetos de IA sem dados preparados para IA (Gartner, 2025).

Quem é dono da arquitetura de dados de receita?

A arquitetura precisa de um patrocinador na diretoria, porque cada linha do mapa tira poder de edição de alguém, e só a diretoria arbitra essa disputa. Cada entidade tem um dono de negócio, a área do processo onde o dado nasce, e operações de receita mantém o mapa enquanto a TI implementa integrações e BI. Nos diagnósticos que conduzo, a arquitetura que se sustenta é a que tem o nome de cada dono escrito no próprio mapa, com a data da última revisão.

Papel	Quem costuma ser	Responde por	Aprova
Patrocinador	Diretor de receita, CEO ou CFO	Arbitrar conflitos entre áreas e cobrar o mapa na reunião de diretoria	O mapa de entidades e as definições oficiais
Dono da entidade	Liderança da área onde o dado nasce: vendas para negócio, financeiro para pedido e fatura, pós-venda para ticket	Regras de cadastro, atributos obrigatórios e correções da entidade	Mudanças nos atributos da própria entidade
Arquiteto da operação	Operações de receita	Desenhar e manter o mapa, a tabela de correspondência e a frequência de cada fluxo	Novas integrações e novos campos que atravessam sistemas
Implementação técnica	TI ou time de dados	Integrações, segurança, acesso e cargas do BI	Fornecedores e a forma técnica de cada fluxo
Responsável pela base	Administrador do CRM ou analista de operações	Deduplicação, tabela de correspondência e erros das integrações	Importações e mesclagens
Usuários	Vendedores, analistas, atendentes e financeiro	Registrar no sistema dono e pedir correção ao dono da entidade	Nada; sinalizam problemas

Em empresas menores, uma pessoa de operações acumula os papéis de arquiteto e de responsável pela base, e a TI pode ser um fornecedor externo, mas o patrocinador continua indispensável. A estrutura do time que sustenta esse trabalho está em time de RevOps.

Erros comuns ao desenhar a arquitetura de dados

Começar pelo BI

A empresa contrata a ferramenta de BI esperando que ela reconcilie os números. Se os sistemas não compartilham chave nem definição, o painel novo mostra a mesma divergência com gráficos melhores, por isso o mapa e a chave vêm antes de qualquer painel.

Dois sistemas editando a mesma entidade

A integração nos dois sentidos parece a mais completa e cria uma disputa permanente: a correção feita no CRM volta ao valor antigo quando o ERP sincroniza. Cada atributo precisa de um único sistema que edita, com os outros só lendo.

Usar o nome da empresa como chave

O nome muda com fusão, com troca de nome fantasia e com a digitação de cada pessoa. O cruzamento pelo nome perde clientes e cria duplicados que o responsável pela base leva semanas para corrigir.

Sincronizar tudo em tempo real

Tempo real em todos os fluxos multiplica custo e falhas, e a maior parte das decisões da diretoria acontece em reunião semanal ou mensal. Reserve o envio por evento para quem age em minutos e use carga diária no resto.

Desenhar sem o financeiro

Projetos conduzidos só por marketing e vendas param no pedido e no contrato, que pertencem a outra diretoria. O financeiro entra desde a primeira reunião, porque é dono das entidades que fecham a conta da receita, e as planilhas dele entram no mapa como sistemas.

Como preparar o time para sustentar a arquitetura?

O mapa vira rotina quando cada pessoa sabe em qual sistema registra e a quem pede correção. As lideranças aprendem a ler o mapa e a cobrar o número oficial na reunião, recusando a planilha paralela. O responsável pela base e a pessoa de operações aprendem a manter a tabela de correspondência e a revisar os erros de integração. Vendedores, analistas e atendentes precisam de uma sessão curta, no sistema da empresa, sobre os campos bloqueados e o caminho da correção. Nas operações que acompanho, a resistência maior vem de quem perdeu a permissão de editar um campo, e a explicação do motivo, feita pelo próprio dono da entidade, resolve mais do que qualquer bloqueio técnico.

Roteiro de 30 dias para a liderança

Em quatro semanas a liderança desenha e decide, e a implementação das integrações fica para o trimestre seguinte, com o mapa aprovado.

1. Dias 1 a 3: nomeie o patrocinador e quem conduz o desenho. A diretoria comunica às áreas que o mapa terá força de regra.
2. Dias 4 a 7: rode o teste do número da diretoria. Classifique cada diferença entre as áreas por definição, chave ou horário.
3. Dias 8 a 12: liste sistemas e planilhas. Inclua toda planilha que alimenta reunião de liderança, com dono.
4. Dias 13 a 17: preencha o mapa de entidades. Defina sistema dono, leitores, chave e frequência, com o dono de cada área presente.
5. Dias 18 a 20: decida a chave única do cliente. Escolha quem gera o ID mestre, a regra de matriz, filial e grupo, e o formato do CNPJ.
6. Dias 21 a 24: fixe as frequências e o horário da fotografia de fechamento. Escreva o horário oficial de cada número de diretoria.
7. Dias 25 a 27: nomeie os donos e aprove o mapa. O patrocinador arbitra as linhas em disputa.
8. Dias 28 a 30: planeje implementação e formação. Ordene as integrações pelo impacto nos números de diretoria e marque as sessões de cada perfil.

Se a sua diretoria passa a reunião reconciliando números em vez de decidir, esse é o trabalho do treinamento in company de Revenue Operations. Eu conduzo a formação com as lideranças de marketing, vendas, pós-venda, financeiro e TI na mesma sala, sobre os sistemas e os números da sua operação. A turma sai com o SLA entre marketing, vendas e CS, que define o que cada área entrega à outra, e com a matriz de métricas de RevOps, que registra a definição de cada indicador e o sistema de onde ele sai, a base para o mapa de entidades.

Perguntas frequentes

O que é arquitetura de dados de receita?

É o desenho que define em qual sistema mora cada entidade da operação comercial, como conta, contato, negócio, pedido, contrato e ticket, quais sistemas leem cada uma, qual chave identifica o mesmo cliente em todos eles e com que frequência os dados sincronizam. Com ela, a diretoria trabalha com um número oficial por indicador.

O CRM deve ser a fonte da verdade de tudo?

O CRM é a fonte da verdade do relacionamento comercial, com contatos, negócios, atividades e dono da carteira. Pedido, fatura e pagamento pertencem ao ERP, e chamados pertencem à ferramenta de atendimento. O CRM exibe esses dados no registro do cliente sem editá-los.

Qual é a melhor chave única para clientes B2B no Brasil?

Um ID mestre gerado por um único sistema, com o CNPJ como atributo validado e uma tabela de correspondência com os identificadores do cliente em cada sistema. A raiz do CNPJ agrupa matriz e filiais, e um campo de grupo econômico liga empresas diferentes que compram juntas. O campo de CNPJ precisa aceitar letras desde a chegada do formato alfanumérico.

Preciso de um data warehouse para ter arquitetura de dados?

A arquitetura vem antes da ferramenta e funciona com os sistemas que a empresa já tem. O data warehouse, um banco que reúne os dados de vários sistemas para análise, ajuda quando o volume e o número de fontes crescem, e ele herda os problemas de chave e definição se o mapa não existir.

Quem deve aprovar o mapa de entidades?

O patrocinador na diretoria aprova o mapa e arbitra as linhas em disputa, e cada dono de entidade aprova as regras da sua. Operações de receita conduz o desenho e mantém o documento atualizado, e a TI valida a viabilidade técnica de cada fluxo.

Como preparar o time para trabalhar com a nova arquitetura?

Comece pelas lideranças, que precisam ler o mapa e cobrar o número oficial na reunião. Depois forme o responsável pela base e a pessoa de operações na manutenção da chave e das integrações, e faça sessões curtas com cada perfil de usuário sobre onde registrar e a quem pedir correção. Meça pelas planilhas paralelas que deixam de circular e pelo tempo gasto em reconciliação na reunião de diretoria.