> ## Documentation Index > Fetch the complete documentation index at: https://docs.m9tz.de/llms.txt > Use this file to discover all available pages before exploring further. # CRM-Integration > Wie der M9TZ Agent Blueprint CRM-Daten als eigene abgegrenzte Domäne behandelt – und wie Abteilungsagenten ausschließlich auf den für sie autorisierten Ausschnitt der Kundendaten zugreifen. Kundenbezogene Daten – Kontakte, Abschlusshistorie, Support-Fälle, Kommunikationsprotokolle – zählen zu den sensibelsten und abteilungsübergreifendsten Datentypen in jedem Unternehmen. Alle Abteilungen benötigen sie in irgendeiner Form, aber keine Abteilung sollte uneingeschränkten Zugriff auf alle Kundendaten haben. Der auf dieser Seite beschriebene Ansatz erläutert, wie der M9TZ Agent Blueprint CRM-Daten als abgegrenzte, zugangskontrollierte Domäne behandelt. ## CRM als separate Datendomäne In einer abteilungsbasierten Agentenarchitektur agiert jeder Abteilungsagent innerhalb seiner eigenen Zuständigkeitsdomäne. CRM-Daten gehören keiner einzelnen Abteilung – sie sind eine gemeinsam genutzte Infrastruktur, auf die mehrere Agenten möglicherweise zugreifen müssen, jeder innerhalb seines eigenen Scopes. Der Blueprint modelliert das CRM als eigenen Mandanten innerhalb des Systems: eine eigenständige Datendomäne mit einer definierten Schnittstelle, über die sämtliche Agentenzugriffe kanalisiert werden. Kein Abteilungsagent liest direkt aus dem CRM-Datenspeicher oder schreibt direkt dorthin. Alle Zugriffe erfolgen über die CRM-Schnittstelle, die durchsetzt, was der jeweils aufrufende Agent einsehen und tun darf. ``` ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ Abteilung A │ │ Abteilung B │ │ Abteilung C │ │ Agent │ │ Agent │ │ Agent │ └────────┬─────────┘ └────────┬─────────┘ └────────┬─────────┘ │ autorisierter │ autorisierter │ autorisierter │ Scope │ Scope │ Scope ▼ ▼ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ CRM-Schnittstelle │ │ (Zugangskontrolle + stabiler Operationssatz) │ └─────────────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────┐ │ CRM-Adapter │ ← austauschbar └──────────────────┘ │ ▼ Ihr CRM-System (bestehende Plattform oder interne Lösung) ``` ## Zugangskontrolle auf Schnittstellenebene Die CRM-Schnittstelle ist der zentrale Punkt, an dem Zugriffsentscheidungen getroffen werden. Wenn ein Abteilungsagent eine Schnittstellenoperation aufruft, prüft die Schnittstelle den autorisierten Scope des aufrufenden Agenten, bevor sie Daten zurückgibt oder einen Schreibvorgang zulässt. Einige Beispiele, wie sich Scopes abteilungsübergreifend unterscheiden: * Ein Vertriebsagent kann berechtigt sein, Abschlussstufe und Kommunikationshistorie eines Kontakts zu lesen und zu aktualisieren, nicht jedoch die Support-Fall-Historie einzusehen. * Ein Support-Agent kann berechtigt sein, Kontaktdaten zu lesen und Fälle für seine zugewiesene Warteschlange zu öffnen, nicht jedoch Abschlusswerte oder Pipeline-Daten zu lesen. * Ein Abrechnungsagent kann berechtigt sein, Kontostatus und Rechnungskontakte zu lesen, nicht jedoch Kontakteigentümer oder Abschlussunterlagen zu ändern. Die Scopes werden in der Designphase als Teil der Rollendefinition jedes Abteilungsagenten festgelegt. Sie werden nicht zur Laufzeit ausgehandelt – es sind feste Deklarationen, die die Schnittstelle durchsetzt. ## Das Adaptermuster für CRM Wie bei der Back-Office- und ERP-Integration folgt auch das CRM demselben Adapterdesign: eine stabile Schnittstelle auf der einen Seite und ein austauschbarer Adapter auf der anderen. Die Schnittstelle definiert einen generischen Operationssatz, der die CRM-Anforderungen von Abteilungsagenten abdeckt. Der Adapter übersetzt diese Operationen in das, was das zugrunde liegende System – ob eine etablierte CRM-Plattform oder eine einfachere interne Lösung – erfordert. ### Generische Operationen der CRM-Schnittstelle Der genaue Operationssatz wird in der Designphase festgelegt; ein repräsentativer Satz umfasst: | Operation | Funktion | | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Kontakt nachschlagen | Gibt Kontaktdetails für einen bestimmten Bezeichner zurück, innerhalb des autorisierten Scopes des Aufrufers | | Kontakt erstellen | Legt einen neuen Kontaktdatensatz mit den Feldern an, für die der Aufrufer Schreibberechtigung hat | | Kontakt aktualisieren | Ändert bestimmte Felder eines bestehenden Kontaktdatensatzes | | Abschluss oder Fall nachschlagen | Gibt einen Abschluss- oder Support-Fall-Datensatz anhand eines Bezeichners zurück | | Abschluss- oder Fallstatus aktualisieren | Bewegt einen Abschluss oder Fall durch einen definierten Statusübergang | | Historien-Eintrag anhängen | Fügt ein zeitgestempeltes Ereignis oder eine Notiz an einen Kontakt- oder Falldatensatz an | | Zugewiesene Datensätze auflisten | Gibt die einem bestimmten Agenten, einer Warteschlange oder einem Eigentümer zugewiesenen Datensätze innerhalb des Scopes zurück | Jede Operation folgt demselben JSON-in-JSON-out-Vertrag, der im gesamten Blueprint verwendet wird. Der aufrufende Abteilungsagent sendet eine strukturierte Anfrage; die Schnittstelle prüft den Scope, ruft den Adapter auf und gibt eine strukturierte Antwort zurück. ## Was hinter dem Adapter steckt Der Adapter kann je nach vorhandenem Setup der Organisation und dem Stand des Builds durch unterschiedliche Systeme unterstützt werden. **In frühen Build- und Testphasen** wird der Adapter typischerweise durch eine lokale Referenzimplementierung unterstützt – einen einfachen, kontrollierten Datenspeicher, der auf jede CRM-Schnittstellenoperation antwortet. Dadurch können Agenten entwickelt und getestet werden, ohne vom Zugang zu einer Produktiv-CRM-Plattform abhängig zu sein. **Im Produktivbetrieb** wird der Adapter durch einen ersetzt, der mit dem CRM-System der Organisation verbunden ist – einer etablierten externen Plattform oder einer gut strukturierten internen Lösung. Der Agentencode und der Schnittstellenvertrag bleiben unverändert. Nur der Adapter ändert sich. Dies entspricht genau der stufenweisen Vorgehensweise, die auf der Seite [ERP- und Legacy-Systeme](/de/agent-structure/erp-legacy-systems) beschrieben wird: Zunächst den Workflow validieren, dann das Produktivsystem anbinden, wenn es benötigt wird und der Workflow belegt ist. Der Blueprint schreibt keine bestimmte CRM-Plattform vor und beschreibt keine konkreten Feldschemata für externe Produkte. Welches System hinter dem Adapter steckt – und wie dieser Adapter entwickelt wird – ist individuell auf Ihre Umgebung zugeschnitten und Bestandteil des Beratungsmandats. Siehe [Beratungsprozess](/de/consulting/engagement-model). ## Klare Trennung von anderen Geschäftsdaten Die Behandlung des CRM als separate Domäne – anstatt Abteilungsagenten den Zugriff auf Kundendaten über gemeinsam genutzte Tabellen oder direkte Abfragen zu ermöglichen – bietet mehrere praktische Garantien: * **Abgrenzung** – Eine Änderung der Speicherstruktur oder des Datenmodells im CRM erfordert nur eine Aktualisierung des Adapters, nicht jedes einzelnen Abteilungsagenten, der auf Kundendaten zugreift. * **Nachvollziehbarkeit** – Sämtliche Zugriffe auf CRM-Daten erfolgen über eine Schnittstelle, was bedeutet, dass Sie an einem zentralen Ort jeden Lese- und Schreibvorgang protokollieren, überwachen und prüfen können, den ein Agent an Kundendatensätzen vorgenommen hat. * **Klarheit der Zugangsberechtigung** – Der Zugang jedes Agenten zu CRM-Daten wird explizit in seiner Rollendefinition deklariert, nicht aus gemeinsam genutzten Datenbankberechtigungen abgeleitet. Sie können die Rollendefinition lesen und genau wissen, welche Kundendaten dieser Agent einsehen kann. * **Unabhängige Austauschbarkeit** – Wenn das CRM-System hinter dem Adapter wechselt, ist der Rest des Agentensystems nicht betroffen. Nur der Adapter muss aktualisiert werden. ## Bezug zur übergeordneten Architektur Die CRM-Integration ist ein Beispiel für ein allgemeines Prinzip des Blueprints: Jede externe Datenquelle wird über eine stabile Schnittstelle mit einer austauschbaren Implementierung dahinter zugegriffen. Abteilungsagenten kommunizieren über definierte Nachrichtenverträge; sie teilen keinen internen Zustand oder gemeinsame Datenspeicher. Das hält jeden Teil des Systems unabhängig verständlich und unabhängig austauschbar – was, wenn das Unternehmen wächst und sich sein technologisches Umfeld weiterentwickelt, die Agentenarchitektur dauerhaft wartbar macht. Derselbe Adapteransatz angewendet auf Back-Office- und Bestandsdaten – einschließlich der empfohlenen stufenweisen Build-Vorgehensweise. Wie die Integrationsarbeit im Rahmen eines Beratungsmandats kalkuliert und durchgeführt wird.