KI-Vertriebsautomatisierung: 5 HubSpot-Plays

Warum gehören diese fünf KI-Plays zusammen?

Weil sie in dasselbe CRM schreiben und an derselben Stelle scheitern. Jedes der fünf Plays beantwortet eine andere Frage, von der Marktdefinition bis zum Umsatznachweis. Keines davon trägt, wenn der Zustand im CRM nicht stimmt. Deshalb baut man sie als einen Kreislauf und nicht als fünf getrennte Projekte.

Die meisten Playbooks für KI im Vertrieb überzeugen auf der Ebene der Möglichkeit. Was technisch geht, ist beeindruckend. Die eigentliche Arbeit beginnt einen Schritt später, und sie besteht aus fünf unbequemen Fragen: Welcher Datensatz soll sich ändern? Welches System besitzt die Entscheidung? Welche Aktion ist erlaubt? Wer bekommt die Ausnahme? Und woran erkennt man, dass echte Verkaufschancen entstanden sind und nicht bloss Aktivität?

Wer diese fünf Fragen nicht beantwortet, bekommt trotzdem einen laufenden Workflow. Nur zeigt sich das Versäumnis nicht sofort. Es zeigt sich Wochen später, wenn jemand die Datensätze von Hand nachbessert, wenn zwei Kollegen dieselbe Firma ansprechen oder wenn niemand belegen kann, welche Kampagne den Abschluss ausgelöst hat.

Die fünf Plays greifen deshalb ineinander:

1. Play 1 – Zielmarkt aufbauen. Neue passende Unternehmen kommen sauber ins CRM.
2. Play 2 – Kaufsignale erkennen. Website-Aktivität wird zu einem belegten Hinweis.
3. Play 3 – Priorität festlegen. Aus vielen Accounts wird eine begründete Reihenfolge.
4. Play 4 – Anfragen verteilen. Eingehende Nachfrage landet bei der richtigen Person.
5. Play 5 – Wirkung nachweisen. Am Ende steht, welche Ansprache Umsatz erzeugt hat.

Play 1: Wie kommen neue Zielkunden ins CRM, ohne Chaos anzurichten?

Neue Zielkunden zu finden, ist der einfache Teil. Teuer wird der Schritt danach. Die Firma steht längst im CRM, ist bereits Kundin oder wird gerade von einem Kollegen bearbeitet. Play 1 prüft genau das, bevor ein Datensatz entsteht. Und es behandelt die Einschätzung der KI als Vorschlag, nicht als Beschluss.

Der Ablauf selbst ist inzwischen Standard. Werkzeuge wie DiscoLike, Ocean.io, AI Ark oder Clay suchen Unternehmen, die den bisherigen Kunden ähneln. Sie räumen Namen, Domain und LinkedIn-Adresse auf, entfernen Doppelte und lassen die KI bewerten, wie gut ein Unternehmen zum eigenen Markt passt. Das ist nützlich, weil es den Markt erweitert, bevor teure Recherche pro Person beginnt.

Das Risiko liegt nicht im Finden. Es liegt in dem Moment, in dem eine KI-Einschätzung ungeprüft zum verbindlichen CRM-Datensatz wird. Steht erst einmal „Tier 1" in einem Feld, das der Vertrieb als Arbeitsanweisung liest, arbeitet das ganze Team mit einer Vermutung, die niemand bestätigt hat.

Wie die Entscheidung kontrollierbar bleibt

Die KI darf bewerten, wie gut ein Unternehmen passt, und eine Priorität vorschlagen. Was im CRM tatsächlich als freigegeben gilt, entscheidet erst ein definierter Freigabeschritt. Dafür trennt Play 1 drei Gruppen von Feldern:

