Perché il fallimento degli AI SDR comincia sotto il pulsante di invio
Nell'ultimo anno, i vendor di AI SDR autonomi hanno ricevuto critiche pubbliche per ARR gonfiato e churn dei clienti. Non entrerò nel merito di nessun vendor in particolare, anche perché non posso vedere i loro conti. Posso però parlare del pattern, perché lo osserviamo allo stesso modo dal lato di chi compra.
Gli agenti inviano. Inviano tanto, in fretta e con una prosa dignitosa. L'invio non è mai stata la parte difficile. Il fallimento degli AI SDR avviene nell'operating layer: le definizioni di pipeline, i feedback loop del CRM e le logiche di disqualificazione che dicono a un agente che cos'è un buon risultato. Senza di questi, l'agente ottimizza l'unica cosa che riesce a vedere, cioè l'attività.
Lo scopo di questo post è quindi dare un nome a queste tre parti, mostrare un esempio di come ciascuna si rompe e dire cosa farei io. Livello strategico, non una guida pratica. La costruzione è la parte in cui conviene avere qualcuno che lavori insieme a voi.
Che cos'è l'operating layer sotto un AI SDR?
L'operating layer è l'insieme di regole e dati costruiti dalle persone che stabiliscono che cos'è un lead, che cos'è un meeting e che cos'è un vicolo cieco. Lo chiamerò underlay. Un agente SDR ci poggia sopra.
Le parti sono tre:
- Definizioni di pipeline: cosa conta come meeting qualificato, come opportunity, come cambio di stage.
- Il feedback loop del CRM: come i risultati tornano indietro, così che l'agente impari cosa ha funzionato.
- Logiche di disqualificazione: le regole su chi non viene mai contattato, o viene rimosso dopo il primo segnale.
Un SDR umano se la cava con un underlay sottile perché una persona assorbe le parti mancanti negli standup, nelle deal review, in corridoio. Un agente non ha un corridoio.
Definizioni di pipeline: l'agente raggiunge il numero che gli avete dato
Immaginiamo un team B2B SaaS che chiede al proprio agente di fissare meeting. Nessuno ha messo per iscritto cosa sia un meeting. Una call di 15 minuti con uno stagista conta? Un no-show riprogrammato conta due volte?
L'agente fissa 120 meeting in un mese. La dashboard è splendida. Gli AE li prendono, e un terzo è con persone senza autorità di budget e senza un problema attivo. Il vendor dichiara successo perché la metrica del contratto erano i meeting. Il cliente se ne va due trimestri dopo perché la pipeline non si è mossa.
La mia sensazione è che molti fallimenti degli AI SDR comincino così, e che così nascano anche alcune delle storie pubbliche sui numeri gonfiati. Nessuno deve per forza mentire. Il numero è stato definito al livello sbagliato.
La soluzione è noiosa. Mettete per iscritto la definizione, salvatela nel CRM come campo con valori controllati e misurate l'agente sullo stage a valle, non sulla prenotazione. In HubSpot è una property con opzioni definite, non una nota in testo libero.
Il feedback loop del CRM: senza risultati non c'è apprendimento
Un agente può migliorare solo se i risultati gli tornano indietro. Per bene o per male, la maggior parte dei CRM è piena di stage obsoleti e campi compilati a metà. I buyer con cui parliamo descrivono SDR che commettono errori manuali quando aggiornano le relazioni account-contatto in Salesforce. Se le persone sbagliano, un agente che legge gli stessi record impara dal rumore.
Ecco un esempio. Un agente scrive a un contatto che ha lasciato l'account sei mesi fa, perché la relazione non è mai stata aggiornata. L'email rimbalza o riceve una risposta vaga. Nulla viene riscritto nel record. La settimana dopo l'agente riprova. Quel ciclo è il fallimento degli AI SDR in miniatura: attività sicura di sé, zero apprendimento.
Il divario si vede anche lato AE. Un cliente ci ha raccontato che i suoi account executive si concentrano su tempistica di firma e budget e non scavano abbastanza a fondo nei pain driver. I motivi di closed-won e closed-lost restano scarni, quindi nulla dice al sistema quali pain abbiano previsto un deal. Non si può addestrare il targeting su dati che nessuno ha raccolto.
Io farei un audit del percorso di write-back prima di comprare qualsiasi cosa. Quali risultati arrivano nel CRM, in quali campi, inseriti da chi, entro quanto tempo? Se la risposta è "dipende dal rep", avete il vostro primo progetto, e non è un progetto sull'agente.
Logiche di disqualificazione: le regole su chi non contattare
Questa è la parte che vedo saltare più spesso. I team definiscono il proprio ICP e dimenticano le esclusioni: clienti esistenti, opportunity aperte, concorrenti, regioni che il team non riesce a seguire, aziende troppo piccole per pagare.
Un cliente ci ha detto che l'outreach in EMEA è difficile per loro e che la persona che lo copre non si trova a suo agio al telefono. Un altro temeva che gli SDR non eseguissero le attività telefoniche previste nei workflow delle campagne. Inserite un agente in questo scenario senza logiche di disqualificazione e inizierà a colpire account EMEA che il team non riesce a lavorare, poi fisserà richiami che nessuno farà. Il volume sale, la conversione scende e tutti danno la colpa all'agente.
Le regole pratiche qui costano poco: per ogni criterio ICP che scrivete, scrivete un'esclusione accanto. Cinque inclusioni e nessuna esclusione significano che l'agente lavora con metà brief, e quel mezzo brief è una radice comune del fallimento degli AI SDR.
Come sequenzierei un rollout per evitare il fallimento degli AI SDR?
Tre fasi, e l'ordine è il punto:
- Prima le definizioni. Stage di pipeline, criteri dei meeting ed esclusioni, scritti e codificati nel CRM. Due o tre settimane in un progetto snello.
- Poi il feedback. Campi per i risultati, write-back obbligatori e un controllo settimanale sul fatto che i motivi di closed-lost siano reali.
- Terzo l'agente, su un segmento ristretto, misurato sulle opportunity create e non sugli invii.
Lo facciamo così perché più avanti, quando qualcuno chiede perché l'agente ha fatto una certa cosa, potete ricondurla a una regola scritta da una persona. Senza questo non si può fare debug. Si può solo spegnere.
È anche per questo che è un problema di RevOps e non di tooling. Se fate RevOps di mestiere, siete dei project manager con una specializzazione, e questo è un progetto: concordare le definizioni, codificarle, strumentare i risultati. La scelta del vendor viene dopo, e un CRM come Salesforce o HubSpot può contenere tutto.
Cosa non so sul fallimento degli AI SDR
Non ho una risposta convincente sul fatto che gli agenti autonomi arriveranno prima o poi a dedurre queste regole da soli. Forse. I vendor lo dicono, e i modelli continuano a migliorare. La mia esperienza è che anche un nuovo assunto molto bravo ha bisogno delle definizioni, e un agente è un nuovo assunto velocissimo senza un manager.
Non posso nemmeno verificare il fatturato di alcun vendor, quindi considerate la mia lettura come un pattern, non come un verdetto. Posso dire che il fallimento degli AI SDR emerge ovunque manchi l'underlay, e che questo si verifica in un pomeriggio.
Se state valutando un agente in questo momento, il mio consiglio è di porre al vostro team tre domande prima della demo: cosa conta come meeting, dove vengono riscritti i risultati e chi non viene mai contattato. Se le risposte richiedono più di un minuto, ripartite da lì. Trovate di più su come affrontiamo questo tipo di lavoro nella nostra libreria di insight.