Produto, billing e mapa de cliente único
Só o que mudou, só campos permitidos, com trava
Propriedades e associações no CRM
Listas, tarefas e alertas no próprio CRM
O que resolve
- Vendedor e CSM veem uso, plano e pagamento sem sair do CRM.
- Listas e automações do CRM passam a disparar por comportamento real no produto.
- A sincronização não duplica contatos nem sobrescreve o que o time preencheu.
Perguntas de negócio que responde
Faça estas perguntas ao seu agente quando o caso estiver pronto.
O que você precisa
- Banco do produto ou eventos e billing conectados na Nekt
- O mapa de cliente único com o id de cada registro no CRM
- A lista de propriedades que a rotina pode escrever
O que você recebe
- Propriedades de uso, plano e pagamento atualizadas no CRM
- Associações de contato, empresa e deal ao workspace do produto
- Um log de envio por registro, com resultado e erro
- Listas, tarefas e alertas do CRM alimentados por dado do produto
Onde ativar
Trial com uso e sem contato vira tarefa para vendas; pagante sem acesso há 30 dias vira tarefa para o CS.
Plano, status e data de saída na ferramenta de atendimento, para o suporte saber com quem fala.
Usuários e estados do CRM viram públicos semelhantes e listas de exclusão nas plataformas de anúncio.
O cálculo é simples. O cuidado está em não duplicar, não sobrescrever e travar antes de escrever. Comece em modo de simulação, com poucas propriedades. 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.
Vendas e CS vivem no CRM, mas uso, plano e status de pagamento estão no banco do produto e no billing. A primeira sincronização costuma criar contato duplicado, sobrescrever campo que o vendedor preencheu e contar uso de usuário interno como uso do cliente. Às vezes derruba a própria fonte do CRM. E o destino escreve propriedades, mas não cria associações entre objetos.
Como costuma ser feito, e a regra
Cada linha é um erro que já aconteceu na prática.
Monte uma tabela de saída por objeto do CRM (empresa, contato, workspace como objeto customizado), com o id do registro do CRM em cada linha. O id vem do mapa de cliente único, nunca de um cruzamento por nome feito na hora. Contato casa por e-mail em minúsculas e sem espaços.
Separe quem ainda não existe no CRM (criar) de quem já existe (atualizar). A rotina de atualizar nunca cria. A de criar confere antes se o e-mail ou o domínio já existe. Comece a criação com um piloto pequeno (por exemplo, 15 registros) e confira se o registro continua lá alguns segundos depois: automações anti duplicado do CRM já apagaram contatos recém-criados.
Compare o valor calculado com o valor atual no CRM e mande só a diferença. Exemplo: marcar usuário ativo como Não só para quem está Sim no CRM e ficou inativo no produto. Mandar tudo todo dia gasta limite de API, dispara automações à toa e polui o histórico da propriedade.
Declare quais propriedades a rotina pode escrever. Telefone, e-mail e documento só são preenchidos quando estão vazios. Dono, etapa e campos editados pelo time nunca são sobrescritos. Propriedades escritas pela rotina ganham um prefixo próprio (por exemplo, lake_ ou produto_), para ninguém editar à mão.
Tire do cálculo usuários internos, de suporte e de serviço (por papel, domínio de e-mail ou lista), contas de teste e de demonstração. Usuário habilitado numa empresa sem pacote ou assinatura vigente não é usuário ativo.
Plano, status da assinatura (active, past_due, canceled, trialing), MRR e data do primeiro pagamento vêm do billing, consolidados por cliente e não por assinatura. Com várias assinaturas, uma regra de prioridade declarada escolhe o status. A data do primeiro pagamento é a da primeira cobrança paga, não a do ciclo. Envie junto a data de referência do dado.
Escreva indicadores que o time usa (usuários ativos em 7 e 30 dias, dias desde o último acesso, módulos em uso, faixa do cliente), não um campo por evento ou funcionalidade. Valores de lista vão traduzidos e numa lista fechada. O HubSpot limita o tamanho de uma propriedade a 512.000 bytes, e a fonte de contatos falha acima de 10.000 campos aninhados; depois de 3 falhas seguidas, ela se desativa.
O destino da Nekt escreve propriedades pelo id do objeto, mas não associa contato a workspace, empresa a workspace ou deal a workspace. Faça isso num notebook que compara as associações esperadas com as existentes e cria só as que faltam, com o rótulo da associação. Rode em simulação antes: num caso real, duas semanas de simulação mostraram centenas de associações a criar e mais de cem contatos que ainda nem existiam.
A rotina confere o portal ou a conta de destino antes de escrever (sandbox no teste, o id esperado em produção) e para se não bater. Confere também o volume: catálogo menor que o mínimo esperado ou número de alterações fora do normal indica dado quebrado na origem, e a rotina para em vez de apagar opções ou zerar campos. Cada envio fica num log com registro, valor, resultado e erro. Chave de API fica no cofre de segredos, nunca no código.
Inclua contas inativas e excluídas no envio, para atualizar status e data de saída no CRM e na ferramenta de atendimento. Senão o CS continua vendo como ativo quem já cancelou.
O que vai para o CRM, e de onde vem
Propriedades escritas pela rotina, com prefixo próprio e data de referência.
Definições
Armadilhas que já aconteceram
Uma automação anti duplicado do CRM apagava contatos recém-criados pela rotina, e o lote parecia ter dado certo.
Crie um piloto e confira se o registro ainda existe alguns segundos depois.
Propriedades demais em contatos passaram do limite de 10.000 campos aninhados; a extração falhou três vezes e a fonte se desativou sem aviso.
Poucas propriedades, revisão das que não são usadas e alerta de falha da fonte.
Sem separar criar de atualizar, cada execução recriava quem tinha o e-mail com maiúscula diferente.
E-mail em minúsculas e rotina de criar que confere existência.
Empresas excluídas ficavam fora do envio e seguiam ativas na ferramenta de atendimento.
Envie inativas e excluídas com a data de saída.
Usuários de um serviço operado pelo próprio time trabalhavam dentro das contas dos clientes e contavam como usuários ativos deles.
Exclua por papel do usuário, além de domínio de e-mail e contas de teste.
Tokens do CRM e de outras ferramentas estavam escritos dentro de notebooks, visíveis a quem abrisse ou versionasse o código.
Guarde no cofre de segredos da Nekt e leia com nekt.load_secret.
Teste de aceitação
O caso está pronto quando todos os itens passam.
- Para uma amostra de 20 contas, plano, status e usuários ativos no CRM batem com o billing e o produto na data de referência.
- Uma segunda execução sem mudança na origem envia zero registros.
- A rotina de atualizar não cria nenhum contato, e os contatos criados batem com o plano do lote de criar.
- Nenhum usuário interno, de suporte ou de teste entra na contagem de usuários ativos.
- Toda associação esperada existe no CRM, e o log não tem erro sem tratamento.
Pacote para o agente
Cole no Claude, ChatGPT ou outro cliente com o MCP da Nekt conectado.
Uso do produto no CRM - Propriedades escritas pela rotina têm o prefixo <prefixo> e trazem a data de referência do dado. Valor no CRM pode estar até 1 dia atrás do produto. - Usuário ativo = usuário do cliente com login ou evento nos últimos 30 dias, fora internos, suporte, serviço e contas de teste, em empresa com plano vigente. - Status de pagamento vem do billing, consolidado por cliente: active, past_due, canceled, trialing. Past_due não é cancelado. - Data do primeiro pagamento = primeira cobrança paga com valor maior que zero, não a data do ciclo. - A rotina nunca sobrescreve dono, etapa nem campos editados pelo time. Telefone, e-mail e documento só são preenchidos quando vazios. - Associação contato, empresa e deal ao workspace é feita por rotina própria; registro sem associação não é cliente sem uso. - Se o valor do CRM divergir do produto, a fonte de verdade é o produto ou o billing, não o CRM. Exceções por cliente: - <cliente>: usuários com papel <papel> são internos e não contam como ativos. - <cliente>: faixa do cliente por volume acumulado: <faixas>.
Construa no meu workspace Nekt o caso "Uso do produto no CRM" seguindo as regras em https://academy.nekt.com/industrias/saas/uso-do-produto-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 planilha alimentada pela Nekt é a fonte única lida por uma automação (por exemplo, n8n) que distribui para várias ferramentas.
Faixa do cliente por volume acumulado (por exemplo, por TPV) enviada ao CRM e à ferramenta de tarefas do time.
No self-service, uma linha por e-mail com total pago e status da última assinatura, escrita no contato.