HubSpot Custom Objects für B2B SaaS

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

Ein benutzerdefiniertes Objekt brauchst du, sobald deine Kunden mehrere Abos gleichzeitig halten und HubSpots Standardobjekte das nicht mehr sauber abbilden. Es ist eine eigene Datentabelle neben Kontakten, Companies, Deals und Tickets, gedacht für Daten, die zu deinem Geschäftsmodell gehören. Verfügbar ist es ausschließlich mit HubSpot Enterprise, im englischen HubSpot heißt es Custom Object. Für B2B-SaaS ist der häufigste Kandidat ein Abo- oder Lizenz-Objekt. Es verfolgt Verlängerungsdatum, Tier und Nutzung getrennt vom ursprünglichen Deal.

An diese Grenze stößt du selten wegen der Datenmenge. Meist liegt es daran, dass Deal- und Company-Eigenschaften etwas abbilden sollen, wofür sie nie gebaut wurden. Ein Deal wird gewonnen, und auf der Company landet eine Eigenschaft namens verlaengerungsdatum. Dann kommt eine zweite Produktlinie dazu, und jemand legt verlaengerungsdatum_produkt_b daneben an. Die dritte Linie folgt demselben Muster.

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

Der eigentliche Bruch kommt erst, wenn eine einzelne Company drei laufende Abos gleichzeitig hat, jedes mit eigenem Verlängerungsdatum, eigenem Tier und eigener Sitzplatzanzahl. Eine Company kann pro Eigenschaft genau einen Wert halten. „Drei davon, jedes mit eigenem Zeitplan“ geht nicht. Ab diesem Punkt ist jeder Workaround ein Symptom desselben Problems, ob durchnummerierte Eigenschaften, ein gemeinsames Notizfeld oder eine Excel-Liste neben HubSpot. Deine Daten haben eine 1:n-Struktur (ein Kunde, mehrere Abos), dein Objektmodell aber nicht.

Mit mangelnder Disziplin hat das nichts zu tun. Es passiert fast von selbst, sobald sich eine Produktlinie in zwei und dann in drei aufteilt. Dein CRM-Setup stammt dann noch aus einer Zeit, in der pro Kunde nur ein Abo zu verfolgen war. Niemand hat das so entschieden. Es ist gewachsen, eine Eigenschaft nach der anderen. So entstehen die meisten Altlasten im CRM-Datenmodell.

Wie entscheidest du zwischen einem benutzerdefinierten Objekt und einer Eigenschaft?

Mit zwei Fragen. Gibt es von dieser Information mehrere Einträge pro Datensatz, also eine 1:n-Beziehung zu einem bestehenden Datensatz? Und braucht sie eine eigene Pipeline oder einen eigenen Lifecycle, unabhängig vom Deal? Zweimal Ja heißt: ein Objekt. Bei einem oder keinem Ja reicht meist eine Eigenschaft, eine Auswahlliste oder eine Lifecycle Stage. Die ist auch günstiger zu pflegen.

In der Praxis läuft es oft andersherum. Ein neuer Datenpunkt taucht auf und fühlt sich „speziell“ an. Also greift jemand zum mächtigeren Werkzeug, ohne zu prüfen, ob die Beziehung dahinter das überhaupt verlangt. Der Reflex ist verständlich. Genau so entstehen aber HubSpot-Instanzen voller benutzerdefinierter Objekte, von denen niemand mehr weiß, warum es sie gibt.

Als Faustregel bleibt nach der Tabelle: Kannst du bei derselben Company auf zwei oder mehr solcher Einträge zeigen, die gleichzeitig bestehen, ist es ein Objekt. Gibt es immer nur einen, ist es eine Eigenschaft.

Ein Beispiel macht das greifbar. Ein SaaS-Unternehmen mit 45 Leuten verkauft drei Produkt-Tiers, jedes einzeln abgerechnet und verlängert. Seine Kunden sind Enterprise-Accounts, die oft mehr als ein Tier gleichzeitig kaufen. Erste Frage, die Kardinalität: Ja, pro Company laufen mehrere Abos parallel. Zweite Frage, der Lifecycle: Ja, jedes Tier verlängert sich im eigenen Rhythmus, egal wann der ursprüngliche Deal geschlossen wurde. Zweimal Ja heißt Objekt, und keine noch so klug benannte Eigenschaft ändert daran etwas. Hätte dasselbe Unternehmen nur ein Tier mit einfacher Jahresverlängerung, lautete die Antwort beide Male Nein. Dann sollte es gar kein Objekt bauen.

