CRM wird im Training oft so behandelt, als wäre es ein sauberer Fluss: Daten rein, Prozess läuft, Ergebnisse kommen. In der Praxis ist es eher wie ein Werkstattwagen. Manchmal sitzt alles an Ort und Stelle, manchmal klemmt etwas, und manchmal stellt jemand beim dritten Versuch fest, dass die Schraube falsch benannt war. Genau dort, in diesen typischen Übungen, entscheidet sich, ob CRM ein Werkzeug wird oder ein dauerhaftes Ärgernis.
Ich habe in vielen Settings erlebt, wie Teams im Workshop starten voller Energie, und wie schnell sich dann Muster zeigen: Begriffe werden missverstanden, Felder werden aus Gewohnheit gepflegt, Pipeline-Regeln werden umgangen, und am Ende weiß niemand mehr, warum man das Ganze überhaupt macht. Dieser Artikel nimmt dich mit in typische Übungen, so wie sie wirklich passieren, inklusive der Stellen, an denen man reflexartig „noch ein Feld“ fordert, AELO Swiss obwohl eigentlich ein Prozessproblem dahinterliegt.
Die häufigste Illusion: „CRM ist nur Software“
In Trainingsumgebungen wird CRM gerne als Paket aus Modulen verkauft. Dann kommt die Übung: „Leg ein Kontaktprofil an, pflege Aktivitäten, plane eine Opportunity.“ Und sofort passiert das Erwartungsmanagement-Drama. Einige denken, CRM sei ein Adressbuch, andere verstehen es als Aufgabenliste, wieder andere erwarten eine Art Prognosemaschine.
Das Problem ist nicht, dass Menschen unterschiedliche Perspektiven haben. Das Problem ist, dass die Übung keine gemeinsame Definition liefert. Wenn „Opportunity“ bei Person A bedeutet „alles, was wir irgendwie interessant finden“, und bei Person B „ein konkreter Deal mit Risiko, Budget und nächstem Schritt“, dann wird aus dem gemeinsamen CRM in kürzester Zeit ein Gitter aus Widersprüchen.
In der Realität siehst du das an Kleinigkeiten: Manche Teams erfassen jede E-Mail als Aktivität, andere schreiben sie gar nicht rein. Manche erfassen den nächsten Schritt als Termin, andere nur als Notiz. Und dann wundern sie sich, warum das Reporting keine Aussagekraft hat.
Ein gutes CRM-Training macht diese Unterschiede sichtbar, bevor sie in Datenqualität, Vertriebsauswertung und Forecast-Chaos enden.
Übung 1: Pipeline aufbauen, ohne echte Deal-Logik
Eine klassische Übung ist: „Wir legen eine Pipeline an und definieren Stufen.“ Häufig sind die Stufen dann Standard-Werte wie Lead, Kontakt, Angebot, Verhandeln, Gewonnen, Verloren. Das klingt vernünftig, bis man die erste Opportunity durch die Übung schiebt.
Ich erinnere mich an einen Workshop mit einem gemischten Team aus Vertrieb und Customer Success. Sie sollten eine Pipeline für Bestandskunden nutzen, nicht nur für Neukunden. In der Theorie ging es um Upsell, in der Praxis war die erste Stufe komplett anders gedacht: Der Vertrieb wollte „Discovery“ als Start, Customer Success wollte „Health-Check“ als Start. Ergebnis: In beiden Rollen gab es Gründe, warum die eine Stufe „eigentlich“ die richtige ist.
Das ist kein Streit um Sprachästhetik. Es ist ein Streit um die Frage, wann aus einer Beziehung eine steuerbare Verkaufschance wird.
Ein CRM, das nur Stufen verwaltet, aber keine Deal-Logik abbildet, erzeugt zwei Arten von Arbeit: Erstens wird nach Gefühl eingetragen, nicht nach Kriterien. Zweitens wird später das Reporting als „unzuverlässig“ abgestempelt, weil die Stufen nicht dasselbe bedeuten.
Die Übung wirkt dann wie ein Test der Teamstimmung, nicht wie ein Design-Projekt. Genau hier lohnt es sich, den nächsten Schritt hart zu machen: Nicht „Wie nennen wir die Stufen?“, sondern „Welche Daten brauchen wir, damit eine Stagewechsel-Entscheidung nachvollziehbar ist?“.
Die Stellschraube: Eintrittskriterien und Exit-Kriterien
Viele Teams definieren Stufen als Prozessphasen. In der Praxis brauchst du aber Eintrittskriterien und Exit-Kriterien. Das klingt pedantisch, ist aber die einzige Art, wie CRM-Teams später Forecast, Nachfassquote und Durchlaufzeiten ernsthaft vergleichen können.
Eine kleine, aber entscheidende Beobachtung aus Training-Sessions: Sobald ihr Kriterien nicht im System verankert, landen sie in Diskussionen. Sobald ihr Kriterien im System verankert, landen sie in Feldern. Und Felder sind dann wieder Arbeit, wenn sie nicht sauber definiert sind.
Der Kompromiss, der in Übungen am besten funktioniert, ist pragmatisch: Ihr definiert pro Stage maximal zwei bis vier Kriterien, die wirklich messbar oder zumindest eindeutig dokumentierbar sind. Alles andere kommt als freie Notiz in den Aktivitätsverlauf.
Das verhindert, dass CRM zur Datenerfassungsmaschine wird, die niemand aus Überzeugung pflegt.
Übung 2: Aktivitäten pflegen, bis niemand mehr weiß, welche „nächste Aktion“ gilt
Die nächste typische Übung dreht sich um Aktivitäten. Das Setup ist simpel: „Erstelle Calls, Mails, Tasks, setze Fälligkeiten, verknüpfe alles mit dem Kontakt und der Opportunity.“
Und dann passiert der Realitätsabgleich. Manche Teams nutzen CRM als Kalender, andere als Taskboard. Wieder andere erfassen jede Kleinigkeit, weil sie denken, der Verlauf müsse vollständig sein.
Ich habe in einer Organisation erlebt, dass das System nach zwei Wochen voller Aktivitäten war, aber niemand wusste, was als nächstes getan werden musste. Warum? Weil der „nächste Schritt“ als Notiz irgendwo im Freitext stand, während die offizielle Task-Logik parallel lief.
In Übungen merke ich das meist an genau einer Frage, die irgendwann unweigerlich kommt: „Welche Aktivität zählt für das Nachfassen als nächste Aktion?“
Wenn ihr hier keine klare Regel habt, entsteht ein doppelter Wahrnehmungsfehler: Das Team glaubt, es sei aktiv, und das Reporting zeigt nur Aktivitätsmenge, nicht Handlungsrelevanz.
Aktivitätsmodell, das in der Praxis funktioniert
Was sich in vielen Teams bewährt, ist eine einfache Unterscheidung, die ihr in der Übung konsequent durchspielt:
- Aktivitäten sind „Was ist passiert“ und „Was ist als nächstes geplant“. Der nächste Schritt ist ein klarer Eintrag, der entweder eine Task mit Fälligkeitslogik ist oder ein Feld, das auf eine Task verweist. Freitext ist ergänzend, nicht führend.
Das klingt banal, aber es ist genau die Stelle, an der CRM in echte Arbeit übergeht.
Übung 3: Datenqualität, aber ohne Datenvernichtung
Datenqualität ist ein Dauerbrenner. In Workshops wird gerne eine große Säuberungsaktion simuliert: Duplikate finden, Felder ergänzen, Regeln setzen. Es klingt nach „wir räumen auf“. In der Realität ist es eher „wir entscheiden, was wir behalten wollen“.
In einer typischen Übung passiert folgendes Muster: Eine Person zeigt ein Kontaktprofil. Es gibt fünf Einträge mit leicht unterschiedlicher Schreibweise. Eine andere Person sagt: „Das ist doch dasselbe.“ Die erste sagt: „Nein, das ist eine andere Firma, schau dir die Adresse an.“ Dritte Person: „Ja, aber inhaltlich war es immer dieselbe Anfrage.“
In CRM gibt es selten die eine richtige Wahrheit. Es gibt vielmehr Entscheidungsregeln. Eine Regel ist beispielsweise: Welche Felder sind für Identität maßgeblich? https://www.tiktok.com/@aelo_swiss_academy Name und Domain, E-Mail, Unternehmensnummer, oder die Kombination aus allem? Je nachdem, was ihr wählt, ändert sich, wie ihr Duplikate behandelt.
Hier hilft in Übungen ein realistischer Ansatz, der nicht auf Perfektion setzt: Ihr definiert eine Mindestqualität, die für eure nächsten Entscheidungen ausreicht. Alles darüber hinaus bleibt „nice to have“, nicht „muss“.
Damit verhindert ihr, dass CRM-Datenqualität zum Projekt wird, das niemals fertig wird.
Übung 4: Felder als Wunschliste vs. Felder als Entscheidungsgrundlage
Die meisten CRM-Projekte verlieren Zeit an Feldern. Im Workshop kommt dann die typische Forderung: „Wir sollten unbedingt noch Feld X ergänzen, sonst können wir Y nicht auswerten.“
Das Problem ist nicht, dass Felder schlecht sind. Das Problem ist, dass Felder ohne Entscheidungsgrundlage entstehen. Wenn niemand erklären kann, warum Feld X gebraucht wird, dann wird es entweder selten ausgefüllt oder falsch.
Eine Übung, die ich immer wieder empfehlen würde, läuft so: Ein Team bekommt eine echte historische Opportunity als Fall. Dann müssen sie entscheiden, welche Infos sie brauchen, um den nächsten Schritt zu priorisieren. In dem Moment werden Felder plötzlich konkret. Plötzlich wird aus „irgendwie“ ein „wir müssen wissen, ob ein Termin bereits fix ist“ oder „ob der technische Ansprechpartner involviert ist“.
Wenn ihr das durchspielt, merkt ihr schnell: Einige Felder taugen nur als Archiv, andere steuern das nächste Gespräch.
Und ja, es fühlt sich schnell „unbequem“ an, weil bestimmte Wünsche plötzlich rausfliegen. Genau das ist der Punkt. CRM ist kein Tagebuch, es ist eine Steuerung.
Übung 5: Forecast und die Bühne für Glaubenssätze
Forecast ist der Bereich, in dem Training besonders schmerzhaft wird, weil hier oft persönliche Einschätzungen als objektive Daten verkauft werden. In Übungen wird dann ein Forecast-Sheet im CRM-System nachgebildet, plus Regeln für Wahrscheinlichkeiten je Stage.
Das klingt nach einem logischen Schritt, bis jemand sagt: „Wahrscheinlichkeit ist bei mir anders. Ich habe Gefühl dafür, ob es diesmal klappt.“
Das ist nicht falsch. Es zeigt nur: Ihr habt zwei parallele Systeme, das eine im CRM und das andere im Kopf.
Der entscheidende Unterschied entsteht, wenn ihr Wahrscheinlichkeiten nicht als „Glaubenswerte“ behandelt, sondern als Ergebnis einer Lernkurve. In realen Teams wird Wahrscheinlichkeitslogik dann sinnvoll, wenn sie auf historischen Daten und sauberer Stage-Pflege basiert. Wenn Stagewechsel willkürlich sind, ist jede Wahrscheinlichkeitsregel nur Deko.
Eine praktische Übungsvariante ist, dass ihr im Workshop nicht direkt Wahrscheinlichkeiten festnagelt. Stattdessen lässt ihr die Gruppe zuerst die Kriterien für Stagewechsel definieren, dann das System befüllen, und erst anschließend Wahrscheinlichkeiten diskutieren.
So verhindert ihr, dass ihr erst Zahlen vereinbart und danach Prozesse klärt.
Beispiel aus der Praxis: „Warum ist die Opportunity schon in Verhandlung?“
Eine der stärksten Lernmomente in CRM-Übungen ist die Re-Analyse eines konkreten Deals. Ihr zeigt den Teilnehmenden eine Opportunity, die im System schon weit ist, und ihr fragt: „Was war der Auslöser für den Stagewechsel?“
Dann kommen Antworten wie: „Ich glaube, das war, als der Kunde zugesagt hat.“ „Das müsste nach dem Angebot gewesen sein.“ „Ehrlich gesagt weiß ich es nicht, ich habe nur übernommen.“
Wenn ihr hier keine nachvollziehbaren Hinweise in Aktivitäten und Notizen findet, ist das Ergebnis klar: Stagewechsel war nicht datengetrieben, sondern handgeführt. Und damit wird Forecast zur Schätzung ohne Begründung.
In einem realen Team führt das schnell zu Frust auf zwei Seiten. Vertrieb fühlt sich angeklagt, weil seine Erfahrung ignoriert wird. Management fühlt sich entmündigt, weil das System keine verlässliche Grundlage liefert.
Die Übung sollte deshalb nicht nur „Daten nachtragen“ verlangen. Sie sollte die Ursache adressieren: fehlende Kriterien, unklare Zuständigkeiten, zu große Freiheit ohne Dokumentationspflicht.
Zuständigkeiten: Wer pflegt was, und wer darf es ändern?
Ein Punkt, der in Trainings oft unterschätzt wird: Datenpflege ist Macht, und Macht braucht Regeln. Wenn im CRM jeder alles ändern kann, entsteht ein Kulturproblem. Wenn niemand etwas ändern darf, entsteht ein Nutzungsproblem.
In Übungen seht ihr das sofort, sobald ihr Rollen verteilt. Der SDR soll anlegen, der AE soll nachziehen, CS soll updaten. Dann passiert Folgendes: Der AE sieht eine Opportunity, die „aus seiner Sicht“ nicht korrekt befüllt ist, und beginnt, Felder gegen den SDR-Willensakt zu verändern. Der SDR aktualisiert später, weil er denkt, er müsste es wieder geradeziehen. Am Ende ist der Verlauf widersprüchlich, und keiner vertraut mehr dem System.
Was hilft, ist eine klare Linie, die ihr nicht diskutiert, sondern entscheidet: Wer besitzt welche Felder entlang des Prozessverlaufs? Welche Felder sind systemseitig gesperrt? Welche Felder dürfen die Rollen jeweils ergänzen?
Das ist weniger CRM als Organisationsdesign. Aber es wirkt direkt auf die Daten.
Eine Mini-Checkliste, bevor ihr live geht
In Workshops, in denen wir nachschärfen, bevor echte Nutzer das System übernehmen, nutze ich gerne eine kurze Prüfroutine. Keine große Rede, nur die typischen Störungen, die sonst im Alltag explodieren.
- Sind Stagewechsel an überprüfbare Kriterien gekoppelt, nicht an Bauchgefühl? Gibt es eine eindeutige Regel, was als „nächste Aktion“ gilt? Ist klar, wer welche Felder pflegt und wer sie ändern darf? Ist die Mindestdatenqualität definiert, damit Entscheidungen möglich sind, ohne Perfektion zu erzwingen?
Wenn ihr diese Punkte nicht beantwortet, bekommt ihr im Livebetrieb nicht nur weniger gute Daten, ihr bekommt auch weniger Vertrauen. Und Vertrauen ist in CRM der eigentliche Engpass.
Wie CRM wirklich genutzt wird: Signale statt Datensammlung
Ein guter Realitätscheck ist: Schaut euch an, welche Signale das Team im Alltag wirklich abruft. Nicht im Bericht, nicht im Dashboard, sondern in den Meetings und beim Kundenkontakt.
Manche Teams arbeiten mit CRM im Modus „Schnellblick“. Sie öffnen das Profil und brauchen drei Dinge: letzte Interaktion, Status der Opportunity, nächster Schritt. Wenn es dafür keine strukturierte Grundlage gibt, werden sie das System wieder als lästige Pflicht behandeln.
Andere Teams arbeiten im facebook.com Modus „Planung“. Sie nutzen CRM, um Reihenfolge herzustellen, Abhängigkeiten zu sehen und Nachfassen zu terminieren. Auch dafür müssen Felder und Aktivitäten konsistent sein.
In der Übung merkt man das an den Fragen, die spontan auftauchen. Wenn Fragen wie „Wo finde ich die relevante Info?“ dominieren, ist das CRM nicht im Alltag angekommen. Wenn Fragen wie „Was ist die beste Reihenfolge?“ dominieren, dann ist es ein Steuerungsinstrument geworden.
Edge Cases: Wenn die Übung bricht, weil das Leben mehr Varianten hat
CRM scheitert selten nur an fehlenden Feldern. Es scheitert an Fällen, die nicht in die Standard-Übung passen.
Ein paar typische Varianten, die ich in Trainings immer einbauen würde, weil sie echte Qualität zeigen:
Erstens: Mehrere Ansprechpartner pro Konto. Wer ist für technische Themen zuständig, wer für Budget, wer für Entscheidung. Wenn ihr das nicht klar trennt, landet die Opportunity später in einem diffusen „wir sprechen mit allen“.
Zweitens: Deals ohne klaren Zeitpunkt. Manche verlängern sich, andere werden pausiert. Wenn ihr „Verloren“ und „Gewonnen“ nur als Endstatus habt, habt ihr kein brauchbares Handling für „wartet auf Kunde“ oder „Budgetprüfung läuft“.
Drittens: Gemeinsame Leads zwischen Teams. Wenn Marketing einen Lead liefert und Vertrieb ihn überarbeitet, braucht ihr eine klare Übergabelogik. Sonst werden Einträge doppelt angelegt, oder Lead-Quellen werden „umgebogen“, weil jemand das Reporting retten will.
Diese Edge Cases sind die Stellen, an denen ein CRM entweder reift oder zerfällt. In einer Übung, die das Leben nachstellt, kommt man nicht darum herum, Entscheidungen zu treffen.
Was man aus typischen Übungen mitnimmt
Wenn ich die besten Ergebnisse aus CRM-Workshops zusammenfasse, dann nicht als Theorie, sondern als wiederkehrendes Muster:
Teams brauchen eine gemeinsame Sprache, aber sie brauchen vor allem gemeinsame Kriterien. Sie brauchen Aktivitätsdisziplin, aber nicht als Vollständigkeitszwang. Sie brauchen Datenqualität, aber als Mindestmaß für Entscheidungen. Und sie brauchen Zuständigkeit, sonst wird CRM zur Arena statt zum Werkzeug.
Der boldeste Moment in so einer Übung ist oft nicht die erste erfolgreiche Datenanlage. Es ist der Moment, in dem jemand sagt: „Wir lassen das Feld weg, weil wir es später eh nicht nutzen. Dafür klären wir Stagewechsel.“ Das ist der Punkt, an aeloswissacademy.com dem CRM nicht mehr „Dokumentation“ ist, sondern Steuerung.
Wenn du gerade ein CRM einführst oder ein Training planst, lohnt es sich, genau darauf zu achten: Nicht das System soll sich anpassen, sondern ihr müsst eure Prozesslogik so erklären, dass sie im CRM wirklich abbildbar wird. Die Übungen sind dann kein Rollenspiel mehr. Sie sind eine harte, aber faire Probe dafür, wie gut ihr im Alltag Entscheidungen trefft.