Ein eindeutiger Name erleichtert Abstimmung und Versionierung des Briefings.
Kostenloser CRM-Anforderungskatalog · ohne E-Mail-Gate
CRM-Anforderungen ordnen. Bevor ein CRM sie festschreibt.
Erfassen Sie Ziel, Kundenmodell, Pipeline, Rollen, Migration, Integrationen und Abnahme in 20 prüfbaren Punkten. Der Export dient als Grundlage für interne Abstimmung, Software-Auswahl oder ein Entwicklungsbriefing – unabhängig davon, ob am Ende Standardsoftware, Customizing oder Individualentwicklung passt.
Lokal und ohne Registrierung: Alle Angaben bleiben während der Nutzung in diesem Browser-Tab. Das Tool speichert und überträgt keine Eingaben an Midnight Motion. Der Katalog ist eine Arbeits- und Gesprächsgrundlage. Er ist keine Vollständigkeits-, Datenschutz-, Machbarkeits-, Kosten- oder Terminzusage.
Interaktive Checkliste und exportierbare Vorlage
20 Prüfpunkte für ein nachvollziehbares Projektbriefing
Die Tool-Seite führt im Browser durch alle folgenden Fragen und erzeugt daraus ein gegliedertes Markdown- und Druckdokument. Ein fiktives Beispiel zeigt die erwartete Detailtiefe, ohne fremde Kundendaten zu verwenden. Die Fortschrittsanzeige zählt nur beschriebene Punkte; sie ist ausdrücklich kein Reifegrad, keine Anbieterbewertung und keine Aussage zur technischen Machbarkeit.
Ziel und Systemgrenze
Ein CRM-Projekt braucht zuerst einen benennbaren Kundenprozess und ein überprüfbares Ergebnis. Eine allgemeine Wunschliste mit möglichst vielen Funktionen trennt dagegen weder Kernproblem noch bewusste Nicht-Ziele.
Beschreiben Sie beobachtbares Problem und gewünschte Veränderung – nicht nur „zentrale Kundendatenbank“.
Rollen, Anzahl, Standorte und unterschiedliche Arbeitsweisen beeinflussen Oberfläche, Rechte und Einführung.
Benennen Sie Dateien, vorhandene Systeme, Übergaben und den häufigsten Workaround vom ersten Kontakt bis zum relevanten Ergebnis.
Formulieren Sie prüfbare Fälle, Datenzustände und Nutzerhandlungen. Ein allgemeines Ziel wie „mehr Effizienz“ ist keine Abnahmebedingung.
Kunden, Vorgänge und Historie
Das Datenmodell bestimmt, ob das CRM den tatsächlichen Beziehungen folgt. Unternehmen, Standorte, Kontakte, Chancen und Servicefälle sollten nicht nur deshalb in ein Objekt gepresst werden, weil eine bestehende Tabelle so aufgebaut ist.
Beschreiben Sie B2B-Organisationen, Standorte, Ansprechpartner, Buying Center, Partner oder B2C-Kunden sowie wichtige Beziehungen.
Zum Beispiel Lead, Verkaufschance, Anfrage, Angebot, Vertrag, Ticket, Aktivität oder Aufgabe – jeweils mit eigener Identität und Lebenszyklus.
Definieren Sie nicht nur Pipeline-Spalten, sondern auch Eintrittsbedingungen, erlaubte Übergänge, Abbruchgründe und nächste Aktionen.
Quellen, IDs, Dubletten, Pflichtfelder, Anhänge, freie Notizen, Historie, Bereinigung und ein kontrollierter Probeimport gehören in dieselbe Entscheidung.
Legen Sie fest, was als fachliche Historie benötigt wird, wer es sehen darf und was nur verlinkt statt dupliziert werden soll.
Verantwortung, Rechte und Ausnahmen
Ein CRM wird zum Arbeitssystem, wenn Zuständigkeiten und nächste Schritte klar sind. Automatisierung sollte den Prozess unterstützen, ohne Sonderfälle unsichtbar zu machen oder Entscheidungen ungeprüft auszulösen.
Schneiden Sie einen Kernweg vom auslösenden Ereignis bis zum fachlichen Ergebnis, einschließlich eines typischen Ausnahmefalls.
Regeln für Eigentümer, Teams, Vertretung, Regionen, Eskalation und offene Aufgaben verhindern herrenlose Kundenfälle.
Denken Sie an Teamgrenzen, sensible Notizen, Exporte, Massenänderungen, Administration und serverseitig durchgesetzte Berechtigungen.
Beschreiben Sie Auslöser, Bedingung, Aktion, Empfänger und Verhalten bei fehlenden oder widersprüchlichen Daten.
Rabatte, Sonderkonditionen, Dubletten, fehlende Pflichtwerte oder zurückgewiesene Übergaben brauchen eine bearbeitbare Warteschlange statt stiller Fehler.
Integration, Datenschutz und Betrieb
CRM-Daten entstehen selten nur im CRM. Datenhoheit, Schnittstellen und Datenschutzanforderungen müssen deshalb vor dem ersten Import geklärt werden – besonders bei ERP-, E-Mail-, Kalender-, Marketing- oder Telefonie-Anbindungen.
Nennen Sie Produkt, Version, Betriebsart, gewünschte Datenobjekte, Richtung, Frequenz sowie verfügbare Dokumentation und Testzugänge.
Für Kundenstamm, Kontakte, Preise, Angebote, Verträge und Aktivitäten muss feststehen, wo verbindlich geändert und wie ein Konflikt behandelt wird.
Erfassen Sie Datenkategorien, Zweck, zuständige Rollen, Auskunft, Korrektur, Löschung, Aufbewahrung, Exporte und erforderliche Protokollierung. Die rechtliche Bewertung bleibt beim Unternehmen und seinen Fachverantwortlichen.
Definieren Sie Kennzahl, Datenquelle, Filter, Aktualität und verantwortliche Rolle. Ein Dashboard kann unklare Definitionen nicht reparieren.
Pilotgruppe, Testdaten, Abnahmeszenarien, Schulung, Parallelbetrieb, Abschaltung alter Listen, Monitoring, Support und verantwortliche Admin-Rolle gehören zusammen.
Vom Wunsch zur prüfbaren Anforderung
Ein Anforderungskatalog ist mehr als eine Funktionsliste.
Eine Funktion wie „Pipeline“ lässt offen, welche Zustände erlaubt sind, wer sie ändern darf und wann ein Vorgang vollständig ist. Der Katalog verbindet deshalb Prozess, Daten, Berechtigung, Systemgrenze und Abnahme. Er ersetzt weder eine fachliche Discovery noch eine rechtliche Prüfung, macht aber die offenen Entscheidungen für alle Beteiligten sichtbar.
Use Case statt Modulname
Beschreiben Sie Auslöser, beteiligte Rolle, benötigte Information, Handlung und Ergebnis. So lässt sich später testen, ob eine Standardlösung den Ablauf abbildet oder nur ähnlich benannte Menüpunkte besitzt.
Datenhoheit statt Vollsynchronisation
Nicht jedes System sollte jedes Feld ändern dürfen. Ein führendes System je kritischem Objekt reduziert Konflikte, doppelte Pflege und unklare Korrekturwege zwischen CRM, ERP und weiteren Diensten.
Rechte als Fachregel
Berechtigungen sind nicht nur technische Rollen. Teamgrenzen, sensible Notizen, Freigaben und Exporte bilden reale Verantwortung ab und sollten mit konkreten Beispieldatensätzen geprüft werden.
Abnahme vor Anbieter-Demo
Gleiche Szenarien, Pflichtdaten und Fehlerfälle machen Lösungen vergleichbarer. Ein hübscher Demo-Datensatz beweist weder Migration, Datenqualität noch den Betrieb mit den tatsächlichen Schnittstellen.
Methodische Orientierung geben insbesondere die offiziellen Datenschutzgrundsätze sowie praxisnahe CRM-Lastenheft-Strukturen. Die verlinkten Beispiele sind keine Zertifizierung des Tools und ersetzen keine Prüfung des eigenen Vorhabens.
Neutrale Systementscheidung
Standard-CRM, Konfiguration, Integration oder Individualentwicklung?
Ein Anforderungskatalog soll keine Eigenentwicklung vorentscheiden. Für übliche Kontaktpflege, Standard-Pipelines und verbreitete Workflows ist eine etablierte CRM-Plattform häufig der belastbarere Ausgangspunkt. Konfiguration passt, wenn Datenmodell und Prozess im Kern vorhanden sind. Eine Integration reicht, wenn vor allem Daten zwischen bestehenden Systemen fehlen. Individuelle CRM-Software wird erst relevanter, wenn ein eigenes Beziehungsmodell, differenzierende Abläufe oder kontrollierte Rollen dauerhaft nicht sinnvoll im Standard abbildbar sind. Alle Wege sollten an denselben Beispieldaten und Akzeptanzfällen geprüft werden.
Export ohne E-Mail-Gate
Ein Arbeitsdokument für Auswahl, Scope und Angebot.
Der Export ordnet alle Angaben nach Ziel, Datenmodell, Arbeitsfluss und Systemlandschaft. Ungeklärte Pflichtpunkte bleiben mit ihrer Begründung sichtbar, damit sie nicht still als Annahme in eine Auswahl oder Aufwandsschätzung eingehen.
- Eigene Angaben in vier fachlichen Bereichen erfassen
- Ungeklärte Voraussetzungen sichtbar behalten
- Fiktives Beispiel als Orientierung laden
- Markdown kopieren oder herunterladen
- Dokument drucken und als PDF speichern
- Mit Fachseite, IT und möglichen Anbietern verifizieren
Nächster sinnvoller Schritt: Den Kernprozess mit zwei bis drei realen Beispieldatensätzen durchspielen. Danach Muss-, Soll- und bewusste Nicht-Ziele priorisieren und Standardsoftware, Customizing, Integration sowie Individualentwicklung anhand derselben Abnahmeszenarien vergleichen.
- 01 · Ziel und Systemgrenze
- Arbeitstitel des CRM-Vorhabens · Welches geschäftliche Problem soll das CRM lösen? · Welche Teams und Nutzergruppen arbeiten damit? · Wie läuft der Kernprozess heute? · Woran wird der erste CRM-Scope abgenommen?
- 02 · Kunden, Vorgänge und Historie
- Welche Kunden- und Kontaktstrukturen gibt es? · Welche fachlichen Objekte müssen getrennt geführt werden? · Welche Zustände, Pflichtfelder und Übergänge sind verbindlich? · Welche Altdaten werden migriert – und in welcher Qualität? · Welche Aktivitäten, Änderungen und Dokumente müssen nachvollziehbar sein?
- 03 · Verantwortung, Rechte und Ausnahmen
- Welcher vollständige Ablauf gehört in Version eins? · Wie werden Datensätze und Aufgaben zugewiesen? · Welche Rollen dürfen welche Daten sehen oder verändern? · Welche Aufgaben, Erinnerungen oder Übergaben sollen automatisch entstehen? · Welche Freigaben und Ausnahmewege müssen sichtbar bleiben?
- 04 · Integration, Datenschutz und Betrieb
- Welche Systeme und Kanäle müssen angebunden werden? · Welches System führt welche Information? · Welche Datenschutz-, Lösch- und Aufbewahrungsregeln gelten? · Welche Entscheidungen sollen Berichte unterstützen? · Wie werden Pilot, Abnahme, Umstellung und Betrieb organisiert?
FAQ
Häufige Fragen zum Anforderungscheck
Was gehört in einen CRM-Anforderungskatalog?
Neben funktionalen Wünschen gehören Ziel und Scope, beteiligte Rollen, Kunden- und Vorgangsmodell, Zustände, Berechtigungen, Migration, Schnittstellen, Datenschutzanforderungen, Reporting, Abnahmeszenarien und Einführung hinein. Jede wichtige Anforderung sollte anhand eines realen Arbeitsfalls prüfbar sein.
Ist ein CRM-Anforderungskatalog dasselbe wie ein Lastenheft?
Die Begriffe werden häufig überlappend verwendet. Ein Lastenheft beschreibt aus Sicht des Auftraggebers, was erreicht und benötigt wird. Der Generator erzeugt eine strukturierte Vorarbeit dafür, aber kein automatisch vollständiges Ausschreibungs- oder Vertragsdokument.
Eignet sich die Vorlage auch für Salesforce, HubSpot oder Microsoft Dynamics?
Ja. Die Fragen sind produktneutral und helfen sowohl bei Auswahl und Customizing einer Plattform als auch bei Integrationen oder Individualentwicklung. Produktspezifische Lizenz-, Hosting- und Funktionsbedingungen müssen anschließend direkt beim jeweiligen Anbieter geprüft werden.
Wie werden CRM-Anforderungen priorisiert?
Zuerst wird ein vollständiger Kernprozess festgelegt. Danach lassen sich Anforderungen als Muss, Soll, Kann und bewusstes Nicht-Ziel ordnen. Muss-Anforderungen brauchen ein klares Akzeptanzkriterium; sonst ist ihre Erfüllung in Demo, Angebot oder Abnahme nicht objektiv prüfbar.
Werden die eingegebenen CRM-Daten gespeichert?
Nein. Die Eingaben werden nur im Zustand des geöffneten Browser-Tabs verarbeitet. Das Tool überträgt sie nicht an Midnight Motion und legt sie nicht dauerhaft im Browser ab. Erst ein bewusstes Kopieren, Herunterladen oder Drucken erzeugt ein Dokument bei Ihnen.
Kann der Katalog die CRM-Kosten berechnen?
Nein. Kosten hängen unter anderem von Nutzerzahl, Produkt und Lizenzmodell, Datenbereinigung, Prozesslogik, Integrationen, Sicherheit, Einführung und Betrieb ab. Der Katalog macht diese Einflussfaktoren sichtbarer, ersetzt aber keine Anbieterprüfung oder belastbare Kalkulation.
Mit echten Beispieldaten weiterarbeiten
Standard-CRM, Anpassung oder eigenes System?
Beschreiben Sie den wichtigsten CRM-Ablauf und die entscheidende Abweichung vom Standard. Im Projekt-Check ordnen wir ein, welcher technische Prüfpfad als Nächstes sinnvoll ist.
CRM-Vorhaben unverbindlich einordnen →