Ein Kontakt, mehrere Unternehmen: Beziehungen in HubSpot richtig zuordnen

Eine Person kann für mehrere Unternehmen arbeiten und in jedem Kaufvorhaben eine andere Rolle haben. Wenn das CRM dafür nur ein Firmenfeld und einen allgemeinen Titel kennt, entstehen falsche Zuordnungen. Ein brauchbares Modell trennt die Person, das Unternehmen, den konkreten Deal und die Rolle innerhalb dieser Beziehung.

Das folgende Beispiel ist fiktiv. Es zeigt, wie ein kleiner B2B-Vertrieb seine Beziehungen abbildet und anschliessend einen Report prüft. Die Methode ist ein eigener Modellierungsvorschlag. Sie setzt keine bestimmte Unternehmensstruktur und keine bestimmte HubSpot-Lizenz voraus.

Erst klären, was jede Zeile beschreibt

Ein Kontakt beschreibt eine Person. Ein Unternehmen beschreibt die im CRM festgelegte geschäftliche Einheit. Ein Deal beschreibt ein abgegrenztes Kaufvorhaben. Diese Definitionen wirken schlicht, verhindern aber, dass eine Person für jeden Auftrag erneut angelegt wird oder ein Konzernname mehrere Vertragspartner verdeckt.

Die Rolle "Entscheiderin" ist häufig keine dauerhafte Eigenschaft einer Person. Jemand kann ein kleines Vorhaben freigeben und bei einem anderen nur beraten. Wird die Rolle am Kontakt gespeichert, wirkt sie in beiden Deals gleich. Gehört sie zur Beziehung zwischen Kontakt und Deal, bleibt der Zusammenhang erhalten.

Bevor Felder angelegt werden, schreibe vier echte Arbeitsfragen auf. Wer beantwortet fachliche Fragen? Welche Firma soll Vertragspartner sein? Wer entscheidet über diesen Deal? Welche Firma erhält die Leistung? Das Modell muss diese Fragen eindeutig beantworten. Alles Weitere bleibt zunächst ausserhalb des Mindestumfangs.

Ein Kontakt, zwei Firmen und zwei Vorhaben

Im Beispiel arbeitet Nora Weiss als externe Beraterin für Nord GmbH und Süd GmbH. Bei Nord begleitet sie die fachliche Prüfung. Bei Süd koordiniert sie einen anderen Einkauf. Sie ist bei keiner der beiden Firmen automatisch die Person mit Zeichnungsbefugnis.

Nora wird einmal angelegt und mit beiden Unternehmen verbunden. Ihre beiden Deal-Rollen werden getrennt erfasst. Damit zeigt eine Aktualisierung ihrer Telefonnummer die richtige Person, ohne dass zwei Kopien auseinanderlaufen. Gleichzeitig bleiben die beiden Kaufvorhaben und ihre Beträge getrennt.

Die unbekannte entscheidende Person wird als offene Information geführt. Ein Titel wie "Consultant" liefert dafür keinen Ersatz. Dass Nora E-Mails zum Projekt beantwortet, beweist ebenfalls keine Befugnis, einen Auftrag zu erteilen.

Beziehungen in HubSpot benennen

HubSpot unterstützt Association Labels für Beziehungen. Eigene Labels und bestimmte Verwendungen sind tarifabhängig; für die Erstellung beschreibt die Dokumentation Super-Admin-Rechte. Die konkrete Verfügbarkeit wird im verwendeten Portal geprüft. Ein Beispielmodell ist keine Zusage, dass jede Funktion in jedem Tarif enthalten ist.

Definiere vor dem Anlegen die Richtung und Bedeutung eines Labels. "Berät" und "wird beraten von" sind unterschiedliche Blickrichtungen derselben Beziehung. Eine kurze Beschreibung hält fest, welche Fälle das Label erlaubt und welche nicht. So wird "Käufer" nicht versehentlich auf jedes verbundene Unternehmen angewendet.

