Meetings in Salesforce-Projekten: Struktur statt Zeitverschwendung

Meetings, die kein Salesforce-Projekt braucht

Requirement Workshop ohne Agenda. Sprint Review, bei dem niemand weiß, was reviewed wird. Go-Live Readiness Check, der zum Kaffeeklatsch verkommt. Ich habe in zehn Jahren Salesforce-Consulting hunderte solcher Meetings erlebt. Und jedes einzelne war vermeidbar.

Salesforce-Projekte scheitern selten an der Technik. Sie scheitern an Meetings, in denen Entscheidungen vertagt, Anforderungen verwässert und Timelines ignoriert werden. In diesem Artikel zeige ich Ihnen die Meeting-Formate, die in CRM-Projekten tatsächlich Ergebnisse bringen, und wie Sie jedes einzelne so aufsetzen, dass es seinen Zweck erfüllt.

Warum Meetings in CRM-Projekten anders laufen

Salesforce-Projekte haben eine Eigenschaft, die sie von klassischer Softwareentwicklung unterscheidet: Die Fachbereiche sitzen mit am Tisch. Vertrieb, Service, Marketing. Menschen, die keine User Stories schreiben und keine Sprintlogik kennen. Aber deren Prozesse Sie in Salesforce abbilden sollen.

Das bedeutet: Jedes Meeting in einem CRM-Projekt ist gleichzeitig ein Übersetzungsproblem. Sie übersetzen zwischen Business-Sprache und technischer Umsetzung. Zwischen dem, was der Vertriebsleiter meint, und dem, was in einem Flow oder einer Validation Rule landen muss.

Wer diesen Kontext ignoriert und Standard-Scrum-Meetings aus dem Lehrbuch anwendet, verliert die Stakeholder nach zwei Wochen. Die Fachbereiche verstehen die Velocity nicht, die Acceptance Criteria klingen wie Fremdsprache, und am Ende liefern Sie eine Org ab, die technisch sauber ist und trotzdem niemand nutzt.

Die fünf Meeting-Typen, die jedes Salesforce-Projekt braucht

Nach Jahren an CRM-Projekten habe ich die Meetinglandschaft auf fünf Formate reduziert. Nicht mehr, nicht weniger. Jedes hat einen klaren Zweck, eine klare Struktur und ein klares Ergebnis.

1. Requirement Workshop

Zweck: Anforderungen erheben und sofort in umsetzbare Einheiten übersetzen.

Der Requirement Workshop ist das wichtigste Meeting im gesamten Projekt. Hier entscheidet sich, ob Sie drei Monate später liefern, was der Kunde braucht, oder was Sie verstanden haben. Das sind zwei verschiedene Dinge.

Mein Setup für Requirement Workshops:

Max. 90 Minuten. Danach sinkt die Qualität der Anforderungen messbar. Lieber zwei Sessions als eine Marathonsitzung.
Prozess vor Feature. Ich starte nie mit "Was brauchen Sie in Salesforce?" sondern mit "Zeigen Sie mir Ihren aktuellen Prozess Schritt für Schritt." Der Unterschied ist enorm.
Live dokumentieren. Ich teile meinen Bildschirm und schreibe die Anforderungen direkt in ein strukturiertes Dokument. Der Kunde sieht sofort, was ich verstanden habe, und korrigiert in Echtzeit.
Entscheidungen erzwingen. Wenn eine Anforderung unklar ist, stelle ich die Frage sofort. Kein "Das klären wir offline". Offline wird nichts geklärt.

💡

Mein wichtigstes Werkzeug im Requirement Workshop: Prozessdiagramme. Ich skizziere den Prozess live als Flowchart. Sobald der Kunde seinen Prozess visuell sieht, fallen ihm Lücken auf, die er verbal nie erwähnt hätte.

2. Sprint Review (Demo-Session)

Zweck: Gebaute Funktionalität zeigen und Feedback einsammeln.

Sprint Reviews in Salesforce-Projekten haben ein Problem: Sie zeigen Konfiguration, keine Software. Für den Kunden sieht ein neues Page Layout oder ein angepasster Flow nicht beeindruckend aus. Es sind keine Animationen, keine Wow-Effekte. Trotzdem muss der Kunde verstehen, was sich verändert hat und warum.

Was funktioniert:

Szenario-basiert demonstrieren. Nicht: "Ich habe ein neues Feld auf dem Account." Sondern: "Frau Müller aus dem Vertrieb öffnet morgens ihren Account und sieht sofort den Umsatz der letzten 12 Monate." Erzählen Sie die Geschichte des Users.
Vorher/Nachher zeigen. Screenshot vom alten Zustand, dann Live-Demo des neuen. Der Kontrast macht den Wert sichtbar.
Feedback sofort kategorisieren. Ich nutze drei Kategorien: Bug, Change Request, Nice-to-have. Wenn der Kunde sagt "Kann man das Feld nicht woanders hinpacken?", ordne ich das sofort ein. Das verhindert Scope Creep.

