Ein CRM soll Informationen dort verfügbar machen, wo sie für die tägliche Arbeit benötigt werden. Gleichzeitig dürfen nicht alle Mitarbeiter automatisch alle Kunden-, Vertrags-, Umsatz- oder Servicedaten sehen und verändern.
Genau hier beginnt die Herausforderung bei CRM-Berechtigungen.
Ein zu offenes Berechtigungsmodell kann Datenschutz-, Vertraulichkeits- und Governance-Probleme erzeugen. Ein zu restriktives Modell führt dagegen schnell dazu, dass Mitarbeiter Informationen nicht finden, Kollegen um Zugriff bitten oder Daten wieder außerhalb des CRM austauschen.
Die beste Rechtearchitektur ist deshalb nicht diejenige mit den meisten Regeln. Sie ist diejenige, die fachliche Verantwortung, Zusammenarbeit und Schutzbedarf möglichst einfach miteinander verbindet.
CRM-Berechtigungen sind kein reines IT-Thema
In vielen CRM-Projekten werden Rollen und Rechte relativ spät betrachtet.
Zunächst werden Prozesse gestaltet, Masken aufgebaut, Daten migriert und Integrationen eingerichtet. Kurz vor dem Go-live entsteht dann die Frage:
Wer darf eigentlich welche Daten sehen und bearbeiten?
Das ist zu spät.
Berechtigungen beeinflussen bereits das Datenmodell und die Prozessgestaltung.
Beispielsweise:
- Darf ein Vertriebsmitarbeiter alle Accounts sehen oder nur seine eigenen?
- Dürfen regionale Teams aufeinander zugreifen?
- Kann Customer Service Opportunities sehen?
- Darf der Vertrieb offene Servicefälle einsehen?
- Sind Umsätze oder Margen für alle sichtbar?
- Darf ein Key Account Manager mehrere Gesellschaften eines Konzerns sehen?
- Wie werden Mitarbeiterwechsel behandelt?
- Welche Daten darf ein externer Partner sehen?
Diese Fragen können nicht allein von der IT beantwortet werden.
Sie benötigen Entscheidungen aus Vertrieb, Service, Management, Datenschutz und gegebenenfalls Informationssicherheit.
Die zentrale Frage: Was muss geschützt werden – und was muss geteilt werden?
Bei Rechtekonzepten wird häufig ausschließlich aus Sicht des Schutzes gedacht.
Die Frage lautet dann:
„Wer darf diese Information sehen?“
Mindestens genauso wichtig ist jedoch:
„Wer muss diese Information sehen, damit der Kundenprozess funktioniert?“
Ein Beispiel:
Der Vertrieb möchte möglicherweise nicht, dass jeder Mitarbeiter sämtliche Opportunity-Werte eines Accounts einsehen kann.
Customer Service muss aber wissen, dass bei einem wichtigen Kunden gerade eine kritische Vertragsverlängerung läuft.
Customer Success benötigt wiederum Informationen über offene Serviceprobleme, bevor ein Renewal-Gespräch stattfindet.
Wenn Rechte zu strikt getrennt werden, entstehen neue Informationssilos innerhalb desselben CRM.
Ein gutes Berechtigungsmodell muss deshalb Schutzbedarf und Prozessbedarf gleichzeitig berücksichtigen.
Least Privilege – aber pragmatisch
So wenig Zugriff wie nötig einschränken – aber so viel Zusammenarbeit wie sinnvoll ermöglichen.Das bedeutet beispielsweise:
- sensible Finanzdaten stärker schützen,
- Kundenstammdaten breiter sichtbar machen,
- Bearbeitungsrechte enger vergeben als Leserechte,
- administrative Rechte konsequent begrenzen,
- personenbezogene oder vertrauliche Felder separat schützen.
Sichtbarkeit und Bearbeitung getrennt betrachten
Ein häufiger Fehler besteht darin, Zugriff als Ja-/Nein-Entscheidung zu behandeln.
In der Praxis gibt es mehrere Ebenen.
Ein Mitarbeiter kann beispielsweise:
- einen Datensatz sehen,
- ihn aber nicht bearbeiten,
- Aktivitäten ergänzen,
- bestimmte Felder ändern,
- andere Felder nur lesen,
- Datensätze löschen,
- exportieren,
- importieren,
- anderen Benutzern zuweisen,
- Massenänderungen durchführen.
Diese Rechte besitzen sehr unterschiedliche Risiken.
Ein Vertriebsmitarbeiter darf vielleicht Accounts anderer Kollegen sehen, sollte sie aber nicht neu zuweisen können.
Ein Service-Mitarbeiter darf Opportunity-Informationen lesen, aber keine Forecast-Werte verändern.
Ein Teamleiter kann Datensätze seines Teams bearbeiten, während ein Administrator systemweite Rechte besitzt.
Deshalb sollte ein Berechtigungskonzept nicht nur die Frage „Wer sieht was?“ beantworten.
Es muss auch definieren:
„Wer darf was damit tun?“
Die fünf Ebenen eines CRM-Berechtigungsmodells
in solides Rechtekonzept lässt sich häufig über fünf Ebenen strukturieren.
| Ebene | Frage | Beispiel |
|---|---|---|
| Benutzer | Wer greift auf das CRM zu? | Account Manager, Service Agent, Administrator |
| Rolle | Welche Funktionen darf diese Person verwenden? | Opportunities bearbeiten, Accounts lesen |
| Organisation / Team | Für welchen Datenbereich gilt der Zugriff? | DACH Sales, Service Europe |
| Datensatz | Welche konkreten Records sind sichtbar? | Eigene Accounts, Team-Accounts, globale Accounts |
| Feld | Welche Informationen innerhalb eines Datensatzes sind geschützt? | Marge, Gehalt, Vertragskonditionen |
Diese Trennung hilft, unnötig komplizierte Sonderregeln zu vermeiden.
Rollen und Teams erfüllen unterschiedliche Aufgaben
Gerade in flexiblen CRM-Plattformen sollte zwischen funktionalen Rechten und Datenzugriff unterschieden werden.
Eine Rolle beantwortet typischerweise:
Was darf der Benutzer tun?
Zum Beispiel:
- Accounts lesen
- Opportunities bearbeiten
- Reports erstellen
- Datensätze löschen
- Felder ändern
- Exporte durchführen
Ein Team beziehungsweise organisatorischer Datenbereich beantwortet dagegen:
Auf welche Datensätze darf er zugreifen?
Beispielsweise:
- DACH
- EMEA
- Key Accounts
- Customer Service
- Management
Diese Trennung ist besonders hilfreich, weil Mitarbeiter derselben Rolle unterschiedliche Datenbereiche benötigen können.
Zwei Account Manager dürfen beispielsweise technisch dasselbe tun, aber jeweils unterschiedliche Regionen betreuen.
Warum zu viele Rollen langfristig teuer werden
Beim Aufbau eines CRM entstehen schnell sehr spezifische Rollen:
- Sales Germany
- Sales Germany Senior
- Sales Austria
- Sales Switzerland
- Sales Manager Germany
- Sales Manager Austria
- Sales Manager Switzerland
- Key Account Germany
- Key Account International
Das funktioniert zunächst.
Später entstehen jedoch immer mehr Kombinationen.
Dann wird unklar:
- Warum besitzt Benutzer A Zugriff, Benutzer B aber nicht?
- Welche Rolle muss bei einem Mitarbeiterwechsel angepasst werden?
- Welche Unterschiede bestehen zwischen zwei fast identischen Rollen?
- Welche Berechtigungen werden überhaupt noch genutzt?
Das Rechtekonzept entwickelt sich zu einer eigenen technischen Landschaft.
Besser ist meist ein modulares Modell:
Rolle = Funktion
Team / Datenbereich = organisatorischer Zugriff
So können Kombinationen wiederverwendet werden.
Zehn Bausteine für ein gutes CRM-Berechtigungskonzept
| Nr. | Baustein | Kernfrage | Nutzen |
|---|---|---|---|
| 1 | Benutzergruppen | Welche typischen Benutzerprofile existieren? | Grundlage für standardisierte Rollen |
| 2 | Funktionsrollen | Welche Aktionen darf eine Benutzergruppe ausführen? | Verhindert unnötige Administratorrechte |
| 3 | Datenbereiche | Welche Datensätze müssen sichtbar sein? | Unterstützt Regionen und Teams |
| 4 | Eigentümerprinzip | Welche Bedeutung besitzt der Record Owner? | Klärt Verantwortung |
| 5 | Leserecht vs. Schreibrecht | Muss der Benutzer Informationen nur sehen oder verändern? | Reduziert Risiko ohne Informationssilos |
| 6 | Feldschutz | Welche Felder sind besonders sensibel? | Schutz vertraulicher Informationen |
| 7 | Sonderzugriffe | Welche legitimen Ausnahmen gibt es? | Verhindert unkontrollierte Workarounds |
| 8 | Externe Benutzer | Welche Daten dürfen Partner oder Portale sehen? | Schutz interner Informationen |
| 9 | Review-Prozess | Wie werden Berechtigungen regelmäßig überprüft? | Verhindert historisch gewachsene Rechte |
| 10 | Dokumentation | Warum existiert eine Rolle oder Regel? | Vereinfacht Betrieb und Audit |
Der Record Owner ist nicht automatisch die Rechtearchitektur
Viele CRM-Systeme besitzen einen Verantwortlichen beziehungsweise Owner für einen Datensatz.
Das ist sinnvoll.
Problematisch wird es, wenn daraus automatisch die Regel entsteht:
„Nur der Owner darf den Datensatz sehen.“
Das passt selten zu modernen Kundenprozessen.
Ein Account kann einen Vertriebsverantwortlichen besitzen, während Service, Customer Success, Marketing oder Management ebenfalls Informationen benötigen.
Der Owner sollte deshalb primär fachliche Verantwortung ausdrücken.
Die Sichtbarkeit kann zusätzlich über Teams, Rollen und weitere Regeln gesteuert werden.
Kundenverantwortung ist häufig komplexer als ein Benutzer
Besonders bei Key Accounts oder internationalen Konzernen reicht ein einzelner Owner häufig nicht aus.
Ein Kunde kann beispielsweise besitzen:
- Global Account Manager
- regionalen Account Manager
- Customer Success Manager
- Service Manager
- technischen Ansprechpartner intern
- Executive Sponsor
Werden all diese Rollen ausschließlich über Benutzerfelder abgebildet, entstehen schnell Sonderkonstruktionen.
In komplexeren Szenarien lohnt es sich deshalb zu überlegen, ob Kundenteams oder relationale Verantwortlichkeiten besser geeignet sind.
Das Datenmodell und das Berechtigungsmodell hängen hier unmittelbar zusammen.
Feldbasierte Rechte nur dort einsetzen, wo sie wirklich notwendig sind
Field-Level Security kann sehr hilfreich sein.
Beispiele für besonders sensible Informationen:
- Marge
- Rabatte
- interne Bewertung eines Kunden
- Vertragskonditionen
- personenbezogene Informationen
- Eskalationsnotizen
- Kreditinformationen
- interne Risikobewertungen
Aber feldbasierte Sicherheit sollte nicht inflationär eingesetzt werden.
Wenn innerhalb eines Datensatzes 80 Felder jeweils eigene Berechtigungsregeln besitzen, wird das System schwer verständlich und kaum noch testbar.
Eine gute Frage lautet deshalb:
Ist diese Information tatsächlich so sensibel, dass sie innerhalb desselben Datensatzes separat geschützt werden muss?
Falls sehr viele Felder geschützt werden müssen, kann dies sogar darauf hinweisen, dass ein eigenes Geschäftsobjekt sinnvoller wäre.
Beispiel: Marge und Umsatz
Ein gutes Beispiel für den gezielten Einsatz von Feldrechten ist eine Opportunity mit mehreren kaufmännischen Informationen. Dazu gehören etwa Deal Value, Listenpreis, Rabatt, Einkaufskosten und Marge.
Nicht jede dieser Informationen ist für jede Benutzergruppe gleichermaßen relevant. Der Vertrieb benötigt beispielsweise den Deal Value und den gewährten Rabatt, um die Opportunity sinnvoll steuern zu können. Das Management braucht darüber hinaus möglicherweise Einblick in Einkaufskosten und Marge, um die Wirtschaftlichkeit des Geschäfts zu beurteilen. Ein externer Vertriebspartner sollte dagegen unter Umständen nur den erwarteten Verkaufswert sehen und keinen Zugriff auf interne Kalkulationsdaten erhalten.
In solchen Fällen ist es meist nicht sinnvoll, unterschiedliche Opportunity-Typen oder parallele Datensätze für verschiedene Benutzergruppen aufzubauen. Besser ist es, die Opportunity grundsätzlich für alle relevanten Beteiligten sichtbar zu lassen und nur besonders sensible Informationen gezielt einzuschränken.
Typische Felder könnten dabei unterschiedlich behandelt werden:
- Deal Value: für Vertrieb und Management sichtbar
- Listenpreis und Rabatt: für den internen Vertrieb sichtbar
- Einkaufskosten: nur für ausgewählte interne Rollen
- Marge: beispielsweise nur für Management oder autorisierte Vertriebsverantwortliche
So bleibt der gemeinsame Kunden- und Opportunity-Kontext erhalten, ohne vertrauliche kaufmännische Informationen unnötig breit zugänglich zu machen. Genau dafür sind gezielte Feldrechte sinnvoll.
Rechte sollten Kundenprozesse nicht zerstören
Ein Berechtigungskonzept kann technisch sauber aufgebaut sein und trotzdem den Kundenprozess verschlechtern. Das passiert vor allem dann, wenn Bereiche zu stark voneinander getrennt werden.
Ein typisches Beispiel: Der Vertrieb kann Servicefälle nicht sehen, der Service hat keinen Einblick in laufende Opportunities und Customer Success sieht ausschließlich Vertragsinformationen. Auf den ersten Blick ist das nachvollziehbar getrennt. Im Alltag entstehen dadurch jedoch drei Informationssilos innerhalb desselben CRM.
Die Folgen zeigen sich häufig erst im konkreten Kundenkontakt. Ein Service-Mitarbeiter erkennt möglicherweise nicht, dass bei einem Kunden gerade eine wichtige Opportunity gefährdet ist. Der Vertrieb sieht nicht, dass mehrere kritische Servicefälle offen sind. Customer Success startet ein Renewal-Gespräch, ohne aktuelle Eskalationen zu kennen.
Das Rechtekonzept erfüllt in diesem Fall zwar seine technische Aufgabe, verhindert aber genau die Zusammenarbeit, die ein CRM eigentlich verbessern soll.
Deshalb sollte bei jeder Einschränkung nicht nur gefragt werden, ob sie aus Sicherheits- oder Datenschutzsicht sinnvoll ist. Ebenso wichtig ist die Frage:
Welche Zusammenarbeit wird dadurch verhindert?
Oft liegt die bessere Lösung nicht darin, einen Bereich vollständig auszublenden. Sinnvoller kann es sein, Leserechte zu erlauben, Bearbeitungsrechte einzuschränken oder nur besonders sensible Informationen zusätzlich zu schützen. So bleibt der notwendige Kundenkontext verfügbar, ohne dass jeder Benutzer automatisch alles verändern oder vertrauliche Details sehen kann.
Matrix: Wer braucht welche Informationen?
Eine einfache Berechtigungsmatrix kann bereits vor der technischen Umsetzung sehr hilfreich sein.
| Datenbereich | Vertrieb | Service | Customer Success | Management |
|---|---|---|---|---|
| Kundenstammdaten | Bearbeiten | Lesen | Lesen | Lesen |
| Opportunities | Bearbeiten | Lesen eingeschränkt | Lesen | Lesen |
| Servicefälle | Lesen | Bearbeiten | Lesen | Lesen |
| Verträge | Lesen | Lesen | Bearbeiten | Lesen |
| Marge | Eingeschränkt | Nein | Nein | Lesen |
| Interne Eskalation | Lesen | Bearbeiten | Lesen | Lesen |
| Benutzerverwaltung | Nein | Nein | Nein | Nein |
Die konkrete Matrix ist selbstverständlich unternehmensabhängig.
Der entscheidende Punkt ist die Methode: Rechte werden aus dem Prozess abgeleitet, nicht aus technischen Möglichkeiten.
Externe Partner brauchen ein eigenes Sicherheitsmodell
Sobald Partner, Händler, Kunden oder andere externe Benutzer auf CRM-Daten zugreifen, steigt die Bedeutung des Berechtigungskonzepts erheblich.
Ein Reseller darf beispielsweise seine eigenen Opportunities sehen.
Er darf aber nicht:
- Opportunities anderer Partner sehen,
- interne Margen erkennen,
- andere Kundenbeziehungen einsehen,
- interne Kommentare lesen,
- vertrauliche Forecasts betrachten.
Gerade bei Partnerportalen sollte deshalb bereits das Datenmodell darauf ausgelegt sein, externe und interne Informationen sauber zu trennen.
Das nachträgliche „Verstecken“ einzelner Felder ist deutlich riskanter als ein von Anfang an klares Berechtigungsmodell.
Hierarchische Rechte nicht automatisch mit der Organisationsstruktur gleichsetzen
Eine Vertriebsorganisation besitzt häufig eine klassische Hierarchie:
Vertriebsleiter
↓
Regionalleiter
↓
Account Manager
Es liegt nahe, diese Struktur 1:1 im CRM abzubilden.
Das kann funktionieren.
Es kann aber auch problematisch werden.
Ein Matrixunternehmen besitzt möglicherweise gleichzeitig:
- Regionen
- Produkte
- Business Units
- Key Accounts
- Branchen
Dann kann ein Kunde gleichzeitig mehreren Verantwortungsbereichen zugeordnet sein.
Ein rein hierarchisches Rechtekonzept stößt hier schnell an Grenzen.
Deshalb sollte zuerst der tatsächliche Informationsbedarf analysiert werden – und erst danach entschieden werden, welche organisatorischen Strukturen für Zugriffsrechte relevant sind.
Berechtigungen müssen bei Mitarbeiterwechseln automatisch mitgedacht werden
Rechtekonzepte funktionieren beim Onboarding häufig gut: Ein neuer Mitarbeiter bekommt eine Rolle, wird einem Team zugeordnet und erhält die benötigten Zugriffe. Schwieriger wird es bei internen Wechseln. Ein Account Manager wird Teamleiter, ein Service-Mitarbeiter wechselt zu Customer Success oder jemand übernimmt vorübergehend eine andere Region. Auch zeitlich begrenzte Projektzugriffe kommen in vielen Unternehmen regelmäßig vor.
Problematisch wird es dann, wenn bei solchen Veränderungen immer nur neue Rechte ergänzt werden. Alte Berechtigungen bleiben bestehen, obwohl sie für die neue Aufgabe gar nicht mehr benötigt werden. Über die Jahre entstehen so sogenannte Permission Accumulations: Mitarbeiter sammeln Zugriffe aus früheren Rollen, Projekten oder Verantwortungsbereichen an.
Genau deshalb sollte ein gutes Berechtigungsmodell nicht nur das Onboarding abdecken, sondern einen festen Joiner-Mover-Leaver-Prozess vorsehen:
- Joiner: Welche Standardrolle und welche Datenzugriffe erhält ein neuer Mitarbeiter?
- Mover: Welche bisherigen Rechte müssen bei einem internen Wechsel entfernt oder angepasst werden?
- Leaver: Welche Zugriffe müssen beim Ausscheiden unmittelbar deaktiviert werden?
Besonders wichtig ist der Mover-Prozess. In der Praxis liegt hier oft das größte Risiko, weil Mitarbeiter ihre alten Rechte behalten und zusätzlich neue erhalten. Temporäre Zugriffe sollten deshalb möglichst von Anfang an mit einem Ablaufdatum versehen werden. So wird aus einer einmaligen Berechtigungsvergabe ein kontinuierlich gepflegter Prozess.
Berechtigungsreviews sollten Teil des CRM-Betriebs sein
Ein Rechtekonzept ist kein einmaliges Projektdokument.
Organisationen verändern sich.
Teams werden zusammengelegt. Regionen ändern sich. Mitarbeiter wechseln. Neue Module kommen hinzu.
Deshalb sollten Berechtigungen regelmäßig überprüft werden.
Ein pragmatischer Rhythmus könnte sein:
Quartalsweise
- privilegierte Benutzer prüfen
- Administratorrechte kontrollieren
- externe Benutzer überprüfen
- temporäre Sonderrechte entfernen
Halbjährlich
- Rollen und Teams überprüfen
- Fachbereiche Zugriffe bestätigen lassen
- nicht mehr verwendete Rollen identifizieren
Jährlich
- gesamtes Berechtigungsmodell gegen Organisationsstruktur und Prozesse prüfen
- Dokumentation aktualisieren
- kritische Berechtigungen auditieren
Administratorrechte besonders restriktiv behandeln
CRM-Administratoren benötigen zwangsläufig umfangreiche Rechte.
Genau deshalb sollte ihre Zahl möglichst klein bleiben.
Nicht jeder Mitarbeiter, der:
- ein Dashboard baut,
- Benutzer unterstützt,
- Reports anpasst,
- Daten importiert,
benötigt automatisch vollständige Administratorrechte.
Wo möglich, sollten administrative Aufgaben differenziert werden.
Außerdem sollte klar nachvollziehbar sein:
- wer Administrator ist,
- warum die Person diese Rechte benötigt,
- wann diese Berechtigung zuletzt geprüft wurde.
SugarAI: Rollen und Teams bewusst trennen
Bei Plattformen wie SugarAI lässt sich ein Berechtigungskonzept sinnvoll über mehrere Ebenen strukturieren. Entscheidend ist dabei vor allem die Trennung zwischen funktionalen Rechten und organisatorischem Datenzugriff.
Rollen sollten in erster Linie festlegen, was ein Benutzer im System tun darf. Dazu gehören zum Beispiel das Lesen oder Bearbeiten von Opportunities, das Erstellen von Reports oder der Export von Daten. Teams steuern dagegen, auf welche Datensätze ein Benutzer zugreifen kann, etwa auf eine bestimmte Region, einen Geschäftsbereich oder definierte Key Accounts.
Diese Trennung verhindert, dass für jede Kombination aus Funktion und Organisationseinheit eine eigene Rolle aufgebaut werden muss. Ein Vertriebsmitarbeiter kann beispielsweise die Rolle Sales User besitzen und gleichzeitig dem Team DACH Sales zugeordnet sein. Wechselt derselbe Mitarbeiter später in eine andere Region, muss nicht zwangsläufig eine neue Rolle vergeben werden. Häufig reicht es, die Teamzuordnung anzupassen.
Für einen Vertriebsleiter kann das Modell erweitert werden: Er erhält zusätzliche funktionale Rechte und Zugriff auf mehrere relevante Teams. Auf diese Weise bleibt das Berechtigungsmodell modular und nachvollziehbar, auch wenn Organisationen wachsen oder sich Zuständigkeiten verändern.
Der Vorteil liegt vor allem in der langfristigen Pflege. Statt immer neue Sonderrollen anzulegen, werden wenige wiederverwendbare Rollen mit flexiblen Teamzuordnungen kombiniert. Das reduziert Komplexität und macht das Sicherheitsmodell leichter administrierbar.
KI-Agenten brauchen ebenfalls Berechtigungen
Mit AI Agents entsteht eine neue Fragestellung:
Welche Daten darf eigentlich ein Agent sehen – und welche Aktionen darf er ausführen?
Ein Meeting-Preparation-Agent benötigt vielleicht:
- Account-Daten,
- Kontakte,
- Aktivitäten,
- Opportunities,
- Servicefälle.
Er benötigt aber möglicherweise keinen Zugriff auf:
- interne Personaldaten,
- vertrauliche Margen,
- andere Regionen,
- administrative Einstellungen.
Noch wichtiger wird die Unterscheidung zwischen Lesen und Handeln.
Ein Agent kann beispielsweise:
- Daten nur analysieren,
- Änderungen vorschlagen,
- Datensätze aktualisieren,
- Nachrichten versenden,
- Prozesse auslösen.
Diese Eskalationsstufen sollten bewusst gesteuert werden.
Für AI gilt deshalb dasselbe Prinzip wie für Menschen:
Nur die Rechte vergeben, die für die Aufgabe tatsächlich notwendig sind.
AI Governance beginnt beim Berechtigungsmodell
Je stärker AI in CRM-Prozesse eingreift, desto wichtiger wird eine Verbindung zwischen klassischer CRM-Security und AI Governance.
Ein Unternehmen sollte beispielsweise wissen:
- Welche Agenten existieren?
- Wer ist für sie verantwortlich?
- Welche Daten können sie verwenden?
- Welche Aktionen dürfen sie durchführen?
- Welche Aktionen benötigen menschliche Freigabe?
- Werden Aktionen protokolliert?
- Können Rechte kurzfristig entzogen werden?
Damit wird das Berechtigungsmodell künftig nicht mehr nur Benutzer verwalten.
Es verwaltet zunehmend Menschen, Integrationen und digitale Agenten.
Typische Fehler bei CRM-Berechtigungen
| Fehler | Kurzfristiger Effekt | Langfristiges Problem |
|---|---|---|
| Jeder sieht alles | Einfacher Betrieb | Datenschutz- und Vertraulichkeitsrisiken |
| Jeder sieht nur eigene Datensätze | Klare Trennung | Zusammenarbeit wird verhindert |
| Zu viele Spezialrollen | Anforderungen schnell gelöst | Rechte werden unübersichtlich |
| Rollen nach Personen statt Funktionen | Individuell passend | Hoher Pflegeaufwand |
| Feldrechte für zu viele Felder | Granulare Kontrolle | Komplexität und Testaufwand |
| Administratorrechte als Workaround | Problem schnell gelöst | Erhöhtes Sicherheitsrisiko |
| Temporäre Zugriffe ohne Ablauf | Flexibilität | Historisch gewachsene Überberechtigung |
| Keine regelmäßigen Reviews | Weniger Aufwand | Veraltete Zugriffe bleiben bestehen |
| Externe Benutzer wie interne behandeln | Schnelle Umsetzung | Risiko ungewollter Datenfreigabe |
| AI Agents ohne eigenes Rechtekonzept | Schneller Pilot | Unklare Daten- und Aktionsrechte |
Praxisbeispiel: Von 27 Rollen zu einem modularen Modell
- Sales Germany
- Sales Austria
- Sales Switzerland
- Senior Sales Germany
- Senior Sales Austria
- Service Germany
- Service Europe
- Sales Manager DACH
- Key Account International
Phase 1: Benutzerprofile definieren
Es entstehen fünf funktionale Grundrollen:- Sales User
- Sales Manager
- Service User
- Customer Success
- CRM Administrator
Phase 2: Datenbereiche trennen
Regionen und organisatorische Datenzugriffe werden nicht mehr über Rollen, sondern über Teams beziehungsweise Datenbereiche gesteuert. Beispiele:- DACH
- Benelux
- France
- Key Accounts
- Global Service
Phase 3: sensible Informationen identifizieren
Nur wenige Felder erhalten zusätzliche Einschränkungen:- Marge
- interne Risikobewertung
- bestimmte Vertragskonditionen
Phase 4: Joiner-Mover-Leaver-Prozess einführen
Jeder Mitarbeiterwechsel löst eine Überprüfung der bestehenden Rechte aus. Temporäre Sonderzugriffe erhalten ein Ablaufdatum.Phase 5: regelmäßiger Review
Management und Fachbereiche bestätigen halbjährlich die wichtigsten Rollen und Datenzugriffe. Das Ergebnis ist nicht weniger Sicherheit. Im Gegenteil. Das Modell wird einfacher – und dadurch besser kontrollierbar.Checkliste: Ist Ihr CRM-Berechtigungsmodell sauber aufgebaut?
- Sind Benutzerrollen nach Funktionen statt nach einzelnen Personen definiert?
- Sind organisatorische Datenbereiche von funktionalen Rollen getrennt?
- Ist klar, welche Benutzer lesen, bearbeiten, löschen oder exportieren dürfen?
- Sind besonders sensible Felder identifiziert?
- Wird Field-Level Security nur gezielt eingesetzt?
- Ist die Bedeutung des Record Owners klar definiert?
- Können mehrere interne Verantwortliche an einem Account beteiligt sein?
- Sind externe Benutzer und Partner sauber von internen Benutzern getrennt?
- Werden administrative Rechte auf wenige Benutzer begrenzt?
- Haben temporäre Sonderrechte ein Ablaufdatum?
- Existiert ein Joiner-Mover-Leaver-Prozess?
- Werden alte Rechte bei internen Wechseln entfernt?
- Werden Rollen und Teams regelmäßig überprüft?
- Ist dokumentiert, warum wichtige Berechtigungen existieren?
- Unterstützt das Modell abteilungsübergreifende Kundenprozesse?
- Verhindert die Rechtearchitektur unnötige Informationssilos?
- Sind Export- und Massendatenrechte separat betrachtet?
- Haben Integrationen nur die notwendigen Rechte?
- Existiert ein eigenes Berechtigungskonzept für AI Agents?
- Werden Agentenaktionen protokolliert und gegebenenfalls freigegeben?
Fazit: Gute Berechtigungen schützen Daten, ohne Zusammenarbeit zu verhindern
Ein gutes CRM-Berechtigungsmodell sollte weder möglichst offen noch möglichst restriktiv sein.
Es sollte nachvollziehbar sein.
Mitarbeiter benötigen die Informationen, die sie für ihren Kundenprozess brauchen. Gleichzeitig müssen sensible Daten, administrative Funktionen und externe Zugriffe angemessen geschützt werden.
Die wichtigste Grundlage ist eine klare Trennung zwischen:
Was darf jemand tun?
und
Auf welche Daten darf jemand zugreifen?
Wer Rollen, Teams, Datensatzsichtbarkeit und Feldschutz sauber trennt, kann ein Rechtekonzept deutlich modularer gestalten.
Das reduziert nicht nur Sicherheitsrisiken.
Es senkt auch den administrativen Aufwand und verhindert, dass aus einigen wenigen Rollen im Laufe der Jahre ein kaum noch wartbares Geflecht aus Sonderrechten entsteht.
Mit AI Agents wird dieses Thema zusätzlich wichtiger. Künftig müssen CRM-Berechtigungen nicht nur Menschen und Integrationen berücksichtigen, sondern auch digitale Agenten, die Daten analysieren und Aktionen ausführen.
Damit wird ein gutes Berechtigungskonzept zu einem zentralen Bestandteil moderner CRM Governance.
CTA
Ist Ihr CRM-Rechtemodell über Jahre gewachsen und inzwischen schwer nachvollziehbar?
Ein Berechtigungsreview kann schnell sichtbar machen, welche Rollen zusammengeführt, welche Sonderrechte entfernt und welche Datenbereiche klarer strukturiert werden sollten.
