HubSpot Custom Objects für B2B SaaS

Was ist ein benutzerdefiniertes Objekt in HubSpot, und wann braucht ein B2B-SaaS-Unternehmen wirklich eines?

Ein benutzerdefiniertes Objekt (Custom Object) ist in HubSpot eine eigene Datentabelle neben den Standardobjekten Kontakte, Companies, Deals und Tickets – gedacht für Daten, die spezifisch zum eigenen Geschäftsmodell gehören, und ausschließlich auf HubSpot Enterprise verfügbar. Für B2B-SaaS ist der häufigste Kandidat ein Abo- oder Lizenz-Objekt, das Verlängerungsdatum, Tier und Nutzung getrennt vom ursprünglichen Deal verfolgt.

Die meisten SaaS-Unternehmen stoßen nicht wegen der Datenmenge an diese Grenze. Sie stoßen daran, weil Deal- und Company-Eigenschaften etwas abbilden sollen, wofür sie nie gebaut wurden. Ein Deal wird gewonnen, eine Eigenschaft namens verlaengerungsdatum landet auf der Company, dann kommt eine zweite Produktlinie dazu und jemand legt verlaengerungsdatum_produkt_b daneben an. Eine dritte Linie folgt demselben Muster.

Zunächst bricht dabei nichts. Es summiert sich nur.

Der eigentliche Bruch zeigt sich erst, wenn eine einzelne Company gleichzeitig drei laufende Abos mit unterschiedlichem Verlängerungsdatum, Tier und Sitzplatzanzahl führt. Eine Company kann pro Eigenschaft genau einen Wert halten. Sie kann nicht "drei davon, jedes mit eigenem Zeitplan" halten – und jeder Workaround ab diesem Punkt (durchnummerierte Eigenschaften, ein gemeinsames Notizfeld, eine Excel-Liste neben HubSpot) ist ein Symptom desselben Problems: Die Daten haben eine 1:n-Struktur, das Objektmodell aber nicht.

Das ist keine Frage mangelnder Disziplin. Es passiert standardmäßig, sobald eine SaaS-Produktlinie sich von einer in zwei, dann drei aufteilt und das CRM-Setup aus einer Zeit stammt, in der pro Kunde nur ein Abo zu verfolgen war. Niemand hat das so entschieden. Es ist so gewachsen, eine Eigenschaft nach der anderen – genau wie die meisten Altlasten im CRM-Datenmodell.

Wie entscheidet man zwischen einem benutzerdefinierten Objekt und einer Eigenschaft?

Der Entscheidungstest hat zwei Fragen: Hat diese Information eine 1:n-Beziehung zu einem bestehenden Datensatz, und braucht sie eine eigene offene Verkaufschancen oder einen eigenen Lifecycle, unabhängig vom Deal? Zwei Mal Ja bedeutet: ein Objekt. Ein Mal oder kein Mal Ja bedeutet meist: eine Eigenschaft, eine Auswahlliste oder eine Lifecycle-Stage reicht – und ist günstiger zu pflegen.

Die meisten Teams drehen diese Logik um. Ein neuer Datenpunkt taucht auf, fühlt sich "speziell" an, und jemand greift standardmäßig zum mächtigeren Werkzeug – ohne zu prüfen, ob die zugrundeliegende Beziehung das überhaupt verlangt. Verständlicher Reflex. Genau so entstehen aber HubSpot-Instanzen mit benutzerdefinierten Objekten, an deren Entstehung sich niemand mehr erinnert.

Eine Regel überlebt die Tabelle: Stehen zwei oder mehr dieser Zeilen gleichzeitig bei derselben Company an, ist es ein Objekt. Gibt es immer nur eine, ist es eine Eigenschaft.

Ein konkreter Fall macht das greifbar. Ein 45-Personen-SaaS-Unternehmen verkauft drei Produkt-Tiers, jedes einzeln abgerechnet und verlängert, an dieselben Enterprise-Accounts, die oft mehr als ein Tier gleichzeitig kaufen. Kardinalität: Ja, mehrere gleichzeitige Abos pro Company. Lifecycle: Ja, jedes Tier verlängert sich nach eigenem Rhythmus, unabhängig davon, wann der ursprüngliche Deal geschlossen wurde. Zwei Mal Ja – das ist ein Objekt, und keine noch so klug benannte Eigenschaft ändert daran etwas. Dasselbe Unternehmen mit nur einem Tier und einfacher Jahresverlängerung würde beide Fragen mit Nein beantworten und sollte gar keins bauen.

