HubSpot Properties: Felder sauber aufsetzen (Einsteiger)

Viele Teams starten mit HubSpot und denken: „Wir brauchen nur ein paar Felder, dann läuft das.“ Ein paar Wochen später sieht die Realität oft so aus: Es gibt zehn Varianten für dieselbe Information, überall Freitext, manche Felder sind Pflicht und nerven, andere werden nie ausgefüllt – und am Ende vertraut niemand mehr den Daten.

Das liegt selten daran, dass Leute „keine Lust“ haben. Meist fehlt eine einfache Grundlage: Properties.

Properties sind in HubSpot einfach Datenfelder. Also kleine Kästchen, in die ihr Dinge eintragt wie „Branche“, „Interesse“, „Budget“, „Status“ oder „Letzte Kontaktaufnahme“. Wenn diese Felder gut aufgebaut sind, wird HubSpot leicht. Wenn sie schlecht gebaut sind, wird HubSpot teuer – in Zeit, in Nerven und in schlechten Entscheidungen.

Ich erkläre dir hier, wie ihr Properties so anlegt, dass Anfänger:innen es verstehen und das Team es wirklich nutzt. Und wir bleiben konsequent bei eurem Prinzip: Deals entstehen erst ab SQL. Genau deshalb sind gute Properties so wichtig.

TL;DR: Startet mit wenigen, klaren Feldern. Nutzt Dropdowns statt Freitext für alles, was ihr auswerten wollt. Macht Pflichtfelder sparsam. Qualifiziert vor SQL über Properties – Deals erst ab SQL.

Warum Properties überhaupt so wichtig sind

Properties sind nicht „nice to have“. Sie sind die Grundlage für fast alles, was ihr später wollt:

Ihr wollt Leads sauber sortieren? → Properties.
Ihr wollt wissen, welche Anfragen gut sind? → Properties.
Ihr wollt automatische Erinnerungen oder Aufgaben? → Properties.
Ihr wollt Reports, die stimmen? → Properties.

Ohne gute Properties macht ihr vieles „aus dem Bauch“. Das funktioniert, bis es plötzlich nicht mehr funktioniert.

Properties sind Felder in HubSpot, in denen ihr Informationen über Kontakte, Unternehmen oder Deals speichert – zum Beispiel Branche, Status oder Zeitrahmen. Ohne klare Properties könnt ihr kaum sauber filtern, automatisieren oder reporten. Gute Felder machen HubSpot leicht nutzbar.

Das wichtigste Prinzip: Weniger Felder, aber die richtigen

Der größte Fehler ist nicht „zu wenig“. Der größte Fehler ist zu viel – und unklar.

Ein guter Start ist:

wenige, klare Felder
einheitliche Begriffe
möglichst wenig Freitext

Denn Freitext sieht flexibel aus, ist aber für Auswertungen fast wertlos. Ein Team schreibt „Maschinenbau“, das nächste „Industrial“, das dritte „Industrie“. Und schon könnt ihr es nicht mehr sauber filtern.

Freitext vs. Auswahlfeld: eine einfache Regel

Wenn ihr etwas später zählen, filtern oder reporten wollt, dann nutzt ihr ein Auswahlfeld (Dropdown). Kein Freitext.

Beispiele, die fast immer als Dropdown besser sind:

Branche
Interesse/Use Case
Region
Lead-Qualität (hoch/mittel/niedrig)
Zeitrahmen (z. B. „< 3 Monate“, „3–6 Monate“, „6+ Monate“)

Freitext ist sinnvoll für:

kurze Notizen aus Gesprächen
Kontext, den man nicht standardisieren kann

Alles, was ihr später zählen oder auswerten wollt, sollte ein Dropdown sein. Freitext ist nur dann sinnvoll, wenn ihr Inhalte nicht standardisieren könnt – etwa Gesprächsnotizen. Dropdowns sorgen dafür, dass alle im Team dieselben Begriffe verwenden.

Naming: so benennt ihr Felder, damit niemand den Überblick verliert

Das klingt banal, spart euch aber später extrem viel Zeit.

Einfacher Standard, der für Marketing und Sales funktioniert:

Feldnamen sind klar und deutsch (oder klar und englisch – aber nicht gemischt)
ihr nutzt immer dieselben Begriffe (z. B. „Unternehmen“ statt mal „Firma“ mal „Company“)
der Name sagt, was genau gemeint ist

Beispiele:

Gut: „Zeitrahmen (Kaufentscheidung)“
Schwierig: „Timing“
Gut: „ICP-Fit“
Schwierig: „Score“

Wenn ihr es noch klarer wollt, könnt ihr Präfixe nutzen, aber nur wenn das Team sie akzeptiert:

„MKT – …“ für Marketing-relevante Felder
„SAL – …“ für Sales-relevante Felder

Wichtig: Nicht kompliziert werden. Euer Ziel ist Nutzung, nicht Perfektion.

Pflichtfelder: hilfreich oder Conversion-Killer?

