Custom Properties (CRM)

Definition: Custom Properties (auch: Custom Fields, benutzerdefinierte Felder) sind vom Unternehmen individuell angelegte Datenfelder in einem CRM-System, die über die vordefinierten Standardfelder hinausgehen und spezifische, geschäftsrelevante Datenpunkte erfassen. Sie ermöglichen die passgenaue Anpassung des CRM an individuelle Branchen, Geschäftsmodelle und Prozesse. In HubSpot, einer der meistgenutzten CRM-Plattformen für KMU und Wachstumsunternehmen (gegründet 2006 von Brian Halligan und Dharmesh Shah am Massachusetts Institute of Technology, MIT), werden benutzerdefinierte Felder explizit als „Custom Properties" bezeichnet. Sie können auf vier Ebenen angelegt werden: Kontakt-, Unternehmens-, Deal- und Custom-Object-Ebene. Salesforce (gegründet 1999, San Francisco) spricht von „Custom Fields" und erlaubt deren Anlage auf nahezu jedem Objekt der Datenstruktur. Laut einer Analyse von HubSpot aus dem Jahr 2022 haben mittlere Unternehmen (100–500 Mitarbeitende) im Durchschnitt 47 aktiv genutzte Custom Properties im Einsatz, während Enterprise-Kunden häufig auf über 200 kommen – mit entsprechend höherem Governance-Aufwand. Die Abgrenzung zu CRM-Tags ist relevant: Custom Properties speichern strukturierte, typisierte Einzelwerte (z. B. ein Datum, eine Zahl oder einen Dropdown-Wert), während Tags unstrukturierte, mehrfach vergebbare Etiketten sind.

Erläuterung

Die Notwendigkeit benutzerdefinierter Felder in Datenbankapplikationen ist seit den frühen Tagen relationaler Datenbanken bekannt. Edgar F. Codd, IBM-Forscher und Vater des relationalen Datenbankmodells, veröffentlichte 1970 in den Communications of the ACM seinen grundlegenden Artikel „A Relational Model of Data for Large Shared Data Banks", der die theoretische Basis für strukturierte Datenhaltung legte – und damit indirekt für das Konzept typisierter, erweiterbarer Felder. Im CRM-Kontext der 1990er-Jahre waren Custom Fields zunächst Entwicklern vorbehalten und erforderten direkte Eingriffe in die Datenbankstruktur. Erst mit dem Aufkommen cloudbasierter CRM-Lösungen in den 2000er-Jahren, allen voran Salesforce (Börsengang 2004, Bewertung seinerzeit ca. 1 Milliarde USD), wurden benutzerdefinierte Felder für Endanwender ohne Programmierkenntnisse zugänglich. Dieser Wandel demokratisierte die CRM-Anpassung und ist heute Standard in allen marktführenden Systemen: HubSpot, Salesforce, Microsoft Dynamics 365, Pipedrive, Zoho CRM und ActiveCampaign bieten jeweils umfangreiche Custom-Field-Frameworks an. Custom Properties existieren in verschiedenen Feldtypen, die jeweils unterschiedliche Anwendungszwecke haben: Texteingaben für Freitextinformationen, Dropdowns für standardisierte Kategorien, Checkboxes für Mehrfachauswahlen, Datumsfelder für zeitbezogene Daten, Zahlenfelder für numerische Werte sowie berechnete Felder (Calculated Properties in HubSpot), die automatisch aus anderen Feldwerten abgeleitet werden. Ein strategisch wichtiger Aspekt ist die Verbindung von Custom Properties mit der Systemperformance: Jedes zusätzliche Feld erhöht die Komplexität von Datenbankabfragen, Filterbedingungen und API-Antwortzeiten. Salesforce empfiehlt in seiner offiziellen Architekturdokumentation, nicht mehr Custom Fields anzulegen als aktiv in Prozessen genutzt werden, und schlägt regelmäßige Field-Audits vor. HubSpot limitiert Custom Properties je nach Plan auf unterschiedliche Höchstzahlen (z. B. 1.000 pro Objekt im Enterprise-Tier). Die Governance von Custom Properties umfasst daher nicht nur die Anlage, sondern auch die Dokumentation, Befüllungsverantwortlichkeit und regelmäßige Bereinigung ungenutzter Felder.

Feldtypen und ihre Verwendung

Single-line Text / Multi-line Text: Für Freitext wie Notizen, individuelle Beschreibungen oder importierte Daten ohne Standardisierungsanforderung. Nicht für Segmentierung geeignet, da Volltextvergleiche unzuverlässig sind.
Dropdown / Radio Select: Für standardisierte Kategorien wie Branche, Kundensegment oder Vertragstyp. Ermöglichen präzise Filterung und Segmentierung, erfordern aber kontinuierliche Pflege der Auswahloptionen.
Checkbox (Multiple Select): Für Mehrfachzuweisungen wie Interessen, verwendete Produkte oder besuchte Events. Kombinierbar mit UND-/ODER-Logik in Segmentierungsregeln.
Date / Date and Time: Für vertragliche Laufzeiten, geplante Folgetermine oder Ablaufdaten. Unverzichtbar für zeitbasierte Trigger-Automatisierungen (z. B. „60 Tage vor Vertragsende").
Number / Currency: Für Umsatzdaten, Deal-Volumina oder Scoring-Werte. Ermöglichen numerische Filterungen und Berechnungen in Dashboards.
Calculated Properties: Automatisch berechnete Felder (z. B. „Tage seit letztem Kauf", „Verbleibende Vertragslaufzeit"), die ohne manuelle Pflege stets aktuell sind.

Custom-Property-Governance: Empfehlungen

Property-Inventar anlegen: Ein zentrales Dokument (z. B. in Confluence oder Notion) listet alle Custom Properties mit Beschreibung, Feldtyp, Befüllungsquelle (manuell/API/Workflow) und verantwortlichem Team.
Naming Conventions: Einheitliche Benennungsmuster wie „[Bereich]_[Feldname]" (z. B. „vertrieb_erstkontaktdatum") vermeiden Namenskollisionen und erleichtern die Navigation in großen Property-Listen.
Nutzungsprüfung: Quartalsweiser Audit, welche Custom Properties in keinem Workflow, keiner Segmentierung und keinem Bericht verwendet werden, und Archivierung ungenutzter Felder.

Praxistipp: Bevor Sie eine neue Custom Property anlegen, beantworten Sie drei Fragen: Welchen konkreten Geschäftsprozess oder welche Entscheidung ermöglicht dieses Feld? Wie wird das Feld befüllt (manuell, über Formular, via API) und wer ist verantwortlich? Ist ein bestehendes Standardfeld oder eine Tag-Lösung für diesen Zweck ausreichend? Nur wenn alle drei Fragen klar beantwortet sind, rechtfertigt sich die Anlage eines neuen Felds. Führen Sie zudem eine Property-Dokumentation als lebendes Dokument im Team – HubSpot bietet dafür die Möglichkeit, Custom Properties mit einer internen Beschreibung zu versehen, die direkt in der Plattform sichtbar ist.