PLG in HubSpot: Von Produktsignalen zur Pipeline

Die Produktdaten bleiben dann in den Analytics-Tools liegen, während dein Vertrieb weiter auf klassische Marketing-Signale schaut.

Daraus entstehen in der Praxis regelmäßig vier Probleme:

• Product Qualified Leads (PQLs) bleiben unbeachtet
• jede Übergabe an den Vertrieb muss jemand von Hand prüfen
• Nutzer mit hoher Kaufabsicht erreichen den Vertrieb nie
• das Ausbaupotenzial in bestehenden Accounts sieht niemand

Die Lösung: Du machst Produktsignale in HubSpot operativ nutzbar. Mit einer sauberen Product-Led-Growth-Architektur wird aus Produktnutzung automatisch qualifizierte Pipeline. Der Grund ist einfach. Signale, Vertriebsprozess und Reporting laufen in einem System zusammen.

Ein PLG-System in HubSpot besteht meist aus diesen fünf Bausteinen:

• Produktsignale, die direkt aus dem Anwendungs-Backend kommen
• ein PQL-Scoring, das an die Produktereignisse des Backends gekoppelt ist
• automatisches Lead-Routing entlang deiner Vertriebsstruktur
• Workflows, die die Arbeit im Vertrieb nach echten Engagement-Signalen priorisieren
• ein RevOps-Reporting, mit dem du Kapazität steuerst und Ressourcen flexibel nach Geschäftsprioritäten verteilst

Dieser Leitfaden zeigt dir Schritt für Schritt, wie du so ein System in HubSpot aufbaust: von der Signalerfassung bis zum Umsatz-Reporting.

‍

Warum Produktsignale heute mehr zählen als je zuvor

Neukundengewinnung wird teurer, und die verlässlichsten Kaufsignale entstehen längst im Produkt selbst. Nicht im Marketing-Funnel.

Trotzdem investieren viele produktgetriebene Anbieter heute deutlich mehr in:

• bezahlte Reichweite
• SDR-Kapazität
• Marketing-Automation-Tools

Dabei liegen die stärksten Kaufsignale schon in deinem eigenen Produkt.

Typisch ist, dass jemand einen Free Trial oder Freemium-Zugang aktiviert, eine Kernfunktion nutzt oder im Produkt mit seinem Team zusammenarbeitet. Genauso aussagekräftig sind wachsende Seat-Zahlen und eine hohe Nutzungsfrequenz. Und dann gibt es den Moment, in dem ein Account an Produktgrenzen stößt.

Solche Signale zeigen echte Kaufabsicht, oft früher und treffsicherer als jede Marketing-Interaktion. Nur: Ohne die passende Architektur in HubSpot wird aus Produktaktivität keine Pipeline.

‍

Die versteckten Risiken 

Produktdaten ohne Wirkung auf den Umsatz

Viele produktgetriebene SaaS-Anbieter messen ihr Produkt sehr genau. Im CRM kommen diese Signale aber selten so an, dass ein Vertriebsteam damit arbeiten kann.

Das sieht dann meist so aus:

• Produktdaten bleiben in der Analytics-Plattform
• Product Qualified Leads werden nicht automatisch geroutet
• der Vertrieb sucht seine Verkaufschancen von Hand
• aktive Trial-Nutzer mit starkem Engagement gehen unter
• Ausbaupotenzial fällt niemandem auf

Solange du Produktsignale nicht operativ nutzt, schöpft PLG sein Umsatzpotenzial nicht aus. Die Daten sind da, sie arbeiten nur nicht für dich.

‍

Der RevOps-Punkt, den die meisten Teams übersehen

Die meisten PLG-Projekte scheitern nicht an fehlenden Daten. Woran sie scheitern, ist zu viel Modell: zusätzliche Scoring-Ebenen, Sonderregeln, manuelle Zwischenschritte.

Systeme, die in der Praxis funktionieren, stehen auf drei Bausteinen. Das firmografische Fit-Scoring bewertet, wie viel ein Account wert werden kann. Das Produktnutzungs-Scoring misst, wie weit ein Nutzer im Produkt angekommen ist. Das automatisierte Routing bringt beides zusammen. Greifen die drei in HubSpot ineinander, erzeugt Produktaktivität von selbst qualifizierte Pipeline. Und dein Vertrieb meldet sich erst dann, wenn ein echtes Kaufsignal vorliegt.

