Vertriebsautomatisierung mit KI: 5 HubSpot-Plays

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

Die fünf Plays bilden zusammen einen geschlossenen Revenue-Kreislauf: Nischen-TAM-Mapping baut den Zielmarkt, Website-Besucher-Deanonymisierung erfasst Kaufsignale, Account-Tiering entscheidet die Priorität, Meeting-Form-Orchestrierung routet eingehende Anfragen, und Outbound-Attribution verbindet jede Ansprache mit Umsatz. Jedes Play beantwortet eine andere Frage – aber alle schreiben in dasselbe CRM, und genau dort entscheidet sich, ob sie tragen.

Die meisten KI-GTM-Playbooks überzeugen auf der Ebene der Möglichkeit. Die eigentliche Arbeit beginnt einen Schritt später: Welcher Datensatz soll sich ändern? Welches System besitzt die Entscheidung? Welche Aktion ist erlaubt? Wer bekommt die Ausnahme? Und welches Ergebnis beweist, dass das Play Pipeline erzeugt hat statt Aktivität?

Ein KI-GTM-Play ist erst produktionsreif, wenn es fünf Dinge hat: einen beobachtbaren Trigger, einen stabilen Identitätsschlüssel, einen Kandidaten-Zustand, einen freigegebenen Zustand und ein messbares kommerzielles Ergebnis. Fehlt eines davon, läuft der Workflow trotzdem. Repariert wird später von Hand.

1. Play 1 – Nischen-TAM-Mapping und CRM-Automatisierung: baut den adressierbaren Markt auf.
2. Play 2 – Website-Besucher-Deanonymisierung: macht Kaufsignale sichtbar.
3. Play 3 – Account-Tiering und Scoring: entscheidet die Priorität.
4. Play 4 – Meeting-Form-Orchestrierung: routet eingehende Nachfrage.
5. Play 5 – Outbound-Attribution: verbindet Ansprache mit Umsatz.

Play 1: Wie entsteht ein Nischen-TAM, ohne HubSpot mit ungoverneten Datensätzen zu füllen?

Über die Company-Domain als operativen Match-Key: Vor jedem Anlegen prüft der Workflow, ob die Firma bereits existiert, ob eine Kundenbeziehung oder ein offener Deal läuft und ob ein Owner zugewiesen ist. KI-Bewertungen landen zuerst in Kandidaten-Feldern – das freigegebene Account-Tier ändert nur eine deterministische Regel oder ein Review.

Der Ausgangspunkt ist bekannt: Lookalike-Quellen wie DiscoLike, Ocean.io, AI Ark oder Clay sammeln Firmen in einer Tabelle, standardisieren Name, Domain und LinkedIn-URL, entfernen Duplikate, klassifizieren den ICP-Fit per KI und weisen ein Tier zu. Diese Sequenz ist nützlich – sie erweitert den Markt, bevor teures Contact-Enrichment beginnt. Das Implementierungsrisiko entsteht an einer anderen Stelle: wenn „Qualified" oder „Tier 1" direkt nach einem KI-Schritt als finale CRM-Wahrheit behandelt wird.

Die Trennung sieht in HubSpot so aus:

• Kandidaten-Properties: TAM Source, TAM Added At, AI ICP Recommendation, AI ICP Rationale, Fit Data Completeness, Enrichment Source, Enriched At.
• Freigabe-Properties: Approved Account Tier, Tier Review Status, Tier Reviewed At, Allowed Motion, Account Activation Status.
• Kontakt-Properties: Buying Role, Persona Evidence, Contact Sourcing Status, Contact Data Confidence.

Tier 1 heißt dabei nicht automatisch „Outreach starten". Das Activation Gate prüft vorher, ob der Account kein Bestandskunde ist, kein aktiver Deal kollidiert, ein gültiger Owner existiert und der Kanal für den Kontakt zulässig ist. Fehlt Evidenz, setzt der Workflow den Tier Review Status auf „Review Required" und weist einen Owner zu – statt den Datensatz in einen unbeobachteten Zweig fallen zu lassen. Und eine Antwort auf eine Outbound-Nachricht ist ein Bewertungs-Trigger, keine automatische Deal-Wahrheit: Ein Deal entsteht erst, wenn die vereinbarten Opportunity-Kriterien vorliegen.