⚠️

Häufiger Fehler: Sprint Reviews nur mit dem Projektleiter des Kunden durchführen. Die Endanwender müssen dabei sein. Sonst bauen Sie eine Org für den Projektleiter, nicht für die Menschen, die täglich damit arbeiten.

3. UAT-Session (User Acceptance Testing)

Zweck: Endanwender testen die Lösung und geben strukturiertes Feedback.

UAT-Sessions sind der Moment der Wahrheit. Hier treffen Ihre technische Lösung und die Realität des Kunden aufeinander. Und die Realität gewinnt immer.

So strukturiere ich UAT-Sessions:

Testszenarien vorbereiten. Ich schreibe für jeden Tester 3-5 konkrete Szenarien auf: "Legen Sie einen neuen Lead an mit diesen Daten. Konvertieren Sie ihn. Was passiert?" Keine Freitext-Tests.
Beobachten, nicht erklären. Wenn der Tester nicht weiß, wo er klicken soll, ist das kein Schulungsproblem. Das ist ein UX-Problem. Ich notiere jede Stelle, an der jemand zögert.
Feedback direkt erfassen. Jedes Issue bekommt sofort eine Priorität: Blocker, Major, Minor. Blocker werden vor Go-Live gefixt, der Rest kommt auf die Roadmap.
Session aufzeichnen. Mit Einverständnis. Sie glauben nicht, wie oft ein Kunde nach dem Go-Live sagt: "Das haben wir anders besprochen." Das Recording ist Ihre Versicherung.

4. Steering Committee

Zweck: Projektentscheidungen auf Management-Ebene treffen.

Das Steering Committee ist das Meeting, das die meisten Salesforce-Berater falsch angehen. Sie präsentieren Projektstatusfolien. Ampelfarben. Meilensteine. Das Management nickt ab. Und die echten Probleme werden nicht besprochen.

Mein Ansatz:

Entscheidungsvorlage statt Statusbericht. Jedes Steering Committee hat genau einen Zweck: Entscheidungen treffen, die das Projektteam nicht treffen kann. Budget-Freigaben, Scope-Änderungen, Rollout-Strategie. Wenn keine Entscheidung ansteht, fällt das Meeting aus.
Max. 30 Minuten. Executives haben keine Stunde für Ihren Projektstatus. Kommen Sie auf den Punkt.
Risiken nach vorne. Ich starte mit den Risiken und Blocker, nicht mit den Erfolgen. Das Management braucht keine Bestätigung, dass alles läuft. Es braucht Informationen, wo es eingreifen muss.

📬

Dieser Artikel gefällt Ihnen? Jeden Dienstag teile ich Praxiswissen zu Salesforce, CRM und Automatisierung. Kostenlos per Newsletter.

5. Go-Live Readiness Meeting

Zweck: Finale Entscheidung: Gehen wir live oder nicht?

Das Go-Live Readiness Meeting ist das Meeting, das über Erfolg oder Desaster entscheidet. Ich habe Projekte erlebt, die trotz offener Blocker live gegangen sind, weil niemand den Mut hatte, den Termin zu verschieben. Und ich habe Projekte erlebt, die unnötig verschoben wurden, weil die Checkliste nicht grün genug war.

Meine Go-Live Readiness Checkliste:

Datenqualität: Sind die migrierten Daten geprüft? Stimmen Account-Hierarchien, Kontaktzuordnungen, historische Opportunities?
Integrationen: Laufen alle Schnittstellen stabil? E-Mail, ERP, Marketing Automation?
User Readiness: Wurden alle Anwender geschult? Kennen sie ihre Dashboards, ihre Queues, ihre Prozesse?
Rollback-Plan: Wenn alles schiefgeht: Was ist Plan B? Wie schnell können wir zurück?
Support-Struktur: Wer ist in Woche 1 nach Go-Live erreichbar? Gibt es einen dedizierten Kanal für Problemmeldungen?

💡

Meine Regel: Wenn auch nur ein Blocker offen ist, gehen wir nicht live. Keine Ausnahmen. Das ist manchmal unbequem, aber es schützt das Projekt und Ihre Reputation als Berater.

Drei Regeln für jedes Meeting in Salesforce-Projekten

Unabhängig vom Format gibt es drei Prinzipien, die ich in jedem CRM-Projekt durchsetze:

