← Alle Insights
ai-sdrRevOpspipelinecrm-hygiene

Das Scheitern von KI-SDRs ist ein Problem der Betriebsebene, kein Versandproblem

Anbieter autonomer KI-SDRs stehen öffentlich wegen aufgeblähtem ARR und Kundenabwanderung in der Kritik. Die Agenten versenden einwandfrei. Was bricht, ist die Betriebsebene darunter, und das ist ein RevOps-Problem.

Warum das Scheitern von KI-SDRs unterhalb des Senden-Buttons beginnt

Im vergangenen Jahr standen Anbieter autonomer KI-SDRs öffentlich in der Kritik, wegen aufgeblähtem ARR und Kundenabwanderung. Ich werde hier keinen einzelnen Anbieter beurteilen, auch weil ich deren Zahlen nicht einsehen kann. Worüber ich sprechen kann, ist das Muster, denn wir sehen dasselbe von der Käuferseite aus.

Die Agenten versenden. Sie versenden viel, schnell und in ordentlicher Prosa. Der Versand war nie der schwierige Teil. Das Scheitern von KI-SDRs geschieht in der Betriebsebene: in den Pipeline-Definitionen, den CRM-Feedbackschleifen und der Disqualifizierungslogik, die einem Agenten sagen, was ein gutes Ergebnis ist. Ohne sie optimiert der Agent auf das Einzige, was er sehen kann: Aktivität.

Dieser Beitrag soll deshalb diese drei Bestandteile benennen, für jeden ein Beispiel für sein Versagen geben und sagen, was ich dagegen tun würde. Strategieebene, keine Anleitung. Der Aufbau ist der Teil, bei dem Sie jemanden an Ihrer Seite haben möchten, der eingebettet mitarbeitet.

Was ist die Betriebsebene unter einem KI-SDR?

Die Betriebsebene ist die Gesamtheit der von Menschen aufgebauten Regeln und Daten, die entscheiden, was ein Lead ist, was ein Meeting ist und was eine Sackgasse ist. Ich nenne sie das Fundament. Ein SDR-Agent sitzt darauf.

Es gibt drei Bestandteile:

  1. Pipeline-Definitionen: was als qualifiziertes Meeting, als Opportunity, als Phasenwechsel zählt.
  2. Die CRM-Feedbackschleife: wie Ergebnisse zurückfließen, damit der Agent lernt, was funktioniert hat.
  3. Disqualifizierungslogik: die Regeln dafür, wer nie kontaktiert oder nach dem ersten Signal wieder entfernt wird.

Ein menschlicher SDR kommt mit einem dünnen Fundament davon, weil ein Mensch die fehlenden Teile in Standups, in Deal-Reviews und auf dem Flur aufnimmt. Ein Agent hat keinen Flur.

Pipeline-Definitionen: Der Agent erreicht die Zahl, die Sie ihm geben

Nehmen wir an, ein B2B-SaaS-Team weist seinen Agenten an, Meetings zu buchen. Niemand hat aufgeschrieben, was ein Meeting ist. Zählt ein 15-minütiges Gespräch mit einem Praktikanten? Zählt ein neu gebuchter Nichterscheinen-Termin doppelt?

Der Agent bucht in einem Monat 120 Meetings. Das Dashboard sieht großartig aus. Die AEs übernehmen sie, und ein Drittel davon findet mit Personen statt, die weder Budgetverantwortung noch ein akutes Problem haben. Der Anbieter meldet Erfolg, weil die Vertragskennzahl Meetings war. Der Käufer kündigt zwei Quartale später, weil sich die Pipeline nicht bewegt hat.

Mein Eindruck ist, dass so das Scheitern von KI-SDRs häufig beginnt und so manche der öffentlichen Geschichten über aufgeblähte Zahlen entstehen. Niemand muss lügen. Die Zahl wurde auf der falschen Ebene definiert.

Die Lösung ist unspektakulär. Schreiben Sie die Definition auf, hinterlegen Sie sie im CRM als Feld mit kontrollierten Werten und messen Sie den Agenten an der nachgelagerten Phase, nicht an der Buchung. In HubSpot ist das eine Eigenschaft mit definierten Optionen, keine Freitextnotiz.

Die CRM-Feedbackschleife: Ohne Ergebnisse kein Lernen

Ein Agent kann sich nur verbessern, wenn Ergebnisse zu ihm zurückfließen. Die meisten CRMs sind, im Guten wie im Schlechten, voller veralteter Phasen und halb ausgefüllter Felder. Käufer, mit denen wir sprechen, beschreiben, dass SDRs beim Aktualisieren von Account-Kontakt-Beziehungen in Salesforce manuelle Fehler machen. Wenn Menschen das falsch machen, lernt ein Agent, der dieselben Datensätze liest, aus Rauschen.

Ein Beispiel: Ein Agent schreibt einen Kontakt an, der den Account vor sechs Monaten verlassen hat, weil die Beziehung nie aktualisiert wurde. Die E-Mail wird zurückgewiesen oder erhält eine vage Antwort. Nichts wird in den Datensatz zurückgeschrieben. In der nächsten Woche versucht der Agent es erneut. Diese Schleife ist das Scheitern von KI-SDRs im Kleinen: selbstsichere Aktivität, null Lerneffekt.