Gemessen wird, was das Play belastbar macht: Duplikatrate, Anteil freigegebener Kandidaten-Accounts, Zeit vom TAM-Eintrag bis zur verantworteten Aktion, Reply-zu-Opportunity-Konversion je Tier und die Zahl der Datensätze, die manuelle Reparatur brauchen.

Play 2: Wie werden Website-Besuche zu Evidenz statt zu angenommener Erlaubnis?

Jeder relevante Besuch wird als HubSpot Custom Event am zuverlässig gematchten Unternehmen gespeichert – mit Seitengruppe, Frequenz, Zeitpunkt, Signalquelle und Identity Confidence. Identifiziert die Quelle nur die Firma, bleibt das Event auf Firmenebene: Aus einem Firmensignal wird nie eine geratene Person, die kontaktiert werden darf.

Der nützliche Kern dieses Plays: Der Kontext gehört zum Signal. Ein Pricing-Seiten-Besuch gestern und ein Blog-Besuch vor sechs Wochen dürfen nicht dieselbe Aktion auslösen. HubSpots Custom-Events-Dokumentation beschreibt, wie sich ein Event wie website_company_visit mit eigenen Feldern definieren und dem passenden Objekt zuordnen lässt. Daneben hält der aktuelle Firmenzustand fest, was jetzt gilt: Latest Website Signal At, Website Signal Strength, Visitor Source, Signal Review Status, Activation Status.

Aktiviert wird erst, wenn vier Bedingungen gleichzeitig bestehen – der Account passt zum freigegebenen ICP, das Signal ist aktuell und für das Geschäft relevant, ein verantwortlicher Owner existiert, und Suppression- wie Policy-Prüfungen erlauben die Aktion. Hoher Fit plus starkes Signal erzeugt eine Owner-Aufgabe mit SLA. Hoher Fit plus schwaches Signal bleibt im Nurturing. Niedriger Fit plus starkes Signal erzeugt eine Review- oder Suppression-Entscheidung – kein automatisches Outbound.

Eine universelle Liste von High-Intent-Seiten gibt es nicht, ebenso wenig ein universelles Frische-Fenster. Beides folgt aus Buying Journey, Traffic-Qualität und Vertriebskapazität – und die Policy steht im Workflow, nicht in einem undokumentierten Prompt. Wer diese Signalstrecke bis zur automatisierten Ansprache weiterdenkt, findet die Systemseite dazu unter AI Outbound.

Messgrößen: Accepted-Signal-Rate, Zeit vom Signal bis zur verantworteten Aktion, Meetings und Opportunities je Signal-Kohorte, False-Positive-Rate – und jede Ansprache, die auf unsicherer Identität beruht.

Play 3: Wie funktioniert Account-Tiering mit zwei Scores und einem freigegebenen Tier?

Fit-Score und Engagement-Score bleiben getrennt sichtbar, und keiner von beiden ist das Tier: Der Fit-Score misst über Firmografie, ob der Account in den Markt gehört; der Engagement-Score misst über Aktivität, was sich gerade ändert. Das freigegebene Tier ist eine eigene, governte Property – sie ändert sich nur, wenn die Freigabebedingungen bestehen.

Der richtige Startpunkt ist kommerzielle Evidenz: Closed-Won- und Closed-Lost-Daten der letzten 12 bis 24 Monate, Muster in Deal-Größe, Zyklus, Branche, Firmengröße und Geografie. Falsch wird es erst, wenn dauerhafter Fit und zeitgebundenes Engagement in eine einzige intransparente Zahl gepresst werden. HubSpot unterstützt getrennte Fit-, Engagement- und kombinierte Scores für Kontakte und Unternehmen – beide Einzelwerte sichtbar zu halten kostet nichts und erklärt jede Tier-Entscheidung.