Unsere These: Lifecycle Stages bilden den Weg eines Interessenten ab, linear und in eine Richtung. Für Produktzustände sind sie der falsche Ort. Aktivierung und Engagement gehören deshalb in eigene Produktsignale und ein eigenes Scoring, nicht in die Lifecycle-Phasen von Kontakt oder Unternehmen. Wer beides vermischt, kann später weder sauber berichten noch sauber routen.

‍

Die Lösung

Die PLG-Architektur in HubSpot

Pipeline entsteht nur dann ohne Handarbeit, wenn die Produktnutzung direkt im CRM ankommt. Genau das leistet ein Product-Led-Growth-System in HubSpot. Die Produktereignisse aus deinem Anwendungs-Backend landen in HubSpot-Properties. Auf dieser Grundlage berechnest du einen PQL-Score aus Produktengagement und firmografischem Fit.

Das System steht auf drei Bausteinen. Erstens erfasst es die Produktsignale. Zweitens bewertet es sie im PQL-Scoring, in der Regel ereignisbasiert, egal ob der Score im Backend oder in HubSpot entsteht. Drittens routet es die Ergebnisse automatisch an den Vertrieb.

Stehen diese Bausteine, aktualisieren HubSpot-Workflows die Lead Stages und lösen das Routing aus, entlang deiner Vertriebsstruktur und deiner SLAs. Deals und Abo-Daten tragen danach ein Reporting über den ganzen Funnel: PQL → SQL → Umsatz. So siehst du, wie aus Produktengagement erst Verkaufschancen und am Ende Umsatz werden.

‍

Welche HubSpot-Funktionen ein PLG-System tragen

Ein PLG-Umsatzsystem steht in HubSpot auf vier Bausteinen. In den Deal-Pipelines führst du Free Trials und Verkaufschancen. Die Lead Stages zeigen den Aktivierungsgrad, etwa als Rot, Gelb und Grün. Workflows übernehmen das PQL-Scoring, das Routing und die Lifecycle-Updates auf Basis der Produktsignale. Und Dashboards und Reports zeigen RevOps die Conversion-Raten über den ganzen Funnel, von PQL über SQL bis zum Umsatz.

‍

Verhaltensbasierte Produktsignale

Ein belastbares PQL-Modell steht nie auf einem Bein. Es kombiniert verhaltensbasierte Produktsignale mit firmografischen Fit-Signalen.

Verhaltensbasierte Signale zeigen, ob ein Account im Produkt ankommt und es dauerhaft nutzt, also Aktivierung und Adoption. Dazu zählen der Trial-Status, zentrale Produktereignisse aus dem Backend und das Seat-Wachstum einer Organisation über einen bestimmten Zeitraum. Zum Trial-Status gehören Ereignisse wie „Trial gestartet“, „Trial beendet“ oder „Self-Checked-Out“. Aus dem Backend kommen etwa erreichte Onboarding-Meilensteine und die Nutzung von Kernfunktionen. Genauso zählt, ob jemand Kolleginnen und Kollegen einlädt oder ob im selben Account mehrere Nutzer aktiv sind.

Welche dieser Signale für dich zählen, hängt von deiner Produktarchitektur und deinem Reporting-Anspruch ab. Viele Teams verdichten das Produktengagement über den Trial-Status auf drei Aktivierungsstufen:

• Rot – geringe Aktivierung (Nutzung unter dem Erwartungswert)
• Gelb – mittlere Nutzung
• Grün – starkes Engagement
  
  

Mit diesen drei Stufen verfolgt RevOps den Trial-Verlauf deutlich leichter. Vor allem trennen sie echte Adoption von bloßem Ausprobieren.

‍

Firmografische Fit-Signale

Engagement allein sagt nichts darüber, ob ein Account je relevanten Umsatz bringt. Deshalb ergänzen firmografische Fit-Signale die Unternehmensebene: Unternehmensgröße, Branche und ICP-Segment. Erst sie machen aus einem Nutzungswert ein belastbares PQL-Kriterium.

Den eigentlichen Nutzen haben diese Signale in der Steuerung. Mit ihnen priorisierst du die Arbeit im Vertrieb und planst die Kapazität deines Teams. Außerdem ordnest du Accounts den Leuten mit den passenden Fähigkeiten zu. Ein Beispiel: Accounts mit weniger als 50 Seats bleiben in der Self-Serve-Strecke, Accounts ab 50 Seats lösen eine sales-assistierte Strecke aus.

