--- id: financeiros/status-credito-no-crm industria: Serviços financeiros uso: muito usado esforco: baixo grao: Registro do destino (contato, negócio, card ou parcela) x data de envio --- # Status de crédito de volta ao CRM O status de cada contrato, as parcelas, o atraso e a cobrança aparecendo no CRM, na régua de e-mail e no WhatsApp, com o mesmo número do core e sem planilha exportada. ## Resumo executivo **Para quem:** Fintechs de crédito, plataformas de funding e escritórios de investimento em que comercial, CS e cobrança trabalham no CRM e no WhatsApp. **O que resolve** - O consultor vê no CRM se o contrato está em dia, atrasado ou quitado, com o mesmo número do core. - A régua de e-mail e a mensageria disparam a partir do status real, não de uma lista exportada. - Quitados, atrasados e enviados à cobrança viram listas que se atualizam sozinhas. **Por que importa:** O dado de carteira mora no core e o time mora no CRM. Sem o retorno, alguém exporta planilha toda semana, o CRM fica dias atrás do core e o consultor oferece crédito novo para quem está em atraso ou cobra quem já quitou. Com o status de volta ao CRM, cada régua e cada abordagem parte do mesmo número do fechamento. **Perguntas de negócio que responde** - Quais clientes do consultor estão com parcela em atraso hoje? - Quais contratos foram enviados ao escritório de cobrança este mês? - Quantos contratos atrasaram já na primeira parcela? - Quem já quitou e pode receber oferta de novo crédito? - Quais clientes do assessor estão com saldo negativo agora? - Quem teve o desembolso concluído e ainda não recebeu a pesquisa de NPS? **O que você precisa** - O core ou a esteira conectado na Nekt, com contratos e parcelas - O destino conectado como saída (CRM, ferramenta de e-mail ou de WhatsApp) e o campo que guarda o id da Nekt - A lista de campos que o time quer ver e o formato que cada destino aceita **O que você recebe** - Uma tabela de exportação por destino, uma linha por registro, já no formato aceito - Status de contrato, atraso e cobrança atualizados no CRM a cada carga - Tags e listas para a régua de e-mail e para pesquisas - Mensagens prontas por destinatário no WhatsApp ## Detalhado ### O problema O contrato vive no core e o relacionamento vive no CRM, com chaves diferentes e formatos que não conversam. Ids chegam como '123.0', datas no formato que o CRM rejeita, números com ponto onde a planilha espera vírgula. Quem envia o status sem regra de prioridade mostra 'em atraso' para um contrato já quitado, e quem testa no destino de produção cria contato duplicado na base inteira. ### Regras de negócio 1. **A chave é o id do destino, limpa.** Cada linha carrega o id que o destino reconhece: id do lead ou do contato no CRM, card_id no Pipefy, id do negócio no Pipedrive, e-mail ou CPF onde o destino só aceita isso. Ids lidos como número chegam como '123.0': converta para texto e tire o sufixo. CNPJ e CPF só com dígitos e zeros à esquerda (14 e 11 posições). (Evite: Mandar o id como número decimal ou o CNPJ sem os zeros à esquerda.) 2. **Uma linha por registro do destino.** Decida o objeto antes de montar: contrato vai para o negócio, parcela para um objeto de parcela, resumo do cliente para o contato. Se o contato tem vários contratos, mande para o contato um resumo (contrato mais recente, maior atraso, total em aberto) e o detalhe para o objeto de contrato. Quando cliente e lead existem para a mesma pessoa, o cliente prevalece. (Evite: Mandar uma linha por contrato para o contato e deixar o último sobrescrever os outros.) 3. **Status por ordem de prioridade.** Contrato com valor em aberto igual a zero é Quitado, independentemente da faixa de atraso que o core ainda carrega. Fora isso, vale a faixa de atraso atual, o atraso máximo da vida do contrato vai em campo separado, e FPD vai como sim ou não, nunca como 1.0. (Evite: Enviar a faixa de atraso do core para um contrato já quitado.) 4. **Mesma régua do fechamento.** Dias de atraso, faixa e FPD que vão para o CRM saem da mesma tabela do aging e da PDD, não de um cálculo novo no export. Assim o número que o consultor vê bate com o do comitê de risco. (Evite: Recalcular dias de atraso dentro da query de exportação.) 5. **Formato do destino só na camada de saída.** Cada destino tem o seu formato: um CRM aceitou datas só como dd-mm-aaaa, a propriedade de data do HubSpot espera aaaa-mm-dd, planilhas brasileiras querem vírgula decimal. Formate numa view de exportação por destino e mantenha a tabela de carteira com tipos de verdade (data, número). (Evite: Gravar data como texto dd-mm-aaaa na tabela de carteira para servir ao CRM.) 6. **Elegibilidade explícita para cada lista.** Toda lista que alimenta uma régua tem a regra escrita. Exemplo real de pré-aprovados: proposta com retorno do parceiro que não foi negado e que já saiu de documentos pendentes e de em análise. Pedido sem retorno do parceiro vai para uma lista de exceção para alguém olhar, nunca para a régua. (Evite: Mandar para a régua todo pedido que não está como negado.) 7. **Tags datadas e padronizadas.** Tags de segmentação seguem um padrão fixo em minúsculas, com espaço trocado por underline: origem, campanha com data (por exemplo, nps__) e uma tag do ano. Só entra quem cumpre a condição, como desembolso concluído para a pesquisa de NPS. (Evite: Tags com espaço e maiúsculas variando por envio.) 8. **Mensagem pronta por destinatário.** Para WhatsApp, junte numa mensagem só todas as linhas de um destinatário (o assessor ou o consultor), uma frase por cliente, com texto padrão para campo vazio ('(sem nome)') e valor formatado. O destinatário é o id do contato na ferramenta de mensageria, filtrado pela tag do time. (Evite: Uma mensagem por cliente para o mesmo assessor.) 9. **Homologação separada de produção.** Toda exportação nasce numa versão de homologação, que escreve numa conta ou num funil de teste, e só depois ganha a versão de produção. Criação de negócio aponta para o funil e a etapa pelo id, buscado antes, e cada envio grava um log para não criar o mesmo registro duas vezes. (Evite: Testar a exportação direto no CRM de produção, com funil escolhido pelo nome.) ### Campos de contrato que voltam ao CRM Exemplo real de uma fintech de crédito. Cada campo vem da tabela de carteira, não do export. - **Id do lead no CRM, sem '.0'** → Chave do registro (`id`) - **Número da CCB em texto** → Contrato (`numero_ccb`) - **Parcelas pagas e valor pago** → Pagamentos (`qtd_parcelas_pagas`) - **Hoje e o máximo da vida do contrato** → Dias de atraso (`dias_atraso, atraso_max`) - **Quitado quando o valor em aberto é zero** → Faixa de atraso (`faixa_atraso`) - **sim ou não** → FPD (`is_fpd`) - **Saldo devedor na data** → Valor em aberto (`valor_aberto`) - **Escritório e data de envio, dd-mm-aaaa** → Cobrança terceirizada (`escritorio_cobranca`) - **Origem, campanha com data, ano** → Tags (`lista de texto`) ### Definições | Métrica | Definição | |---|---| | Dias de atraso | data de referência menos o vencimento da parcela vencida mais antiga em aberto, por contrato, da tabela de carteira | | Atraso máximo | maior número de dias de atraso que o contrato já teve, desde a originação | | Faixa enviada | Quitado quando o valor em aberto é zero; senão a faixa de atraso da política na data de referência | | FPD | contrato cuja primeira parcela venceu e não foi paga; enviado como sim ou não | | Valor em aberto | soma do saldo das parcelas não pagas do contrato na data de referência | | Enviado à cobrança | contrato com escritório de cobrança e data de envio preenchidos, por mês de envio | | Defasagem do destino | horas entre a última atualização do core e a escrita no destino, por carga | | Cobertura do cruzamento | registros elegíveis com id do destino encontrado / registros elegíveis, por envio | ### Armadilhas - **Id com '.0'.** O id do lead veio do arquivo do core como número decimal. O CRM não reconheceu '123.0' e criou contatos novos em vez de atualizar os existentes. Como evitar: Converta o id para texto e remova o sufixo antes de enviar. - **Quitado aparecendo em atraso.** O core mantinha a última faixa de atraso depois da quitação, e o CRM mostrava cliente quitado como inadimplente para o consultor. Como evitar: Valor em aberto zero vira Quitado antes de qualquer faixa. - **Data rejeitada em silêncio.** A data foi enviada no formato padrão do banco de dados e o CRM, que esperava dd-mm-aaaa, deixou o campo vazio sem erro. Como evitar: Teste o formato de cada campo de data no destino de homologação. - **CNPJ sem zeros.** O CNPJ lido como número perdeu os zeros à esquerda, e o cruzamento com o cadastro falhou para empresas com CNPJ iniciado em zero. Como evitar: Guarde documento como texto, só dígitos, completado com zeros. - **Retorno do parceiro vazio.** Parte das propostas ficou sem o retorno do parceiro gravado. Filtrar só por não negado mandou para a régua de pré-aprovados gente que nunca foi avaliada. Como evitar: Sem retorno vai para a lista de exceção. - **Negócio criado no funil errado.** A criação de negócios usava o funil padrão, e os registros caíram fora do funil e da etapa em que o time trabalha. Foi preciso mover um a um. Como evitar: Busque os ids de funil e etapa e crie direto neles. ### Teste de aceitação - [ ] Numa amostra de 50 contratos, dias de atraso, faixa, FPD e valor em aberto no CRM são iguais aos da tabela de carteira na mesma data. - [ ] Nenhum id enviado termina em '.0' e todo CNPJ tem 14 dígitos. - [ ] Nenhum contrato com valor em aberto zero aparece com faixa de atraso no destino. - [ ] Reprocessar a exportação não cria nenhum registro novo no destino. - [ ] O número de registros enviados é igual ao de registros elegíveis com id encontrado, e a cobertura do cruzamento aparece no log. ### Context document ```text Status de crédito no CRM - Destinos: , , . Cada destino tem sua view de exportação; a tabela de carteira tem tipos de verdade. - Chave: id do destino em texto, sem '.0'. CPF com 11 e CNPJ com 14 dígitos, só números. - Status: valor em aberto zero = Quitado. Senão, faixa de atraso da política. Atraso máximo e FPD (sim/não) em campos próprios. - Dias de atraso, faixa e FPD vêm da tabela de carteira do fechamento, nunca de cálculo no export. - Formato de data por destino: = dd-mm-aaaa; HubSpot = aaaa-mm-dd. Decimal com vírgula só em planilha. - Pré-aprovados: retorno do parceiro não negado e fora de documentos pendentes e em análise. Sem retorno do parceiro vai para exceção. - Tags: minúsculas, espaço vira underline, data aaaammdd no nome da campanha. - WhatsApp: uma mensagem por destinatário, uma frase por cliente. - Homologação escreve em ; produção em . Funil e etapa pelo id. Exceções por cliente: - : o contato no CRM recebe o resumo; contratos e parcelas vão para o objeto . - : escritório de cobrança e data de envio vêm de . - : a pesquisa de NPS só vai para quem teve desembolso concluído há mais de dias. ``` ### Variações - **Parcelas como objeto próprio:** Uma linha por parcela com vencimento, pagamento, valor e dias de atraso, para o CRM mostrar o extrato do cliente. - **Saldo negativo para o assessor:** Escritórios de investimento: contas com saldo negativo, valor e dias parados, numa mensagem por assessor. - **Cadastro no ERP a partir da esteira:** Cliente, tags, projeto, vendedor e contas a pagar e a receber criados no ERP a partir do card aprovado, com homologação antes.