Was verlangt HubSpot für ein benutzerdefiniertes Objekt?

Vor allem die richtige Edition. Benutzerdefinierte Objekte verlangen ein Enterprise-Abonnement, und zwar über jeden HubSpot Hub hinweg und nicht nur im Sales Hub. Gemeint sind Marketing und Sales, Service und Content, Data und Smart CRM. So steht es in HubSpots eigener Dokumentation. Wer Objekte anlegen und verwalten darf, regeln die Kontoberechtigungen. Wie viele Objekte du anlegen kannst und wie viele Eigenschaften pro Objekt, hängt vom Abo ab und ist nicht fix veröffentlicht.

Klär diese Anforderung, bevor du das Projekt planst, nicht danach. Die Enterprise-Pflicht ist eine echte Kostenschwelle und gilt Hub-übergreifend. Ein Team mit Sales Hub Enterprise, aber Marketing Hub Professional kann trotzdem kein Objekt anlegen.

Bei mindestens einer Grenze ist HubSpots Dokumentation konkret. Diese Grenze zählt, sobald dein Abo-Objekt gleichzeitig mit Companies, Deals und einer Verlängerungs-Pipeline verknüpft sein soll: Verknüpfungs-Limits zwischen Datensätzen lassen sich auf bis zu 10'000 pro Verknüpfungstyp konfigurieren. Das geht ab der Professional-Edition, und zwar in Marketing Hub und Sales Hub, Service Hub und Data Hub, Content Hub und Revenue Hub. Beim ersten Aufbau spielt diese Obergrenze 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 später. Dann sollen ein Support-Ticket, ein Nutzungsereignis und eine Verlängerungschance alle auf denselben Abo-Datensatz zeigen, ohne dass HubSpot die Anzahl stillschweigend deckelt. Prüf diese Zahl deshalb früh. Nicht erst, wenn dein Datenmodell schon auf einer Annahme steht statt auf einer dokumentierten Grenze.

Wie viele Objekte und Eigenschaften erlaubt sind, steht dagegen nicht als feste Zahl in der Objekt-Dokumentation. Die Grenze hängt vom Abo ab und ist im Produkt- und Leistungskatalog von HubSpot gelistet. Jede Zahl, die anderswo kursiert, ist ungeprüft, bis du sie gegen dein eigenes Portal und dessen Edition abgeglichen hast.

Auch die Berechtigungen entscheidest du vor dem Baubeginn, nicht danach. HubSpot koppelt das Anlegen und Verwalten benutzerdefinierter Objekte an kontoweite Berechtigungen. Die sind getrennt von den Standard-Objektrechten, die dein Vertrieb ohnehin hat. In der Praxis heißt das: Eine benannte Person entscheidet, wer überhaupt ein neues Objekt anlegen darf. Meist ist das, wer RevOps oder die CRM-Administration verantwortet. Diese Regel muss stehen, bevor irgendwer ein zweites oder drittes Objekt anlegt, nur weil er gerade an eine Grenze gestoßen ist.

An dieser Stelle entscheidet sich auch, ob du das Objekt intern baust oder einen HubSpot-Implementierungspartner dazuholst. Intern klappt das gut, solange der Fall einfach ist: ein Abo-Typ, ein Verlängerungsmuster. Müssen dagegen mehrere Pipelines, Hub-übergreifende Berechtigungen und Automatisierungen gleichzeitig zusammenpassen, wird es teuer. Dann kostet ein falscher erster Versuch meist mehr, als dir vorher Unterstützung zu holen.

Wie modellierst du ein Abo-Objekt für dein SaaS-Unternehmen Schritt für Schritt?

Ein Abo-Objekt ohne Automatisierung steht im Datenmodell und leistet keine Arbeit. Deshalb gehört mehr dazu als das Anlegen. Du definierst die Eigenschaften und verknüpfst das Objekt mit den Datensätzen, von denen es abhängt. Dann gibst du ihm eine eigene Pipeline und schließt mindestens eine Automatisierung an, bevor es live geht.