Kombinierst du beide Ebenen, bildet dein PQL-Scoring Engagement und Accountpotenzial gleichermaßen ab. Bleibt die Frage, wie du Leads und Verkaufschancen miteinander verknüpfst.

‍

‍

Warum Free Trials in HubSpot Deals sein sollten

Ein Free Trial ist der Moment, in dem ein Interessent zum ersten Mal ernsthaft investiert. Und genau dieser Moment verschwindet in den meisten CRMs spurlos.

Viele funktionierende PLG-Systeme führen deshalb jeden Free Trial als Deal in HubSpot. Das bringt dir vier Dinge. Du siehst die Pipeline klar, und der Trial bekommt einen strukturierten Verlauf. Das Engagement des Vertriebs wird nachvollziehbar, und die Attribution auf den Umsatz wird belastbar.

Der Datenfluss beginnt, sobald ein Nutzer den Trial startet: Das Anwendungs-Backend legt in HubSpot automatisch einen Deal an. Produktereignisse aktualisieren danach dessen Properties, und die Trial-Daten werden auf den zugehörigen Lead gespiegelt. So entsteht eine produktgetriebene Deal-Pipeline, in der die Produktaktivität selbst Verkaufschancen erzeugt und fortschreibt.

‍

Die Spiegellogik zwischen Deal und Lead

Damit Lead und Deal nicht auseinanderlaufen, braucht es eine Spiegellogik. Legt das Backend einen Deal in einer festen Stage an, spiegelt eine Deal-zu-Lead-Logik dessen Daten zurück auf den Lead. In einer PLG-Strecke ist die erste Stage der Deal-Pipeline damit die Standard-Stage für alle PQLs. Jeder Free Trial wird zur Verkaufschance, solange keine Regel dagegen spricht. Meist heißt diese Stage „Test Trial Self-Served“. Die Stage ist zugleich deine Messlatte dafür, wann ein Lead oder eine Verkaufschance ganz ohne Zutun des Vertriebs zum zahlenden Kunden geworden ist.

Den Deal erzeugt das Backend automatisch beim Trial-Start, und er ist die Single Source of Truth für Trials. Die gespiegelte Lead-Deal-Logik folgt immer derselben Reihenfolge: Produktereignis → Deal-Anlage → Wechsel der Lead Stage. Die nächste Stage der Deal-Pipeline heißt „Test Trial Sales-Assisted“. Hier liegt ein Free-Trial-Deal, bei dem ein Mensch übernimmt, weil die Aktivierung gering ist oder jemand ausdrücklich um Hilfe bittet. Die Strecke selbst bleibt produktgetrieben.

In diese Stage wandert ein Deal unter mehreren Bedingungen:

• der Nutzer bucht einen Termin
• der Vertrieb weist die Verkaufschance nach internen Regeln von Hand Sales-Assisted zu
• eine Automation verschiebt den Deal nach Zeitablauf und/oder PQL-Score

Kurz gesagt: Ein Lead oder eine Verkaufschance wird sales-assistiert, sobald der Interessent selbst handelt oder ein definiertes Zeitfenster überschritten ist. Dasselbe gilt, wenn der Trial ohne Checkout endet. Oder die Vertriebsleitung greift bewusst ein, weil der PQL-Score stark ist.

‍

Doppelte Leads zwischen Marketing und Produkt vermeiden

Ein Interessent, der zweimal im CRM steht, kostet deinen Vertrieb Zeit und dein Marketing die Attribution. In PLG-Systemen passiert genau das regelmäßig. Jemand meldet sich zuerst für ein Webinar an, und in HubSpot entsteht ein Marketing-Lead. Später startet dieselbe Person mit derselben E-Mail-Adresse einen Trial.

Ohne saubere Datenlogik legt das CRM beim Trial-Start einen zweiten Datensatz an. Ein gut gebautes PLG-System aktualisiert stattdessen den vorhandenen Lead. Es setzt die Lead Stage auf „Trial-Nutzung – Rot“ und erzeugt den zugehörigen Deal für den Trial. So bleibt die Marketing-Attribution erhalten, und deine CRM-Struktur bleibt sauber.

‍

‍

Schritt 1: Leg fest, was ein Product Qualified Lead (PQL) ist

