CRM-Architektur

CRM-Architekturberatung beginnt mit der Arbeit zwischen Erstkontakt und Ende der Kundenbeziehung. Wie gelangt eine Anfrage ins System? Wann ist sie qualifiziert? Wer verantwortet den nächsten Schritt? Welcher Nachweis bewegt eine Verkaufschance weiter? Wie erfolgt die Übergabe an die Leistungserbringung, und wie werden Verlängerung, Ausbau, Support oder Abschluss dokumentiert? Auch reale Ausnahmen wie mehrere Entscheider, Vertriebspartner, lange Beschaffung, reaktivierte Chancen und gemeinsam betreute Konten gehören in das Modell.

Der schriftliche Umfang nennt Bereiche, Lebenszyklusphasen, Datensatzarten, Nutzer, Rollen, Quellen, Kommunikationskanäle, Berichte, Automatisierungen, Migrationshistorie, Umgebungen, Schulung, Abnahme und Verantwortung nach dem Start. Ein CRM für ein Vertriebsteam unterscheidet sich grundlegend von einem regionsübergreifenden System, das Marketing, Finanzen, Service und Leistung verbindet. Eine Bereinigung ist nicht automatisch eine Neuimplementierung; ein Prototyp ist kein Produktivbetrieb.

Vor einer Anpassung prüfen wir die vorhandenen Plattformfunktionen. Salesforce, HubSpot, Microsoft Dynamics 365, Pipedrive, Zoho oder eine individuelle Lösung können passen. Eine Zusage gibt es erst nach Prüfung von Anforderungen, Tarif, regionaler Verfügbarkeit, API-Zugriff, Sicherheit und Gesamtkosten. Die Architektur trennt Konfiguration, Erweiterung, Integration und Individualsoftware. Die CRM-Implementierung verspricht weder Umsatz noch kürzere Zyklen oder Nutzung; überprüfbar sind dagegen Funktionen, Rechte, Daten, Automationen, Berichte und vereinbarte Szenarien.

Das Datenmodell bildet das Geschäft ab, nicht die zuerst gefundene Tabelle. Kontakte, Organisationen, Leads, Chancen, Produkte, Abonnements, Fälle, Standorte, Partner und Aktivitäten werden nur dann getrennt modelliert, wenn sie verschiedene Sachverhalte mit eigenen Regeln darstellen. Felder erhalten fachliche Definition, Datentyp, gültige Werte, Schutzbedarf, Quelle, Eigentümer und Aufbewahrung. Ein eigenes Objekt entsteht aus einer echten Beziehung, nicht weil eine zusätzliche Tabelle bequem ist.

Identitätsregeln verhindern unbemerkte Duplikate. Wir definieren Abgleichsschlüssel, Schwellen, Vorrang, Zusammenführungsrecht und Ausnahmen für Sammeladressen, Tochtergesellschaften, Franchises und Personen mit mehreren Mandaten. Eine E-Mail-Adresse ist nicht immer ein verlässlicher eindeutiger Schlüssel. Automatisches Zusammenführen bleibt begrenzt, protokolliert und möglichst rückgängig zu machen; unklare Fälle gehen an eine benannte Prüfung.

Datensatzbesitz und Sichtbarkeit werden getrennt. Der Besitzer kann für die nächste Handlung zuständig sein, während ein Team lesen darf, Marketing die Einwilligung verwaltet und Finanzen ein Rechnungsfeld kontrolliert. Pflichtfelder erscheinen erst, wenn sie für eine Phase nötig werden. Wesentliche Schemaänderungen werden versioniert und gegen Berichte, Automationen und Integrationen getestet; alte Felder werden bewusst stillgelegt, statt als konkurrierende Wahrheit weiterzubestehen.

Eine Vertriebspipeline funktioniert, wenn Phasen erkennbaren Ereignissen entsprechen. Qualifiziert kann bestätigte Eignung und ein bekanntes Problem verlangen; Angebot versendet einen versionierten Angebotsdatensatz; zugesagt einen benannten Entscheidungsweg statt einer optimistischen Prozentzahl. Eintritt, Austritt, Rückbewegung, Verlustgründe, Inaktivität und Wiedereröffnung werden definiert. Prognosekategorie und Verkaufsphase bleiben getrennt, wenn sie verschiedene Fragen beantworten.