• Die Felder für Vorschläge (Kandidaten-Properties). Hier landen das Urteil der KI und die Belege dahinter: TAM Source, TAM Added At, AI ICP Recommendation, AI ICP Rationale, Fit Data Completeness, Enrichment Source, Enriched At.
• Die Felder für den freigegebenen Zustand. Sie sagen, was operativ gilt: Approved Account Tier, Tier Review Status, Tier Reviewed At, Allowed Motion, Account Activation Status.
• Die Felder zur Person. Sie halten Rolle und Datenqualität fest: Buying Role, Persona Evidence, Contact Sourcing Status, Contact Data Confidence.

Diese Trennung verhindert, dass ein KI-Ergebnis direkt eine Vertriebsaktion auslöst. „Tier 1" heisst deshalb nicht automatisch „Ansprache starten". Vorher prüft eine Freigabe-Schranke (Activation Gate) vier Dinge: ob der Account schon Kunde ist, ob ein offener Deal kollidiert, ob eine verantwortliche Person eingetragen ist und ob der gewählte Kanal für diesen Kontakt zulässig ist.

Fehlt ein Beleg, setzt der Workflow den Prüfstatus auf „Review Required" und weist die Entscheidung einer Person zu. Der Datensatz fällt damit nicht in einen unbeobachteten Zweig. Er bleibt als offene Entscheidung sichtbar. Auch eine Antwort auf eine Outbound-Nachricht wird nicht automatisch zum Deal: Sie ist zunächst ein Anlass zur Bewertung. Ein Deal entsteht erst, wenn die vereinbarten Kriterien erfüllt sind.

Woran wir messen, ob Play 1 funktioniert

Nicht daran, wie viele Datensätze automatisch entstehen. Sondern daran, ob am Ende belastbare Arbeit herauskommt: Duplikatrate, Anteil der freigegebenen Vorschläge, Zeit vom Eintrag bis zur verantworteten Aktion, Antwort-zu-Verkaufschance je Prioritätsstufe. Dazu die unbequemste Zahl, die Zahl der Datensätze, die ein Mensch nachbessern musste.

Play 2: Was sagt ein Website-Besuch wirklich aus?

Ein Website-Besuch kann ein wertvolles Kaufsignal sein. Er zeigt aber zunächst nur Interesse eines Unternehmens. Er sagt nicht, welche Person dahintersteckt und ob diese Person angesprochen werden darf. Genau diese Unterscheidung bildet Play 2 ab: Aus Website-Aktivität wird ein belegter Hinweis, ohne dass aus einem Firmensignal eine geratene Person wird.

Der Unterschied klingt akademisch und kostet in der Praxis Termine. Wer aus einem Firmenbesuch eine Person ableitet und diese anschreibt, verbrennt genau den Kontakt, den er gewinnen wollte. Wer umgekehrt gar nichts tut, verschenkt das aussagekräftigste Signal, das eine Website liefert.

Unsere These: Der Kontext gehört zum Signal, nicht in den Kopf des Vertriebs. Ein Besuch auf der Preisseite von gestern und ein Blogbesuch von vor sechs Wochen dürfen nicht dieselbe Aktion auslösen. Wird diese Unterscheidung nicht im Workflow festgehalten, entsteht sie pro Fall neu, und jeder im Team entscheidet anders.

So wird der Besuch zu einem belegten Hinweis

Jeder relevante Besuch wird beim sicher zugeordneten Unternehmen als eigenes Ereignis gespeichert, mit Seitengruppe, Häufigkeit, Zeitpunkt, Quelle und einer Angabe dazu, wie sicher die Zuordnung ist. HubSpots Dokumentation zu eigenen Ereignissen beschreibt, wie sich ein solches Ereignis mit eigenen Feldern definieren und dem passenden Objekt zuordnen lässt. Identifiziert die Quelle nur die Firma, bleibt der Hinweis auf Firmenebene.

Daneben hält der aktuelle Firmenzustand fest, was jetzt gilt: Latest Website Signal At, Website Signal Strength, Visitor Source, Signal Review Status, Activation Status. Angesprochen wird erst, wenn vier Bedingungen gleichzeitig erfüllt sind. Der Account passt zum freigegebenen Zielmarkt. Das Signal ist aktuell und geschäftlich relevant. Eine verantwortliche Person existiert. Und die Sperrlisten erlauben die Aktion.