• Ein Marketing Qualified Lead (MQL) ist ein Kontakt oder Account, der Marketing-Engagement oder Anmeldeabsicht zeigt, aber noch keinen Free Trial gestartet hat. Ihn bringst du mit automatisiertem Nurturing in Richtung Trial-Start.
• Ein Product Qualified Lead (PQL) ist ein Nutzer oder Account, dessen Verhalten im Produkt starke Kaufabsicht zeigt. Er hat einen Free Trial gestartet oder sendet deutliche Aktivierungssignale. In vielen PLG-Systemen ist zunächst jeder Trial-Nutzer ein PQL-Kandidat, solange keine Regel ihn ausschließt. Der Unterschied zum MQL: Ein PQL steht auf echter Produktaktivität, nicht auf Marketing-Interaktion.
• In einer typischen PLG-Strecke leben MQLs und PQLs in der Lead-Pipeline, Verkaufschancen dagegen in der Deal-Pipeline. Diese Trennung hat zwei Vorteile. Du kannst PLG mit Inbound und Outbound kombinieren. Und die Übergabe vom Marketing an den Vertrieb bleibt einfach, weil kein Marketing-Begriff mit einem Vertriebsobjekt vermischt wird.
• Konkret nutzen MQLs die Lead Stages „Neu“ und „Interessiert“. „Neu“ steht für frisch importierte Leads ohne nennenswertes Engagement, die noch auf ein erstes Verhaltens- oder Marketing-Signal warten. „Interessiert“ steht für Leads mit früher Absicht, etwa wiederholten Besuchen oder Content-Nutzung, aber ohne gestarteten Trial. Hier arbeitet deine Automation auf den Trial-Start hin. In derselben Stage landet auch Inbound ohne Trial, zum Beispiel Kontaktformulare, Webinar-Teilnehmer oder Content-Anfragen.
• Eine Verkaufschance ist dagegen ein Free-Trial-Ereignis, das als Deal direkt aus dem Backend deiner Anwendung entsteht. Dieser Deal ist die Single Source of Truth für Trial-Status und Fortschritt.

‍

Schritt 2: Hol die Produktsignale ins CRM 

Ohne Produktereignisse im CRM bleibt jede PLG-Strategie Theorie. Dein erster operativer Schritt ist deshalb die Synchronisation aus dem Backend nach HubSpot.

Die meisten SaaS-Anbieter lösen das über eine API-Anbindung zwischen Produktdatenbank oder Backend und HubSpot.

Diese Produkt-Properties werden typischerweise synchronisiert:

• Trial-Status (aktiv, beendet, verlängert)
• Trial-Startdatum
• Trial-Enddatum
• Aktivierungsmeilensteine im Produkt (produktspezifisch)
• Anzahl der Seats (hängt oft mit der Adoption im Unternehmen zusammen)
• PQL-Score

Startet ein Nutzer einen Trial, kann das System automatisch:

• ein Unternehmen in HubSpot anlegen
• einen zugehörigen Kontakt erzeugen
• einen Deal in der PLG-Pipeline anlegen
• einen Lead-Datensatz erzeugen

Damit sieht dein Vertrieb Produktaktivität sofort im CRM.

‍

Schritt 3: Leg den Revenue-Datenfluss fest

Die teuerste offene Frage in jedem PLG-Projekt lautet: Wo entstehen die Umsatzdaten? Wer sie nicht beantwortet, pflegt Abschlüsse später von Hand nach.

Im Regelfall fließen die Produktereignisse per API aus dem Anwendungs-Backend nach HubSpot. Dort aktualisieren sie die Properties, die das PQL-Scoring und die Lead-Stage-Automation antreiben. Erreicht ein Lead die definierten Schwellen, routen Workflows die Verkaufschance an den Vertrieb oder lassen sie in der Self-Serve-Strecke. So erzeugt Produktnutzung unmittelbar Pipeline und Umsatz-Reporting.

Eine verbreitete PLG-Architektur sieht so aus:

• Deals = Single Source of Truth für Trials
• Billing-System (etwa Stripe) = Single Source of Truth für Abos

Der Ablauf:

1. Nutzer startet einen Free Trial → das Backend legt einen HubSpot-Deal an
2. Produktereignisse aktualisieren die Deal-Properties
3. Nutzer schließt ein Abo ab → das Stripe-Abo wird ins Backend synchronisiert
4. Backend aktualisiert den HubSpot-Deal → der Deal wandert automatisch auf Closed Won

Dein Vertrieb muss damit nichts von Hand nachpflegen, und der Umsatz entsteht im System statt in einer Tabelle.

‍

Schritt 4: Automatisiere die Lead Stages 

Sobald ein Score existiert, können HubSpot-Workflows die Lead Stages selbst setzen. Dein Vertrieb sieht dann auf einen Blick, wer gerade kaufbereit ist.