1. Leg Objekt und Kerneigenschaften fest. Vier Eigenschaften tauchen in fast jedem SaaS-Aufbau auf: Tier, monatlich wiederkehrender Umsatz (MRR), Verlängerungsdatum und die Zahl der Sitzplätze oder die Nutzung.
2. Setz die Verknüpfungen. Verbinde den Abo-Datensatz mit seiner Company und dem auslösenden Deal. Getrennt davon verknüpfst du ihn mit der Verlängerungs-Pipeline, die er später durchläuft.
3. Bau eine eigene Verlängerungs-Pipeline, statt die ursprüngliche Sales-Pipeline weiterzunutzen. Verlängerungen haben andere Stages als ein Erstverkauf, etwa bevorstehend, gefährdet, verlängert und gekündigt. Mischst du beides, werden beide Reports unzuverlässiger.
4. Leg vor dem Launch einen Berechtigungs- und Ansichtsplan für den Vertrieb fest. Wer sieht das Objekt? Welche Standardansicht bekommt wer? Und welche Eigenschaften sind editierbar statt nur lesbar?
5. Schließ mindestens eine Automatisierung an. Die kleinste Version ist eine Verlängerungserinnerung, die 60 Tage vor dem Verlängerungsdatum auslöst. Warnungen bei Nutzungsschwellen und ein Churn-Risiko-Scoring können folgen, sobald das Basisobjekt stabil läuft.

Schritt eins und zwei sind meist schnell erledigt. Kennt dein Team seine Abo-Struktur, sind das ein paar Stunden Konfiguration. Bei Schritt drei, der eigenen Verlängerungs-Pipeline, ist die Versuchung groß, abzukürzen und einfach die Sales-Pipeline wiederzuverwenden. Lass das. HubSpots eigene Pipeline-Dokumentation behandelt Pipelines für benutzerdefinierte Objekte als eigenständig konfiguriert, mit eigenen Stages und Automatisierungsregeln. Die Plattform selbst geht also davon aus, dass Verlängerung und Neugeschäft zwei verschiedene Lifecycles sind und keine Pipeline mit zwei Hüten. Neugeschäft und Verlängerungsrisiko brauchen unterschiedliche Stages und Reports, oft auch unterschiedliche Owner. Legst du beides zusammen, kann keine der beiden Pipelines mehr gut, wofür sie da ist.

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. Der Vertrieb nutzt es nie, weil niemand Berechtigungen und Standardansichten geplant hat. Oder das Objekt bekommt nie eine Automatisierung. Jedes Muster sieht anders aus, die Ursache ist dieselbe: Das Objekt wurde als Übung in Datenmodellierung gebaut, nicht als System, das jemandem gehört.

• Objekt-Wildwuchs. Für Randfälle kommt ein zweites, dann ein drittes Objekt dazu, obwohl eine Eigenschaft auf dem ersten gereicht hätte. 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 im Standard-Arbeitsbereich deines Vertriebs taucht es nie auf. Also arbeiten alle aus Gewohnheit weiter mit Deal-Eigenschaften. Gescheitert ist dann nicht das Schema, sondern die Einführung.
• Ein Datenfriedhof. Datensätze entstehen und werden nie wieder angefasst. Es gibt keine Verlängerungserinnerung und keinen Churn-Risiko-Workflow, nichts, das die Daten des Objekts liest und etwas damit tut. Ein ungenutztes benutzerdefiniertes Objekt ist eine teure Datenbanktabelle, kein System.

Gegen alle drei Muster hilft dieselbe Lösung, und sie ist günstiger, als sie klingt. Benenne eine Person als Owner, bevor das Objekt live geht. Gib ihr die Befugnis, Nein zu einem zweiten Objekt zu sagen, solange eine Eigenschaft noch reicht. Wildwuchs entsteht meist nicht aus schlechter Absicht. Er entsteht, weil niemand klar dafür zuständig war, „noch nicht“ zu sagen.

Wie führst du ein neues benutzerdefiniertes Objekt ein, ohne bestehendes Reporting zu beschädigen?

