Un founder con cui ho parlato di recente sta lanciando un secondo prodotto. Nuovo acquirente, nuovi concorrenti, un ICP diverso da quello a cui il core business vende da anni. Il team go-to-market dedicato è di due persone: un account executive e un go-to-market engineer. Niente SDR, niente field marketing, nessuno a presidiare uno stand. E la prima domanda sul tavolo non era «come costruiamo pipeline», era «ci servono davvero gli SDR, o possiamo semplicemente puntarci degli agent IA?» È l’istinto giusto attaccato alla prima domanda sbagliata.
Quest’anno la domanda è ovunque, e per una buona ragione. L’economia del sales development a cadenza si è ribaltata. SaaStr ora sostiene che la maggior parte degli SDR saranno AI SDR nel 2026 e oltre, e la versione più citata della storia è Jason Lemkin che sostituisce un team commerciale di circa dieci persone con venti agent IA gestiti da poco più di una persona. Se è un founder e osserva questo, la tentazione è ovvia: saltare del tutto l’assunzione di SDR e comprare gli agent.
Ma c’è una frase nel consiglio stesso di SaaStr che conta più del titolo. Un AI SDR, scrivono, è un force multiplier per una motion che già funziona, non un rimedio per una che non funziona. Questa singola distinzione è tutto il problema di un lancio di nuovo prodotto, ed è il motivo per cui «AI SDR contro human SDR» è il punto di partenza sbagliato.
Quando dico outbound engine, intendo quattro cose, e nessuna è una persona. La prima è una lista di account basata su un vero ICP per questo prodotto, non ereditata dall’azienda che l’ha costruito. La seconda è un motivo per contattare adesso: un trigger event, una tecnologia installata, uno schema di assunzioni, qualcosa che giustifichi il timing. La terza è una sequenza e un’offerta a cui vale la pena rispondere, scritte e testate invece che presunte. La quarta è l’impianto dati sotto a tutto: il modello a oggetti del CRM, l’enrichment, il routing, il reporting, perché la motion sia misurabile dal primo invio.
Questo è l’engine. L’SDR, umano o IA, è la manodopera che lo fa girare. La manodopera non è l’engine. Ed ecco la parte che i founder saltano: se non c’è un engine, automatizzare la manodopera non automatizza nulla. Ha comprato un modo più rapido per spedire un’ipotesi.
Un AI SDR è davvero un force multiplier. Se l’outbound già funziona con le persone, gli agent lo rendono più economico, più veloce e più costante, e l’argomento a loro favore è solido. Il problema è la parola «già». Una motion che funziona è una lista definita, sincronizzata su un segnale vero, fatta passare attraverso una sequenza testata, che produce risposte e prenota meeting. Quando esiste, moltiplicare è intelligente.
Quando il prodotto è stato lanciato il mese scorso e nessuno ha fatto girare una singola sequenza, non c’è una motion da moltiplicare. Sta puntando un moltiplicatore sullo zero. Gli agent invieranno diligentemente mille e-mail costruite su un ICP che nessuno ha validato, contro una lista che nessuno ha difeso, con un’offerta che nessuno ha testato, e lo faranno a una scala che rende l’errore più difficile da vedere, non più facile. La versione onesta di «devo comprare un AI SDR per il mio nuovo prodotto» è «no, perché non ha ancora la cosa che dovrebbe moltiplicare».
L’altra metà è il go-to-market engineer, e voglio rendere giustizia al ruolo, perché è reale ed è utile. Il livello di execution di un outbound engine moderno oggi è davvero engineering: Clay, enrichment waterfall, Apollo, tooling scriptabile con Claude, l’intero stack. Qualcuno deve costruirlo e farlo girare. Quello è il GTM engineer, e ne vuole uno.
Quello che non farei è scambiare quella persona per quella che progetta l’engine. Molti operatori che si presentano come GTM engineer sono certificati Clay, hanno costruito qualche sequenza e non si sono mai seduti dentro un vero ciclo di vendita. È una competenza di execution, non di strategia. Chi decide l’ICP, il segnale e l’offerta deve aver visto deal vinti e persi, perché l’engine vale solo quanto quelle decisioni. Costruire contro progettare è la distinzione, e un team lean ha bisogno di entrambi, anche quando sono due persone con quattro cappelli.
Di recente abbiamo inquadrato esattamente questo con un’azienda di infrastruttura dati che stava avviando una seconda linea di prodotto accanto al core business. Il founder aveva già automatizzato la propria funzione di sourcing per il recruiting, senza più sourcer a libro paga, e chiedeva ragionevolmente perché il sales development dovrebbe essere diverso. Domanda legittima, e la risposta è istruttiva.
Il sourcing è stato automatizzato perché aveva prima una motion funzionante: un profilo di candidato definito, un canale che produceva risposte, una sequenza che prenotava call. Hanno automatizzato qualcosa che già funzionava. Il nuovo prodotto non aveva nulla di tutto ciò. Non c’era un ICP scritto, non c’era una lista di account, non c’era un segnale su cui sincronizzare l’outreach, e nessuna sequenza testata da chicchessia. Automatizzare la funzione SDR lì non avrebbe automatizzato una motion. Avrebbe automatizzato un’ipotesi, in volume, prima che qualcuno verificasse se fosse vera.
- Scriva l’ICP e la buying persona per il nuovo prodotto. Nuovo prodotto, nuovo acquirente. Non erediti il profilo della casa madre solo perché sul deck c’è lo stesso logo.
- Costruisca una lista di account che può difendere, basata su un segnale vero: un trigger event, una tecnologia installata, uno schema di funding o di assunzioni. Una lista senza un motivo per contattare adesso è solo un database.
- Scriva e testi a mano una sequenza e un’offerta. Ottenga dieci risposte vere prima di automatizzare un solo invio. Economico, falsificabile, e le dice se l’engine ha una qualche trazione.
- Allestisca l’impianto dati. Il modello a oggetti del CRM, l’enrichment, il routing e il reporting, perché la motion sia strumentata dal primo giorno invece che ricostruita dopo.
- Solo ora decida la manodopera. Con l’engine costruito e dimostrato su piccola scala, un solo operatore più l’automazione fa girare ciò che richiedeva un team, e l’AI SDR diventa finalmente il force multiplier che le hanno venduto invece di un modo costoso per scalare un’ipotesi.
Probabilmente finirà con meno SDR di quanti ne avrebbe assunti due anni fa. Quella parte della previsione è corretta, e non la contesto. Ma ci arriva costruendo prima l’engine e automatizzando una motion che già funziona, non comprando agent e sperando che dietro compaia una motion. Se sta lanciando outbound per un nuovo prodotto e vuole un secondo paio di mani sull’engine prima di decidere la manodopera, è esattamente il lavoro che facciamo in programmatic outbound e strategia GTM, quindi ci racconti cosa sta lanciando.
- 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.» Gennaio 2026. lennysnewsletter.com