Viele Unternehmen haben ein CRM, trotzdem gehen Anfragen verloren. Das liegt selten daran, dass die Software zu schwach ist. Meist fehlt eine gemeinsame Sprache für den Ablauf.
Ohne klare Status weiß das Team nicht, was ein Eintrag bedeutet. Ohne nächste Schritte bleibt alles beim Gefühl „irgendwer kümmert sich schon“.
CRM als Ablage versus Prozess
Ein CRM als Ablage sammelt Kontakte, Notizen und vielleicht Termine. Ein CRM als Prozesswerkzeug zeigt zusätzlich:
- wo ein Vorgang steht
- was als Nächstes passieren muss
- wer verantwortlich ist
- wann eine Frist endet
Der Unterschied ist nicht das Produkt, sondern die Definition dahinter.
Merkmale eines guten Status
Ein guter Status ist handlungsfähig. Er beantwortet mindestens eine Frage:
Was ist jetzt der nächste sinnvolle Schritt?
Schwache Status klingen nach Ordnung, helfen aber nicht:
- offen
- in Bearbeitung
- später
- warten auf Rückmeldung
Bessere Status sind konkreter:
- Erstkontakt offen
- Termin vereinbart
- Angebot in Erstellung
- Angebot versendet
- Entscheidung offen
- abgeschlossen gewonnen
- abgeschlossen verloren
Wichtig ist nicht die perfekte Bezeichnung, sondern dass alle sie gleich verstehen.
Eintrittskriterium
Für jeden Status brauchst du eine Eintrittsregel. Beispiel:
Status „Erstkontakt offen“
Eintritt, wenn eine qualifizierte Anfrage vorliegt und noch keine erste persönliche Rückmeldung erfolgt ist.
Ohne Eintrittskriterium landen unterschiedliche Fälle im selben Status. Dann wird Priorisierung schwer.
Austrittskriterium
Ebenso wichtig ist das Austrittskriterium:
Wann gilt der Status als abgeschlossen?
Beispiel:
- „Angebot versendet“ endet, wenn Rückmeldung eingegangen ist oder die Frist abgelaufen ist.
- „Entscheidung offen“ endet mit gewonnen oder verloren, nicht mit „wir melden uns irgendwann“.
Status ohne Austritt sammeln offene Enden.
Verantwortlicher
Jeder aktive Vorgang braucht eine klar benannte Verantwortung. Nicht „das Team“, nicht „Vertrieb allgemein“, sondern eine Person oder Rolle mit konkreter Aufgabe.
Beispiele:
- Erstkontakt: Innendienst
- Angebot: Angebotsverantwortliche
- Nachfassen: zuständige Beraterin
Wenn Verantwortung unklar bleibt, verschiebt sich Arbeit in informelle Kanäle.
Pflichtaktion und Frist
Ein Status wird erst nutzbar, wenn er mit Aktion und Zeit verknüpft ist.
Beispiel:
| Status | Pflichtaktion | Frist |
|---|---|---|
| Erstkontakt offen | Rückruf oder E-Mail | innerhalb von 24 Stunden |
| Angebot in Erstellung | Angebot fertigstellen | innerhalb von 3 Werktagen |
| Entscheidung offen | Follow-up senden | nach 5 Werktagen ohne Rückmeldung |
So entsteht ein Ablauf, der nicht von Erinnerungskultur einzelner Personen abhängt.
Beispielpipeline
Ein einfaches Modell für B2B-Dienstleistungen:
- Neu eingegangen
- Erstkontakt erfolgt
- Bedarf geklärt
- Angebot versendet
- Entscheidung offen
- Gewonnen oder verloren
Jeder Schritt hat Eintritt, Austritt, Verantwortliche und Pflichtaktion. Erst dann lohnt sich die Frage nach Automationen.
Häufige Fehler
- Zu viele Status für den tatsächlichen Ablauf
- Keine Regeln, wann ein Datensatz den Status wechselt
- Kein Eigentümer pro aktivem Vorgang
- Follow-up ohne Abschlusskriterium
- Formulare liefern zu wenig Kontext für den ersten Schritt
- Ausnahmen werden nicht dokumentiert und verwässern das Modell
Statusmodell an realen Vorgängen testen
Ein Statusmodell sollte nicht im Konferenzraum enden. Nimm abgeschlossene, offene und problematische Vorgänge aus verschiedenen Ownern und ordne sie gemeinsam ein. Wenn zwei Personen denselben Fall in unterschiedliche Status legen, fehlt entweder eine Definition oder die Daten reichen für die Entscheidung nicht aus.
Für jeden Status gehören fünf Fragen in die Dokumentation: Was muss beim Eintritt vorliegen? Welche Handlung ist Pflicht? Wer ist Owner? Welche Frist gilt? Was beweist den Austritt? Diese Fragen machen auch sichtbar, ob ein Status zu groß ist. „In Bearbeitung“ umfasst oft Recherche, Angebot, Warten und interne Freigabe – vier unterschiedliche Situationen mit verschiedenen nächsten Schritten.
Reduziere Status, die nur Farbe liefern. Ergänze dagegen einen Status, wenn eine echte Übergabe, ein anderes Risiko oder ein anderes Ergebnis vorliegt. Die Pipeline muss nicht jeden Arbeitsschritt abbilden, aber jeden relevanten Entscheidungszustand.
Nächste Aktion sichtbar machen
Der Status allein reicht nicht. Zwei Vorgänge können beide „qualifiziert“ sein und trotzdem unterschiedliche nächste Schritte benötigen. Beim einen fehlt ein technisches Detail, beim anderen muss ein Entscheidungstermin mit mehreren Beteiligten vorbereitet werden. Ergänze deshalb eine Pflichtaktion, einen Owner und eine Frist. Die Aktion sollte mit einem Verb beginnen und ein erwartetes Ergebnis haben, etwa „Bedarf mit Ansprechpartnerin bis Donnerstag klären und Entscheidungstermin dokumentieren“.
Ein brauchbares Modell trennt dabei Zustand und Aktivität. „E-Mail gesendet“ ist eine Aktivität; „Entscheidung offen“ ist ein Zustand. Eine Aktivität kann den Zustand verändern, muss es aber nicht. Wenn sie keine Veränderung auslöst, braucht der Owner eine Regel für den nächsten Versuch, eine Pause oder den Abschluss. Diese Trennung verhindert, dass viele dokumentierte Aktivitäten einen stillstehenden Vorgang verdecken.
Auch Verantwortlichkeit braucht mehr als einen Namen. Bei Urlaub, Übergabe oder Teamwechsel muss klar sein, wer die Aufgabe übernehmen darf und welche Information dafür genügt. Ein Vertretungsprozess kann eine gemeinsame Queue, eine definierte Rolle oder eine zeitlich begrenzte Übergabe verwenden. Wichtig ist, dass der Vorgang nicht an der persönlichen Erinnerung des ursprünglichen Owners hängt.
Automation erst nach der Definition
Automationen sind nützlich, wenn der Prozess bereits verständlich ist. Beim Eingang kann das CRM einen Vorgang erstellen und nach einer Routingregel einen Owner zuweisen. Nach einem Angebot kann eine Follow-up-Aufgabe entstehen. Bei einer überfälligen Frist kann eine Eskalation sichtbar werden.
Automatisiere nicht den unklaren Statuswechsel selbst. Wenn „qualifiziert“ keine gemeinsame Bedeutung hat, erzeugt eine automatische Weiterleitung nur mehr falsche Vorgänge. Beginne mit einer kleinen Regel, prüfe die Ausnahmefälle und dokumentiere, wer die Regel ändern darf.
Reporting und Pflegeverantwortung
Ein CRM-Prozess braucht einen Owner für die Datenlogik. Diese Rolle prüft Definitionen, Dubletten, überfällige Vorgänge und die Wirkung von Automationen. Sie muss nicht jede Notiz selbst pflegen; sie muss aber sicherstellen, dass das Modell im Alltag funktioniert.
Reporting sollte mindestens offene Arbeit, Zeit je Status, Vorgänge ohne Owner, Übergänge und Endzustände zeigen. Eine hohe Zahl von Aktivitäten kann sogar ein Warnsignal sein, wenn daraus keine Statusänderung oder Entscheidung entsteht. Besprich monatlich einige Fälle und gleiche Dashboardwerte mit der Realität ab.
Ein Status ist eine Entscheidung, keine Farbe
Ein gutes Statusmodell hilft vor allem dann, wenn jemand den Vorgang übernimmt oder priorisiert. Der Status muss deshalb eine Aussage über die nächste Entscheidung enthalten. „Neu“ bedeutet: Der Vorgang ist noch nicht geprüft. „Qualifiziert“ bedeutet: Die Mindestinformationen liegen vor und ein konkreter nächster Schritt ist sinnvoll. „Angebot offen“ bedeutet: Eine Entscheidung des Gegenübers steht aus und es gibt eine definierte Wiedervorlage. Diese Aussagen sind enger als bloße Aktivitätsbeschreibungen.
Prüfe die Pipeline mit drei Arten von Fällen: einem einfachen Vorgang, einer Ausnahme und einem Vorgang ohne Antwort. Wenn das Modell nur den Standardfall abbildet, entstehen außerhalb der Mitte wieder Notizen und private Listen. Ein pausierter Vorgang braucht einen Grund und einen Zeitpunkt für die erneute Prüfung. Ein verlorener Vorgang braucht einen nachvollziehbaren Grund, damit das Reporting nicht nur „nein“ zählt. Ein gewonnener Vorgang braucht die Übergabe in Umsetzung oder Betreuung.
Die Einführung sollte an wenigen realen Fällen beginnen. Bitte nicht alle historischen Datensätze sofort umzubauen, sondern definiere eine Pilotgruppe und beobachte, ob Owner Statuswechsel zuverlässig pflegen. Nach zwei oder drei Arbeitszyklen werden Begriffe angepasst, die zu häufigen Rückfragen führen. Erst wenn das Modell verständlich ist, lohnt sich eine breitere Migration oder eine Automation der Statuspflege.
Prozessstatus und Reporting zusammenbringen
Ein Statusmodell dient nicht nur der täglichen Arbeit, sondern auch der späteren Auswertung. Wenn „gewonnen“ erst nach einer bestätigten Übergabe gesetzt wird, kann die Zahl mit dem tatsächlichen Geschäftsabschluss verbunden werden. Wenn „verloren“ einen Grund braucht, lassen sich Muster erkennen, ohne einzelne Mitarbeitende vorschnell zu bewerten. Wenn „pausiert“ ein Datum für die Wiederaufnahme enthält, bleibt der Bestand von aktiv offenen Vorgängen unterscheidbar.
Definiere diese Endzustände gemeinsam mit den Menschen, die daraus Entscheidungen ableiten. Vertrieb braucht vielleicht eine andere Detailtiefe als Umsetzung; beide müssen aber dieselben Kernzustände erkennen. Das CRM sollte nicht jedes interne Detail erzwingen. Es muss jedoch genug Kontext tragen, damit ein Vorgang übergeben, vertreten und ausgewertet werden kann.
Ein monatlicher Review kann wenige Fälle pro Status durchgehen: Ist der Eintritt gerechtfertigt? Wurde die Pflichtaktion erledigt? Ist der Austritt belegt? Gibt es Vorgänge, die nur wegen fehlender Pflege in einem Status liegen? Diese Prüfung verbessert die Definitionen und zeigt, welche Automationen wirklich helfen. Sie ersetzt nicht die Verantwortung des Teams, macht sie aber sichtbar.
Besonders hilfreich ist die Unterscheidung zwischen „wartet auf uns“ und „wartet auf die andere Seite“. Beide Vorgänge können offen sein, brauchen aber unterschiedliche Owner und Fristen. Ebenso sollte ein Statuswechsel nicht allein durch eine gesendete Nachricht ausgelöst werden, wenn noch keine Antwort oder Entscheidung vorliegt. Das Modell muss abbilden, was tatsächlich bekannt ist, nicht was jemand versucht hat.
Wenn Status, nächste Aktion und Ergebnis zusammenpassen, wird das CRM auch zur Grundlage für Verbesserungen außerhalb des Vertriebs. Experience erkennt, welche Informationen am Einstieg fehlen. Growth erkennt, welche Quellen zu tragfähigen Vorgängen führen. Die Administration kann Regeln und Berechtigungen gezielt pflegen. Genau dadurch bleibt die Architektur offen für weitere Artikel, Prozesse und redaktionelle Entscheidungen, ohne die Startmenge technisch zu begrenzen.
Fazit
Ein CRM wird erst dann wirksam, wenn Status und nächste Schritte für alle verständlich sind.
Wer zuerst den Ablauf definiert, nutzt vorhandene Software deutlich besser. Wer nur Datensätze sammelt, hat eine digitale Ablage, aber noch keinen Prozess.
Ein CRM wird erst dann wirksam, wenn Status und nächste Schritte für alle verständlich sind. Definiere Eintritt, Austritt, Owner, Frist und Pflichtaktion an echten Fällen und automatisiere erst danach. So wird aus einer digitalen Ablage ein Flow, der Arbeit sichtbar weiterführt.