Customers do billing, companies do CRM, contas do produto e tickets
Cascata de chaves, da mais forte para a mais fraca
Uma linha por cliente com o id de cada sistema
MRR, health score, agente de IA e CRM
O que resolve
- Receita, uso, tickets e negócios do CRM passam a se cruzar pela mesma chave.
- Cada vínculo diz como foi feito, então dá para confiar ou auditar.
- O mesmo cliente para de ser contado duas vezes, e dois clientes param de virar um só.
Perguntas de negócio que responde
Faça estas perguntas ao seu agente quando o caso estiver pronto.
O que você precisa
- Billing, CRM e banco do produto conectados na Nekt
- Um campo que guarde o id de um sistema dentro do outro, ou o CNPJ preenchido
- Um dono para as correções manuais de vínculo
O que você recebe
- Uma tabela de clientes canônicos com o id de cada sistema
- A coluna de método e qualidade de cada vínculo
- Filas de qualidade: pagantes sem CRM, CRM sem pagante, conflitos de CNPJ
- Um agente de IA que encontra o cliente por qualquer id
Onde ativar
MRR, health score, comissão e suporte por cliente leem a mesma tabela de identidade.
Encontra o cliente por qualquer id, CNPJ ou e-mail e responde com receita, uso e tickets juntos.
Lista semanal de pagantes sem CRM, deals ganhos sem pagante e conflitos de documento para o dono corrigir na origem.
A regra é simples. O trabalho está em achar a chave estável entre os sistemas e manter as correções manuais em dia. O detalhado traz as regras de negócio, as armadilhas e o teste de aceitação. Ou mande tudo direto para o seu agente com o MCP da Nekt.
Cada sistema identifica o cliente do seu jeito: o billing por customer, o CRM por company e deal, o produto por workspace e o suporte por e-mail. Quem cruza por nome ou por domínio de e-mail casa empresas diferentes que usam gmail e separa a mesma empresa que tem dois CNPJs. Quando o mapa é regravado em vez de atualizado, clientes diferentes acabam fundidos e a receita de um aparece no outro.
Como costuma ser feito, e a regra
Cada linha é um erro que já aconteceu na prática.
Crie uma chave própria de cliente e uma ponte por sistema (customer do billing, company do CRM, workspace do produto, organização do suporte). O cliente canônico é a conta econômica que paga, não o usuário nem a assinatura. Guarde em cada linha como o vínculo foi feito (linked_via ou match_method) e um nível de confiança.
1) Id de um sistema gravado no outro (id da assinatura no deal, id do customer na conta do produto, id do produto em atributo customizado do suporte). 2) CNPJ só com dígitos. 3) Domínio de e-mail corporativo. 4) Nome normalizado, só como último recurso e marcado como fraco. A primeira regra que casar decide.
Remova tudo que não é dígito e complete com zeros à esquerda até 14 dígitos. CNPJ guardado como número perde o zero inicial e não casa. Documento com 11 dígitos ou menos é CPF.
Descarte gmail, hotmail, outlook, yahoo, icloud, uol e similares antes de casar por domínio. Para esses, a chave é o e-mail inteiro. Normalize o e-mail com minúsculas e sem espaços; no Gmail, ignore pontos e o sufixo +alias.
Nome é útil para sugerir um vínculo, não para confirmar. Se houver casamento aproximado, normalize (sem acento, sem ltda, me, epp, eireli, sa) e exija pelo menos 5 caracteres e 2 palavras. Quando existe identificador estável, ele vence o nome.
Uma empresa pode ter várias sub-contas pagando (várias assinaturas, vários CNPJs do grupo). Diga em cada métrica qual grão ela usa. Somar as sub-contas pode mudar a faixa do cliente e quem o CS atende. No grupo com vários CNPJs, o principal é o de maior MRR, para a identidade não mudar sem motivo.
Defina a precedência de status. Em geral, o billing ou o produto manda sobre o CRM, que fica desatualizado: numa base real, havia três vezes mais companies marcadas como churn no CRM do que workspaces inativos no produto.
A ponte deve ter um id canônico por CNPJ e por id externo, mantendo o vínculo mais antigo. Uma ponte gravada por append em vez de upsert criou linhas conflitantes e fundiu clientes diferentes, levando a receita de um para o outro. Guarde a ponte com válido de e válido até quando o vínculo muda.
Vínculos que nenhuma regra resolve vão para uma tabela de sobrescritas com o id, a data, quem confirmou e o motivo, aplicada antes da cascata. Sempre que possível, corrija também na origem (o CNPJ ou o id no CRM).
Contas de teste, demo e e-mails da própria empresa saem do mapa. No mapa de usuário para conta, usuários de serviço e integrações não podem ligar uma conta à outra. Em eventos de produto, resolva a conta em cascata: id da conta no evento, depois workspace para conta, depois usuário para conta.
Chaves de vínculo por ordem de confiança
A primeira que casar decide. Grave qual foi na coluna de método.
Definições
Armadilhas que já aconteceram
O mapa de identidade foi gravado por append durante semanas, ganhou dois ids para o mesmo CNPJ e passou a fundir clientes diferentes no relatório de receita.
Grave a ponte por upsert, com um id canônico por CNPJ e o vínculo mais antigo vencendo.
A qualificação de leads era medida por empresa e a receita por sub-conta. Empresas com várias sub-contas mudavam de faixa quando as irmãs eram somadas.
Crie a conta empresa como verdade adicional e diga em cada métrica qual grão ela usa.
O CRM tinha muito mais companies marcadas como perdidas do que workspaces de fato inativos, e os relatórios de churn divergiam.
Defina que billing ou produto manda e corrija o CRM a partir deles.
Um cliente com três produtos tinha três deals ganhos e aparecia como três clientes no relatório comercial.
Ligue deal à assinatura e conte clientes pelo id do customer, não pelo deal.
Tickets chegavam só com e-mail ou telefone e ficavam fora do health score.
Ligue pelo e-mail do contato, depois pelo domínio corporativo, e meça a fatia de tickets sem cliente.
Teste de aceitação
O caso está pronto quando todos os itens passam.
- Cada id externo (customer, company, workspace) aparece em no máximo um cliente canônico.
- Nenhum cliente canônico tem dois CNPJs que não estejam declarados como mesmo grupo econômico.
- O MRR somado pelos clientes canônicos é igual ao MRR total do billing no mesmo dia.
- Pelo menos 95% do MRR tem vínculo forte (id gravado ou CNPJ) com o CRM, e a lista do restante existe com o motivo.
- Nenhum cliente canônico é formado só por um domínio de e-mail pessoal.
Pacote para o agente
Cole no Claude, ChatGPT ou outro cliente com o MCP da Nekt conectado.
Identidade do cliente - Cliente = conta econômica que paga. Use a chave canônica da tabela de identidade, nunca o nome da empresa. - Para ligar sistemas, use a tabela de identidade. A ordem de confiança é: id gravado em outro sistema > CNPJ (só dígitos, 14 posições) > domínio de e-mail corporativo > nome normalizado. - E-mail pessoal (gmail, hotmail, outlook, yahoo, icloud, uol) nunca é chave de empresa. - Vínculo por nome é fraco: avise quando a resposta depende dele. - Conta = a empresa. Sub-conta = cada customer ou assinatura que paga. Diga qual grão está usando. - Status do cliente vem do billing ou do produto, não do CRM. - Contas internas, de teste, de demo e usuários de serviço não são clientes. - Se um id não estiver na tabela de identidade, diga que o cliente não foi vinculado em vez de adivinhar. Exceções por cliente: - <cliente>: grupo econômico com os CNPJs <lista>, consolidado no CNPJ <principal>. - <cliente>: vínculo manual entre a conta <id produto> e a assinatura <id billing>, confirmado em <data>.
Construa no meu workspace Nekt o caso "Cliente único entre billing, CRM, produto e suporte" seguindo as regras em https://academy.nekt.com/industrias/saas/cliente-unico-billing-crm-produto.md. 1) Encontre as tabelas de origem e confirme as colunas usadas pelas regras. 2) Crie uma transformação no grão indicado aplicando todas as regras. 3) Rode o teste de aceitação e me mostre o resultado de cada item. 4) Crie o context document do caso no workspace, com as exceções dos meus clientes em aberto para eu preencher.
Variações
Grave o id do cliente canônico e o MRR na company do CRM para vendas e CS trabalharem com a mesma chave.
Para contatos sem id, um modelo de deduplicação com regra negativa: nenhum grupo pode ter dois CPFs distintos.
Sem CNPJ, a chave é o e-mail canônico. Para vários customers com o mesmo e-mail, some receita por pessoa.