Daraus folgen drei klare Wege. Hoher Fit und starkes Signal erzeugen eine Aufgabe mit Frist. Hoher Fit und schwaches Signal bleiben im Nurturing. Niedriger Fit und starkes Signal erzeugen eine Prüfentscheidung, kein automatisches Outbound.

Eine allgemeingültige Liste kaufnaher Seiten gibt es nicht, und ein allgemeingültiges Zeitfenster für Signalfrische auch nicht. Beides folgt aus der Kaufreise, der Verkehrsqualität und der Kapazität im Vertrieb. Entscheidend ist, dass die Regel im Workflow steht und nicht in einem undokumentierten Prompt. Wer diese Strecke bis zur automatisierten Ansprache weiterdenkt, findet die Systemseite dazu unter AI Outbound.

Woran wir messen, ob Play 2 funktioniert

Anteil der akzeptierten Signale, Zeit vom Signal bis zur verantworteten Aktion, Meetings und Verkaufschancen je Signal-Gruppe, Fehlalarmquote. Und ausdrücklich mitgezählt: jede Ansprache, die auf einer unsicheren Zuordnung beruhte.

Play 3: Wie priorisiert man Accounts, ohne sich selbst zu täuschen?

Zwei Fragen entscheiden über Priorität, und sie werden regelmässig vermischt. Passt dieser Account grundsätzlich zu uns? Und bewegt er sich gerade? Play 3 hält beide Antworten getrennt sichtbar und macht die Priorität selbst zu einer dritten Angabe, die bewusst freigegeben wird.

Warum das zählt, merkt man erst im Streitfall. Wenn eine Prioritätsstufe fällt, will jemand wissen, warum. Steckt beides in einer einzigen Zahl, lautet die Antwort „das Modell hat entschieden", und ab dann glaubt der Vertrieb der Zahl nicht mehr.

Unsere These: Wer dauerhafte Passung und kurzfristige Bewegung in eine Zahl presst, verliert die Erklärbarkeit und gewinnt nichts. Die Passung ändert sich über Jahre, die Bewegung über Tage. Zwei Grössen mit unterschiedlicher Halbwertszeit gehören nicht in dasselbe Feld.

Deep Dive Guide · 15 Seiten · kostenlos

Welcher Lead zuerst

Die Rangfolge, die vor der Kampagne stehen muss, nicht danach. Eine Matrix mit zwei Achsen statt einer Zahl und einer Handlung je Feld.

Guide ansehen →

So entsteht die Reihenfolge

Der Startpunkt ist kommerzielle Evidenz, nicht Bauchgefühl: gewonnene und verlorene Deals der letzten 12 bis 24 Monate, dazu die Muster in Deal-Grösse, Zyklusdauer, Branche, Firmengrösse und Region. Daraus entstehen zwei getrennte Bewertungen. Der Fit-Score misst über Firmendaten, ob ein Account in den Markt gehört. Der Engagement-Score misst über Aktivität, was sich gerade ändert. HubSpot unterstützt getrennte Fit-, Engagement- und kombinierte Bewertungen für Kontakte und Unternehmen. Beide Einzelwerte sichtbar zu halten kostet nichts und erklärt jede Entscheidung.

Dazu kommen Felder, die den Zustand nachvollziehbar machen: Score Model Version, Tier Evaluation At, Tier Review Status, Tier Override Reason, Previous Approved Tier. Wer als Mensch übersteuert, hinterlässt Grund und Datum. So bleibt die Ausnahme sichtbar, statt im Feld zu verschwinden.