Was verlangt HubSpot tatsächlich für ein benutzerdefiniertes Objekt?

Benutzerdefinierte Objekte verlangen ein Enterprise-Abonnement über jeden HubSpot Hub hinweg – Marketing, Sales, Service, Content, Data und Smart CRM –, nicht nur den Sales Hub, direkt bestätigt gegen HubSpots eigene Dokumentation. Kontoberechtigungen regeln, wer sie anlegen und verwalten darf, und sowohl die Anzahl der Objekte als auch die Eigenschaften-Limits pro Objekt sind abo-abhängig statt fix und öffentlich.

Diese Enterprise-Anforderung gehört vor die Projektplanung, nicht danach. Sie ist eine echte Kostenschwelle, und sie gilt Hub-übergreifend – ein Team mit Sales Hub Enterprise, aber Marketing Hub Professional, kann trotzdem kein Objekt anlegen.

HubSpots eigene Dokumentation ist bei mindestens einer Grenze konkret, die relevant wird, sobald ein Abo-Objekt gleichzeitig mit Companies, Deals und einer Verlängerungs-offene Verkaufschancen verknüpft werden soll: Verknüpfungs-Limits zwischen Datensätzen lassen sich auf bis zu 10'000 pro Verknüpfungstyp konfigurieren, verfügbar ab dem Professional-Tier über Marketing Hub, Sales Hub, Service Hub, Data Hub, Content Hub und Revenue Hub hinweg. Diese Obergrenze spielt beim ersten Aufbau selten eine Rolle – die meisten SaaS-Instanzen brauchen pro Abo-Datensatz nur eine Handvoll Verknüpfungen: eine Company, einen auslösenden Deal, vielleicht einen Verlängerungs-Deal. Relevant wird sie erst später, wenn ein Support-Ticket, ein Nutzungsereignis und eine Verlängerungschance alle denselben Abo-Datensatz referenzieren sollen, ohne dass HubSpot die Anzahl stillschweigend deckelt. Diese Zahl früh prüfen – nicht erst, wenn ein Datenmodell bereits auf einer Annahme statt auf einer dokumentierten Grenze aufgebaut ist.

Die Anzahl erlaubter Objekte und Eigenschaften selbst steht nicht als feste Zahl in HubSpots Objekt-Dokumentation – sie ist abo-abhängig und im Produkt- und Leistungskatalog von HubSpot gelistet. Jede Zahl, die anderswo kursiert, gilt als ungeprüft, bis sie gegen das eigene Portal und dessen tatsächliches Tier abgeglichen wurde.

Berechtigungen gehören vor den Baubeginn entschieden, nicht danach. HubSpot koppelt das Anlegen und Verwalten benutzerdefinierter Objekte an kontoweite Berechtigungen, getrennt von den Standard-Objektrechten, die Vertriebsmitarbeiter ohnehin schon haben. In der Praxis heißt das: Eine benannte Person – meist wer Vertriebssteuerung und Auswertung oder die CRM-Administration verantwortet – entscheidet, wer überhaupt ein neues Objekt anlegen darf, bevor das zweite oder dritte von irgendwem angelegt wird, der gerade an eine Grenze gestoßen ist.

Hier entscheidet sich auch, ob das Objekt intern gebaut wird oder ein HubSpot-Implementierungspartner dazukommt. Interne Umsetzung funktioniert gut bei einem wirklich einfachen Fall – ein Abo-Typ, ein Verlängerungsmuster. Sobald mehrere Pipelines, Hub-übergreifende Berechtigungen und Automatisierungen gleichzeitig zusammenpassen müssen, übersteigen die Kosten eines falschen ersten Versuchs meist die Kosten, sich vorher Unterstützung zu holen.

Wie modelliert man ein Abo-Objekt für ein SaaS-Unternehmen Schritt für Schritt?

Ein Abo-Objekt zu modellieren heißt: Eigenschaften definieren, es mit den Datensätzen verknüpfen, von denen es abhängt, ihm eine eigene offene Verkaufschancen geben und mindestens eine Automatisierung anschließen, bevor es live geht. Wird der letzte Schritt ausgelassen, existiert das Objekt im Datenmodell, ohne irgendeine Arbeit zu leisten.

