HubSpot entwickelt sich schneller, als die meisten Teams realisieren

Warum die neuesten Updates von HubSpot die Revenue-Architektur verändern – und wo globale Teams noch an Grenzen stoßen

Im vergangenen Jahr hat HubSpot eine Reihe von Updates veröffentlicht, die auf den ersten Blick inkrementell wirken. Hier eine Beta-Funktion. Dort eine kleine UI-Verbesserung. Release Notes, die oft als „low impact“ gekennzeichnet sind.

Doch zusammengenommen erzählen diese Änderungen eine deutlich größere Geschichte.

HubSpot entwickelt sich leise, aber entschlossen von einem CRM, das primär für Marketing- und Sales-Execution optimiert ist, hin zu einer Plattform, die echte Revenue-Architektur unterstützt – von Qualifizierung über Routing und Angebotserstellung bis hin zu Delivery und langfristigem Customer Value.

Für RevOps-Teams und Solution Architects verändert dieser Wandel bereits heute, was sich nativ abbilden lässt. Gleichzeitig zeigen die Updates auch klar, wo die Plattform noch aufholt – insbesondere bei globalen und hochkomplexen Setups.

Line Items und Custom Objects: Fundament für Post-Sales-Architektur

Die Möglichkeit, Line Items mit Custom Objects zu verknüpfen, ist eines der strukturell wichtigsten Updates, das HubSpot in den letzten Jahren ausgeliefert hat.

Historisch waren Line Items eng an Deals gebunden. Für die Angebotserstellung war das sinnvoll – nach Deal-Abschluss führte es jedoch häufig zu fragilen Workarounds. Delivery-, Onboarding- und Customer-Success-Teams benötigten dieselben granularen Produktdaten – allerdings in einem anderen operativen Kontext.

Mit diesem Update schließt sich diese Lücke endlich.

Teams können nun:

• Line Items aus einem oder mehreren Deals mit einem Delivery- oder Onboarding-Objekt verknüpfen
  
• Standard- und benutzerdefinierte Line-Item-Properties in Post-Sales-Workflows und Reports nutzen
  
• Leistungsumfang während der Umsetzung anpassen, ohne Closed-Won-Umsätze zu verändern
  

Ein entscheidender Punkt ist dabei die Datenintegrität: Änderungen an Line Items auf einem Custom Object verändern nicht den ursprünglichen Deal. Forecasting, Revenue-Reporting und historische Genauigkeit bleiben unangetastet – essenziell für Finance- und Leadership-Teams.

Aus Systemdesign-Perspektive ist das ein bedeutender Schritt nach vorn.

Wo die Funktion noch reift

Aktuell richtet sich diese Funktion klar an fortgeschrittene Portale:

• Line-Item-Verknüpfungen erfordern Operations Hub / Data Hub Professional und Custom Code
  
• Es gibt keine native No-Code-Workflow-Aktion zur Erstellung der Verknüpfungen
  
• Association Labels und Limits sind noch nicht verfügbar
  

Diese Punkte schmälern den Wert der Funktion nicht. Sie zeigen vielmehr, dass HubSpot aktuell die Benutzerfreundlichkeit auf ein neu erweitertes Datenmodell aufsetzt. Eine No-Code-Abstraktion würde die Adoption deutlich verbreitern.

Multi-Currency: Die verbleibende Hürde für globale Revenue-Modelle

In Single-Currency-Portalen fühlen sich Line-Item-Verknüpfungen nahezu vollständig an.

In Multi-Currency-Umgebungen wird jedoch eine strukturelle Lücke sichtbar, die globale Teams sofort bemerken.

In der Praxis bedeutet das:

• Deal-Line-Items respektieren korrekt die Deal-Währung
  
• Line Items auf Custom Objects springen standardmäßig auf die Company-Währung
  
• Manuell erstellte Line Items auf Custom Objects ignorieren die Deal-Währung vollständig
  

Das Ergebnis ist eine gemischte Währungsdarstellung über Sales-, Delivery- und Finance-Objekte hinweg – selbst wenn sie dieselbe kommerzielle Vereinbarung abbilden.

Das nimmt der Funktion nicht ihren Wert, definiert jedoch klar eine Grenze für globale Teams.

Was die nächste Stufe ermöglichen würde

Zwei Ergänzungen würden die meisten realen Use Cases lösen:

• Währungskontrollen auf Custom Objects, vergleichbar mit Deals
  
