Wie erzwingen Sie unterschiedliche CRM-Felder je Markt in HubSpot?

Eine gemeinsame Pipeline sollte nicht jeden Markt auf dasselbe Mindest-Datenmodell zwingen. HubSpot unterstützt jetzt mehrere Bedingungen in der Conditional Property Logic, im Public Beta. Ein Deal kann in jedem Markt dieselbe Phase durchlaufen, während sich die Pflichtfelder ändern, sobald eine zweite Bedingung erfüllt ist, etwa das Land.

Welches Problem entsteht durch eine gemeinsame Pipeline über mehrere Märkte hinweg?

Ein Unternehmen mit einer globalen Pipeline möchte in der Regel überall dieselben Deal-Phasen, für saubere Berichte und vergleichbare Prognosen. Märkte unterscheiden sich jedoch. Ein Markt benötigt in einer bestimmten Phase zusätzliche Qualifizierungsinformationen, die ein anderer Markt nicht braucht. Bislang mussten Teams zwischen zwei schwachen Optionen wählen. Entweder sie bauten separate Pipelines für denselben Vertriebsprozess auf, was doppelten Pflegeaufwand und schnelle Prozessabweichungen zwischen den Regionen bedeutete. Oder sie erzwangen nur die Felder, auf die sich alle Märkte einigen konnten, wodurch wichtige, marktspezifische Daten komplett aus dem CRM herausfielen. Keine der beiden Optionen reicht für ein RevOps-Team, das sowohl Konsistenz als auch präzise lokale Datenerfassung braucht.

Was ändert sich mit der Mehrfachbedingungs-Logik von HubSpot?

Die Conditional Property Logic von HubSpot erlaubt es Administratoren bereits, ein Feld basierend auf dem Wert eines anderen Feldes zu erfordern oder anzuzeigen, etwa ein Verlängerungsdatum, das erst erscheint, sobald ein Kontakt als Kunde markiert ist. Das Public Beta für Kombinationsoperatoren erweitert dies auf mehrere Bedingungen, die mit UND verknüpft werden, sodass ein abhängiges Feld nur erscheint, wenn alle Bedingungen gleichzeitig erfüllt sind. Ein Deal kann so in jedem Markt dieselben Phasen-Pflichtfelder verlangen, während ein marktspezifisches Feld nur erscheint, wenn das Marktfeld beispielsweise auf Deutschland gesetzt ist und gleichzeitig eine zweite Bedingung, etwa der Deal-Typ, zutrifft.

Wie verändert das Reporting und Pipeline-Design?

Mit mehreren verfügbaren Bedingungen bleiben gemeinsame Phasen unternehmensweit gemeinsam, da die zugrunde liegende Pipeline-Struktur nicht mehr nach Region aufgespalten werden muss. Marktspezifische Felder erscheinen nur dort, wo sie wirklich relevant sind, statt jedem Deal unabhängig von der Relevanz aufgezwungen zu werden. Das Reporting wird zuverlässiger, weil es eine Pipeline gibt, gegen die berichtet wird, statt mehrerer regionaler Kopien, die im Laufe der Zeit auseinanderdriften. Das ist ein bedeutender Schritt für jedes Unternehmen, das ein GTM-Modell über mehr als einen Markt skaliert: ein gemeinsames Modell mit definiertem Raum für echte betriebliche Unterschiede zwischen Regionen.

Wie sollten RevOps-Teams das auf eine Multi-Market-Pipeline anwenden?

Kartieren Sie zunächst die Felder, die sich tatsächlich je Markt unterscheiden, statt vorsorglich Bedingungen für jedes theoretisch variable Feld hinzuzufügen. Klären Sie, welche zweite Bedingung, Markt, Deal-Typ oder Produktlinie, den Unterschied tatsächlich bestimmt, denn Kombinationslogik ist nur sinnvoll, wenn das Zusammenspiel der Bedingungen eine echte Geschäftsregel widerspiegelt. Testen Sie die Logik zunächst an einer kleinen Gruppe von Deals in jedem betroffenen Markt, bevor Sie sie portalweit ausrollen, und dokumentieren Sie die Regel in einfacher Sprache, damit Vertriebsmitarbeitende verstehen, warum ein Feld erscheint oder verschwindet.

Einzelbedingung vs. Mehrfachbedingungs-Logik