1. Objekt und Kerneigenschaften definieren. Tier, monatlich wiederkehrender Umsatz (MRR), Verlängerungsdatum und Sitzplatz- oder Nutzungsanzahl sind die vier, die in fast jedem SaaS-Aufbau auftauchen.
2. Verknüpfungen setzen. Den Abo-Datensatz mit seiner Company, dem auslösenden Deal und – getrennt davon – einer Verlängerungs-offene Verkaufschancen verbinden, die er später durchläuft.
3. Eine eigene Verlängerungs-offene Verkaufschancen bauen, statt die ursprüngliche Sales-offene Verkaufschancen weiterzunutzen. Verlängerungen haben andere Stages (bevorstehend, gefährdet, verlängert, gekündigt) als ein Erstverkauf – wer beides mischt, macht beide Reports weniger verlässlich.
4. Berechtigungs- und Ansichtsplan für Vertriebsmitarbeiter festlegen, vor dem Launch: Wer sieht das Objekt, welche Standardansicht bekommt wer, welche Eigenschaften sind editierbar statt nur lesbar.
5. Mindestens eine Automatisierung anschließen. Eine Verlängerungserinnerung, 60 Tage vor dem Verlängerungsdatum ausgelöst, ist die minimale Version; Nutzungsschwellen-Alerts und Churn-Risiko-Scoring können folgen, sobald das Basisobjekt stabil läuft.

Schritt eins und zwei sind meist schnell erledigt – ein paar Stunden Konfiguration für ein Team, das seine eigene Abo-Struktur bereits kennt. Schritt drei, die eigene Verlängerungs-offene Verkaufschancen, ist die Stelle, an der Teams versucht sind, die Ecke zu schneiden und stattdessen die Sales-offene Verkaufschancen wiederzuverwenden. Nicht tun. HubSpots eigene offene Verkaufschancen-Dokumentation behandelt Pipelines für benutzerdefinierte Objekte als eigenständig konfiguriert, mit eigenen Stages und Automatisierungsregeln – die Plattform selbst geht davon aus, dass ein Verlängerungs-Lifecycle und ein Neugeschäfts-Lifecycle zwei verschiedene Dinge sind, keine offene Verkaufschancen mit zwei Hüten. Eine offene Verkaufschancen für Neugeschäft und eine für Verlängerungsrisiko brauchen unterschiedliche Stages, unterschiedliche Reports und oft unterschiedliche Owner – wer beides zusammenlegt, macht beide schlechter in dem, was sie eigentlich leisten sollen.

Wo scheitern Projekte mit benutzerdefinierten Objekten in der Praxis?

Drei Muster erklären die meisten gescheiterten Objekt-Projekte: Niemand pflegt das Objekt nach dem Launch, Vertriebsmitarbeiter übernehmen es nie, weil niemand Berechtigungen und Standardansichten geplant hat, oder das Objekt bekommt nie eine Automatisierung angeschlossen. Jedes Muster sieht anders aus, hat aber dieselbe Ursache – das Objekt wurde als Datenmodellierungs-Übung gebaut, nicht als System, das jemandem gehört.

• Objekt-Wildwuchs. Ein zweites, dann ein drittes Objekt kommt für Randfälle dazu, die als Eigenschaft auf dem ersten Objekt geblieben wären. Sechs Monate später kann niemand mehr erklären, warum es vier SaaS-bezogene Objekte statt eines gibt.
• Kein Berechtigungs- oder Ansichtsplan. Das Objekt existiert, aber Vertriebsmitarbeiter sehen es nie in ihrem Standard-Arbeitsbereich und arbeiten aus Gewohnheit weiter mit Deal-Eigenschaften. Nicht das Schema ist gescheitert, sondern die Einführung.
• Ein Datenfriedhof. Datensätze entstehen und werden nie wieder angefasst – keine Verlängerungserinnerung, kein Churn-Risiko-Workflow, nichts, das die Daten des Objekts liest und etwas damit tut. Ein ungenutztes benutzerdefiniertes Objekt ist eine teure Datenbanktabelle, kein System.

Alle drei Muster teilen eine Lösung, die günstiger ist, als sie klingt: eine Person als Owner benennen, bevor das Objekt live geht, und ihr die Befugnis geben, Nein zu einem zweiten Objekt zu sagen, wenn eine Eigenschaft noch reicht. Die meisten Wildwuchs-Fälle entstehen nicht aus schlechter Absicht. Sie entstehen, weil niemand klar dafür zuständig war, "noch nicht" zu sagen.