Dazu kommen Governance-Felder, die den Zustand erklärbar machen: Score Model Version, Tier Evaluation At, Tier Review Status, Tier Override Reason, Previous Approved Tier. Ein menschlicher Override braucht Grund und Review-Datum – die Ausnahme bleibt sichtbar, statt im Feld zu verschwinden.

Der Workflow-Punkt, der am leichtesten untergeht: Re-Enrollment ist in HubSpot-Workflows per Default aus. Ein Scoring-Workflow bleibt nur aktuell, wenn die erlaubten Wiedereintritte explizit gewählt sind – die konkreten Score-Inputs und Review-Status-Wechsel, nicht jede Property-Änderung. Ändert sich der Fit-Score, wird das Kandidaten-Tier neu bewertet; ändert sich das Engagement, die Aktivierungspriorität. Das freigegebene Tier flattert nicht bei jedem Input.

Messgrößen: Konversionsrate, Deal-Größe und Zyklus je freigegebenem Tier, Override-Rate mit Gründen, Accounts mit unvollständigen Daten, Tier-Verteilung – und jeder Datensatz, der das Tier ohne gültiges Review-Event gewechselt hat.

Play 4: Wann darf eine Meeting-Anfrage an einen Owner geroutet werden?

Erst wenn Identität und Ownership aufgelöst sind: Kontakt per E-Mail nachschlagen, Firma per Domain, Association bestätigen – dann Kundenstatus, offene Deals und bestehende Ownership prüfen, bevor irgendetwas neu zugewiesen wird. Die meisten Routing-Fehler entstehen nicht im Formular, sondern durch doppelte Identitäten, fehlenden Firmenkontext oder ignorierte Owner.

Das Play beginnt mit einem Trigger-Contract: Form Submission ID, Submitted At, Formularname, Seiten-URL, Quelle und die rohen Identitätsfelder. Das ist der Deduplizierungsschlüssel und zugleich der Audit-Trail. Für einen Bestands-Account behält der Account-Owner die Anfrage – mit Kontext, ohne dass parallel eine automatisierte Sequenz startet, wenn eine Opportunity oder eine aktive Kundenbeziehung existiert. Bei einem neuen Account wird erst der Firmen-Fit qualifiziert, dann angelegt, dann ein Owner aufgelöst – und erst danach bekommt ein Outbound-Tool den Datensatz. Wie ein solches Routing im Detail aufgebaut wird, zeigt der Leitfaden Intelligentes Lead Routing in HubSpot.

Der Fallback ist Teil der Route, kein Sonderfall. Fehlende Domain, private E-Mail-Adresse, Duplikat-Kandidat, Owner-Konflikt oder gescheitertes Enrichment erzeugen einen Review-Zustand mit Grund, Owner und SLA – nie einen unzugewiesenen Datensatz, nie eine Default-Sequenz. Der operative Zustand beantwortet eine einzige Frage: Wer besitzt den nächsten Schritt, und bis wann? Erst wenn diese Antwort existiert, wird Instantly, HeyReach, eine Sales-Aufgabe oder ein anderer Follow-up ausgelöst.

Messgrößen: Zeit von Submit bis Owner, Quote unverantworteter Anfragen, Duplikatrate, Routing-Ausnahmen, Verhältnis gebuchter zu gehaltenen Meetings und Opportunities je Qualifizierungs- und Routing-Pfad.

Play 5: Wie wird Outbound attribuiert, ohne die Quellenwahrheit zu überschreiben?

Jede Outbound-Aktion wird als Event am Kontakt geloggt – mit Kampagne, Kanal, Sequenz, Provider-Touch-ID und Zeitstempel –, während First und Last Outbound Touch als aktuelle Properties für schnelle Workflow-Entscheidungen bereitstehen. Ein dokumentiertes Attributionsfenster entscheidet, welche Touches zählen; HubSpots Original Traffic Source bleibt unangetastet.

Das verbreitete Zwei-Checkbox-Modell – „Outbound Campaign" und „Sign Up" – ist ein Startpunkt, aber keine Produktions-Attribution: Ein binäres Feld sagt, dass etwas passiert ist, aber nicht, welche Kampagne, welcher Kanal, welche Sequenz und welcher Zeitpunkt bewertet werden sollen. Die Event-Timeline behält die Historie, die aktuellen Properties tragen die Workflow-Logik, und kommerzielle Ergebnisse – Signup At, Meeting Created At, Opportunity Created At, Closed Won At – stehen als eigene Felder daneben.

