Contratos e parcelas do core, cards da esteira
Chave do destino limpa, status por prioridade, formato do destino
Uma linha por registro do destino, só com o que mudou
CRM, régua de e-mail, WhatsApp e pesquisas
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.
Perguntas de negócio que responde
Faça estas perguntas ao seu agente quando o caso estiver pronto.
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
Onde ativar
Status de contrato, atraso e cobrança no contato e no negócio, atualizados a cada carga do core.
Listas e tags de quitados, atrasados, pré-aprovados e desembolsos concluídos alimentam a régua e o NPS.
Mensagem diária por consultor ou assessor com os clientes que pedem ação hoje.
A regra de status vem pronta do caso de inadimplência. O trabalho está na chave de cruzamento e no formato de cada destino. 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 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.
Como costuma ser feito, e a regra
Cada linha é um erro que já aconteceu na prática.
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).
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.
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.
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.
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).
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.
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_<originador>_<aaaammdd>) e uma tag do ano. Só entra quem cumpre a condição, como desembolso concluído para a pesquisa de NPS.
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.
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.
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.
Definições
Armadilhas que já aconteceram
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.
Converta o id para texto e remova o sufixo antes de enviar.
O core mantinha a última faixa de atraso depois da quitação, e o CRM mostrava cliente quitado como inadimplente para o consultor.
Valor em aberto zero vira Quitado antes de qualquer faixa.
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.
Teste o formato de cada campo de data no destino de homologação.
O CNPJ lido como número perdeu os zeros à esquerda, e o cruzamento com o cadastro falhou para empresas com CNPJ iniciado em zero.
Guarde documento como texto, só dígitos, completado com zeros.
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.
Sem retorno vai para a lista de exceção.
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.
Busque os ids de funil e etapa e crie direto neles.
Teste de aceitação
O caso está pronto quando todos os itens passam.
- 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.
Pacote para o agente
Cole no Claude, ChatGPT ou outro cliente com o MCP da Nekt conectado.
Status de crédito no CRM - Destinos: <CRM>, <ferramenta de e-mail>, <ferramenta de WhatsApp>. 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: <CRM> = 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 <conta/funil de teste>; produção em <conta/funil>. Funil e etapa pelo id. Exceções por cliente: - <cliente>: o contato no CRM recebe o resumo; contratos e parcelas vão para o objeto <objeto>. - <cliente>: escritório de cobrança e data de envio vêm de <tabela>. - <cliente>: a pesquisa de NPS só vai para quem teve desembolso concluído há mais de <N> dias.
Construa no meu workspace Nekt o caso "Status de crédito de volta ao CRM" seguindo as regras em https://academy.nekt.com/industrias/financeiros/status-credito-no-crm.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
Uma linha por parcela com vencimento, pagamento, valor e dias de atraso, para o CRM mostrar o extrato do cliente.
Escritórios de investimento: contas com saldo negativo, valor e dias parados, numa mensagem por assessor.
Cliente, tags, projeto, vendedor e contas a pagar e a receber criados no ERP a partir do card aprovado, com homologação antes.