Cómo actualizar una base de datos de leads B2B: reglas de frescura antes de enviar

Una hoja puede tener empresa, nombre, cargo, email y señal en todas sus columnas y aun así estar lista para fallar. La persona pudo cambiar de trabajo, el dominio migrar, la empresa cerrar una línea de negocio o la vacante usada como señal haber desaparecido. El dato no se vuelve falso de golpe; pierde confiabilidad hasta que alguien lo verifica.

Ese envejecimiento no ocurre a la misma velocidad. El dominio legal de una compañía suele ser más estable que un cargo. Una industria puede conservarse durante años; una señal de contratación puede perder valor en semanas. Un email que entregó hace seis meses no prueba que el buzón siga activo hoy. Por eso la frescura debe vivir por campo, no como una única fecha de exportación.

La postura de picos.Ai es que una base de leads necesita reglas de caducidad igual que una integración necesita permisos. Sin ellas, el equipo descubre los datos viejos mediante rebotes, respuestas molestas y personalización absurda. Es una forma cara de hacer control de calidad.

TTL —time to live— es el periodo durante el cual un dato puede usarse sin una nueva verificación bajo una política definida. No declara que el campo sea verdadero hasta el último segundo y falso después. Indica cuándo la incertidumbre ya es suficiente para exigir otra fuente, revisión o bloqueo.

Cada registro necesita al menos captured_at, verified_at, source_url o source_id, source_type, confidence y expires_at. Conserva también el valor anterior cuando cambie. Sobrescribir “VP Sales” con “Advisor” sin historial impide saber qué campaña usó cada versión y cuándo se tomó la decisión.

No copies un calendario universal. Una operación con ciclos de lanzamiento mensuales, datos propios y cuentas enterprise tendrá ventanas distintas a una campaña de alto volumen basada en directorios. Define el TTL como hipótesis operativa, mide qué campos cambian antes del vencimiento y ajústalo con evidencia.

Hay cinco compuertas. Empresa: confirmar que la cuenta existe, conserva el dominio y sigue dentro del ICP. Persona: comprobar que el contacto mantiene relación con la empresa y que su rol puede influir en el problema. Email: validar sintaxis, dominio, estado del buzón según la herramienta y rebotes previos. Señal: revisar que la fuente siga disponible y dentro de la ventana definida. Supresión: consultar opt-outs, clientes, oportunidades activas y bloqueos justo antes de exportar.

La supresión no debería tener TTL que permita olvidarla. Una baja debe persistir de forma central y propagarse a nuevas campañas y herramientas. Google exige a remitentes elegibles cumplir requisitos de baja para mensajes de marketing o suscripción, y la FTC exige honrar opt-outs en mensajes comerciales sujetos a CAN-SPAM. El alcance legal depende del caso y la jurisdicción; operativamente, reciclar un opt-out por importar una lista vieja sigue siendo una mala decisión.

Para señales, guarda el hecho y la fecha del hecho, no solo la fecha en que tu herramienta lo encontró. Descubrir hoy una nota de expansión publicada hace dos años no crea una señal nueva. El crawler es reciente; el evento no.

Clasifica cada campo por volatilidad y consecuencia. Alta volatilidad con alta consecuencia —cargo, relación laboral, email, opt-out— exige verificación cercana al envío. Volatilidad media —headcount, tecnología, vacantes, etapa comercial— necesita revisión según campaña y fuente. Datos más estables —dominio principal, país, industria amplia— pueden usar ventanas mayores, salvo que una anomalía active revisión.

Después asigna una acción al vencimiento. Refresh consulta una fuente permitida. Review envía el registro a una cola humana. Quarantine lo separa de la campaña. Reject lo excluye cuando falta un requisito obligatorio. Unknown conserva explícitamente la incertidumbre; no debe convertirse en false ni rellenarse con una inferencia solo para completar el esquema.

