Was Maklergruppen von ihrem CRM verlangen sollten

In meiner Beratungsarbeit erlebe ich denselben Moment immer wieder: Ein Maklerbüro wächst — eine zweite GmbH fürs Gewerbegeschäft, eine Hausverwaltung, ein Zusammenschluss mit einem anderen Büro. Und plötzlich stellt niemand mehr die Frage „Welche Funktionen hat das CRM?". Sondern: Wer darf was sehen? Wo laufen die Daten? Wer haftet, wenn das System steht? Dieser Artikel ist die Anforderungsliste, die ich Maklergruppen für diesen Moment mitgebe — bewusst anbieterneutral formuliert.

Der Moment, in dem sich die Fragen ändern

Ein Einzelbüro wählt sein CRM nach dem Alltag: Exposé, Kontakte, Termine, Portale. Das ist richtig so. Aber sobald mehrere Gesellschaften, mehrere Marken oder eine eigene IT-Verantwortung ins Spiel kommen, verschiebt sich die Auswahl von der Funktions- auf die Strukturebene. Auf einmal sitzen andere Menschen mit am Tisch: die Geschäftsführung der Schwester-GmbH, der Datenschutzbeauftragte, manchmal eine externe IT. Und die stellen Fragen, die in keinem Feature-Vergleich auftauchen.

Das Problem: Viele Gruppen merken erst nach der Einführung, dass ihr System diese Fragen nicht beantworten kann. Dann laufen zwei oder drei getrennte CRM-Instanzen parallel — mit doppelten Kontakten, getrennten Historien und einem Berichtswesen, das aus Excel-Exporten zusammengeklebt wird. Genau das lässt sich vermeiden, wenn die richtigen Anforderungen von Anfang an auf der Liste stehen.

„Die Frage ist nicht, welches CRM die meisten Funktionen hat. Die Frage ist, welches System Eure Struktur trägt, wenn aus einem Büro eine Gruppe geworden ist."

Die sieben Anforderungen

Die Liste ist aus Auswahlprozessen entstanden, die ich begleitet habe. Sie ist bewusst kurz — sieben Punkte, die eine Gruppe wirklich prüfen sollte, bevor sie unterschreibt.

1. Die Gesellschaftsstruktur muss ins System passen — nicht umgekehrt. Wenn Wohnen, Gewerbe und Hausverwaltung über getrennte GmbHs laufen, braucht jede Einheit ihre eigenen Firmendaten: Impressum, Signatur, Logo. Entscheidend ist dabei die Frage nach der Doppelpflege — muss jede Gesellschaft alles neu hinterlegen, oder werden zentrale Werte vererbt und nur Abweichungen gepflegt? Und genauso wichtig: Die Gesellschaft sollte eine Zuordnung sein, keine Datengrenze. Der gemeinsame Kontaktbestand ist oft der eigentliche Grund, warum eine Gruppe ein gemeinsames System will.

2. Rechte, die der Organisation folgen. Je größer die Gruppe, desto wichtiger wird die Frage, wer was sieht und bearbeitet. Ein brauchbares Berechtigungsmodell arbeitet auf mehreren Ebenen — Nutzer, Rollen, Teams, im Zweifel Rechte je Datensatz. Der Praxistest ist einfach: Lässt sich abbilden, dass das Gewerbe-Team die Eigentümer des Wohn-Teams nicht sieht, beide aber denselben Notar kennen? Wenn die Antwort ein Workaround ist, wird es später teuer.

3. Die Marke muss durchgängig sein — bis in den Posteingang. Gruppen führen ihre Marken bewusst. Dann darf das CRM kein Fremdkörper sein: Login unter der eigenen Domain, Systemmails vom eigenen Absender, Buttons und Vorlagen im eigenen CI. Und wer mehrere Marken über getrennte Portal-Verträge vermarktet, braucht mehrere Portal-Konten in einem System — sonst zwingt das CRM zur Trennung, die man organisatorisch gerade vermeiden wollte.

4. Betrieb verbindlich geregelt — nicht versprochen. Ein Einzelbüro lebt mit „das System ist eigentlich immer erreichbar". Eine Gruppe mit dreißig Nutzern kann das nicht: Steht das CRM, steht das Geschäft. Deshalb gehört ein Service Level Agreement auf die Liste — Verfügbarkeit, Support-Erreichbarkeit, Reaktionszeiten nach Schweregrad, Fehlerbehebungszeiten. Nicht, weil Papier Ausfälle verhindert, sondern weil ein Anbieter, der sich vertraglich bindet, seine eigene Betriebsqualität kennen muss.

