CRM, sistema acadêmico, financeiro e marketing
Chave forte primeiro, documento validado, pessoa nunca no lugar do contrato
Status de conciliação por venda, matrícula e pagamento
Painel de aquisição, auditoria e agente de IA
O que resolve
- Cada venda do CRM tem a matrícula e o pagamento correspondentes, ou um motivo explícito para não ter.
- Matrículas sem negociação no CRM aparecem, em vez de sumirem do funil.
- A origem de cada matrícula é atribuída por evidência, com a mesma identidade de pessoa nos três sistemas.
Perguntas de negócio que responde
Faça estas perguntas ao seu agente quando o caso estiver pronto.
O que você precisa
- CRM, sistema acadêmico e financeiro conectados na Nekt (o acadêmico pode vir de uma consulta preparada ou planilha)
- Uma chave acadêmica no CRM, como o RA, preenchida antes de marcar a venda
- A regra da escola: uma venda gera uma matrícula, ou várias
O que você recebe
- Uma tabela por negócio ganho com matrícula vinculada, método de vínculo e status de conciliação
- Uma dimensão de pessoa e de cliente com documento validado e identificadores dos três sistemas
- Painel de aquisição com origem da matrícula e pendências de conciliação
- Um agente de IA que explica a divergência de um caso específico
Onde ativar
Venda, matrícula e pagamento lado a lado, com origem e status de conciliação por período letivo.
Vendas sem matrícula e matrículas sem venda para o time comercial e a secretaria revisarem.
Investiga um caso: mostra o negócio, a matrícula, os títulos e por qual chave cada um casou.
Três ou quatro fontes sem chave comum. Comece pela chave acadêmica no CRM e pela regra de documento válido. 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.
O CRM registra a negociação com o responsável, o sistema acadêmico registra o aluno e o financeiro registra quem pagou. Não há chave comum, e os campos de ligação são preenchidos à mão. Quem cruza por nome ou por qualquer documento cola venda no cliente errado; quem cruza por pessoa parte o contrato em dois quando o pai paga pelo filho.
Como costuma ser feito, e a regra
Cada linha é um erro que já aconteceu na prática.
CRM = processo comercial (negociação, vendedor, etapa). Sistema acadêmico = matrícula oficial, aluno, turma, contrato e situação. Financeiro = título, pagador e pagamento. Marketing = origem e campanha. Um não prova o outro: negócio ganho não comprova matrícula, e pode haver matrícula sem negociação no CRM.
Ligue o contas a receber pelo id do contrato ou da venda, nunca pela pessoa. O pagador (pai, mãe, empresa) muitas vezes é diferente do titular e do aluno; juntar por pessoa e contrato parte o mesmo contrato em duas linhas. Exponha o pagador como coluna.
Se o CRM tem o RA do aluno num campo do negócio, vincule os dados acadêmicos só quando o RA é único nas duas fontes. RA é texto: preserve zeros à esquerda e nunca converta para número. RA repetido fica sem vínculo e com motivo.
Tente em ordem: id do negócio gravado no financeiro (por exemplo, `numero_documento` no Omie), depois CPF ou CNPJ validado com produto compatível, depois e-mail e telefone normalizados. Grave em cada linha qual método casou.
Limpe tudo que não for dígito. Só vira chave CPF com 11 dígitos ou CNPJ com 14. Qualquer outro tamanho é digitação errada: trate como sem documento e não tente casar, para não grudar a venda no cliente errado.
E-mail: minúsculo e sem espaços. Telefone: só dígitos e remova o DDI 55 apenas quando sobrar mais de 11 dígitos. Use uma única tabela de referência de telefone por pessoa; duas lógicas diferentes já cortaram o DDD achando que era DDI.
Saber que é a mesma pessoa não diz que é a mesma venda: um aluno pode ter várias matrículas e um responsável vários filhos. Mantenha uma linha por negócio ganho e separe o vínculo de identidade (é a mesma pessoa) da conciliação (é esta matrícula, desta venda).
Classifique cada caso: conciliado, só no CRM, só no acadêmico, só no financeiro ou ambíguo. Matrícula sem negociação não é erro automático (rematrícula, balcão, empresa); é uma categoria para o time revisar.
A origem da matrícula vem da evidência mais forte da mesma pessoa: UTM do marketing, depois tag e canal do atendimento, depois o campo de origem do CRM. Recupere UTMs embutidas em `traffic_source` e em payloads codificados. Quando a fonte guarda só a origem de entrada, o modelo é origem única, não multitoque: declare isso.
Origem tem dezenas de grafias para o mesmo evento. Use uma tabela de-para valor bruto para origem padronizada e outra origem para canal esperado, que audita o canal escolhido à mão. Campos que misturam vários tipos de informação ficam fora da atribuição.
Qual sistema responde o quê
E qual chave liga cada um.
Definições
Armadilhas que já aconteceram
Centenas de negócios tinham o campo CNPJ preenchido com tamanho errado e casavam com o cliente errado.
Só aceite 11 ou 14 dígitos depois de limpar; o resto vira sem documento.
Ao juntar financeiro por pessoa, milhares de contratos em que o responsável pagava pelo aluno viraram duas linhas e a receita duplicou.
Ligue o contas a receber só pelo id do contrato.
Parte dos títulos do financeiro não tinha o número do contrato, e o cruzamento por documento sozinho pegava a parcela errada.
Case por documento + data de pagamento + data de emissão + valor, e exclua outliers manuais documentados antes da camada confiável.
Clientes cobrados por um gateway não conectado apareciam como sem pagamento e geravam falso alerta.
Confira o campo de plataforma de pagamento do negócio antes de tratar ausência como problema.
Quem usou um e-mail no formulário e outro na compra aparecia como venda fora do funil, subestimando o retorno da captação.
Mantenha um dicionário de identificadores por pessoa (e-mails, ids do CRM e da plataforma de venda) e declare o limite.
Centenas de campanhas existiam só na UTM dos leads, sem gasto registrado em nenhuma plataforma de mídia.
Una as campanhas das plataformas com as UTMs numa dimensão com chave sintética e marque quais não têm custo.
Teste de aceitação
O caso está pronto quando todos os itens passam.
- Cada negócio ganho do período aparece exatamente uma vez, e a soma dos status de conciliação é igual ao total de vendas.
- Toda matrícula oficial do período tem um status: vinculada a uma venda ou matrícula sem negociação.
- Nenhum vínculo usa documento com tamanho diferente de 11 ou 14 dígitos.
- A soma do financeiro por contrato é igual ao total do financeiro no mesmo recorte, inclusive nos contratos com pagador diferente do titular.
- Todo RA mantém o mesmo número de caracteres da fonte acadêmica, com zeros à esquerda.
Pacote para o agente
Cole no Claude, ChatGPT ou outro cliente com o MCP da Nekt conectado.
Conciliação de venda, matrícula e pagamento - CRM = processo comercial. Sistema acadêmico = matrícula oficial, aluno, turma e situação. Financeiro = título, pagador e pagamento. Marketing = origem e campanha. - Negócio ganho não comprova matrícula. Pode haver matrícula sem negociação no CRM. - Lead, responsável financeiro e aluno podem ser pessoas diferentes. Não chame contato do CRM de aluno. - Financeiro se liga à venda pelo id do contrato, nunca pela pessoa. O pagador fica em coluna própria. - RA é texto: preserve zeros à esquerda. Vínculo acadêmico só com RA único nas duas fontes. - Ordem de vínculo: id do negócio no financeiro, documento validado com produto compatível, e-mail e telefone normalizados. Registre metodo_match. - Documento válido: CPF com 11 dígitos ou CNPJ com 14 depois de limpar. Outros tamanhos = sem documento. - Telefone: só dígitos; remover DDI 55 apenas com mais de 11 dígitos. E-mail minúsculo e sem espaços. - Status de conciliação: conciliado, só CRM, só acadêmico, só financeiro, ambíguo. - Origem da matrícula: UTM do marketing, depois tag do atendimento, depois campo de origem do CRM. Modelo de origem única, não multitoque. Exceções por cliente: - <cliente>: o RA é gravado no campo <campo> do negócio antes de marcar a venda. - <cliente>: o id do negócio é digitado no campo <campo> do financeiro. - <cliente>: uma venda gera <n> matrículas (uma por turma ou disciplina).
Construa no meu workspace Nekt o caso "Venda, matrícula e pagamento conciliados" seguindo as regras em https://academy.nekt.com/industrias/educacao/conciliacao-crm-sistema-academico-financeiro.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
Plataforma de venda no lugar do acadêmico: pessoa = e-mail normalizado, com dicionário de e-mails e ids da plataforma e do CRM.
Contrato com vários itens (curso, acomodação, seguro, aéreo): conte contratos distintos e ligue o financeiro pelo contrato.
Cliente = CNPJ validado, nome canônico vindo do financeiro, depois da cobrança, depois do CRM.