Ein technischer Punkt geht dabei besonders leicht unter. Der Wiedereintritt in einen HubSpot-Workflow ist standardmässig ausgeschaltet. Eine Bewertung bleibt also nur aktuell, wenn die erlaubten Wiedereintritte ausdrücklich gewählt sind, und zwar für die konkreten Eingangsgrössen statt für jede Feldänderung. Ändert sich die Passung, wird die vorgeschlagene Stufe neu bewertet. Ändert sich die Aktivität, ändert sich die Dringlichkeit. Die freigegebene Stufe flattert nicht bei jedem Impuls.

Woran wir messen, ob Play 3 funktioniert

Abschlussquote, Deal-Grösse und Zyklusdauer je freigegebener Stufe. Dazu die Häufigkeit menschlicher Übersteuerung samt Gründen, die Accounts mit unvollständigen Daten und die Verteilung über die Stufen. Und jeder Datensatz, dessen Stufe ohne gültige Prüfung gewechselt hat.

Play 4: Wer bearbeitet eine eingehende Meeting-Anfrage?

Eine Meeting-Anfrage ist erst dann nützlich, wenn klar ist, wer sie bearbeitet. Die meisten Fehler passieren nicht im Formular, sondern danach: doppelte Datensätze, fehlender Firmenkontext, ein übergangener Kollege. Play 4 klärt Identität und Zuständigkeit, bevor die Anfrage irgendwohin weitergegeben wird.

Der Schaden ist unmittelbar messbar. Eine Anfrage, die einem Bestandskunden gehört und trotzdem in einer automatisierten Sequenz landet, kostet Vertrauen bei genau dem Kunden, der am wahrscheinlichsten nachkauft.

Unsere These: Der Weg einer Anfrage folgt aus dem Zustand, den es im CRM schon gibt. Nicht aus dem Formular, über das sie kam. Deshalb steht am Anfang die Auflösung und nicht die Verteilung.

So läuft die Auflösung

Der Reihe nach: Kontakt über die E-Mail-Adresse nachschlagen, Firma über die Domain, Verknüpfung bestätigen. Danach prüfen, ob eine Kundenbeziehung besteht, ob offene Deals laufen und wer bereits zuständig ist. Erst dann wird etwas zugewiesen.

Festgehalten wird das in einem Auslöse-Nachweis mit Formular-ID, Zeitpunkt, Formularname, Seiten-URL, Quelle und den rohen Identitätsfeldern. Dieser Nachweis ist zugleich der Schlüssel gegen Doppelte und die Nachvollziehbarkeit für später. Bei einem Bestands-Account behält die zuständige Person die Anfrage, mit Kontext und ohne parallel startende Sequenz. Bei einem neuen Account wird zuerst die Passung geprüft, dann der Datensatz angelegt, dann eine zuständige Person bestimmt. Erst danach bekommt ein Outbound-Werkzeug den Datensatz überhaupt zu sehen. Wie ein solches Routing im Detail aufgebaut wird, zeigt der Leitfaden Intelligentes Lead Routing in HubSpot.

Der Ausnahmeweg ist Teil der Route und kein Sonderfall. Fehlende Domain, private E-Mail-Adresse, Verdacht auf einen Doppelten, Zuständigkeitskonflikt oder gescheiterte Recherche führen in einen Prüfzustand mit Grund, Zuständigkeit und Frist. Nie in einen Datensatz ohne Verantwortlichen, und nie in eine Standardsequenz. Der operative Zustand beantwortet eine einzige Frage: Wer besitzt den nächsten Schritt, und bis wann? Erst wenn diese Antwort existiert, wird Instantly, HeyReach oder eine Aufgabe im Vertrieb ausgelöst.

Woran wir messen, ob Play 4 funktioniert

Zeit von der Anfrage bis zur zuständigen Person, Anteil unverantworteter Anfragen, Duplikatrate, Zahl der Ausnahmen. Dazu das Verhältnis gebuchter zu gehaltenen Meetings und die Verkaufschancen je Qualifizierungsweg.

Play 5: Welcher Kontakt bekommt den Credit für einen Deal?