Das größte Risiko ist ein Dashboard der Geschäftsführung, das plötzlich nicht mehr stimmt. Am häufigsten passiert das, wenn alte Deal- oder Company-Eigenschaften abgeschaltet werden, bevor die neuen Reports geprüft sind. Deshalb gilt eine feste Reihenfolge: bauen, nachfüllen, automatisieren. Die alten Eigenschaften schaltest du erst zum Schluss ab, nie zuerst.

1. Bauen: Leg das Objekt mit seinen Eigenschaften und Verknüpfungen in einer Sandbox oder Testumgebung an, falls du eine hast. Nicht direkt in der Produktivinstanz.
2. Nachfüllen: Übertrag die bestehenden Abo-Daten aus den Deal- und Company-Eigenschaften, die das Objekt ersetzt. Das ist eine einmalige Migration. Prüf sie an einer Stichprobe, bevor sie im großen Maßstab läuft.
3. Automatisieren: Richte den Verlängerungs-Workflow und jedes Reporting ein, das darauf aufbaut. Lass beides mindestens einen vollständigen Reporting-Zyklus lang parallel zu den alten Eigenschaften laufen.
4. Alte Eigenschaften zuletzt abschalten: erst dann, wenn jeder Report und jeder Workflow, der sie bisher gelesen hat, auf das neue Objekt umgebaut und im direkten Vergleich geprüft ist.

Der typische Fehler ist, direkt zum letzten Schritt zu springen. Ein Team baut das neue Abo-Objekt, hält sich für fertig und archiviert die alten Eigenschaften zum Verlängerungsdatum noch in derselben Woche. Dann stellt sich heraus, dass ein Dashboard der Geschäftsführung weiter auf die alte Eigenschaft zeigt. Und die aktualisiert sich nicht mehr. Die Parallelphase in Schritt drei ist deshalb keine bürokratische Vorsicht. Nur dort fällt ein kaputter Report bei der Prüfung auf und nicht live im Meeting der Geschäftsführung.

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

Ein benutzerdefiniertes Objekt ist ein Baustein deiner gesamten HubSpot-Implementierung, kein Feature, das du isoliert einschaltest. Am meisten bringt es Unternehmen, die schon eine produktgetriebene Vertriebsbewegung in HubSpot fahren. Dort müssen Nutzungsdaten direkt in Entscheidungen über Vertrieb und Verlängerung einfließen.

Ähnlich ist es bei gruppenweiten Unternehmen, die ein CRM über mehrere Teams oder Länder betreiben. Dort wird ein undokumentiertes Objektmodell schnell zum Governance-Problem. Wer an die Grenze zwischen Objekt und Eigenschaft stößt, führt meist mehrere Produktlinien, eine gruppenweite Struktur oder beides. Selten ist es ein Unternehmen mit einem einzigen Produkt. Unterhalb dieser Komplexität reicht eine sauber organisierte Eigenschaftenstruktur mit klarem Lifecycle weiterhin aus. Ein benutzerdefiniertes Objekt wäre dann nur Pflegeaufwand ohne passenden Nutzen. Hier zahlt sich auch der Blick auf die ganze Revenue Engine aus: Das Objektmodell ist ein Hebel darin, nicht das ganze System.

Wir arbeiten mit Fixed Scope und Fixed Price. Deshalb fällt die Entscheidung zwischen Objekt und Eigenschaft bei uns einmal und vorab, in einer Prüfung der CRM-Architektur. So muss niemand sechs Monate später nachbauen, wenn die Deal-Eigenschaften längst an ihre Grenze gestoßen sind und der halbe Vertrieb eine eigene Excel-Liste neben HubSpot führt.

Kostenloses Erstgespräch – 60 Minuten, kein Pitch. Du bekommst eine ehrliche Einschätzung, ob dein HubSpot-Datenmodell heute schon ein benutzerdefiniertes Objekt braucht.

SalesPlaybook ist HubSpot Diamond Solutions Partner mit 39+ 5-Sterne-Bewertungen im HubSpot Solutions Directory. Im Zweifel modellieren wir zuerst mit Standardobjekten. Bei Cargoo entstand so eine „7-stellige Enterprise Sales Pipeline mit einem Holistischen HubSpot Setup“, mit der gesamten Buyer Journey in 6 Monaten in HubSpot.