Ejemplo: una empresa cumple el ICP y su dominio está confirmado, pero el contacto fue verificado hace nueve meses y la página pública ya no muestra el rol. El registro no necesita desaparecer. La cuenta vuelve a investigación, el contacto queda bloqueado y el sistema busca una ruta pública y verificable. Adivinar otro email sería renovar la fecha sin renovar la evidencia.

No ejecutes el waterfall completo sobre cada fila. Empieza por gates baratos: supresión, dominio activo, cuenta dentro del ICP, fecha y presencia de campos obligatorios. Solo después consulta la fuente específica del campo vencido. Si cambió el dominio, quizá debas invalidar email y tecnología; si venció una señal, no necesitas comprar otra vez el teléfono.

Usa fingerprint del valor y de la fuente para detectar si un proveedor devolvió exactamente el mismo dato. Registra provider, lookup_at, resultado, costo, valor anterior y razón del refresh. Si una segunda fuente solo repite la primera, no reportes cobertura incremental. Ya publicamos una guía de waterfall enrichment para medir precisión y costo por dato usable.

Para cuentas de alto valor, combina automatización con revisión. La página oficial de la empresa puede ganar sobre un agregador para cargo o dominio; un proveedor puede servir para cobertura inicial. Cuando dos fuentes discrepen, conserva ambas y aplica una regla visible. “Último dato recibido” es fácil de programar, pero no siempre es el dato más nuevo ni el más confiable.

El CRM o warehouse debe conservar identidad, historial, supresión y estado comercial. Clay u otro motor puede calcular vencimientos, ejecutar waterfalls y preparar la evidencia. Instantly o Smartlead debe recibir únicamente registros que pasaron las compuertas. Los eventos de reply, bounce y opt-out deben regresar con IDs comunes y cambiar la elegibilidad futura.

Antes de exportar, ejecuta una función eligibility(contact_id, campaign_id, now). Debe revisar account fit, contact fit, verificación, expiración, supresión, campaña activa y conflictos con otras secuencias. Devuelve allow, review o block junto a códigos de razón. Un booleano sin explicación hará que cada excepción termine en un mensaje de Slack.

Vuelve a comprobar la elegibilidad al programar y, cuando el sender lo permita, antes del envío. Entre ambos momentos puede llegar una respuesta, baja o cambio de etapa. Usa webhooks idempotentes para propagar eventos y una lista central para impedir que una importación posterior resucite registros bloqueados.

Mide registros vencidos por campo, porcentaje refrescado, cambios encontrados, costo por actualización útil, tiempo en cola y bloqueos por razón. Después conecta esos datos con hard bounces, respuestas de cargo incorrecto, opt-outs, respuestas positivas, reuniones y oportunidades por cohorte.

Incluye falsos bloqueos. Una política demasiado estricta puede detener cuentas válidas y elevar costos sin mejorar resultados. Audita muestras de allow, review y block; compara fuentes y observa cuántos campos cambian antes o después del TTL. Ajusta ventanas por segmento y proveedor, no por intuición general.

No prometemos un porcentaje universal de reducción de rebotes ni una ventana perfecta de 30, 60 o 90 días. La infraestructura, el mercado y la fuente cambian. La métrica útil es cuánto error evita cada refresh frente a su costo y cuánto aprendizaje conserva el sistema.

Añade fuente y verified_at a los campos que deciden envío. Define tres niveles de volatilidad. Bloquea automáticamente opt-outs, hard bounces y personas sin relación laboral verificable. Revisa señales vencidas y cuentas con conflicto comercial. Prueba la política sobre una cohorte pequeña antes de aplicarla a toda la base.

picos.Ai puede implementar esta capa sobre Clay, Instantly o Smartlead y CRM, con reglas de elegibilidad, refresh selectivo y reporting por causa. Si hoy la única fecha disponible es cuándo compraste la lista, podemos convertirla en un registro auditable antes del siguiente lanzamiento.

Una lista fresca no es una lista recién descargada. Es una lista donde cada decisión importante conserva fuente, fecha y una respuesta clara a la pregunta incómoda: ¿todavía sabemos que esto es cierto?