Viele Unternehmen wachsen schneller als ihr CRM-Datenmodell. Eine Zentrale, mehrere Filialen, regionale Ansprechpartner und unterschiedliche Liefer- oder Servicebeziehungen landen dann häufig in einem einzigen Unternehmensdatensatz. Anfangs wirkt das unkompliziert. Später entstehen jedoch unklare Zuständigkeiten, falsche Segmentierungen und Reports, die zentrale und lokale Umsätze vermischen.
Die entscheidende Frage lautet deshalb nicht: „Wie kann ich möglichst viele Adressen in HubSpot speichern?“ Sondern: Welche Einheit soll in welchem Prozess als Unternehmen gelten?
Dieser Artikel zeigt, wie du Unternehmen mit mehreren Standorten in HubSpot sinnvoll strukturierst, wann die Parent-Child-Logik ausreicht und wann ein eigenes Datenmodell erforderlich wird.
„Standort“ kann in der Praxis ganz unterschiedliche Bedeutungen haben:
Diese Einheiten sollten nicht automatisch gleich modelliert werden. Eine zusätzliche Adresse als Eigenschaft auf dem Unternehmensdatensatz kann für einen Versandprozess genügen. Sie reicht aber nicht aus, wenn der Standort eigene Deals, Ansprechpartner, Servicefälle oder Umsätze besitzt.
Ein belastbares Datenmodell beginnt daher mit einer fachlichen Entscheidung: Welche Prozesse werden auf Ebene der Gesamtorganisation gesteuert und welche auf Standortebene?
Die einfachste Lösung ist ein einziger Unternehmensdatensatz für die gesamte Organisation. Zusätzliche Eigenschaften speichern beispielsweise Hauptadresse, Vertriebsregion, Standortanzahl oder eine Liste wichtiger Niederlassungen.
Diese Variante ist sinnvoll, wenn:
Der Vorteil liegt in der geringen Komplexität. Kontakte und Deals müssen nicht auf mehrere Unternehmensdatensätze verteilt werden. Auch Segmentierungen bleiben leichter verständlich.
Die Grenze ist schnell erreicht: Sobald ein Standort separat angesprochen, verkauft, betreut oder ausgewertet werden soll, werden einfache Eigenschaften zu einer Notlösung. Mehrere Ansprechpartner lassen sich zwar am Unternehmen speichern, aber ihre konkrete Zuordnung zu einzelnen Niederlassungen bleibt unklar. Gleiches gilt für Deals, Tickets und Aktivitäten.
Für viele mittelständische Unternehmen ist die Parent-Child-Struktur der beste Ausgangspunkt. Die Zentrale wird als übergeordnetes Unternehmen angelegt. Jede Filiale oder regionale Gesellschaft erhält einen eigenen Unternehmensdatensatz und wird als untergeordnetes Unternehmen verknüpft.
HubSpot unterstützt dafür die Beziehungen „Parent company“ und „Child company“. Eine übergeordnete Gesellschaft kann mehrere untergeordnete Unternehmen besitzen; ein untergeordnetes Unternehmen kann dabei nur einer übergeordneten Gesellschaft zugeordnet werden. Das passt gut zu klassischen Konzern-, Filial- oder Niederlassungsstrukturen.
Ein mögliches Modell sieht so aus:
Wichtig ist, dass die Hierarchie nicht nur optisch gepflegt wird. Sie muss in Prozesse übersetzt werden. Beispielsweise können zentrale Ansprechpartner der Parent Company zugeordnet werden, während lokale Einkäufer, Servicekontakte und Deals am jeweiligen Child Company-Datensatz hängen.
Was sie nicht automatisch lösen, ist die fachliche Konsolidierung. Ein Report über die gesamte Unternehmensgruppe muss bewusst definieren, ob Daten der Parent Company, der Child Companies oder beider Ebenen einbezogen werden. Ohne diese Regel entstehen schnell Doppelzählungen oder unvollständige Ergebnisse.
Ein Unternehmensdatensatz allein erklärt noch nicht, welche Rolle ein Kontakt oder Deal in der Struktur spielt. Dafür sind beschreibende Verknüpfungen hilfreich. Association Labels können beispielsweise kenntlich machen, ob ein Kontakt als Standortleitung, Einkauf, Rechnungskontakt oder Serviceverantwortlicher zugeordnet ist.
Der Nutzen entsteht vor allem dann, wenn diese Beziehungen in Segmentierungen, Reports oder Workflows verwendet werden. Ein Workflow könnte etwa nur Kontakte mit der Rolle „Servicekontakt“ berücksichtigen. Ein Vertriebsteam kann sich auf Entscheider der Parent Company konzentrieren, während ein regionales Team die Ansprechpartner der Child Companies bearbeitet.
Labels sollten jedoch nicht inflationär eingesetzt werden. Wenn für jede denkbare Ausnahme ein neues Label entsteht, wird das Datenmodell schwer verständlich. Besser sind wenige, klar definierte Rollen mit einer dokumentierten Bedeutung.
Ein eigenes Objekt für Standorte kann sinnvoll werden, wenn der Standort eine eigenständige operative Einheit ist, aber nicht sauber als Unternehmen abgebildet werden soll. Typische Beispiele sind Filialen, Verkaufsstellen, Anlagen, betreute Einrichtungen oder regionale Servicepunkte.
Ein solches Modell ist besonders interessant, wenn Standorte:
Custom Objects sind allerdings kein kostenloser Ausweg aus einem ungeklärten Datenmodell. Sie erhöhen den Abstimmungs-, Administrations- und Integrationsaufwand. Außerdem hängen sie von den verfügbaren HubSpot-Abonnements ab. Die offizielle Entwicklerdokumentation nennt für das Anlegen und Verwalten eigener Objektschemata Enterprise-Anforderungen. Das sollte vor der Konzeption anhand des konkreten Portals geprüft werden.
Als Faustregel gilt: Wenn ein Standort wie ein eigenständiges Unternehmen verkauft, betreut und ausgewertet wird, ist ein Company-Datensatz meist verständlicher. Wenn der Standort eine zusätzliche fachliche Entität zwischen Unternehmen, Verträgen und Prozessen darstellt, kann ein Custom Object die bessere Architektur sein.
Für die Modellierung hat sich ein schrittweises Vorgehen bewährt:
Besonders wichtig ist ein eindeutiger Identifikator je Standort. Der Name allein ist selten ausreichend, weil Schreibweisen variieren und sich Gesellschaften umbenennen können. Je nach Systemlandschaft kommen Kundennummern, Standortnummern oder externe IDs infrage.
Freitext ist schnell angelegt, aber schlecht filterbar und kaum automatisierbar. Für wiederkehrende Auswertungen gehören relevante Merkmale in strukturierte Eigenschaften oder Beziehungen.
Ohne Hierarchie geht der Zusammenhang zur Gesamtgruppe verloren. Vertrieb und Service sehen dann einzelne Datensätze, aber keine gemeinsame Kundenstruktur.
Wenn lokale Deals, Tickets und Kontakte konsequent nur an der Zentrale hängen, lässt sich die operative Realität später nicht mehr zuverlässig auswerten. Die Zuordnung sollte dem tatsächlichen Prozess folgen.
Ein Datenmodell, das technisch importierbar ist, muss nicht automatisch reportfähig sein. Definiere die wichtigsten Fragen vorher: Welcher Standort hat offene Deals? Welche Gruppe erzielt welchen Umsatz? Wer ist für welchen Servicefall zuständig?
Für die meisten mittelständischen Unternehmen empfehlen wir, mit dem einfachsten Modell zu starten, das die realen Prozesse korrekt abbildet:
Der wichtigste Schritt ist nicht die technische Einrichtung, sondern die gemeinsame Definition der Geschäftslogik. Wer vorab festlegt, welche Ebene für Marketing, Sales, Service und Reporting maßgeblich ist, verhindert spätere Sonderlösungen.
Ein sauberes HubSpot-Datenmodell muss nicht maximal komplex sein. Es muss verständlich, steuerbar und für die wichtigsten Prozesse belastbar sein. Genau daran sollte sich die Entscheidung für Eigenschaften, Unternehmenshierarchien oder eigene Objekte orientieren.