5. Infrastruktur-Optionen für die IT-Richtlinie. Die meisten Gruppen fahren gut auf einer gemeinsam betriebenen Plattform. Aber manche haben IT-Richtlinien — aus dem Konzernumfeld, aus Versicherungsanforderungen, aus eigener Überzeugung — die eine dedizierte Umgebung verlangen. Dann zählt die Rollenteilung: Wer stellt die Umgebung, wer betreibt die Anwendung, wo liegen die Administratorrechte? Ein Anbieter, der darauf eine klare Antwort hat, hat diese Frage schon einmal ernsthaft durchdacht.

6. Datenschutz als Architektur, nicht als Feature. Bei einer Gruppe prüft im Zweifel ein Datenschutzbeauftragter mit: Wo wird gehostet? Wer sind die Sub-Verarbeiter, und sind sie öffentlich dokumentiert? Was passiert mit KI-Verarbeitung — wird mit Kundendaten trainiert? Diese Antworten müssen vor der Einführung vorliegen, schriftlich und nachlesbar. Ein Anbieter, der hier ausweicht, wird auch beim AVV-Entwurf ausweichen.

7. Exit-Fähigkeit — der unterschätzte Punkt. Die beste Bindung ist die, die der Anbieter nicht erzwingen muss. Eine offene API, ein vollständiger Datenexport und faire Vertragslaufzeiten gehören auf die Liste, gerade wenn man nicht vorhat, sie zu nutzen. Mein Ehrlichkeitstest im Auswahlprozess: Wie komme ich mit allen Daten wieder raus? Die Reaktion auf diese Frage sagt mehr über einen Anbieter als jede Produktdemo.

Was nicht auf die Liste gehört

Genauso wichtig wie die sieben Punkte ist, was ich bewusst weglasse. Feature-Breite als Kriterium: Die Gruppe, die an ihrer CRM-Einführung scheitert, scheitert fast nie an einer fehlenden Funktion — sondern daran, dass die Struktur nicht passt oder die Mitarbeiter das System nicht annehmen. „Enterprise" als Label: Der Begriff sagt nichts. Manche Anbieter meinen damit eine Preisstufe, manche ein Rechtemodell, manche nur ein Vertriebsgespräch. Entscheidend ist, welche der sieben Anforderungen konkret erfüllt sind — nicht, wie das Paket heißt. Lange Laufzeiten als „Sicherheit": Eine Mindestlaufzeit von drei Jahren schützt nicht die Gruppe, sie schützt den Anbieter. Verbindlichkeit entsteht durch SLA und Exit-Fähigkeit, nicht durch Vertragsbindung.

Wie man Anbieter konkret prüft

Aus der Liste werden im Auswahlprozess Fragen. Meine Empfehlung: Stellt sie schriftlich, vor der Demo — und lasst Euch die Antworten geben, bevor der Anbieter die Präsentation steuert. Zum Beispiel: Wie bilden wir drei GmbHs mit gemeinsamem Kontaktbestand ab, und was müssen wir doppelt pflegen? Können zwei Marken über getrennte ImmoScout24-Verträge aus einem System veröffentlichen? Welche SLA-Werte bietet Ihr an, und wie sind sie gestaffelt? Wo ist die Liste Eurer Sub-Verarbeiter öffentlich einsehbar? Wie sieht ein vollständiger Datenexport aus?

Ein Anbieter, der diese Fragen präzise beantwortet, hat die Anforderungen von Gruppen schon einmal real gelöst. Ein Anbieter, der auf die Demo verweist, hat sie bisher nur präsentiert.

Wo propgen dabei steht

Transparenz gehört dazu: Ich berate nicht nur, ich baue mit propgen selbst ein CRM — und diese Liste ist zugleich die Messlatte, an der wir uns messen lassen. Die Bausteine, die propgen dafür mitbringt, sind einzeln dokumentiert: mehrere Gesellschaften mit Vererbung statt Doppelpflege, Rollen & Rechte auf vier Ebenen, mehrere ImmoScout24-Konten, die eigene Makler-Domain, dedizierte Infrastruktur mit klarer Rollenteilung und ein SLA, dessen Werte individuell vereinbart werden. Den Überblick gibt propgen für Enterprise.

Und der siebte Punkt gilt auch für uns selbst: propgen ist monatlich kündbar und hat eine offene API. Nicht, weil wir wollen, dass jemand geht — sondern weil eine Gruppe, die bleiben soll, nie das Gefühl haben darf, eingesperrt zu sein.

Fazit

Wenn aus einem Maklerbüro eine Gruppe wird, ändert sich die CRM-Frage grundlegend: weg von der Funktionsliste, hin zu Struktur, Betrieb und Verbindlichkeit. Die sieben Anforderungen — Gesellschaftsstruktur, Rechte, Marke, SLA, Infrastruktur, Datenschutz, Exit-Fähigkeit — sind der Kern dessen, was eine Gruppe schriftlich prüfen sollte, bevor sie sich bindet. Wer sie früh stellt, erspart sich das teuerste Szenario der Branche: zwei Systeme, doppelte Daten und ein Berichtswesen aus Excel.