Wie führt man ein neues benutzerdefiniertes Objekt ein, ohne bestehendes Reporting zu brechen?

Die Einführung folgt der Reihenfolge Bauen, Nachfüllen, Automatisieren, und erst zuletzt die alten Eigenschaften abschalten – nie zuerst. Alte Deal- oder Company-Eigenschaften abzuschalten, bevor neue Reports gegen sie geprüft sind, ist der häufigste Grund, warum eine Einführung ein Dashboard zerstört, auf das die Geschäftsführung sich bereits verlässt.

1. Bauen: Das Objekt, seine Eigenschaften und Verknüpfungen in einer Sandbox oder Testumgebung anlegen, falls vorhanden – nicht direkt in der Produktivinstanz.
2. Nachfüllen: Bestehende Abo-Daten aus den Deal-/Company-Eigenschaften übertragen, die ersetzt werden – eine einmalige Migration, an einer Stichprobe geprüft, bevor sie im großen Massstab läuft.
3. Automatisieren: Den Verlängerungs-Workflow und jedes darauf aufbauende Reporting einrichten und mindestens einen vollständigen Reporting-Zyklus lang parallel zu den alten Eigenschaften laufen lassen.
4. Alte Eigenschaften zuletzt abschalten, erst wenn jeder Report und jeder Workflow, der sie bisher gelesen hat, gegen das neue Objekt neu gebaut und Seite an Seite geprüft wurde.

Direkt zum letzten Schritt zu springen, ist der häufigste Fehler bei dieser Einführung. Ein Team baut das neue Abo-Objekt, hält sich für fertig und archiviert die alten Verlängerungsdatum-Eigenschaften noch in derselben Woche – nur um festzustellen, dass ein Geschäftsführungs-Dashboard weiterhin auf die Eigenschaft zeigt, die sich nicht mehr aktualisiert. Die Parallelphase in Schritt drei ist keine bürokratische Vorsicht. Sie ist der einzige Punkt der Einführung, an dem ein kaputter Report bei der Prüfung auffällt statt live in einem Meeting der Geschäftsführung.

Wo steht ein benutzerdefiniertes Objekt im größeren HubSpot-Setup?

Ein benutzerdefiniertes Objekt ist ein Baustein der gesamten HubSpot-Implementierung eines Unternehmens, kein isoliert zu aktivierendes Feature. Am wichtigsten ist es für Unternehmen, die bereits eine produktgetriebene Bewegung in HubSpot fahren, bei der Nutzungsdaten direkt in Vertriebs- und Verlängerungsentscheidungen einfließen müssen.

Dasselbe Muster zeigt sich bei gruppenweiten Unternehmen, die ein CRM über mehrere Teams oder Länder betreiben, wo ein undokumentiertes Objektmodell schnell zum Governance-Problem wird. Teams, die an die Objekt-gegen-Eigenschaft-Grenze stoßen, führen meist mehrere Produktlinien, eine gruppenweite Struktur oder beides gleichzeitig – selten ein Einzelprodukt-Einzelunternehmen-Setup. Unterhalb dieser Komplexitätsschwelle erledigt eine sauber organisierte Eigenschaftenstruktur mit klarem Lifecycle die Aufgabe weiterhin, und ein benutzerdefiniertes Objekt wäre nur Pflegeaufwand ohne passenden Nutzen. Genau hier zahlt sich auch eine breitere Revenue-Engine-Perspektive aus – das Objektmodell ist ein Hebel darin, nicht das ganze System.

Unter einem Modell mit Fixed Scope und Fixed Price wird die Objekt-gegen-Eigenschaft-Entscheidung einmal, vorab, im Rahmen einer CRM-Architektur-Prüfung getroffen – nicht sechs Monate später nachgebaut, wenn die Deal-Eigenschaften-Grenze bereits erreicht ist und die halbe Vertriebsmannschaft längst eine eigene Excel-Liste neben HubSpot führt.

Buche jetzt Deinen HubSpot Erstgespräch Call – kostenlos, 60 Minuten, kein Pitch, eine klare ehrliche Einschätzung, ob es passt dazu, ob Dein HubSpot-Datenmodell aktuell wirklich ein benutzerdefiniertes Objekt braucht.