Un founder con el que hablé hace poco está lanzando un segundo producto. Nuevo comprador, nuevos competidores, un ICP distinto del que el negocio principal ha vendido durante años. El equipo go-to-market dedicado son dos personas: un account executive y un go-to-market engineer. Sin SDR, sin field marketing, sin nadie para atender un stand. Y la primera pregunta sobre la mesa no fue «cómo construimos pipeline», fue «¿de verdad necesitamos SDR, o simplemente les apuntamos agents de IA?» Es el instinto correcto pegado a la primera pregunta equivocada.
La pregunta está en todas partes este año, y por una buena razón. La economía del sales development por cadencia se dio vuelta. SaaStr ahora sostiene que la mayoría de los SDR serán AI SDR en 2026 y más adelante, y la versión más citada de la historia es Jason Lemkin reemplazando un equipo de ventas de unas diez personas por veinte agents de IA gestionados por poco más de una persona. Si usted es founder y observa eso, la tentación es obvia: saltarse por completo la contratación de SDR y comprar los agents en su lugar.
Pero hay una frase en el propio consejo de SaaStr que importa más que el titular. Un AI SDR, anotan, es un force multiplier para una motion que ya funciona, no un arreglo para una que no funciona. Esa sola distinción es todo el problema de un lanzamiento de producto nuevo, y es la razón por la que «AI SDR contra human SDR» es el punto de partida equivocado.
Cuando digo outbound engine, me refiero a cuatro cosas, y ninguna es una persona. La primera es una lista de cuentas basada en un ICP real para este producto, no heredada de la empresa que lo construyó. La segunda es una razón para contactar ahora: un trigger event, una tecnología instalada, un patrón de contrataciones, algo que justifique el timing. La tercera es una secuencia y una oferta que valga la pena responder, escritas y probadas en lugar de supuestas. La cuarta es la plomería de datos por debajo de todo: el modelo de objetos del CRM, el enrichment, el routing, el reporting, para que la motion sea medible desde el primer envío.
Eso es el engine. El SDR, humano o de IA, es la mano de obra que lo hace correr. La mano de obra no es el engine. Y aquí está la parte que los founders se saltan: si no hay engine, automatizar la mano de obra no automatiza nada. Compró una forma más rápida de enviar una suposición.
Un AI SDR es realmente un force multiplier. Si el outbound ya funciona con humanos, los agents lo hacen más barato, más rápido y más consistente, y el argumento a su favor es sólido. El problema es la palabra «ya». Una motion que funciona es una lista definida, sincronizada con una señal real, pasada por una secuencia probada, que produce respuestas y agenda reuniones. Cuando eso existe, multiplicar es inteligente.
Cuando el producto se lanzó el mes pasado y nadie ha corrido una sola secuencia, no hay motion que multiplicar. Está apuntando un multiplicador al cero. Los agents enviarán obedientemente mil correos construidos sobre un ICP que nadie validó, contra una lista que nadie defendió, con una oferta que nadie probó, y lo harán a una escala que hace el error más difícil de ver, no más fácil. La versión honesta de «¿debo comprar un AI SDR para mi producto nuevo?» es «no, porque todavía no tiene la cosa que se supone que debe multiplicar».
La otra mitad de esto es el go-to-market engineer, y quiero hacerle justicia al rol porque es real y es útil. La capa de ejecución de un outbound engine moderno hoy sí es ingeniería: Clay, enrichment waterfalls, Apollo, herramientas scriptables con Claude, todo el stack. Alguien tiene que construir y operar eso. Ese es el GTM engineer, y quiere uno.
Lo que no haría es confundir a esa persona con la que diseña el engine. Muchos operadores que se presentan como GTM engineers están certificados en Clay, han construido algunas secuencias y nunca se sentaron dentro de un ciclo de ventas real. Esa es una habilidad de ejecución, no de estrategia. La persona que decide el ICP, la señal y la oferta debe haber visto deals ganarse y perderse, porque el engine solo vale lo que valen esas decisiones. Construir contra diseñar es la distinción, y un equipo lean necesita ambos, incluso cuando son dos personas con cuatro sombreros.
Hace poco encuadramos exactamente esto con una empresa de infraestructura de datos que estaba levantando una segunda línea de producto junto a su negocio principal. El founder ya había automatizado su propia función de sourcing de reclutamiento, sin sourcers en la nómina, y preguntaba razonablemente por qué el sales development debería ser diferente. Pregunta legítima, y la respuesta es instructiva.
El sourcing se automatizó porque primero tenía una motion que funcionaba: un perfil de candidato definido, un canal que producía respuestas, una secuencia que agendaba llamadas. Automatizaron algo que ya funcionaba. El producto nuevo no tenía nada de eso. No había un ICP escrito, no había lista de cuentas, no había señal para sincronizar el outreach, y ninguna secuencia probada por nadie. Automatizar la función SDR ahí no habría automatizado una motion. Habría automatizado una hipótesis, en volumen, antes de que alguien comprobara si era verdad.
- Escriba el ICP y la buying persona para el producto nuevo. Nuevo producto, nuevo comprador. No herede el perfil de la casa matriz solo porque el logo en el deck es el mismo.
- Construya una lista de cuentas que pueda defender, basada en una señal real: un trigger event, una tecnología instalada, un patrón de funding o de contrataciones. Una lista sin una razón para contactar ahora es solo una base de datos.
- Escriba y pruebe una secuencia y una oferta a mano. Consiga diez respuestas reales antes de automatizar un solo envío. Barato, falsable, y le dice si el engine tiene algo de tracción.
- Monte la plomería de datos. El modelo de objetos del CRM, el enrichment, el routing y el reporting, para que la motion esté instrumentada desde el día uno en lugar de reconstruida después.
- Solo ahora decida la mano de obra. Con el engine construido y probado a pequeña escala, un solo operador más la automatización hace correr lo que antes requería un equipo, y el AI SDR por fin se convierte en el force multiplier que le vendieron en lugar de una forma cara de escalar una suposición.
Probablemente terminará con menos SDR de los que habría contratado hace dos años. Esa parte de la predicción es correcta, y no la discuto. Pero llega ahí construyendo primero el engine y automatizando una motion que ya funciona, no comprando agents y esperando que aparezca una motion detrás de ellos. Si está lanzando outbound para un producto nuevo y quiere un segundo par de manos en el engine antes de decidir la mano de obra, ese es justamente el trabajo que hacemos en programmatic outbound y estrategia GTM, así que cuéntenos qué está lanzando.
- SaaStr. «Dear SaaStr: Should I Use an AI SDR Before I Have a Working Human SDR Motion?» 2026. saastr.com
- SaaStr. «Why Most SDRs Will Be AI SDRs In 2026+.» 2026. saastr.com
- Lenny’s Newsletter. «We Replaced Our Sales Team With 20 AI Agents, Here’s What Happened Next.» Enero de 2026. lennysnewsletter.com