Wenn aus mehreren Kontaktversuchen später ein Signup oder eine Verkaufschance entsteht: Welcher Kontakt, welche Kampagne und welcher Kanal bekommen die Gutschrift? Play 5 beantwortet das nach einer vorher festgelegten Regel. Und es lässt die Antwort offen, wenn sie sich nicht belegen lässt.

Ohne diese Antwort ist jede Budgetdiskussion Meinung gegen Meinung. Mit ihr lässt sich sagen, welche Kampagne Verkaufschancen erzeugt hat und welche nur Aktivität.

Unsere These: Erzwungene Sicherheit ist die teurere Lüge. Ein Bericht, der jeden Deal einer Quelle zuordnet, wirkt vollständig und führt zu falschen Entscheidungen. Ein Bericht, der einen ehrlichen Rest offen lässt, ist unbequem und brauchbar.

Erst klären, was zugeordnet werden soll

Zugeordnet werden zwei verschiedene Dinge, und ihre Vermischung ist die häufigste Fehlerquelle. Das eine ist die einzelne Berührung: eine E-Mail, eine Nachricht, ein Anruf, jeweils mit Kampagne, Kanal, Sequenz und Zeitpunkt. Das andere ist das kommerzielle Ergebnis: ein Signup, ein Meeting, eine Verkaufschance, ein Abschluss. Die Frage der Zuordnung lautet, welche Berührungen innerhalb eines vorher festgelegten Zeitfensters vor dem Ergebnis lagen.

Das verbreitete Modell mit zwei Häkchen, „Outbound Campaign" und „Sign Up", ist ein Startpunkt. Als Zuordnung trägt es nicht. Ein Ja-Nein-Feld sagt, dass etwas passiert ist. Es sagt nicht, welche Kampagne, welcher Kanal, welche Sequenz und welcher Zeitpunkt bewertet werden sollen.

So wird es gebaut

Jede Outbound-Aktion wird als Ereignis am Kontakt festgehalten, mit Kampagne, Kanal, Sequenz, Kennung beim Anbieter und Zeitstempel. Die Verlaufsliste behält die Historie. Zwei aktuelle Felder für die erste und die letzte Berührung tragen die Workflow-Logik, weil ein Workflow keine Historie durchsuchen soll. Die kommerziellen Ergebnisse stehen als eigene Felder daneben: Signup At, Meeting Created At, Deal Created At, Closed Won At.

Taucht ein Ergebnis auf, werden die vorausgegangenen Berührungen gegen eine dokumentierte und versionierte Regel bewertet. Zeitfenster und Identitätsregel sind ausdrücklich festgelegt. Getrennt ausgewiesen wird, was eine Berührung ausgelöst hat und was sie nur begleitet hat. Lässt sich die Identität nicht sicher verbinden oder liegt die Berührung ausserhalb der Regel, lautet das Ergebnis „Unknown" oder „Unattributed". HubSpots eigene Angabe zur ursprünglichen Verkehrsquelle bleibt dabei unangetastet. Wie diese Quellenlogik grundsätzlich arbeitet, steht im Beitrag Source Attribution in HubSpot aufbauen.

Woran wir messen, ob Play 5 funktioniert

Signups, Verkaufschancen, Pipeline und gewonnener Umsatz nach Outbound-Berührung. Getrennt nach ausgelöst und begleitet, dazu die Leistung je Kampagne und Kanal, die Fehlerquote bei der Identitätszuordnung und der nicht zuordenbare Rest, ehrlich ausgewiesen.

Welches Muster steckt hinter allen fünf Plays?

Hinter allen fünf Plays steckt dieselbe Grundidee. Bevor eine Automatisierung eine Vertriebsaktion auslöst, müssen fünf Dinge geklärt sein. Was ist passiert? Welcher Datensatz ist betroffen? Was empfiehlt die KI? Was davon ist freigegeben? Und wer verantwortet den nächsten Schritt?

