Resposta direta: um score ou sinal deve deixar de acionar marketing e vendas quando a evidência que sustenta a decisão mudou mais rápido do que a empresa consegue confirmá-la. Não use um prazo universal. Defina a validade pelo tipo de fato, velocidade de mudança, consequência do erro e capacidade de recalcular. Quando vencer, o sistema precisa executar uma política explícita: recalcular, reduzir confiança, pedir revisão, usar uma regra segura ou não agir. Manter o último valor porque o campo continua preenchido é uma decisão oculta — e frequentemente a pior.
Um lead pode ter nota 92 porque visitou uma página há 45 dias, um cliente pode receber oferta porque um estoque foi sincronizado ontem, e uma recomendação pode continuar ativa depois de compra, cancelamento, caso de suporte ou troca de território. O problema não é apenas drift do modelo. É a diferença entre o momento em que algo aconteceu, chegou, foi calculado e ainda pode justificar uma ação.
Use o Contrato Frescor–Ação
- Decisão e owner — qual ação o valor libera, quem responde por ela e qual erro é inaceitável.
- Evidência — evento, atributo, preferência, estado comercial, score ou recomendação; fonte e granularidade.
- Relógios — quando ocorreu, chegou, foi calculada, foi confirmada e vence.
- Regra de validade — prazo, condição de mudança, combinação de ambos e exceções por mercado ou canal.
- Comportamento vencido — recalcular, reconsultar fonte, reduzir peso, revisar, suprimir ou parar.
- Dependências — identidade, consentimento, estoque, capacidade, território, oportunidade, serviço e modelo.
- Versão — lógica, features, fonte, janela, timezone e configuração aplicados.
- Evidência da execução — valor lido, idade, decisão, ação, resultado, correção e eventual override.
O contrato pertence à decisão, não ao campo. Um email corporativo pode continuar correto por meses, mas ser insuficiente para autorizar contato. Uma preferência declarada não deve simplesmente perder peso como um clique; ela permanece até mudança, retirada ou necessidade de confirmação contextual. Um preço, saldo, caso aberto ou disponibilidade pode exigir minutos. Um score preditivo precisa de computed_at, versão do modelo e política para mudanças após o cálculo.
Separe cinco relógios
- Ocorrência — quando a interação, compra, mudança ou sinal aconteceu no mundo.
- Ingestão — quando o CRM, CDP ou warehouse recebeu o fato.
- Cálculo — quando regra, modelo ou agregação produziu o valor usado.
- Confirmação — quando uma fonte ou pessoa verificou que ele ainda vale.
- Expiração — quando o valor deixa de liberar a ação sem nova evidência.
Guardar apenas updated_at mistura relógios. Um batch pode atualizar o registro hoje usando um evento antigo; um operador pode corrigir a etiqueta sem renovar a evidência; uma recomputação pode emitir o mesmo score sem observar novas informações. O Google Cloud recomenda timestamps e consultas point-in-time para features temporais. Isso evita usar informação futura no treino e também ajuda a reconstruir o que o sistema sabia quando agiu.
Validade muda por classe de evidência
- Preferência explícita — preserve fonte, escopo e retirada; confirme novamente quando finalidade ou contexto mudarem, não por decay arbitrário.
- Engajamento — use janela e decay compatíveis com o ciclo de compra; diferencie atividade humana provável de scanner ou proxy.
- Fit e firmografia — recalcule após mudança de empresa, território, função, porte ou oferta; não trate cadastro antigo como verdade permanente.
- Estado comercial — pagamento, pedido, oportunidade, suporte, consentimento e estoque pedem fonte autoritativa e transições, não apenas tempo.
- Score ou recomendação — registre momento, versão, features e horizonte; invalide quando uma dependência crítica mudar.
A HubSpot permite decay de eventos de engajamento em intervalos configuráveis. A Microsoft documenta cadências diferentes para leads novos e atualizados. A Salesforce mostra que fórmulas armazenadas não se atualizam sozinhas, enquanto calculated insights podem ser agendados. Essas capacidades são úteis, mas uma frequência do produto não é automaticamente um SLA de negócio.
Exemplo: o score alto que não deveria abrir a fila
Considere uma empresa B2B no Brasil. O lead baixou um material e visitou preços, recebeu score alto e foi encaminhado. Depois abriu uma oportunidade por parceiro, trocou de unidade e entrou em negociação com outro executivo. Quarenta dias depois, um batch recalcula o mesmo score sem considerar oportunidade ativa ou ownership. A automação cria nova tarefa para pré-vendas e inicia WhatsApp.
O conserto não é reduzir o score de 92 para 78. O contrato define que oportunidade ativa, owner e estado de contato são precondições; eventos de intenção têm janela; mudança de conta invalida o match; o executor reconsulta CRM antes de agir. Se qualquer evidência crítica estiver vencida, prepara contexto para revisão — não envia.
Pilote em seis semanas
- Semana 1 — escolha uma ação real e inventarie os 10 a 20 campos, eventos e scores usados; meça quantas decisões leem valores sem data confiável.
- Semana 2 — atribua fonte, cinco relógios, owner, dependências e comportamento vencido; identifique o que a plataforma recalcula e o que apenas armazena.
- Semana 3 — implemente flags de validade e logs em shadow mode; não altere roteamento nem mensagens.
- Semana 4 — compare decisões atuais com decisões bloqueadas, recalculadas ou revisadas; investigue falsos vencimentos e valores artificialmente renovados.
- Semana 5 — libere uma pequena coorte com fallback e revisão diária; teste atraso, duplicidade, timezone, correção, mudança de estado e indisponibilidade da fonte.
- Semana 6 — avalie resultado, risco, custo e operação; manter, corrigir, ampliar ou retirar.
Entregáveis: inventário decisão–evidência, contrato versionado, dicionário de relógios, regras de validade, consultas de recálculo, gateway de ação, logs, painel, runbook e decisão de investimento. O NIST recomenda monitorar produção, drift, anomalias e confiabilidade; isso não substitui critérios específicos do processo comercial.
Escolha a arquitetura proporcional
- Configuração nativa — rápida para decay, filtros e recálculo simples; limitada por objetos, cadências e histórico da plataforma.
- Regra no momento da ação — revalida fonte e estado antes de executar; aumenta chamadas, latência e tratamento de falhas.
- Warehouse ou feature table — preserva histórico e point-in-time; exige identidade, modelagem, processamento e operação.
- Gateway de decisão — centraliza validade, autorização e fallback entre CRM, mídia, commerce e atendimento; maior controle e maior responsabilidade de engenharia.
O custo cresce com número de decisões, fontes, frequências, regiões, identidades, históricos, SLAs, volumes, correções, ambientes, regras e ações downstream. Calcular tudo em tempo real pode ser caro e frágil; batch diário pode ser insuficiente para preço, consentimento ou caso aberto. O contrato ajuda a pagar latência apenas onde o risco e o valor justificam.
Meça ações válidas — não campos atualizados
Meça idade da evidência no uso, ações impedidas por vencimento, recálculo concluído, tempo até atualização, fila de revisão, overrides, falsos bloqueios, ações corrigidas e custo por decisão válida. Depois conecte conversão, receita ou margem apenas entre unidades elegíveis e maduras. Uma queda no volume pode ser melhoria se elimina contato inadequado; uma alta no score médio pode ser só mudança de janela.
Use https://makinai.co/insights/pt/perguntar-observar-inferir-preferencias-cliente-ia-crm para separar preferência declarada de inferência, https://makinai.co/insights/pt/lead-score-ia-drift-modelo-qualidade-pipeline para monitorar deterioração do modelo, https://makinai.co/insights/pt/campos-vazios-crm-ia-contrato-ausencia-atualidade para tratar ausência e atualidade e https://makinai.co/insights/pt/ia-reconciliacao-estado-cliente-receita-crm-commerce para reconciliar estados comerciais. Se um score ainda dispara filas, mensagens ou ofertas sem computed_at, expiração e fallback, leve à MAKINAI, em https://makinai.co/services/pt/consultoria-crm-ecommerce-commerce, uma decisão, 30 dias de logs e os campos que a sustentam. Podemos delimitar o menor piloto antes de trocar a plataforma inteira.
As fontes documentam recursos e práticas de tempo, cálculo e monitoramento. Não definem TTLs universais nem provam ganho comercial. O Contrato, os cinco relógios, o piloto e os critérios econômicos são recomendações editoriais a validar no processo real.