Ein typischer PLG-Lebenszyklus:

• Neu
• Interessiert
• Free Trial aktiv – Rot
• Free Trial aktiv – Gelb
• Free Trial aktiv – Grün
• Trial beendet
• Self-Checked-Out
• Disqualifiziert

So läuft es typischerweise ab:

• Trial gestartet → der Lead wechselt auf „Free Trial aktiv – Rot“
• Nutzung steigt → die Stage wechselt auf Gelb oder Grün
• Abo beginnt → der Lead wechselt auf Self-Checked-Out
• Damit erkennt dein Vertrieb Nutzer mit hoher Kaufabsicht sofort.

‍

Schritt 5: Route PQLs an den Vertrieb

Die Frage ist nicht, ob der Vertrieb eingreift, sondern wann. Routing-Regeln beantworten sie, bevor jemand sie im Einzelfall diskutiert.

Gängige Routing-Trigger:

• Seat-basiertes Routing, damit du Accounts nach ARR-Potenzial und Vertriebsstruktur behandelst.
  
  • Accounts ab 50 Seats → an den Enterprise-Vertrieb
  • Accounts unter 50 Seats → bleiben in der PLG-Strecke

Terminbuchung als Trigger, damit Nutzer mit hoher Kaufabsicht sofort eine Rückmeldung bekommen:

• Hat der Lead schon einen Owner → die Zuständigkeit bleibt
• Hat der Lead keinen Owner → die Zuständigkeit wird automatisch vergeben

Aktivierungs-Trigger: Wird ein PQL-Score grün, entsteht eine Aufgabe, und die zuständige Person bekommt eine Benachrichtigung.

Trial-Ende: Endet der Trial und bleibt das Engagement rot, wird der Lead automatisch disqualifiziert.

In der Praxis kommen weitere Trigger dazu. Mit Task Queues ordnest du sie so, dass klar ist, welche Aufgabe den Kontakt zum Interessenten startet und welche ihn fortsetzt.

‍

Schritt 6: Automatisiere die Vertriebs-Workflows

Jeder Handgriff, den ein Mensch im Lebenszyklus übernimmt, ist eine Fehlerquelle und kostet Zeit. HubSpot-Workflows können den ganzen PLG-Lebenszyklus tragen, mit diesen drei Automationen:

1. Lead Stage aus dem PQL-Score setzen: Rot → Gelb → Grün aktualisiert die Stages automatisch.
2. Trial über Produktereignisse spiegeln: Der Deal entsteht und wird danach auf den Lead gespiegelt.
3. Deals aus Abo-Daten automatisch schließen: Trifft ein Abo-Startdatum ein, wandern Deal und Lead automatisch auf Closed Won beziehungsweise Self-Checked-Out.

So bleibt es bei einer Single Source of Truth, und niemand pflegt dieselben Daten zweimal.

‍

Schritt 7: Miss PQL → SQL → Umsatz

Treiben Produktsignale deine Pipeline, entscheidet das Reporting, ob die Vertriebskapazität dorthin fließt, wo sie Umsatz bringt. HubSpot-Dashboards bilden dafür den ganzen PLG-Funnel ab, in vier Gruppen von Kennzahlen.

Aktivierungs-Kennzahlen

• Verlauf Rot → Gelb → Grün
• Zeit bis zur Aktivierung

Conversion-Kennzahlen

• Trial → zahlend
• PQL → SQL
• Self-Serve gegen sales-assistiert

Vertriebskennzahlen

• Pipeline-Wert je Strecke
• Abschlussquote
• Sales Velocity

Umsatzkennzahlen

• Neues MRR
• Durchschnittliche Deal-Größe
• Expansionsumsatz

Weil du Trials als Deals führst, wird Produktaktivität zu messbaren Pipeline-Daten.

Alle genannten Kennzahlen kannst du zusätzlich nach Kohorten auswerten. Das geht, weil Data-Sync-Workflows die Lead- und Deal-Properties synchron halten. Für deinen Vertrieb heißt das weniger Doppelerfassung: Dieselben geografischen und demografischen Datenpunkte liegen auf allen Objekten, also auf Unternehmen, Kontakt → Lead ↔ Deal.

Für dich heißt das: Halte das Modell klein. Drei Bausteine, drei Aktivierungsstufen, ein Deal pro Trial. Wenn du sehen willst, wie weit dein HubSpot-Setup davon entfernt ist, such dir unten einen Termin aus.

‍