Pflichtfelder sind verführerisch, weil sie „Datenqualität“ erzwingen sollen. In der Praxis blockieren sie oft genau das, was ihr wollt: schnelle Übergaben und saubere Prozesse.

Eine einfache Faustregel:

Extern (Formulare): so wenig Pflichtfelder wie möglich
Sonst sinkt die Anfragequote.
Intern (Sales-Prozess): Pflichtfelder erst dann, wenn sie wirklich gebraucht werden
Zum Beispiel beim Schritt „SQL bestätigt“ oder „Deal wird erstellt“.

So bleibt es für Anfänger:innen leicht – und trotzdem habt ihr die Daten dort, wo sie zählen.

Unser Prinzip „Deal erst ab SQL“: welche Felder ihr vorher braucht

Wenn ihr Deals erst ab SQL anlegt (sehr gut), dann braucht ihr vor SQL ein paar Felder, mit denen Sales sauber qualifizieren kann. Sonst landet alles wieder im Freitext – und niemand kann später auswerten, warum gute oder schlechte Leads entstehen.

Ein pragmatisches Set für High-Intent B2B (SaaS/Industrie):

Auf Kontakt- oder Unternehmensebene (vor SQL):

ICP-Fit: hoch / mittel / niedrig
Bedarf (Need): klar / unklar
Zeitrahmen (Timing): < 3 Monate / 3–6 Monate / 6+ Monate
Rolle/Einfluss: Entscheider:in / Treiber:in / Nutzer:in / unklar
Lead Status: neu / versucht / erreicht / qualifiziert / unqualifiziert
Quelle (Source): z. B. Organic / Paid / Referral / Event / Outbound
Optional: Use Case (Dropdown)

Damit kann Sales in wenigen Minuten sauber arbeiten, ohne Deals zu früh anzulegen.

Ab SQL (wenn der Deal entsteht):
Jetzt kommen Deal-Felder dazu, die wirklich Opportunity-relevant sind, zum Beispiel:

Deal-Typ (Neu / Upsell)
erwarteter Umfang (Range statt exakte Zahl, wenn ihr es schlank wollt)
nächster Schritt (kurz, standardisiert oder als Aktivität)

Der Punkt ist: Deal-Felder braucht ihr erst, wenn es wirklich eine Chance gibt.

Wenn ihr Deals erst ab SQL anlegt, braucht ihr vor SQL klare Qualifizierungsfelder auf Kontakt- oder Unternehmensebene. Zum Beispiel Fit, Bedarf, Timing und Lead Status. So kann Sales sauber entscheiden, ob wirklich eine Verkaufschance entsteht – ohne die Pipeline zu füllen.

Governance: wer darf Felder anlegen – und wer räumt auf?

Das ist der Teil, den viele unterschätzen. Wenn jede:r jederzeit Felder anlegen kann, habt ihr nach ein paar Monaten ein CRM, das nur noch „historisch gewachsen“ ist.

Ein einfaches Modell reicht:

Es gibt eine Person oder ein kleines Duo als Owner (z. B. RevOps/Marketing Ops + Sales Ops).
Neue Felder werden kurz „beantragt“ (kann ein Slack-Thread sein).
Einmal im Quartal gibt es 30 Minuten „Aufräumen“: doppelte Felder entfernen, Werte vereinheitlichen, Unnötiges löschen.

Das ist nicht Bürokratie. Das ist Wartung. Genau wie bei einer Website.

Mini-Vorlage: so briefst du ein neues Property in 2 Minuten

Wenn ihr ein neues Feld braucht, beantwortet kurz diese Fragen. Das verhindert 80 % der Fehlfelder:

Wofür brauchen wir das Feld? (Entscheidung/Prozess/Reporting)
Wer pflegt es? (Marketing, Sales, automatisch)
Woher kommt der Wert? (Formular, Gespräch, Import, Integration)
Welcher Typ ist richtig? (Dropdown, Zahl, Text)
Wie nutzen wir es später? (Filter, Segment, Report, Automation)

Wenn ihr das nicht beantworten könnt, braucht ihr das Feld meistens nicht.

Checkliste: Properties, die ein Team wirklich nutzt

Wir haben wenige, klare Felder (kein Wildwuchs).
Wichtige Dinge sind Dropdowns, nicht Freitext.
Feldnamen sind einheitlich (eine Sprache, gleiche Begriffe).
Pflichtfelder blockieren keine Anfragen.
Vor SQL gibt es Qualifizierungsfelder (Fit/Need/Timing), damit Deals nicht zu früh entstehen.
Es gibt Owner und einen festen Rhythmus zum Aufräumen.

FAQ

Wenn du willst, machen wir euer Property-Setup gemeinsam sauber

Wenn du willst, erstellen wir mit dir ein Property-Set inklusive Naming-Logik und leichter Governance. So bleibt HubSpot ein System, das euer Team gern nutzt – und nicht eine Pflichtübung.

HubSpot-Projekte mit JUNGMUT

Weitere Artikel zum Thema:

Jungmut Admin

See Full Bio

HubSpot Properties: so bleibt euer CRM aufgeräumt (und wirklich nutzbar)