Ein Gründer, mit dem ich kürzlich gesprochen habe, launcht ein zweites Produkt. Neuer Käufer, neue Wettbewerber, ein anderer ICP als der, in den das Kerngeschäft seit Jahren verkauft. Das Go-to-Market-Team dafür besteht aus zwei Personen: einem Account Executive und einem Go-to-Market Engineer. Keine SDRs, kein Field Marketing, niemand für einen Messestand. Und die erste Frage auf dem Tisch war nicht „Wie bauen wir Pipeline auf“, sondern „Brauchen wir überhaupt SDRs, oder setzen wir einfach AI Agents darauf an?“ Das ist der richtige Instinkt an der falschen ersten Frage.
Die Frage ist dieses Jahr aus gutem Grund überall. Die Ökonomie cadence-basierter Sales Development hat sich gedreht. SaaStr argumentiert inzwischen, dass die meisten SDRs 2026 und danach AI SDRs sein werden, und die meistzitierte Version der Geschichte ist Jason Lemkin, der ein rund zehnköpfiges Sales-Team durch zwanzig AI Agents ersetzt, gesteuert von kaum mehr als einer Person. Wer als Gründer das beobachtet, verspürt eine naheliegende Versuchung: den SDR-Hire ganz überspringen und stattdessen die Agents kaufen.
Aber es gibt einen Satz in SaaStrs eigenem Rat, der mehr zählt als die Überschrift. Ein AI SDR, schreiben sie, ist ein Force Multiplier für eine Motion, die bereits funktioniert, kein Reparaturmittel für eine, die es nicht tut. Genau diese Unterscheidung ist das ganze Problem bei einem neuen Produkt-Launch, und sie ist der Grund, warum „AI SDR versus Human SDR“ der falsche Ausgangspunkt ist.
Wenn ich Outbound-Engine sage, meine ich vier Dinge, und keines davon ist eine Person. Das erste ist eine Zielliste auf Basis eines echten ICP für dieses Produkt, nicht vererbt von dem Unternehmen, das es gebaut hat. Das zweite ist ein Grund, gerade jetzt zu kontaktieren: ein Trigger-Event, eine installierte Technologie, ein Hiring-Muster, etwas, das das Timing begründet. Das dritte ist eine Sequenz und ein Angebot, auf die zu antworten sich lohnt, geschrieben und getestet statt angenommen. Das vierte ist die Datenbasis darunter: das CRM-Objektmodell, das Enrichment, das Routing, das Reporting, damit die Motion ab dem ersten Versand messbar ist.
Das ist die Engine. Der SDR, ob Mensch oder AI, ist die Arbeitskraft, die sie betreibt. Die Arbeitskraft ist nicht die Engine. Und hier ist der Teil, den Gründer überspringen: Wenn es keine Engine gibt, automatisiert das Automatisieren der Arbeitskraft nichts. Sie haben einen schnelleren Weg gekauft, eine Vermutung zu verschicken.
Ein AI SDR ist tatsächlich ein Force Multiplier. Wenn Outbound mit Menschen bereits funktioniert, machen Agents es günstiger, schneller und konsistenter, und das Argument für sie ist stark. Das Problem ist das Wort „bereits“. Eine funktionierende Motion ist eine, in der eine definierte Liste, getimt an einem echten Signal, durch eine getestete Sequenz geführt, Antworten erzeugt und Meetings bucht. Wenn das existiert, ist Multiplizieren klug.
Wenn das Produkt letzten Monat gelauncht ist und niemand eine einzige Sequenz gefahren hat, gibt es keine Motion zum Multiplizieren. Sie richten einen Multiplikator auf null. Die Agents verschicken brav tausend E-Mails, die auf einem von niemandem validierten ICP beruhen, gegen eine von niemandem verteidigte Liste, mit einem von niemandem getesteten Angebot, und sie tun es in einem Umfang, der den Fehler schwerer sichtbar macht, nicht leichter. Die ehrliche Version von „Soll ich einen AI SDR für mein neues Produkt kaufen“ lautet „Nein, weil Sie das, was er multiplizieren soll, noch nicht haben.“
Die andere Hälfte davon ist der Go-to-Market Engineer, und ich will der Rolle gerecht werden, denn sie ist real und nützlich. Der Execution-Layer einer modernen Outbound-Engine ist heute tatsächlich Engineering: Clay, Enrichment-Waterfalls, Apollo, Claude-skriptbares Tooling, der ganze Stack. Irgendjemand muss das bauen und betreiben. Das ist der GTM Engineer, und Sie wollen einen.
Was ich nicht tun würde, ist diese Person mit der zu verwechseln, die die Engine entwirft. Viele Operator, die sich als GTM Engineers bezeichnen, sind Clay-zertifiziert, haben ein paar Sequenzen gebaut und nie in einem echten Sales Cycle gesessen. Das ist eine Execution-Fähigkeit, keine Strategie-Fähigkeit. Wer ICP, Signal und Angebot entscheidet, muss Deals gewinnen und verlieren gesehen haben, denn die Engine ist nur so gut wie diese Entscheidungen. Bauen versus Entwerfen ist die Unterscheidung, und ein schlankes Team braucht beides, selbst wenn es zwei Personen mit vier Hüten sind.
Wir haben genau das kürzlich mit einem Dateninfrastruktur-Unternehmen durchgespielt, das neben seinem Kerngeschäft eine zweite Produktlinie aufbaut. Der Gründer hatte die eigene Recruiting-Sourcing-Funktion bereits automatisiert, ohne verbliebene Sourcer auf der Gehaltsliste, und fragte verständlicherweise, warum Sales Development anders sein sollte. Faire Frage, und die Antwort ist lehrreich.
Sourcing wurde automatiert, weil es zuerst eine funktionierende Motion hatte: ein definiertes Kandidatenprofil, einen Kanal, der Antworten erzeugte, eine Sequenz, die Gespräche buchte. Sie haben etwas automatisiert, das bereits funktionierte. Das neue Produkt hatte nichts davon. Es gab keinen aufgeschriebenen ICP, keine Zielliste, kein Signal, an dem sich Outreach timen ließe, und keine von irgendjemandem getestete Sequenz. Die SDR-Funktion dort zu automatisieren hätte keine Motion automatisiert. Es hätte eine Hypothese automatisiert, im Volumen, bevor irgendwer geprüft hat, ob sie stimmt.
- Schreiben Sie den ICP und die Buying Persona für das neue Produkt. Neues Produkt, neuer Käufer. Übernehmen Sie nicht das Profil der Muttergesellschaft, nur weil dasselbe Logo auf dem Deck steht.
- Bauen Sie eine Zielliste, die Sie verteidigen können, auf Basis eines echten Signals: ein Trigger-Event, eine installierte Technologie, ein Funding- oder Hiring-Muster. Eine Liste ohne einen Grund, gerade jetzt zu kontaktieren, ist nur eine Datenbank.
- Schreiben und testen Sie eine Sequenz und ein Angebot von Hand. Holen Sie zehn echte Antworten, bevor Sie einen einzigen Versand automatisieren. Günstig, falsifizierbar, und es zeigt Ihnen, ob die Engine überhaupt Zugkraft hat.
- Stellen Sie die Datenbasis auf. Das CRM-Objektmodell, Enrichment, Routing und Reporting, damit die Motion ab Tag eins instrumentiert ist, statt sie später zu rekonstruieren.
- Erst jetzt entscheiden Sie über die Arbeitskraft. Mit gebauter und im Kleinen bewiesener Engine steuert eine Person plus Automatisierung, was früher ein Team brauchte, und der AI SDR wird endlich zum Force Multiplier, als der er verkauft wird, statt zu einer teuren Art, eine Vermutung zu skalieren.
Sie werden wahrscheinlich mit weniger SDRs enden, als Sie vor zwei Jahren eingestellt hätten. Dieser Teil der Vorhersage stimmt, und ich argumentiere nicht dagegen. Aber Sie kommen dorthin, indem Sie zuerst die Engine bauen und eine Motion automatisieren, die bereits funktioniert, nicht indem Sie Agents kaufen und hoffen, dass dahinter eine Motion auftaucht. Wenn Sie Outbound für ein neues Produkt aufbauen und ein zweites Paar Hände an der Engine wollen, bevor Sie über die Arbeitskraft entscheiden, ist das genau die Arbeit, die wir in Programmatic Outbound und GTM-Strategie machen, also erzählen Sie uns, was Sie launchen.
- 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.“ Januar 2026. lennysnewsletter.com