--- id: educacao/conciliacao-crm-sistema-academico-financeiro industria: Educação uso: muito usado esforco: alto grao: Negócio ganho, matrícula e contrato --- # Venda, matrícula e pagamento conciliados Cada venda do CRM ligada à matrícula oficial e ao que foi pago, mesmo quando quem negociou, quem paga e quem estuda são pessoas diferentes. ## Resumo executivo **Para quem:** Escolas, faculdades e empresas de educação em que a venda acontece no CRM, a matrícula no sistema acadêmico e a cobrança no financeiro. **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. **Por que importa:** Na educação, lead, responsável financeiro e aluno costumam ser pessoas diferentes, e cada sistema guarda uma delas. Sem conciliação, o CRM diz que vendeu, o acadêmico diz outra coisa e o financeiro não fecha com nenhum dos dois. É a base para CAC por matrícula, comissão de vendedor e qualquer resposta confiável sobre aquisição. **Perguntas de negócio que responde** - Quantas matrículas do semestre não têm negociação no CRM? - Quantas vendas do mês ainda não viraram matrícula no sistema acadêmico? - De qual campanha e canal vieram as matrículas de agosto? - Por que o pagamento deste cliente diverge entre o CRM e o financeiro? - Quanto foi pago por responsáveis financeiros diferentes do aluno? **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 ## Detalhado ### O problema 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. ### Regras de negócio 1. **Cada sistema responde uma pergunta.** 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. (Evite: Contar matrículas pelos negócios ganhos no CRM.) 2. **Ancore no contrato, não na pessoa.** 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. (Evite: Juntar financeiro e venda por CPF da pessoa.) 3. **Chave acadêmica só quando é única.** 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. (Evite: Converter o RA para número e juntar mesmo quando ele se repete.) 4. **Cascata de chaves com método registrado.** 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. (Evite: Um único join por nome ou por e-mail.) 5. **Documento só com tamanho válido.** 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. (Evite: Casar pelo documento bruto, com ponto, traço ou dígito faltando.) 6. **Uma padronização de contato para todos.** 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. (Evite: Cada consulta com sua própria limpeza de telefone.) 7. **Identidade não é conciliação de venda.** 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). (Evite: Juntar todas as matrículas da pessoa em cada venda dela.) 8. **Status de conciliação explícito.** 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. (Evite: Descartar o que não casou.) 9. **Origem por evidência, origem única.** 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. (Evite: Usar só o campo de origem preenchido à mão no CRM.) 10. **Padronize origem e canal por referência.** 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. (Evite: Agrupar a origem pelo texto bruto.) ### Qual sistema responde o quê E qual chave liga cada um. - **Marketing** → Origem, campanha e UTM do lead (`e-mail e telefone normalizados`) - **Atendimento (WhatsApp)** → Tags e canal da conversa (`telefone sem DDI`) - **CRM** → Negociação, vendedor, etapa e valor vendido (`id do negócio`) - **Sistema acadêmico** → Matrícula oficial, aluno, turma e situação (`RA (texto, zeros à esquerda)`) - **Financeiro** → Título, pagador e pagamento (`id do contrato ou numero_documento`) - **Dimensão de pessoa ou cliente** → Um documento validado e os ids dos três sistemas (`CPF 11 ou CNPJ 14 dígitos`) ### Definições | Métrica | Definição | |---|---| | Venda CRM | negócio distinto com status ganho, na data de fechamento | | Matrícula oficial | registro do sistema acadêmico com situação de matrícula ativa no período letivo | | Taxa de conciliação | vendas do período com status conciliado / vendas do período | | Matrícula sem negociação | matrícula oficial do período sem negócio ganho vinculado por nenhum método | | Venda sem matrícula | negócio ganho sem matrícula vinculada até o fim do período letivo | | Pagador diferente do titular | contrato cujo pagador principal no financeiro tem documento diferente do titular ou do aluno | | Origem da matrícula | canal e campanha da evidência mais forte da pessoa, com o método de atribuição em coluna | ### Armadilhas - **Documento digitado errado.** Centenas de negócios tinham o campo CNPJ preenchido com tamanho errado e casavam com o cliente errado. Como evitar: Só aceite 11 ou 14 dígitos depois de limpar; o resto vira sem documento. - **Contrato partido em dois.** Ao juntar financeiro por pessoa, milhares de contratos em que o responsável pagava pelo aluno viraram duas linhas e a receita duplicou. Como evitar: Ligue o contas a receber só pelo id do contrato. - **Pagamento sem id de ligação.** Parte dos títulos do financeiro não tinha o número do contrato, e o cruzamento por documento sozinho pegava a parcela errada. Como evitar: Case por documento + data de pagamento + data de emissão + valor, e exclua outliers manuais documentados antes da camada confiável. - **Gateway fora da Nekt.** Clientes cobrados por um gateway não conectado apareciam como sem pagamento e geravam falso alerta. Como evitar: Confira o campo de plataforma de pagamento do negócio antes de tratar ausência como problema. - **E-mail diferente na captura e na compra.** Quem usou um e-mail no formulário e outro na compra aparecia como venda fora do funil, subestimando o retorno da captação. Como evitar: Mantenha um dicionário de identificadores por pessoa (e-mails, ids do CRM e da plataforma de venda) e declare o limite. - **Campanha sem custo.** Centenas de campanhas existiam só na UTM dos leads, sem gasto registrado em nenhuma plataforma de mídia. Como evitar: 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 - [ ] 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. ### Context document ```text 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: - : o RA é gravado no campo do negócio antes de marcar a venda. - : o id do negócio é digitado no campo do financeiro. - : uma venda gera matrículas (uma por turma ou disciplina). ``` ### Variações - **Infoproduto:** 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. - **Intercâmbio e viagem:** Contrato com vários itens (curso, acomodação, seguro, aéreo): conte contratos distintos e ligue o financeiro pelo contrato. - **B2B e corporativo:** Cliente = CNPJ validado, nome canônico vindo do financeiro, depois da cobrança, depois do CRM.