Regel 1: Jedes Meeting hat ein definiertes Ergebnis

Nicht "Wir besprechen das Thema Leads", sondern "Am Ende dieses Meetings haben wir: die Lead-Qualifizierungskriterien definiert, die Routing-Regeln festgelegt und die Conversion-Felder bestimmt." Wenn Sie das Ergebnis nicht in einem Satz formulieren können, ist das Meeting nicht reif.

Regel 2: Die richtigen Personen, nicht alle Personen

Ein Requirement Workshop mit zwölf Teilnehmern ist kein Workshop, sondern eine Konferenz. Ich lade maximal sechs Personen ein: den Process Owner, 2-3 Key User und den technischen Ansprechpartner. Alle anderen bekommen das Protokoll.

Regel 3: Dokumentation in 24 Stunden

Jedes Meeting-Ergebnis wird innerhalb von 24 Stunden dokumentiert und an alle Beteiligten geschickt. Nicht als Protokoll mit Zeitstempeln, sondern als Liste von Entscheidungen und offenen Punkten mit Verantwortlichkeiten. Wer diese Regel nicht einhält, verliert die Kontrolle über das Projekt.

Häufige Fragen

Wie gehe ich mit Stakeholdern um, die jedes Meeting dominieren?

Direkt ansprechen, aber nicht im Meeting selbst. Ich nehme dominante Stakeholder nach dem Meeting zur Seite und sage: "Ihre Beiträge sind wertvoll. Aber ich brauche auch die Perspektive der anderen Teilnehmer. Können wir einen Modus finden, bei dem alle zu Wort kommen?" In der Praxis funktioniert es gut, gezielt andere Teilnehmer mit Namen anzusprechen: "Herr Schmidt, wie läuft das in Ihrem Team?"

Remote oder vor Ort: Was funktioniert besser für Salesforce-Workshops?

Requirement Workshops funktionieren vor Ort besser. Die Dynamik, das Whiteboard, die Möglichkeit, spontan den Bildschirm eines Users anzuschauen. Sprint Reviews und UAT-Sessions funktionieren remote hervorragend, weil ohnehin am Bildschirm gearbeitet wird. Steering Committees sind remote effizienter, weil Executives ungern eine Stunde Anfahrt für 30 Minuten Meeting investieren.

Was tun, wenn der Kunde keine Entscheidungen im Meeting trifft?

Das ist das häufigste Problem in CRM-Projekten. Mein Ansatz: Ich setze eine Deadline. "Wenn bis Freitag keine Entscheidung zum Lead-Routing vorliegt, implementiere ich Variante A, weil sie dem Best Practice entspricht." Das erzeugt Handlungsdruck, ohne konfrontativ zu sein. In 90% der Fälle kommt die Entscheidung vor Freitag.

Wie viele Meetings pro Woche sind in einem Salesforce-Projekt normal?

In der aktiven Implementierungsphase: 3-4 pro Woche. Ein Daily Standup (15 Minuten, nur das Projektteam), ein bis zwei Workshops mit dem Fachbereich, und einmal pro Sprint ein Review. Das Steering Committee findet alle zwei Wochen statt. Mehr als fünf Meetings pro Woche sind ein Warnsignal, dass Zuständigkeiten unklar sind.

Struktur schlägt Talent

Die besten Salesforce-Berater, die ich kenne, sind nicht die mit den meisten Zertifizierungen. Es sind die, die Meetings so führen, dass Entscheidungen fallen, Anforderungen klar werden und Projekte Fahrt aufnehmen.

Gute Meeting-Strukturen sind kein Nice-to-have in CRM-Projekten. Sie sind die Grundlage dafür, dass die technische Arbeit überhaupt sinnvoll stattfinden kann. Denn die beste Flow-Automatisierung bringt nichts, wenn die Anforderung auf einem Missverständnis basiert, das in einem chaotischen Workshop entstanden ist.

Nehmen Sie die fünf Formate aus diesem Artikel und wenden Sie sie in Ihrem nächsten Projekt an. Nicht alle auf einmal. Starten Sie mit dem Requirement Workshop. Wenn der sauber läuft, folgt der Rest von allein.

Wenn Sie gerade ein Salesforce-Projekt planen oder mitten in der Umsetzung stecken und merken, dass die Meetings nicht die Ergebnisse liefern, die Sie brauchen: Ich unterstütze Sie gerne. Ob als externer Projektberater, der die Workshop-Strukturen aufsetzt, oder als Sparringspartner für Ihr internes Team. Melden Sie sich, und wir schauen gemeinsam, wo der Hebel liegt.

Jetzt Kontakt aufnehmen