Prospección automatizada sin convertirse en spam

Un agente que manda correo en frío a nombre de tu empresa puede hacer daño real en una tarde. Si le escribe a direcciones muertas, a trampas de spam, o a la misma persona tres veces, tu dominio pierde reputación y tus correos legítimos empiezan a caer en spam semanas después. El envío es la parte sencilla. Lo que decide si tienes un producto o un incidente es todo lo que pasa antes: quién califica para recibir un correo, y con qué evidencia. Eso es lo que hay detrás de AI SDR.

Este texto es sobre esa maquinaria de decisión, y sobre la regla que la sostiene: no inventamos datos.

Cuatro filtros, en orden

Un correo candidato pasa por cuatro filtros antes de salir, y el orden importa.

El primero es parseo: una celda de una fuente ("ventas@empresa.com; contacto@otra.com") se convierte en direcciones candidatas. Suena trivial hasta que ves las fuentes reales, donde un campo trae tres correos, un teléfono, y a veces una URL pegada.

El segundo es validación de almacenamiento: estructura, sufijo del dominio contra la Public Suffix List, sintaxis RFC, ASCII en la parte local. Lo que falla no se descarta; se manda a cuarentena, con la razón, para poder auditarlo después.

El tercero es verificación de buzón: ¿existe la casilla? Es un paso aparte y posterior, no parte de la importación. Usamos un verificador propio y gratuito como primer filtro, y un proveedor de pago para los dominios corporativos donde el primero devuelve "desconocido".

El cuarto es política de envío, y es de solo lectura: es el único punto que autoriza un envío en vivo. Ahí vive la regla que más nos costó afinar.

La evidencia tiene niveles, y el umbral se mueve

No todos los "válido" valen lo mismo. El verdicto de un verificador gratuito no autoriza un envío por sí solo; la señal que sí lo hace es la del proveedor de correo, con niveles de confianza, y un "existe el buzón" de alta confianza pesa distinto que uno de confianza media. El umbral mínimo tampoco es fijo: se ajusta según la salud de nuestro propio dominio emisor. Con el dominio sano, el listón baja al nivel medio. En periodo de prueba o con rebotes altos, el listón sube. Si la salud colapsa, el envío se bloquea por completo.

El resultado práctico es que el sistema se restringe solo justo cuando hay más riesgo. Un pico de rebotes se registra y además endurece el filtro para el siguiente lote.

Una dirección tocada una vez queda bloqueada

La regla de deduplicación es simple y estricta a propósito: una dirección que alguna vez recibió un envío queda bloqueada de forma permanente para el primer contacto. Sin ventana de 30 días, sin excepción por campaña distinta. Hay una escotilla para re-contactar a la misma persona, pero trae un piso de 30 días que no se puede saltar en crudo. La única ruta normal que vuelve a escribirle a alguien es una secuencia de seguimiento controlada.

Esto se hace cumplir en código, no en la buena voluntad del agente. El agente decide qué decir y a quién apuntar; no decide si puede enviar. Esa decisión vive en un solo módulo, de solo lectura, que se consulta justo antes de la entrega por red.

La regla de fondo: no inventar datos

La base de datos es el producto. Queremos el conjunto de contactos más completo, a la calidad más alta, y esas dos metas no se negocian una contra la otra. De ahí sale la regla que más nos importa: un dato inventado es peor que un dato en blanco.

En concreto:

• No borramos datos de negocio con valor. Un registro malo se degrada, se cuarentena, o se marca inválido, pero se conserva y queda auditable. El borrado duro es solo para basura sin contenido.
• En un backfill llenamos huecos; nunca sobreescribimos un valor que ya existe.
• No inferimos el nombre de una persona a partir de su correo. jperez@empresa.com no autoriza escribir "Juan Pérez" en ningún lado. Si un dato se refuta y el reemplazo no viene de una fuente real, se limpia y se deja en blanco.
• No probamos que dos empresas son la misma con substrings, tokens de marca, o regex de sufijos legales. La prueba válida es exacta: mismo dominio o subdominio, misma etiqueta registrada, o una revisión curada, y pasa por un solo punto de control.

Esta última es fácil de subestimar. La tentación de decir "empresa.com y empresa.com.mx son la misma" con una comparación de cadenas es enorme, y casi siempre está mal en el caso que importa. Una lista de prefijos nunca termina de estar completa, y cada falso positivo copia la relación de una empresa a otra que no le corresponde.

Cómo evitamos que se degrade

Un sistema de reglas se pudre cuando alguien, con prisa, escribe un literal donde debía ir un valor de un catálogo. Cualquier columna con un conjunto finito de valores está restringida por la base de datos, con el conjunto canónico en código o en una política YAML que edita un operador. Y hay un guardián en integración continua que corre contra cinco categorías de deriva y falla el pull request ante cualquier hallazgo nuevo. El guardián no confía en que el ingeniero recuerde la regla; falla la build si la rompe.

Pruébalo

Corremos esto para nuestra propia generación de demanda y para clientes de iNBest que quieren un SDR que no queme su dominio. Si quieres verlo trabajando sobre tu propio pipeline, escríbenos.

Entra a aisdr.inbest.cloud y pide un piloto. Lo apuntamos a un segmento de tu mercado y ves cómo califica, verifica y decide a quién escribir antes de que salga un solo correo, con la evidencia detrás de cada decisión.

Nos sirve el detalle de operadores que ya mandan correo en frío. Dinos dónde nuestros filtros se sienten demasiado estrictos o demasiado laxos, qué señal de deliverability te falta, qué reporte te gustaría ver. Escríbenos a hola@inbest.cloud.