Welche HubSpot-Updates sind 2026 für RevOps-Teams wirklich relevant?
Was hat sich bei der Wiederverwendung von Datensätzen in HubSpot Workflows geändert?
HubSpot-Workflows können jetzt Datensätze wiederverwenden, die innerhalb desselben Workflows erstellt wurden. Bisher galt: Wurde in einem Workflow ein neuer Datensatz erzeugt – etwa ein Deal, eine Aufgabe oder ein Kontakt –, konnte später im selben Ablauf nicht mehr darauf zugegriffen werden. Der Workaround bestand darin, Workflows zu verketten: Workflow 1 erstellt den Datensatz, Workflow 2 greift ihn über einen Trigger auf und führt die Logik fort. Alternativ mussten Teams Custom-Code-Aktionen nutzen, um den neu erstellten Datensatz zu identifizieren und zu referenzieren.
Beide Ansätze funktionierten, brachten aber technische Schulden mit sich. Verkettete Workflows sind schwerer zu auditieren, fehleranfälliger und schwierig an neue Admins zu übergeben. Custom Code verursacht Wartungsaufwand und schafft Abhängigkeiten von denjenigen, die ihn geschrieben haben. Mit der Zeit summieren sich diese Ketten – und was als sauberes Automationsdesign begann, wird zu einem Geflecht voneinander abhängiger Flows, das niemand mehr voll durchblickt.
Die Lösung ist einfach: Derselbe Workflow kann nun einen Datensatz erstellen und später im selben Flow darauf zugreifen – einschließlich der Aktualisierung von Feldern, der Erstellung von Verknüpfungen und dem Auslösen von Folgeschritten. Für RevOps-Teams, die aus diesem Grund bisher komplexe Workflow-Ketten pflegen mussten, bedeutet das eine spürbare Vereinfachung. Der richtige Schritt: Bestehende Workflow-Designs prüfen und dort konsolidieren, wo noch das alte Muster verwendet wurde.
Was sind HubSpot Quote Rules und warum sind sie wichtig?
Mit den Quote Rules, die sich derzeit in der Public Beta im nativen CPQ von HubSpot befinden, können Revenue-Operations-Teams Verkaufslogiken definieren, die direkt bei der Angebotserstellung automatisch greifen. Regeln können prüfen, welche Produkte zusammen verkauft werden dürfen oder müssen, kommerziell ungültige Produktkombinationen blockieren, maximale Rabattobergrenzen pro Position festlegen und ergänzende Produkte empfehlen, sobald ein Kernprodukt zum Angebot hinzugefügt wird.
Das Problem, das hier gelöst wird, ist allzu bekannt: Sales-Teams wollen Tempo machen. Das Revenue Leadership fordert Margenkontrolle. Finance pocht auf strikte Rabatt-Leitplanken. Ohne ein definiertes Regelwerk führt das zu endlosen Genehmigungsschleifen für Routineentscheidungen – jede 5-%-Rabattanfrage löst einen Slack-Thread aus, jedes Sonder-Bundle braucht ein Sign-off, und die Pipeline Velocity bricht ein. Reps umgehen den Prozess, indem sie eigene Preislisten in Spreadsheets oder PDFs pflegen – das Ergebnis sind Inkonsistenzen und Datenlücken im Reporting.
Quote Rules verlagern die Durchsetzung nach vorne. Regeln werden einmal definiert und automatisch angewendet, sobald Reps Angebote in HubSpot erstellen. Freigaben bleiben echten Ausnahmen vorbehalten – nicht alltäglichen Entscheidungen, die eigentlich nie einen manuellen Review hätten erfordern dürfen. Für RevOps-Teams geht der Nutzen weit über Geschwindigkeit hinaus: Angebotsdaten werden konsistenter, Discount-Reportings verlässlich und das „Schatten-CPQ“ in Excel verschwindet nach und nach.
Wie verändert das die Positionierung von HubSpot gegenüber spezialisierten CPQ-Tools?
Historisch gesehen war HubSpots natives CPQ im Vergleich zu dedizierten Quoting-Tools eine Lücke. Quote Rules bringen es näher an HubSpot-first CPQ-Tools heran, die diese Lücke bisher gefüllt haben. Das strategische Argument für den Verbleib im nativen HubSpot-Stack liegt auf der Hand: ein Datenmodell, ein System, eine Single Source of Truth für Angebote, Regeln und Pipeline-Daten. Jedes zusätzliche Tool im Revenue Tech Stack erhöht die Integrationskomplexität und den Aufwand für Datenabgleiche. Wo HubSpots native Funktionen ausreichen, reduziert die Konsolidierung diesen Overhead spürbar.
Der Haken: Quote Rules befinden sich noch in der Beta-Phase. Beta-Features bergen Implementierungsrisiken – ihr Verhalten kann sich bis zur allgemeinen Verfügbarkeit noch ändern. RevOps-Teams sollten die aktuelle Komplexität ihrer Angebotserstellung mit dem abgleichen, was Quote Rules leisten können, bestehende Lücken identifizieren und entsprechend planen, anstatt sich bei einer vollständigen CPQ-Konsolidierung auf ein Beta-Produkt zu verlassen.
FAQ: HubSpot-Workflows und CPQ-Updates
Muss ich bestehende Workflows umbauen, um die Wiederverwendung von Datensätzen zu nutzen?
Ein kompletter Neuaufbau ist nicht erforderlich. Bestehende Workflows funktionieren weiter wie gewohnt. Die Chance liegt darin, Workflow-Ketten zu überarbeiten, die nur deshalb gebaut wurden, weil die Wiederverwendung von Datensätzen nicht möglich war – diese lassen sich jetzt zu einzelnen Flows vereinfachen, was den Wartungsaufwand reduziert und die Nachvollziehbarkeit verbessert.
Welche Arten von Regeln können in HubSpot Quote Rules definiert werden?
In der aktuellen Betaversion unterstützen Quote Rules die Validierung von Produktbündeln (erforderliche und ausgeschlossene Kombinationen), maximale Rabatte pro Position sowie Produktempfehlungen, die durch das Hinzufügen bestimmter Artikel ausgelöst werden. Der Funktionsumfang kann vor der allgemeinen Verfügbarkeit noch erweitert werden.
Reicht das native CPQ von HubSpot mittlerweile für B2B-SaaS-Unternehmen aus?
Für Unternehmen mit moderater Angebotskomplexität – Standard-Produktkatalogen, einfacher Rabattlogik und wenigen Freigabestufen – reicht HubSpot CPQ mit Quote Rules meist völlig aus. Unternehmen mit hochvolumigen, stark konfigurierbaren Produkten, komplexen Pricing Engines oder mehrstufigen Genehmigungshierarchien über mehrere Währungen hinweg benötigen möglicherweise weiterhin ein dediziertes CPQ-Tool.
Wie sollten RevOps-Teams diese Updates priorisieren?
Starte mit einem Audit. Für die Record-Wiederverwendung: Identifiziere, welche Multi-Workflow-Ketten wegen früherer Beschränkungen existieren, und schätze den Konsolidierungsaufwand ab. Für Quote Rules: Gleiche aktuelle Pain Points bei der Angebotserstellung – wie Freigabefrequenzen, inkonsistente Rabatte oder Schatten-Tabellen – mit den Möglichkeiten der Regel-Ebene ab.
Welches Risiko birgt der Einsatz von Beta-Funktionen in der Produktivumgebung?
Beta-Features können sich in Verhalten oder Verfügbarkeit noch ändern, bevor sie allgemein verfügbar (General Availability) sind. Speziell bei Quote Rules solltest Du unternehmenskritische Angebotslogik nicht ohne Fallback-Plan auf Beta-Funktionalitäten aufbauen. Nutze die Beta-Phase, um das Feature anhand Deiner Quoting-Anforderungen zu validieren – nicht, um bestehende Systeme direkt vollständig abzulösen.