Taucht ein Signup oder eine Opportunity auf, werden die vorausgegangenen Touches gegen eine dokumentierte, versionierte Policy bewertet: Attributionsfenster und Identitätsregel sind explizit, Sourced- und Influenced-Ergebnisse bleiben getrennt. Lässt sich die Identität nicht zuverlässig verbinden oder liegt der Touch außerhalb der Policy, heißt das Ergebnis „Unknown" oder „Unattributed" – erzwungene Sicherheit wäre die teurere Lüge. Wie die Quellenlogik in HubSpot grundsätzlich arbeitet, steht im Beitrag Source Attribution in HubSpot aufbauen.

Messgrößen: Signups, Opportunities, Pipeline und Closed-Won-Umsatz nach Outbound-Touch, Sourced gegen Influenced, Kampagnen- und Kanalleistung, Identity-Match-Fehler – und der unattributierte Rest, ehrlich ausgewiesen.

Welche HubSpot-Architektur steckt hinter allen fünf Plays?

Hinter allen fünf Plays liegt dasselbe Produktionsmuster in sieben Schritten: Trigger-Contract, Identitätsauflösung, Kandidaten-Zustand, freigegebener Zustand, Activation Gate, Fallback und Outcome-Writeback. Wer dieses Muster einmal als gemeinsames Schema anlegt, standardisiert, wie jedes künftige KI-Play in HubSpot einzieht – statt pro Play ein neues Wahrheitsmodell zu bauen.

Die Grenzziehung über den ganzen Stack: Externe Tools sammeln und veredeln Evidenz, KI interpretiert variablen Kontext, HubSpot besitzt den akzeptierten Zustand, den Owner, die Erlaubnis und das Ergebnis – Kanal-Tools führen nur die freigegebene Motion aus. Diese eine Zeile unterscheidet ein System von einer Ansammlung isolierter Automatisierungen. Wie SalesPlaybook HubSpot als diese governte Betriebsschicht aufsetzt, steht auf der Serviceseite HubSpot CRM.

Dass sich Governance nicht gegen Geschwindigkeit stellt, zeigt ein veröffentlichtes Kundenbeispiel: Beim Schweizer Unternehmen Aumico hat SalesPlaybook die HubSpot-CRM-Einführung so aufgesetzt, dass der Angebotsprozess direkt aus sauberen 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 Governance 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 – der Aufbau folgt fünf Schritten: Zuerst entstehen die gemeinsamen Felder für Quelle, Zeitstempel, Kandidat, Freigabe, Owner, Fallback und Outcome. Dann folgt das Tiering aus historischen Daten, danach die Website- und Meeting-Trigger über dieselben Identitäts- und Owner-Kontrollen, zuletzt die Attributionsschleife – und ein monatlicher Blick auf die Ausnahmen.

1. Gemeinsames Schema definieren. Die Felder für Quelle, Zeitstempel, Kandidat, Freigabe, Owner, Fallback und Outcome entstehen einmal – alle fünf Plays nutzen sie wieder.
2. Tiering vor Aktivierung bauen. Fit- und Engagement-Logik aus den historischen Daten definieren, dann das TAM-Mapping an das freigegebene Account-Tier anschließen.
3. Website- und Meeting-Trigger ergänzen. Beide Trigger hinzufügen und über dieselben Identitäts-, Account-Kontext- und Owner-Kontrollen führen – kein zweites Wahrheitsmodell.
4. Attributionsschleife schließen. Outbound-Touch-Events loggen, bevor die Ausführung skaliert – dann spätere Signups und Umsatz gegen die dokumentierte Policy verbinden.
5. Ausnahmen monatlich reviewen. Override-Gründe, Fallback-Raten, veraltete Daten und manuelle Reparaturen zeigen, welche Regel, Quelle oder welches Play sich ändern muss.

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