Wenn benannte Beziehungen im vorhandenen Setup fehlen, muss eine einfachere Darstellung ihre Grenze sichtbar machen. Ein strukturiertes Rollenregister mit Kontakt-ID und Deal-ID kann vorübergehend helfen. Ein Freitextfeld ohne eindeutigen Dealbezug löst das Problem nicht. Vor zusätzlicher Software lohnt sich die Prüfung, wie viele solcher Mehrfachbeziehungen tatsächlich bearbeitet werden.

Warum ein Report plötzlich doppelt zählt

Nimm D-40 mit 20.000 EUR. Neben Nora ist ein zweiter Kontakt zugeordnet. Ein tabellarischer Export mit einer Zeile pro Deal-Kontakt-Beziehung enthält D-40 zweimal. Werden beide Beträge addiert, erscheinen 40.000 EUR. Der Deal hat sich nicht verändert; die Körnung der Tabelle hat sich verändert.

D-41 hat einen zugeordneten Kontakt und 30.000 EUR. Die Beziehungstabelle enthält insgesamt drei Zeilen und summiert sich fälschlich auf 70.000 EUR. Auf Deal-Ebene sind es zwei eindeutige Vorhaben mit zusammen 50.000 EUR. Eine Prüfung nach Deal-ID erkennt den Unterschied.

Ein pauschales Entfernen doppelter Beträge ist keine Lösung: Zwei verschiedene Deals können denselben Betrag haben. Gruppiert wird nach der fachlichen Identität des Deals, nicht nach dem Zahlenwert. Kontakte werden in einer eigenen Ansicht gezählt. Die Reportbeschreibung nennt deshalb ausdrücklich "eine Zeile pro Deal" oder "eine Zeile pro Beziehung".

Änderungen brauchen eine zeitliche Bedeutung

Wenn Nora die Beratung bei Nord beendet, ist ihre frühere Beteiligung an D-40 weiterhin Teil des Vorgangs. Eine aktuelle Beziehung und ein historischer Projektbezug sind nicht dasselbe. Lege fest, wie das Ende einer aktiven Rolle dokumentiert wird, ohne vergangene Aktivitäten auf eine andere Person umzuhängen.

Dasselbe gilt für Firmenwechsel. Eine neue E-Mail-Adresse rechtfertigt nicht, alle alten Deals dem neuen Arbeitgeber zuzuordnen. Prüfe aktuelle Kontaktwege getrennt von historischen Käuferbeziehungen. Bei einer echten Dublette hilft der Artikel zur Identitätsprüfung; bei Statusfragen die Unterscheidung von Lifecycle, Lead-Status und Deal-Phase.

Das Modell mit einer zweiten Person abnehmen

Lass eine Person ohne Vorwissen D-40 öffnen. Sie soll Käufer, fachliche Ansprechpartnerin und offene Entscheidungsfrage benennen. Anschliessend öffnet sie D-41 und beantwortet dieselben Fragen. Wenn sie dafür den gesamten E-Mail-Verlauf durchsuchen muss, liefert das Modell die benötigte Information noch nicht.

Der technische Test vergleicht Kontaktzahl, Dealzahl und Beträge vor und nach der Zuordnung. Erwartet werden weiterhin eine Nora, zwei Vorhaben und 50.000 EUR auf Deal-Ebene. Die Beziehungstabelle darf mehr Zeilen enthalten. Ihre Summe wird nicht als Pipelinewert verwendet.

Im HubSpot-Setup gehört dieses Modell vor den Dashboardbau. Das prüfbare Ergebnis sind verständliche Beziehungen und ein Report, der jede fachliche Einheit genau nach seiner festgelegten Körnung zählt.

Quellenprüfung: 5. November 2026. Verlinkte Produktdokumentation belegt die ausdrücklich genannten Funktionen. Methoden, Tabellen und Rechenfälle sind eigene redaktionelle Vorschläge; fiktive Beispiele sind keine Kundenresultate.