Eine gemeinsame Pipeline sollte nicht jeden Markt in dasselbe minimale Datenmodell zwingen. HubSpot unterstützt jetzt mehrere Bedingungen in der bedingten Property-Logik (Conditional Property Logic) in der Public Beta. Ein Deal kann in jedem Markt dieselbe Phase durchlaufen, während sich die Pflichtfelder basierend auf einer zweiten Bedingung, wie etwa dem Land, ändern.
Welches Problem entsteht durch eine einzige gemeinsame Pipeline über mehrere Märkte hinweg?
Ein Unternehmen, das eine globale Pipeline betreibt, wünscht sich meist überall dieselben Deal Stages – für ein sauberes Reporting und vergleichbare Forecasts. Doch Märkte unterscheiden sich: Der eine Markt benötigt in einer Phase zusätzliche Qualifizierungsinformationen, die ein anderer Markt gar nicht nutzt.
Bisher standen Teams vor zwei unbefriedigenden Optionen und einem dritten, stilleren Weg: marktspezifische Daten einfach zu erfassen, ohne sie als Pflichtfelder durchzusetzen. Die beiden verbindlichen Optionen bestanden entweder aus separaten Pipelines für denselben Sales-Prozess – was doppelten Pflegeaufwand und ein schnelles Auseinanderdriften der Prozesse zwischen den Regionen bedeutete – oder darin, nur die Felder verbindlich zu machen, auf die sich jeder Markt einigen konnte.
Die Community-Idea-Threads vor dieser Beta zeigen die Kosten des ersten Weges ganz deutlich: Teams berichteten, dass sie mehr Pipelines anlegten als nötig, weil eine Logik mit nur einer Bedingung die Interaktionen zwischen Properties nicht abbilden konnte.
Was ändert sich mit HubSpots Multi-Condition Conditional Property Logic?
Mit der bedingten Eigenschaftslogik von HubSpot können Admins bereits festlegen, dass ein Feld abhängig vom Wert eines anderen Feldes angezeigt oder zum Pflichtfeld wird – etwa ein Verlängerungsdatum, das erst erscheint, sobald ein Kontakt als Kunde markiert ist.
Zwei aktuelle Betas erweitern dies auf komplementäre Weise.
Erstens machten neue Operatoren (Is Known, Is Any Of, Is Not Equal To, Is None Of) einzelne Bedingungen deutlich flexibler. So lässt sich ein Markt-Feld beispielsweise für eine gesamte Region mit einer einzigen Is-Any-Of-Bedingung einblenden – ganz ohne separate Regel pro Land.
Zweitens erweitert die Public Beta für Kombinationsoperatoren dies auf mehrere, mit UND verknüpfte Bedingungen, sodass eine abhängige Property erst dann erscheint, wenn alle Bedingungen gleichzeitig erfüllt sind. Zusammen bedeutet das: Ein marktspezifisches Feld kann für DACH-weite Deals eines bestimmten Deal-Typs angezeigt werden – ohne eine Regel pro Land.
Ein Deal kann über alle Märkte hinweg dieselben bedingten Stage-Properties (HubSpots stage-basierte Pflichtfelder) beibehalten, während ein marktspezifisches Feld über die Conditional Property Logic darübergelegt wird: Es erscheint nur, wenn die Market-Property auf Deutschland gesetzt ist und – seit der Kombination-Operatoren-Beta – eine zweite Bedingung wie der Deal-Typ ebenfalls erfüllt ist. Beide Mechanismen ergänzen sich perfekt, werden aber an unterschiedlichen Stellen konfiguriert: Stage-basierte Pflichtfelder liegen in den Pipeline-Einstellungen, wertebasierte Bedingungen in den Property-Einstellungen.
Wie verändert das Dein Reporting und Pipeline-Design?
Dank multipler Bedingungen bleiben gemeinsame Stages unternehmensweit einheitlich, da die Pipeline-Struktur nicht mehr nach Region aufgespalten werden muss. Marktspezifische Felder erscheinen nur dort, wo sie wirklich relevant sind – statt unabhängig von ihrer Relevanz an jedem Deal zu hängen.
Ein konsolidiertes Reporting lässt sich leichter pflegen: Mit einer einheitlichen Pipeline können Phasen-Definitionen zwischen Regionen nicht unbemerkt auseinanderdriften, sodass phasenbasierte Reports auch ohne manuellen Abgleich vergleichbar bleiben. Das allein macht das Reporting noch nicht verlässlich. Ausfüllquoten von Feldern, einheitliche Kriterien für den Phasenübergang und disziplinierte Nutzung bestimmen nach wie vor die Datenqualität; die gemeinsame Struktur eliminiert lediglich eine systematische Fehlerquelle.
Ein wichtiger Schritt für jedes Unternehmen, das seine GTM-Motion über mehrere Märkte hinweg skaliert: ein gemeinsames Datenmodell mit definiertem Freiraum für echte operative Unterschiede zwischen den Regionen.
Wie sollten RevOps-Teams dies auf eine Multi-Market-Pipeline anwenden?
Mappe die Properties, die sich zwischen den Märkten tatsächlich unterscheiden, bevor Du bedingte Logiken aufbaust – statt defensiv für jedes potenziell abweichende Feld Bedingungen einzufügen. Prüfe genau, welche zweite Bedingung – Markt, Deal-Typ oder Produktlinie – den Unterschied wirklich ausmacht; Kombinationslogiken stiften nur dann Nutzen, wenn das Zusammenspiel der Bedingungen eine reale Geschäftsregel abbildet. Teste die Logik an einer kleinen Auswahl von Deals in jedem betroffenen Markt, bevor Du sie portalweit ausrollst, und dokumentiere die Regel in klarer Sprache, damit Sales Reps verstehen, warum ein Feld ein- oder ausgeblendet wird.
Single-Condition- vs. Multi-Condition-Eigenschaftslogik
| Kompetenz | Einzelne Bedingung | Mehrfach-Bedingung (Beta) |
|---|---|---|
| Felder angezeigt basierend auf | Ein Property-Wert | Zwei oder mehr Werte, verknüpft mit AND |
| Typischer Use Case | Verlängerungsdatum anzeigen, sobald Kunde | Marktfeld für einen Markt und einen Deal-Typ anzeigen |
| Pipeline-Struktur erforderlich | Erzwingt oft getrennte Pipelines | Eine gemeinsame Pipeline über alle Märkte hinweg |
| Auswirkungen auf das Reporting | Risiko von Pipeline-Drift | Konsistentes, vergleichbares Reporting |
Häufig gestellte Fragen
Welche Eigenschaftstypen unterstützen mehrfach bedingte Eigenschaftslogik?
Welche HubSpot-Abonnements enthalten dieses Feature?
Bedingte Eigenschaftslogik, einschließlich Kombinationsoperatoren, erfordert Sales Hub, Marketing Hub, Service Hub, Content Hub, Data Hub oder Smart CRM auf Professional- oder Enterprise-Ebene. Teams mit Free- oder Starter-Tiers können bedingte Logik für Pipeline-Phasen als eingeschränkte Alternative nutzen, jedoch keine feldübergreifende Logik mit mehreren Bedingungen.
Wie viele Bedingungen können in einer einzigen Regel kombiniert werden?
Die aktuelle Dokumentation der Public Beta nennt keine maximale Anzahl von Bedingungen. Das ist ein Hinweis auf eine unvollständige Dokumentation, kein bestätigtes Systemlimit; überprüfe die praktische Grenze in Deinem eigenen Portal, bevor Du tief verschachtelte Regeln aufsetzt. In der Praxis ist das entscheidende Limit die Lesbarkeit für Dein Sales-Team: Jede zusätzliche Bedingung multipliziert die Zahl der Wertekombinationen, unter denen das Feld erscheint oder verschwindet – was Regeln schwerer dokumentierbar, debuggbar und übergebbar macht.
Zusätzliche Bedingungen werden per UND verknüpft – die Logik greift also erst, wenn jede einzelne Bedingung der Regel erfüllt ist. Praktische Grenzen setzt daher eher die Lesbarkeit für Dein Sales-Team als ein fixes Systemlimit.
Ersetzt dies die Notwendigkeit separater Business Units in HubSpot?
Nein. Multi-Condition-Logik löst Unterschiede bei der Datenerfassung innerhalb einer gemeinsamen Pipeline. Dieses Feature adressiert Abweichungen bei der Datenerfassung in einem geteilten Prozess. Es ersetzt keine strukturelle Trennung, wo sie wirklich notwendig ist. Beachte jedoch, dass HubSpot viele dieser Fälle innerhalb eines einzigen Portals abbildet: Mehrere Währungen werden pro Portal nativ unterstützt, und unterschiedliche Sales-Prozesse werden typischerweise als separate Pipelines und nicht als getrennte Portale modelliert.
Separate Portale oder Business Units werden erst bei wirklich getrennten Organisationen notwendig – etwa bei eigenständigen juristischen Einheiten mit individuellem User Management, separatem Branding oder spezifischen Anforderungen an die Data Residency. Starte mit der schlanksten funktionierenden Struktur, meist einer gemeinsamen Pipeline plus konditionalen Feldern, und teile sie erst auf, wenn eine konkrete Anforderung es erzwingt. Nutze dieses Feature für Varianten innerhalb eines gemeinsamen Prozesses, nicht für strukturell unterschiedliche Geschäftsbereiche.
Lässt sich eine Multi-Condition-Logik nachträglich auf bestehende Deals anwenden?
Die Logik greift künftig überall dort, wo ein Datensatz manuell erstellt oder bearbeitet wird: auf der Datensatzseite, der Indexseite des Objekts (Inline- und Bulk-Edit), im Formular zur Datensatzerstellung, in der HubSpot Mobile App und in der Sales-Extension. Sie greift nicht, wenn Datensätze durch andere HubSpot-Tools verändert werden – etwa durch Workflows, Importe oder die API. Bestehende Deals mit bereits ausgefüllten Feldern werden nicht automatisch nachvalidiert. Nach Aktivierung der Beta lohnt sich daher ein Portal-Audit, um zu prüfen, ob ältere Deals den neuen Regeln entsprechen. Prüfe beim Audit nicht nur die Datensätze selbst, sondern auch alle Workflows und Import-Routinen, die Deal-Eigenschaften befüllen – denn diese umgehen die bedingte Pflichtfeld-Logik komplett.
Welches Risiko birgt der übermäßige Einsatz von bedingter Logik in der Pipeline?
Sales Reps stehen vor einer unübersichtlichen Maske, wenn zu viele Felder abhängig von verschachtelten Bedingungen ein- und ausgeblendet werden. Setze Multi-Condition-Logik nur dort ein, wo eine echte Business-Regel sie rechtfertigt, und halte die Gesamtzahl bedingter Felder pro Stage überschaubar, damit die Datensatzansicht während eines Live-Calls nutzbar bleibt.