Zuweisungen machen die nächste Handlung sichtbar. Region, Sprache, Produkt, Kapazität, Kontobeziehung oder Fachgebiet können die Verteilung steuern; bei fehlenden Daten oder Abwesenheit braucht es eine Ausweichroute. Automatisierung übernimmt nur stabile, autorisierte Schritte. Sie kann Aufgaben anlegen, Zustände abgleichen oder eine geprüfte Nachricht vorbereiten, darf aber keine Einwilligung erfinden, vertrauenswürdige Werte ohne Vorrangregel überschreiben oder einen Vorgang durch ein undurchsichtiges Modell schließen.

Berichte folgen dem vereinbarten Lebenszyklus. Konversion, Geschwindigkeit, Alter, Quelle, Abdeckung und Prognose nennen Grundgesamtheit, Zeitpunkt und Ausschlüsse. Eine aus administrativen Gründen verschobene Phase darf nicht als Kaufsignal erscheinen. Aktivitätszahlen sind weder Beleg für Beziehungsqualität noch Kaufabsicht oder künftigen Umsatz. Führungskräfte brauchen Zugriff auf die zugrunde liegenden Datensätze und deren Qualitätszustand.

Migration beginnt mit Inventar und Auswahl. Quelle, Verantwortung, Umfang, Qualität, Schutzbedarf, Historie, Anhänge, Dubletten und Löschpflichten werden bewertet. Konfigurationsdaten und Kundendatensätze benötigen verschiedene Verfahren. Wir ordnen Felder und Werte zu, transformieren Stichproben, proben den Ablauf, stimmen Mengen und wichtige Summen ab, erfassen Ablehnungen und planen den Wechsel. Vor einer Veränderung der Altquelle bleibt eine Sicherung gemäß dem schriftlichen Wiederherstellungsplan erhalten.

Integrationen benennen Richtung, Datenhoheit und Fehlerverhalten. Für jede Verbindung stehen führendes System, erlaubte Aktualisierung, Konfliktregel, Frequenz, Identifikator, Protokollierung und Verantwortung für Wiederholungen fest. Webhooks, APIs, Dateien und Middleware haben unterschiedliche Garantien. Ein doppelseitiger Pfeil in einer Grafik ist noch kein Integrationsvertrag.

Zugriff folgt dem geringsten erforderlichen Recht. Lesen, Bearbeiten, Exportieren, Löschen, Konfigurieren und Administrieren werden unterschieden. Sensible Kunden-, Gesundheits-, Finanz- oder Personaldaten können Feld- und Zeilenschutz, regionale Grenzen, Aufbewahrung und Audit verlangen. Dienstkonten haben Besitzer, enge Rechte, verwaltete Geheimnisse und Widerruf. Der tatsächliche Auditumfang des gewählten Tarifs wird getestet; eine CRM-Einrichtung erzeugt weder automatisch Datenschutz noch Rechtskonformität.

Die Abnahme nutzt durchgängige Szenarien: Anfrage erfassen, qualifizieren, Beziehungen anlegen, zuweisen, mit Nachweis weiterführen, Ausgabe erstellen, an die Leistung übergeben, Dublette behandeln, Einwilligung widerrufen, Ausnahme melden und fehlerhafte Integration wiederherstellen. Berechtigungen werden mit jeder Rolle und nicht nur als Administrator geprüft. Migrationsstichproben und Summen werden abgestimmt, Automationen beobachtet, mobile Ansichten und wichtige Exporte geöffnet.

Schulung folgt Aufgaben und Entscheidungen statt einer Führung durch Schaltflächen. Nutzer lernen Phasenbedeutung, notwendige Erfassung, nächste Handlung, Ausnahmeweg und Fehlermeldung. Administratoren erhalten Datenwörterbuch, Rollenmodell, Automationsregister, Integrationskarte, Veröffentlichungsnachweis und Betriebshandbuch. Adoption bedeutet nicht nur Anmeldung; wir betrachten offene Aufgaben, unzugeordnete Datensätze, Dubletten, Umgehungslösungen, Supportfragen und die Qualität echter Pipeline-Besprechungen.

Im Betrieb brauchen Plattformupdates, abgelaufene Zugangsdaten, fehlerhafte Synchronisation, wachsende Warteschlangen, Speicher, API-Grenzen, Rollenänderungen und Berichtabweichungen Verantwortung. Überwachungszeiten, Reaktion, Änderungskapazität und Eskalation stehen schriftlich fest. KI kann freigegebene Datensätze zusammenfassen, Aufgaben vorschlagen oder einen Entwurf liefern; sie erfindet keine Fakten, leitet keine Einwilligung ab und erhält ohne gesonderte Freigabe keine autonome Geschäftsentscheidung.