In HubSpot lässt sich diese Logik in sieben wiederkehrende Bausteine übersetzen. Wer sie einmal als gemeinsames Schema anlegt, legt damit fest, wie jedes künftige KI-Play ins CRM einzieht, statt pro Play ein neues Wahrheitsmodell zu bauen.

Die Grenzziehung über den ganzen Stack lässt sich in vier Sätzen sagen. Externe Werkzeuge sammeln und veredeln Belege. Die KI deutet den veränderlichen Kontext. HubSpot besitzt den akzeptierten Zustand, die Zuständigkeit, die Erlaubnis und das Ergebnis. Kanal-Werkzeuge führen nur aus, was freigegeben wurde.

Diese Aufteilung unterscheidet ein System von einer Ansammlung isolierter Automatisierungen. Wie SalesPlaybook HubSpot als diese Betriebsschicht aufsetzt, steht auf der Serviceseite HubSpot CRM.

Dass Kontrolle nicht gegen Geschwindigkeit steht, zeigt ein veröffentlichtes Kundenbeispiel. Beim Schweizer Unternehmen Aumico hat SalesPlaybook die HubSpot-Einführung so aufgesetzt, dass der Angebotsprozess direkt aus geprüften CRM-Zuständen läuft. Die publizierte Case Study nennt als Ergebnis „80 % weniger Zeitaufwand für Angebote". Der Mechanismus dahinter ist derselbe wie in den fünf Plays: Ein definierter Zustand löst eine definierte Aktion aus, und niemand baut die Entscheidung pro Fall neu.

Genau deshalb lohnt sich der Architektur-Aufwand vor dem ersten Play. Nicht weil Kontrolle ein Selbstzweck wäre, sondern weil jede Automatisierung nur so schnell ist wie der Zustand, dem sie trauen kann. Ein Workflow, dessen Eingangsdaten niemand freigegeben hat, spart keine Zeit. Er verlagert die Arbeit nur ans Ende, wo sie teurer ist.

In welcher Reihenfolge baut man die fünf Plays auf?

Schema vor Aktivierung. Zuerst entstehen die gemeinsamen Felder, dann die Priorisierung aus historischen Daten, dann die Auslöser für Website und Formular, zuletzt der Wirkungsnachweis. Wer in dieser Reihenfolge baut, muss nichts nachträglich auseinandersortieren.

1. Gemeinsames Schema definieren. Die Felder für Quelle, Zeitpunkt, Vorschlag, Freigabe, Zuständigkeit, Ausnahme und Ergebnis entstehen einmal. Alle fünf Plays nutzen sie wieder.
2. Priorisierung vor Aktivierung bauen. Passung und Aktivität aus den historischen Daten ableiten, dann den Zielmarkt-Aufbau an die freigegebene Stufe anschliessen.
3. Auslöser ergänzen. Website- und Formular-Auslöser über dieselben Prüfungen für Identität, Firmenkontext und Zuständigkeit führen. Kein zweites Wahrheitsmodell.
4. Wirkungsnachweis schliessen. Die Berührungen protokollieren, bevor die Ausführung skaliert. Erst danach spätere Signups und Umsatz gegen die dokumentierte Regel verbinden.
5. Ausnahmen monatlich ansehen. Übersteuerungsgründe, Ausnahmequoten, veraltete Daten und manuelle Nachbesserungen zeigen, welche Regel, welche Quelle oder welches Play sich ändern muss.

Wer den Kreislauf von der anderen Seite betrachtet, fragt nicht „Welche Systeme brauche ich?", sondern „Woher kommt verlässlich neue Pipeline?". Die Gegenrechnung dazu steht auf der Seite Pipeline Generation. Und wer die Agenten-Funktionen von HubSpot ausreizen will, liest ergänzend HubSpot Agent Builder: Agenten und Workflows kombinieren. Dort geht es um das Werkzeug, hier um die Architektur, in die jedes Ergebnis eines Agenten mündet.