Respuesta directa: un score o señal debe dejar de activar marketing y ventas cuando la evidencia que lo sostiene cambia más rápido de lo que la empresa puede verificarla. No use un plazo universal. Defina vigencia según tipo de evidencia, velocidad de cambio, consecuencia del error y capacidad de recálculo. Al vencer, el sistema debe recalcular, reducir confianza, pedir revisión, aplicar una regla segura o no actuar. Conservar el último valor porque el campo sigue completo es una política oculta — y suele ser la peor.
Un lead puede mantener 92 puntos por una visita de hace 45 días. Un cliente puede recibir una oferta basada en inventario de ayer. Una recomendación puede continuar activa después de una compra, cancelación, caso de soporte o cambio de territorio. El problema no es solo drift: se confundieron los momentos en que algo ocurrió, llegó, se calculó y todavía justificaba una acción.
Use el Contrato Vigencia–Acción
- Decisión y responsable — qué acción habilita el valor, quién responde y qué error es inaceptable.
- Evidencia — evento, atributo, preferencia, estado comercial, score o recomendación; fuente y granularidad.
- Relojes — cuándo ocurrió, ingresó, se calculó, se confirmó y vence.
- Regla de vigencia — plazo, condición de cambio o ambos, con excepciones por mercado y canal.
- Comportamiento vencido — recalcular, consultar fuente, bajar peso, revisar, suprimir o detener.
- Dependencias — identidad, consentimiento, inventario, capacidad, territorio, oportunidad, servicio y modelo.
- Versión — lógica, features, fuente, ventana, zona horaria y configuración.
- Evidencia de ejecución — valor leído, edad, decisión, acción, resultado, corrección y override.
El contrato pertenece a la decisión, no al campo. Un correo corporativo puede seguir correcto durante meses y aun así no autorizar contacto. Una preferencia declarada no debe perder peso como un clic; permanece hasta cambiar o retirarse, con nueva confirmación si cambia la finalidad. Precio, saldo, caso abierto o disponibilidad pueden requerir minutos. Un score necesita momento de cálculo, versión, horizonte y regla de invalidación.
Separe cinco relojes de negocio
- Ocurrencia — cuando sucedió la interacción, compra, cambio o señal.
- Ingesta — cuando CRM, CDP o warehouse recibió el hecho.
- Cálculo — cuando regla, modelo o agregado produjo el valor.
- Confirmación — cuando una fuente o persona verificó que todavía aplica.
- Expiración — cuando el valor deja de liberar la acción sin evidencia nueva.
Un único updated_at no representa los cinco. Un batch puede tocar hoy el registro usando un evento antiguo. Un operador puede corregir una etiqueta sin renovar la evidencia. Un recálculo puede emitir el mismo score sin observar novedades. Google Cloud recomienda timestamps y consultas point-in-time para features temporales, disciplina útil para reconstruir qué sabía el sistema al actuar.
La vigencia cambia por clase de evidencia
- Preferencia declarada — conserve fuente, alcance y retiro; confirme si cambia finalidad o contexto, sin decay arbitrario.
- Interacción — use ventana y decay coherentes con el ciclo de compra; separe actividad humana probable de scanners y proxies.
- Fit y firmografía — actualice ante cambios de empresa, territorio, cargo, tamaño u oferta; un perfil antiguo no es verdad permanente.
- Estado comercial — pago, pedido, oportunidad, soporte, consentimiento e inventario requieren fuentes autorizadas y transiciones.
- Score o recomendación — registre tiempo, versión, features y horizonte; invalide cuando cambie una dependencia crítica.
HubSpot permite decay configurable. Microsoft documenta distintas cadencias para leads nuevos y actualizados. Salesforce explica que fórmulas almacenadas no se actualizan automáticamente mientras calculated insights pueden agendarse. Son capacidades útiles, pero la frecuencia del producto no es automáticamente un SLA de negocio.
Ejemplo: el score alto que no debería abrir otra cola
Una empresa B2B latinoamericana recibe un lead de distribuidor que asistió a un evento y consultó precios. El score sube y entra a ventas. Después cambia de territorio, se abre una oportunidad con un partner y el ejecutivo responsable inicia negociación. Cuarenta días más tarde, un batch reproduce el score sin revisar oportunidad ni owner. La automatización crea otra tarea y activa mensajes.
La solución no es bajar 92 a 78. El contrato convierte oportunidad activa, owner y estado de contacto en precondiciones; los eventos de intención tienen ventana; el cambio territorial invalida el match; el ejecutor consulta CRM antes de actuar. Si una evidencia crítica venció, prepara contexto para revisión — no envía.
Ejecute un piloto de seis semanas
- Semana 1 — elija una acción e inventaríe los 10 a 20 campos, eventos y scores usados; mida decisiones que leen valores sin fecha confiable.
- Semana 2 — asigne fuente, cinco relojes, responsable, dependencias y comportamiento vencido; separe lo que la plataforma recalcula de lo que solo almacena.
- Semana 3 — implemente vigencia y logs en shadow mode sin cambiar routing ni mensajes.
- Semana 4 — compare decisiones actuales con bloqueadas, recalculadas y revisadas; investigue vencimientos falsos y evidencia renovada artificialmente.
- Semana 5 — libere una cohorte pequeña con fallback y revisión diaria; pruebe retraso, duplicidad, zona horaria, corrección, cambio de estado y caída de fuente.
- Semana 6 — evalúe resultado, riesgo, costo y carga operativa; mantener, corregir, ampliar o retirar.
Los entregables incluyen inventario decisión–evidencia, contrato versionado, diccionario de relojes, reglas, consultas de recálculo, gateway, logs, tablero, runbook y decisión de inversión. NIST recomienda monitoreo de producción, drift, anomalías y confiabilidad; la empresa aún debe fijar límites propios.
Elija arquitectura proporcional
- Configuración nativa — rápida para decay, filtros y refresh; limitada por objetos, cadencias e historia de la plataforma.
- Regla al actuar — revalida fuente y estado antes de ejecutar; aumenta llamadas, latencia y manejo de fallas.
- Warehouse o feature table — conserva historia y exactitud point-in-time; exige identidad, modelado, procesamiento y operación.
- Gateway de decisión — centraliza vigencia, autorización y fallback entre CRM, medios, commerce y servicio; añade responsabilidad técnica.
El costo crece con decisiones, fuentes, frecuencia, países, identidades, historia, SLAs, volumen, correcciones, ambientes, reglas y acciones downstream. Calcular todo en tiempo real puede ser caro y frágil; batch diario puede ser lento para consentimiento, inventario, precio o caso abierto. El contrato paga baja latencia donde riesgo y valor la justifican.
Mida acciones válidas — no campos actualizados
Mida edad al uso, acciones impedidas por vencimiento, recálculo, latencia de refresh, cola de revisión, overrides, bloqueos falsos, acciones corregidas y costo por decisión válida. Conecte conversión, ingresos o margen solo entre unidades elegibles y maduras. Menor volumen puede ser mejora si elimina contacto inapropiado; score promedio mayor puede ser solo otra ventana.
Use https://makinai.co/insights/es/preguntar-observar-inferir-preferencias-cliente-ia-crm para separar preferencia de inferencia, https://makinai.co/insights/es/lead-scoring-ia-deriva-modelo-calidad-pipeline para vigilar deterioro del modelo, https://makinai.co/insights/es/campos-vacios-crm-ia-contrato-ausencia-vigencia para gobernar ausencia y vigencia y https://makinai.co/insights/es/ia-reconciliacion-estado-cliente-ingresos-crm-commerce para reconciliar estados comerciales. Si un score activa colas, mensajes u ofertas sin momento de cálculo, expiración y fallback, lleve a MAKINAI, mediante https://makinai.co/services/es/consultoria-crm-ecommerce-commerce, una decisión, 30 días de logs y sus campos. Podemos delimitar el piloto mínimo antes de reemplazar el stack.
Las fuentes documentan capacidades y prácticas de tiempo, cálculo y monitoreo. No establecen TTLs universales ni prueban impacto comercial. El Contrato, los cinco relojes, el piloto y la economía son recomendaciones editoriales para validar en el workflow real.