Zwei aktuelle Betas erweitern diese Funktion aufeinander abgestimmt.

Erstens machen neue Operatoren (Is Known, Is Any Of, Is Not Equal To, Is None Of) Einzelbedingungen deutlich flexibler. So kann beispielsweise ein Marktfeld mit einer einzigen Is-Any-Of-Bedingung für eine ganze Region angezeigt werden, ohne eine separate Regel für jedes Land zu benötigen.

Zweitens erweitert die Public Beta für Kombinationsoperatoren dies auf mehrere Bedingungen, die mit UND verknüpft werden, sodass eine abhängige Eigenschaft nur erscheint, wenn alle Bedingungen gleichzeitig erfüllt sind. Zusammen bedeutet das, dass ein marktspezifisches Feld für DACH-weite Deals eines bestimmten Deal-Typs erscheinen kann, ohne eine Regel pro Land.

Ein Deal kann in jedem Markt dieselben bedingten Phasen-Eigenschaften (HubSpots phasenbasierte Pflichtfelder) beibehalten, während ein marktspezifisches Feld zusätzlich über die Conditional Property Logic erzwungen wird: Es erscheint nur, wenn das Marktfeld auf Deutschland gesetzt ist und – seit der Beta für Kombinationsoperatoren – eine zweite Bedingung wie der Deal-Typ ebenfalls erfüllt ist. Die beiden Mechanismen ergänzen sich, werden aber an unterschiedlichen Stellen konfiguriert: Phasenbasierte Anforderungen in den Pipeline-Einstellungen, wertbasierte Bedingungen in den Eigenschaftseinstellungen.

Wie verändert das Reporting und Pipeline-Design?

Mit mehreren verfügbaren Bedingungen bleiben gemeinsame Phasen unternehmensweit gemeinsam, da die zugrunde liegende Pipeline-Struktur nicht mehr nach Region aufgespalten werden muss. Marktspezifische Felder erscheinen nur dort, wo sie tatsächlich relevant sind, statt jedem Deal unabhängig von seiner Relevanz zugeordnet zu werden.

Konsolidiertes Reporting lässt sich dadurch leichter pflegen: Bei einer Pipeline können Phasendefinitionen nicht unbemerkt zwischen Regionen auseinanderlaufen, sodass phasenbasierte Berichte ohne manuelle Abstimmung vergleichbar bleiben. Das macht Reporting nicht automatisch zuverlässig. Ausfüllquoten der Felder, konsistente Kriterien für den Phasenwechsel und disziplinierte Nutzung bestimmen weiterhin die Datenqualität; die gemeinsame Struktur beseitigt lediglich eine systematische Quelle von Abweichungen.

Das ist ein wichtiger Schritt für jedes Unternehmen, das ein GTM-Modell über mehr als einen Markt skaliert: ein gemeinsames Modell mit definiertem Raum für echte betriebliche Unterschiede zwischen Regionen.

Wie sollten RevOps-Teams das auf eine Multi-Market-Pipeline anwenden?

Kartieren Sie zunächst die Eigenschaften, die sich tatsächlich je Markt unterscheiden, bevor Sie bedingte Logik aufbauen, statt vorsorglich Bedingungen für jedes Feld hinzuzufügen, das theoretisch variieren könnte. Klären Sie, welche zweite Bedingung – Markt, Deal-Typ oder Produktlinie – den Unterschied tatsächlich bestimmt, denn Kombinationslogik ist nur sinnvoll, wenn das Zusammenspiel der Bedingungen eine echte Geschäftsregel widerspiegelt. Testen Sie die Logik zunächst an einer kleinen Gruppe von Deals in jedem betroffenen Markt, bevor Sie sie portalweit ausrollen, und dokumentieren Sie die Regel in einfacher Sprache, damit Vertriebsmitarbeitende verstehen, warum ein Feld erscheint oder verschwindet.

Einzelbedingung vs. Mehrfachbedingungs-Logik

‍

‍

Häufig gestellte Fragen

Welche Eigenschaftstypen unterstützen die Mehrfachbedingungs-Logik?

Die Conditional Property Logic von HubSpot gilt für Enumerationseigenschaften wie Dropdown-Auswahlen und einzelne Kontrollkästchen sowie für Datums- und Datum-Uhrzeit-Eigenschaften. Die Logik greift überall dort, wo Nutzer Datensätze manuell anlegen oder bearbeiten, einschließlich der Datensatzseite und der Indexseite.

