Inhaltsverzeichnis
Mehrere Standorte in HubSpot: So bleibt dein CRM sauber und steuerbar
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.
Das eigentliche Problem: Standort ist nicht gleich Standort
„Standort“ kann in der Praxis ganz unterschiedliche Bedeutungen haben:
- eine reine Liefer- oder Rechnungsadresse,
- eine Filiale mit eigenen Ansprechpartnern,
- eine rechtlich eigenständige Gesellschaft,
- ein regionaler Vertriebsbereich,
- eine Serviceeinheit mit eigenen Verträgen oder Tickets.
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?
Variante 1: Ein Unternehmensdatensatz mit Standort-Eigenschaften
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:
- alle Standorte zentral eingekauft werden,
- Verträge und Entscheidungen ausschließlich über die Zentrale laufen,
- es keine standortbezogene Pipeline oder Betreuung gibt,
- Adressen nur für Kommunikation, Logistik oder interne Information benötigt werden.
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.
Variante 2: Parent-Child-Companies für Zentrale und Standorte
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:
- ACME Holding GmbH: zentrale Einkaufs- und Managementbeziehungen
- ACME Süd GmbH: regionale Vertriebs- und Serviceprozesse
- ACME Nord GmbH: eigene Ansprechpartner und lokale Deals
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 Parent-Child-Strukturen gut lösen
- die Sichtbarkeit der Unternehmenshierarchie,
- die Trennung von zentralen und lokalen Ansprechpartnern,
- die Zuordnung von Deals oder Tickets zu einer konkreten Einheit,
- die Auswertung nach Zentrale, Standort oder Gesamtgruppe,
- die Vorbereitung von Workflows und Segmentierungen.
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.
Beziehungen mit Association Labels präzisieren
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.
Wann ein eigenes Standort-Objekt sinnvoll sein kann
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:
- eigene Stammdaten und Statuswerte benötigen,
- mit mehreren Unternehmen oder Verträgen verbunden sein können,
- regelmäßig in eigenen Reports erscheinen,
- eigene Prozesse und Automationen auslösen,
- nicht deckungsgleich mit einer juristischen Gesellschaft sind.
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.
Ein praxistauglicher Entscheidungsweg
Für die Modellierung hat sich ein schrittweises Vorgehen bewährt:
- Prozesse erfassen: Kläre, ob Vertrieb, Marketing, Service, Abrechnung und Reporting zentral oder standortbezogen arbeiten.
- Granularität festlegen: Entscheide, ob eine Adresse genügt, ein Child Company benötigt wird oder eine eigene Entität erforderlich ist.
- Verantwortlichkeiten definieren: Lege fest, wer Parent- und Child-Datensätze anlegen, ändern und zusammenführen darf.
- Beziehungen dokumentieren: Definiere, welche Kontakte, Deals, Tickets und Aktivitäten an welcher Ebene hängen.
- Reporting testen: Baue einen Testreport für Standortebene und Gesamtgruppe, bevor die Struktur breit ausgerollt wird.
- Import und Integration prüfen: Stelle sicher, dass externe Systeme dieselben Schlüssel und Hierarchien verwenden.
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.
Typische Fehler bei der Umsetzung
Alle Standorte in Freitextfeldern speichern
Freitext ist schnell angelegt, aber schlecht filterbar und kaum automatisierbar. Für wiederkehrende Auswertungen gehören relevante Merkmale in strukturierte Eigenschaften oder Beziehungen.
Jeden Standort als völlig unabhängiges Unternehmen anlegen
Ohne Hierarchie geht der Zusammenhang zur Gesamtgruppe verloren. Vertrieb und Service sehen dann einzelne Datensätze, aber keine gemeinsame Kundenstruktur.
Die Parent Company als Sammelbecken verwenden
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.
Reporting erst nach der Migration bedenken
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?
SMARTTEC-Empfehlung
Für die meisten mittelständischen Unternehmen empfehlen wir, mit dem einfachsten Modell zu starten, das die realen Prozesse korrekt abbildet:
- eine Company, wenn Standorte nur Adress- oder Informationsmerkmale sind,
- Parent-Child-Companies, wenn Zentrale und Standorte jeweils eigene operative Beziehungen besitzen,
- ein Custom Object erst dann, wenn Standorte eine eigenständige fachliche Entität mit komplexen Beziehungen darstellen.
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.
