Warum HubSpots neueste Updates die Revenue-Architektur verändern und wo globale Teams weiterhin an Grenzen stoßen
Im vergangenen Jahr hat HubSpot eine Reihe von Updates veröffentlicht, die auf den ersten Blick inkrementell wirken. Ein Beta-Feature hier, eine kleine UI-Verbesserung da – und Release Notes, die oft als „low impact“ gekennzeichnet sind.
Doch zusammengefasst erzählen diese Veränderungen eine viel größere Geschichte.
HubSpot entwickelt sich leise, aber konsequent von einem auf Marketing- und Sales-Execution optimierten CRM zu einer Plattform, die echte Revenue-Architekturen tragen kann – von Qualifizierung und Routing über Quoting und Delivery bis hin zum langfristigen Customer Value.
Für RevOps-Teams und Solution Architects verändert dieser Shift bereits, was nativ gebaut werden kann. Gleichzeitig machen diese Updates deutlich, wo die Plattform noch Nachholbedarf hat – insbesondere bei globalen und hochkomplexen Setups.
Positionen (Line Items) und Custom Objects: Das Fundament für Post-Sales-Architekturen
Die Möglichkeit, Line Items mit Custom Objects zu verknüpfen, ist eines der strukturell wichtigsten Updates, die HubSpot seit Jahren veröffentlicht hat.
Historisch gesehen waren Line Items eng an Deals gekoppelt. Für die Angebotserstellung war das sinnvoll, zwang die Teams nach dem Deal-Abschluss jedoch zu fragilen Workarounds. Delivery-, Onboarding- und Customer Success-Teams benötigten oft dieselben granularen Produktdaten – nur in einem anderen operativen Kontext.
Mit diesem Update schließt sich diese Lücke endlich.
Teams können jetzt:
Line Items aus einem oder mehreren Deals einem Delivery- oder Onboarding-Objekt zuordnen
Greife in Post-Sales-Workflows und im Reporting sowohl auf Standard- als auch auf benutzerdefinierte Line-Item-Properties zu
Passe den Projektumfang während der Umsetzung an, ohne Closed-Won-Umsatzdaten zu verfälschen
Ein entscheidendes Detail ist hier die Datenintegrität. Das Bearbeiten von Line Items auf einem Custom Object verändert nicht den ursprünglichen Deal. Forecasting, Revenue-Reporting und historische Genauigkeit bleiben intakt – unverzichtbar für Finance- und Führungsteams.
Aus Sicht des Systemdesigns ist das ein enormer Sprung nach vorn.
Wo es noch in den Kinderschuhen steckt
Heute richtet sich diese Power ganz klar an anspruchsvollere Portale:
Verknüpfungen von Positionen (Line Items) erfordern Operations Hub / Data Hub Professional und Custom Code
Es gibt keine native No-Code-Workflow-Aktion, um diese Assoziationen zu erstellen
Association Labels und Limits sind noch nicht verfügbar
Keines dieser Probleme entwertet das Feature. Sie zeigen lediglich, dass HubSpot die Benutzerfreundlichkeit auf einem neu erweiterten Datenmodell erst noch aufbauen muss. Eine No-Code-Abstraktion an dieser Stelle würde die Adoption deutlich steigern.
Multi-Currency: Die verbleibende Hürde für globale Revenue-Modelle
Bei Portalen mit nur einer Währung wirken die Verknüpfungen von Zeilenelementen nahezu lückenlos.
In der Praxis:
Deal-Positionen berücksichtigen die Deal-Währung korrekt
Mit Custom Objects verknüpfte Positionen (Line Items) nutzen standardmäßig die Unternehmenswährung
Manuelle Line Items auf Custom Objects ignorieren die Deal-Währung komplett
Das Ergebnis ist eine uneinheitliche Währungsdarstellung über Sales-, Delivery- und Finance-Objekte hinweg – selbst wenn diese Datensätze dieselbe kommerzielle Vereinbarung abbilden.
Das schmälert den Wert des Features keineswegs, setzt globalen Teams jedoch eine klare Grenze.
Was das nächste Level freischalten würde
Zwei Ergänzungen würden die meisten Praxisfälle abdecken:
Währungssteuerungen für Custom Objects – vergleichbar mit denen für Deals
Oder die Möglichkeit, die Deal-Währung auf verknüpfte benutzerdefinierte Objekte zu vererben und festzuschreiben
Mit Blick auf die aktuelle Entwicklung von HubSpot wirkt dies weniger wie eine grundlegende Limitation, sondern eher wie der nächste logische Evolutionsschritt des Datenmodells.
Standard-Eigenschaftswerte: Eine ganze Klasse von Workarounds eliminieren
Eines der am meisten unterschätzten Updates hatte enorme architektonische Auswirkungen: Standardwerte, die direkt auf Properties definiert werden.
Bisher mussten Teams Standardwerte umständlich simulieren durch:
„On create“-Workflows
Berechnete Eigenschaften als Konstanten genutzt
Komplexe Enrollment-Logik, um Edge Cases abzufangen
Dieser Ansatz war von Grund auf fragil: Ein einziger fehlender Wert konnte fehlerhafte Berechnungen und unzuverlässiges Reporting nach sich ziehen.
Mit nativen Standards:
Workflow-Volumen sinkt
Berechnete Eigenschaften werden einfacher und verlässlicher
Formulare und Feldlogik lassen sich leichter anpassen
Neue Admins verstehen sofort das beabsichtigte Datenverhalten
Ein Paradebeispiel für Plattformreife: echter Mehrwert entsteht hier nicht durch neue Features, sondern durch das gezielte Vermeiden von Technical Debt.
Bedingtes Lead-Scoring: Qualifizierungslogik, die der Realität standhält
Mit der Einführung des Conditional Scoring (UND-Logik) passt sich das native Lead Scoring von HubSpot endlich der Praxis an, wie Qualifizierungsmodelle tatsächlich aufgebaut sind.
Komplexe ICP- und Persona-Definitionen lassen sich nun direkt im Scoring-Modell abbilden, ohne:
Aktive Listenketten
Workflow-basierte Scoring-Hacks
Versteckte Abhängigkeiten, die schwer zu warten sind
Für Inbound-getriebene GTM-Modelle ist das eine grundlegende Verbesserung. Die MQL-Definition wird präziser, besser begründbar und lässt sich bei strategischen Anpassungen leichter weiterentwickeln.
Intelligentere Übergaben durch flexible Teamstrukturen
Qualifizierung stiftet nur dann Mehrwert, wenn das anschließende Handover sauber funktioniert.
Indem Nutzer Hauptmitglieder mehrerer Teams sein können, räumt HubSpot eine der größten Hürden in der Routing-Logik aus dem Weg. Teams können nun folgendes abbilden:
Skill- und priorisierungsbasierte Routing-Modelle
Schlankere Workflows ohne doppelte Logik
Teamstrukturen, die sich weiterentwickeln – ohne ständige Re-Architektur
Kombiniert mit konditionalem Scoring verbessert das den Weg vom ersten Touchpoint bis zur menschlichen Übergabe erheblich.
Property History als Events: Ein echtes Upgrade für Deine Analytics
Die Umwandlung von Eigenschaftsänderungen in native Custom Events markiert einen weiteren unaufgeregten, aber wegweisenden Schritt.
Statt historische Daten in einzelnen Workflows zu isolieren, werden Eigenschaftsänderungen jetzt zu wiederverwendbaren Bausteinen:
Workflow-übergreifend auslösbar
Nutzbar in Listen und Customer Journeys
Abfragbar in Reportings und benutzerdefinierten Datasets
Damit rückt HubSpot echten historischen Analysen ein ganzes Stück näher, ohne dass Teams auf fragile Snapshot-Workarounds zurückgreifen müssen – und das gilt auch für Custom Objects.
Das Gesamtbild
Für sich genommen mögen diese Updates wie kleine Schritte wirken.
Zusammengenommen zeigen sie eine Plattform, die gezielt in fundamentale Bausteine investiert – Line Items, Properties, Events, Scoring – statt nur oberflächliche Features zu liefern.
Für RevOps-Teams liegen die Konsequenzen auf der Hand:
Sauberere Architekturen
Weniger Designs, die auf Workarounds basieren
Größeres Vertrauen in das native Datenverhalten
Was noch fehlt, ist nicht die Richtung, sondern die Umsetzung:
Konsistentes Multi-Währungs-Handling über Deals hinaus
Mehr No-Code-Zugriff auf neu gewonnene, mächtige Objekte
Eine letzte Steuerungsebene für wirklich globale Umsatzmodelle
Das Fundament steht. Das Momentum ist da.
Und wenn die jüngsten Releases ein Hinweis sind, verlangsamt HubSpot das Tempo keineswegs … es steuert auf etwas viel Größeres zu – und ich könnte kaum begeisterter sein!