• Oder die Möglichkeit, die Deal-Währung auf verbundene Custom Objects zu vererben und zu fixieren
  

Angesichts der aktuellen Entwicklung von HubSpot wirkt dies weniger wie eine fundamentale Limitation, sondern eher wie der nächste logische Schritt im Datenmodell.

Default Property Values: Eine ganze Klasse von Workarounds verschwindet

Eines der unscheinbarsten Updates hatte architektonisch eine enorme Wirkung: Default Values direkt auf Properties zu definieren.

Bisher mussten Teams Default-Werte simulieren über:

• „On Create“-Workflows
  
• Berechnete Properties als Konstanten
  
• Komplexe Enrollment-Logiken zur Abdeckung von Edge Cases
  

Dieses Setup war von Natur aus fragil. Ein fehlender Wert konnte Kaskadeneffekte auslösen – mit fehlerhaften Berechnungen und unzuverlässigem Reporting als Folge.

Mit nativen Default Values:

• Sinkt das Workflow-Volumen
  
• Werden berechnete Properties einfacher und stabiler
  
• Lassen sich Formulare und Feldlogiken flexibler anpassen
  
• Verstehen neue Admins sofort das intendierte Datenverhalten
  

Das ist ein Paradebeispiel für Plattform-Reife: nicht durch mehr Features, sondern durch weniger technische Schulden.

Conditional Lead Scoring: Qualifizierungslogik, die der Realität entspricht

Mit der Einführung von Conditional Scoring (AND-Logik) nähert sich das native Lead Scoring von HubSpot endlich der Realität gängiger Qualifizierungsmodelle an.

Komplexe ICP- und Persona-Definitionen lassen sich nun direkt im Scoring-Modell abbilden – ohne:

• Verkettete Active Lists
  
• Workflow-basierte Scoring-Hacks
  
• Versteckte Abhängigkeiten, die schwer wartbar sind
  

Für inbound-getriebene Go-to-Market-Modelle ist das eine fundamentale Verbesserung. Die MQL-Definition wird klarer, belastbarer und leichter weiterzuentwickeln.

Smarter Handover durch flexible Teamstrukturen

Qualifizierung ist nur dann wertvoll, wenn der anschließende Handover sauber funktioniert.

Dass Nutzer nun Hauptmitglied mehrerer Teams sein können, beseitigt eine der größten Einschränkungen im Routing. Teams können jetzt:

• Skill-basierte oder prioritätsbasierte Routing-Modelle designen
  
• Schlankere Workflows ohne doppelte Logik aufbauen
  
• Teamstrukturen weiterentwickeln, ohne ständig neu zu architektieren
  

In Kombination mit Conditional Scoring verbessert das den Weg vom First Touch bis zur klaren menschlichen Ownership erheblich.

Property History als Events: Ein echtes Analytics-Upgrade

Dass Property-Änderungen zu nativen Custom Events werden, ist ein weiteres leises, aber bedeutendes Update.

Anstatt historische Daten in einzelnen Workflows einzuschließen, werden Property-Änderungen nun wiederverwendbare Bausteine:

• Als Trigger in Workflows
  
• Nutzbar in Listen und Customer Journeys
  
• Auswertbar in Reports und Custom Datasets
  

Damit nähert sich HubSpot echter historischer Analyse – ohne fragile Snapshot-Strategien. Und das gilt auch für Custom Objects.

Das große Ganze

Einzeln betrachtet wirken viele dieser Updates inkrementell.

Zusammen zeigen sie jedoch eine Plattform, die in ihre Kernbausteine investiert – Line Items, Properties, Events, Scoring – statt nur in oberflächliche Features.

Für RevOps-Teams bedeutet das:

• Sauberere Architekturen
  
• Weniger workaround-getriebene Designs
  
• Mehr Vertrauen in natives Datenverhalten
  

Was noch fehlt, ist keine Richtung – sondern Vollendung:

• Konsistentes Multi-Currency-Handling über Deals hinaus
  
• Mehr No-Code-Zugriff auf neu gewonnene Datenmacht
  
• Eine letzte Kontrollschicht für wirklich globale Revenue-Modelle
  

Das Fundament ist solide. Die Dynamik ist real. Und wenn die letzten Releases ein Indikator sind, verliert HubSpot nicht an Tempo – es baut auf etwas deutlich Größeres hin. Und ich könnte kaum gespannter sein, wohin diese Reise führt.