Die Lücke zeigt sich auch auf der AE-Seite. Ein Kunde erzählte uns, dass sich seine Account Executives auf Abschlusszeitpunkt und Budget konzentrieren und nicht tief genug nach den Schmerzpunkten fragen. Die Gründe für Closed-won und Closed-lost bleiben dadurch dünn, sodass nichts dem System sagt, welche Schmerzpunkte einen Abschluss vorhergesagt haben. Man kann das Targeting nicht mit Daten trainieren, die niemand erfasst hat.

Ich würde den Rückschreibeweg prüfen, bevor ich irgendetwas kaufe. Welche Ergebnisse landen im CRM, in welchen Feldern, von wem eingetragen und innerhalb welcher Frist? Lautet die Antwort „Das hängt vom Vertriebsmitarbeiter ab“, haben Sie Ihr erstes Projekt, und es ist kein Agentenprojekt.

Disqualifizierungslogik: Die Regeln dafür, wen man nicht kontaktiert

Das ist der Teil, den ich am häufigsten übersprungen sehe. Teams definieren ihr ICP und vergessen die Ausschlüsse: Bestandskunden, offene Opportunities, Wettbewerber, Regionen, in denen das Team nicht nachfassen kann, und Unternehmen, die zu klein sind, um zu zahlen.

Ein Kunde sagte uns, dass die Ansprache in EMEA für ihn schwierig sei und die zuständige Person sich am Telefon unwohl fühle. Ein anderer befürchtete, dass SDRs die in Kampagnen-Workflows eingebauten Telefonaufgaben nicht ausführen würden. Setzt man in dieses Bild einen Agenten ohne Disqualifizierungslogik, schießt er auf EMEA-Accounts, die das Team nicht bearbeiten kann, und bucht Rückrufe, die niemand durchführt. Das Volumen steigt, die Konversion sinkt, und alle geben dem Agenten die Schuld.

Faustregeln sind hier günstig: Schreiben Sie zu jedem ICP-Kriterium einen Ausschluss daneben. Fünf Einschlüsse und keine Ausschlüsse bedeuten, dass der Agent mit einem halben Briefing arbeitet, und dieses halbe Briefing ist eine häufige Ursache für das Scheitern von KI-SDRs.

Wie würde ich einen Rollout staffeln, um das Scheitern von KI-SDRs zu vermeiden?

Drei Phasen, und die Reihenfolge ist entscheidend:

  1. Zuerst die Definitionen. Pipeline-Phasen, Meeting-Kriterien und Ausschlüsse, aufgeschrieben und im CRM abgebildet. Zwei bis drei Wochen in einem schlanken Projekt.
  2. Danach das Feedback. Ergebnisfelder, verpflichtendes Rückschreiben und eine wöchentliche Prüfung, ob die Closed-lost-Gründe echt sind.
  3. Der Agent kommt an dritter Stelle, in einem engen Segment, gemessen an erzeugten Opportunities und nicht an Versandzahlen.

Wir gehen so vor, damit Sie später, wenn jemand fragt, warum der Agent etwas getan hat, dies auf eine von einem Menschen geschriebene Regel zurückführen können. Ohne das lässt sich der Agent nicht debuggen. Man kann ihn nur abschalten.

Deshalb ist das auch ein RevOps-Problem und kein Tooling-Problem. Wer beruflich RevOps betreibt, ist ein Projektmanager mit Spezialgebiet, und dies ist ein Projekt: Definitionen abstimmen, abbilden, Ergebnisse instrumentieren. Die Anbieterwahl kommt danach, und ein CRM wie Salesforce oder HubSpot kann das alles abbilden.

Was ich über das Scheitern von KI-SDRs nicht weiß

Ich habe keine überzeugende Antwort darauf, ob autonome Agenten diese Regeln irgendwann selbst ableiten werden. Vielleicht. Die Anbieter behaupten es, und die Modelle werden immer besser. Meine Erfahrung ist, dass selbst ein starker neuer Mitarbeiter die Definitionen braucht, und ein Agent ist ein schneller neuer Mitarbeiter ohne Vorgesetzten.

Ich kann auch die Umsätze keines Anbieters prüfen, verstehen Sie meine Einschätzung also als Muster, nicht als Urteil. Sicher sagen kann ich, dass das Scheitern von KI-SDRs überall dort auftritt, wo das Fundament fehlt, und das lässt sich an einem Nachmittag überprüfen.

Wenn Sie gerade einen Agenten in Erwägung ziehen, empfehle ich Ihnen, Ihrem eigenen Team vor der Demo drei Fragen zu stellen: Was zählt als Meeting, wohin werden Ergebnisse zurückgeschrieben, und wer wird nie kontaktiert? Wenn die Antworten länger als eine Minute dauern, beginnen Sie dort. Mehr dazu, wie wir diese Art von Arbeit angehen, finden Sie in unserer Insights-Bibliothek.

Noah Charak
Noah Charak
Managing Director

Gründer von Checkpoint GTM. 15 Jahre Revenue und Business Operations im Berliner Start-up-Ökosystem, mit über 65 abgeschlossenen Transformationsprojekten. Spezialist für CRM-Architektur und RevOps, zertifiziert in Salesforce und HubSpot.

LinkedIn

Diesen Beitrag teilen