Welche HubSpot-Abonnements beinhalten diese Funktion?

Conditional Property Logic einschließlich der 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-Tarifen können bedingte Logik für Pipeline-Phasen als eingeschränkte Alternative nutzen, jedoch keine Mehrfachbedingungs-Logik für Eigenschaften.

Wie viele Bedingungen lassen sich in einer Regel kombinieren?

Die aktuelle Public-Beta-Dokumentation nennt keine maximale Anzahl von Bedingungen. Das ist eine Feststellung zur fehlenden Dokumentation und kein bestätigtes Systemlimit; prüfen Sie die praktische Obergrenze in Ihrem eigenen Portal, bevor Sie tief verschachtelte Regeln aufbauen. In der Praxis ist die entscheidende Grenze die Verständlichkeit für Ihr Vertriebsteam: Jede zusätzliche Bedingung vervielfacht die Anzahl der Wertekombinationen, unter denen das Feld erscheint oder verschwindet, und macht Regeln dadurch schwieriger zu dokumentieren, zu debuggen und zu übergeben.

Zusätzliche Bedingungen werden mit UND verknüpft. Die Logik greift also nur, wenn alle Bedingungen der Regel erfüllt sind; praktische Grenzen ergeben sich daher eher daraus, was für Ihr Vertriebsteam verständlich bleibt, als aus einem festen Systemmaximum.

Ersetzt das die Notwendigkeit separater Business Units in HubSpot?

Nein. Mehrfachbedingungs-Logik löst Unterschiede in der Datenerfassung innerhalb einer gemeinsamen Pipeline. Die Funktion adressiert Variationen bei der Datenerfassung innerhalb eines gemeinsamen Prozesses. Sie ersetzt keine strukturelle Trennung, wenn diese tatsächlich erforderlich ist. HubSpot bildet allerdings mehrere dieser Fälle innerhalb eines einzigen Portals ab: Mehrere Währungen werden nativ pro Portal unterstützt, und unterschiedliche Vertriebsprozesse werden typischerweise als separate Pipelines modelliert, nicht als separate Portale.

Separate Portale oder Business Units werden erst für wirklich eigenständige Organisationen notwendig, etwa separate Rechtseinheiten mit eigener Benutzerverwaltung, eigenem Branding oder Anforderungen an die Datenresidenz. Beginnen Sie mit der kleinstmöglichen Struktur, die funktioniert – in der Regel eine gemeinsame Pipeline plus bedingte Felder – und trennen Sie erst, wenn eine konkrete Anforderung dies erzwingt. Nutzen Sie diese Funktion für Variationen innerhalb eines gemeinsamen Prozesses, nicht für strukturell unterschiedliche Geschäfte.

Lässt sich die Mehrfachbedingungs-Logik rückwirkend auf bestehende Deals anwenden?

Die Logik wird künftig überall dort erzwungen, wo ein Datensatz manuell angelegt oder bearbeitet wird: auf der Datensatzseite, der Objekt-Indexseite (Inline- und Massenbearbeitung), im Formular zum Erstellen eines Datensatzes, in der HubSpot Mobile App und in der Sales Extension. Sie greift nicht, wenn Datensätze durch andere HubSpot-Tools wie Workflows, Importe oder die API geändert werden. Bestehende Deals mit bereits ausgefüllten Feldern werden nicht automatisch erneut validiert. Ein Portal-Audit nach Aktivierung der Beta lohnt sich daher, um zu prüfen, ob ältere Deals noch den neuen Regeln entsprechen. Prüfen Sie bei einem Audit bestehender Deals nicht nur die Datensätze selbst, sondern auch Workflows und Importprozesse, die Deal-Eigenschaften befüllen, da diese die bedingte Durchsetzung vollständig umgehen.

Welches Risiko birgt eine übermäßige Nutzung bedingter Logik in einer Pipeline?

Vertriebsmitarbeitende sehen eine verwirrende Oberfläche, wenn zu viele Felder aufgrund verschachtelter Bedingungen erscheinen und verschwinden. Setzen Sie Mehrfachbedingungs-Logik nur dort ein, wo eine echte Geschäftsregel das rechtfertigt, und begrenzen Sie die Gesamtzahl bedingter Felder je Phase, damit die Datensatzseite während eines laufenden Gesprächs nutzbar bleibt.