Demo Training: was es abdecken sollte (und warum die meisten Teams den schweren Teil überspringen)

Diagnostiziere, bevor du trainierst: ist die Demo wirklich das Problem?

Wenn eine Demo-to-Close-Rate fällt, ist der Reflex, Demo Training zu buchen. Die Slides polieren, den Ablauf proben, die Übergänge coachen. Manchmal ist das richtig. Oft nicht, weil das Conversion-Problem nicht in der Demo entstanden ist.

Hier ist das unbequeme Muster, das ich beim Review von Calls immer wieder sehe. Die Demo selbst ist kompetent. Der Rep ist souverän, das Produkt sieht gut aus, das Tempo passt. Und trotzdem wird der Deal danach still. Wenn ich es zurückverfolge, liegt das Problem fast nie in den dreißig Minuten Screen-Share. Es liegt in den zwanzig Minuten davor: eine Discovery, die an der Oberfläche blieb, Pain, der benannt, aber nie entwickelt wurde, Impact, der nie zur Sprache kam. Der Rep ging mit einem halbfertigen Bild der Welt des Käufers in die Demo, und keine noch so polierte Darbietung gleicht das aus.

In meinem EU Sales Call Benchmark, 1.400+ ausgewertete Calls über 140+ B2B-SaaS- und AI-Unternehmen in Benelux und DACH, bewerten Demos im Schnitt 6,5 von 10. Das ist der höchste Wert aller Skills, die ich messe. Discovery bewertet 4,2. Die Lücke zwischen diesen zwei Zahlen ist der Ort, an dem die meisten Conversion-Probleme tatsächlich wohnen.

Die Demo ist die Kirsche auf der Torte. Wenn die Torte schlechte Discovery ist, behebt bessere Dekoration das nicht.

Bevor du dich also auf Demo Training festlegst, fahre die Diagnose: Hör dir fünf der jüngsten verlorenen Deals deines Teams an. In wie viel Prozent förderte die Discovery einen echten Impact auf Executive-Level zutage, eine Konsequenz, die der Käufer persönlich spürte, nicht nur ein Problem, das er abstrakt anerkannte? Liegt diese Zahl unter der Hälfte, beginne mit Discovery. Ist die Discovery durchgängig tief und die Demo konvertiert trotzdem nicht, dann hast du ein echtes Demo-Problem und Training wird etwas bewegen.

Die falsche Hälfte des Demo Trainings

Wenn Sales Leader sagen, sie wollen Demo Training, meinen sie meist, dass ihre Reps souveräner präsentieren, Einwände glatter behandeln und nicht mehr nach der Hälfte eines vierzigminütigen Feature-Durchlaufs den Raum verlieren sollen. Alles legitime Probleme. Keines davon das Hauptproblem.

Das Hauptproblem ist Selektion: Welche Teile des Produkts zeigst du, in welcher Reihenfolge, und wie verbindest du sie mit dem, was genau dieser Käufer dir vor einer halben Stunde oder vor zwei Wochen gesagt hat? Das ist der Skill, der eine Demo, die einen Deal bewegt, von einer trennt, die, in Robert Falcones deutlichen Worten, auf das Produkt statt auf den Käufer fokussiert ist. Teams haben ihre Demos geübt. Die Struktur ist da. Aber die Verbindung zwischen dem, was in der Discovery herauskam, und dem, was gezeigt wird, ist die Stelle, an der die Punkte verschwinden. Eine Demo, die bei der Darbietung gut und bei der Relevanz schlecht abschneidet, ist immer noch eine Produkttour mit besserer Beleuchtung.

Eine polierte Demo der falschen Sache ist immer noch die falsche Sache.

Die Szenen-Library: wie ein richtiges Demo-Playbook gebaut wird

Die praktische Antwort auf das Selektionsproblem ist eine Szenen-Library: ein Satz modularer, eigenständiger Demo-Einheiten, die Reps für jedes Gespräch je nach dem, was die Discovery ergeben hat, anders zusammenstellen können.

Jede Szene deckt einen konkreten Pain und die Features ab, die ihn adressieren. Was den Ansatz funktionieren lässt, ist, dass jede Szene für sich vollständig ist. Sie hat fünf Komponenten, die ich in einer Demo-Storyboard-Vorlage nutze, wenn ich mit Teams Playbooks baue:

1. Pain: das konkrete Problem, das diese Szene adressiert, in der Sprache des Käufers formuliert. Keine Feature-Kategorie, ein echter Reibungspunkt. "Du hast erwähnt, dass dein Ops-Team jeden Montag drei Stunden damit verbringt, Daten aus zwei Systemen zu ziehen" ist ein Pain. "Unser Reporting-Modul" ist keiner.

2. Impact: die Konsequenz dieses Pains, wenn er ungelöst bleibt. Das ist es, was die Szene dringlich statt informativ wirken lässt. Du benennst die Kosten, Zeit, Umsatz, Risiko oder eine persönliche Konsequenz für jemanden im Raum, bevor du das Produkt öffnest.

3. Features und wie man sie zeigt: die Demonstration selbst, mit konkreten, aufgeschriebenen Navigationsschritten. Nicht "zeig das Dashboard", sondern "öffne den Integrations-Tab, filtere nach Datenquelle, zeig den automatisierten Pull". Dieser Grad an Konkretheit trennt eine wiederholbare Szene von einem Rep, der es aus dem Gedächtnis macht. Eine Szene kann ein, zwei oder drei Features haben, nur so viele, wie der Pain rechtfertigt.

4. User Story: eine vergleichbare Kundensituation, die die Szene in etwas Echtem verankert. Konkret, nicht generisch. Eine Story über ein 40-Personen-SaaS-Unternehmen in Deutschland, dessen Ops-Lead jeden Montag drei Spreadsheets manuell abglich, ist für den richtigen Käufer glaubwürdig. Ein Slide mit fünfzig Logos ist es nicht. Der Käufer muss den Namen nicht erkennen, er muss das Problem erkennen.

5. Anker-Fragen: der Check-in, der die Szene abschließt und Informationen erzeugt. Richard Harris bringt es gut auf den Punkt: Ersetze "Ergibt das Sinn?" durch "Wie vergleicht sich das mit eurer aktuellen Arbeitsweise?" oder "Welcher Use Case kommt dir jetzt in den Sinn, wo du das gesehen hast?" Die Antwort sagt dir, ob du tiefer gehst oder weiterziehst.

Eine konkrete Szene für ein B2B-SaaS-Reporting-Tool könnte so aussehen:

Ein typisches Produkt hat genug Material für acht bis fünfzehn Szenen. Die meisten Demos nutzen drei oder vier. Welche du wählst, hängt vollständig davon ab, was die Discovery zutage gefördert hat. Dieser Selektionsmoment, vor deiner Szenen-Library zu stehen und zu wählen, ist der Skill, der fast nie trainiert wird.

Das Demo-Playbook ist kein festes Skript. Es ist eine Library, aus der du schöpfst, basierend auf dem, was der Käufer dir über seine Welt erzählt hat.

Warum Discovery und Demo getrennt bleiben sollten, und was zu tun ist, wenn es nicht geht

Die Architektur oben funktioniert nur, wenn du tatsächlich Discovery-Informationen hast, mit denen du arbeiten kannst. Das klingt offensichtlich. Es ist es offenbar nicht.

In meinen Call-Daten kombinieren mehr als die Hälfte der Teams, mit denen ich gearbeitet habe, Discovery und Demo in einem einzigen Meeting. Die Absicht ist Effizienz. Das Ergebnis ist, dass beide leiden. Wenn du durch die Fragen hetzt, um zum Produkt zu kommen, bekommst du oberflächliche Antworten. Wenn du im selben Call von Fragen auf Screen-Share wechselst, verlierst du den Moment, das Gehörte zu synthetisieren, bevor du entscheidest, was du zeigst.

Ich habe mir diese Aufteilung in den Zahlen angesehen. Impact-Discovery, das Verstehen von Kosten und Konsequenz des Problems, nicht nur seiner Existenz, passiert in 34% der Fälle in einem eigenständigen Discovery Call. In einem kombinierten Meeting fällt das auf 7%. Die Szenen, um die du deine Demo baust, sind nur so gut wie die Informationen, die sie auswählen.

Allerdings ist ein separater Discovery Call nicht immer möglich. Früher im Sales-Zyklus, niedrigerer ACV, Product-Led-Motion, es gibt Situationen, in denen du einen Call bekommst. Der Hybrid funktioniert, aber er verlangt echte Struktur: ein Hard Stop bei der Discovery, bevor du das Produkt öffnest, ein Moment der Synthese, in dem du dem Käufer sagst, was du zeigen wirst und warum, und die Verpflichtung, nur zu zeigen, was der erste Teil des Calls verdient hat. Die Reps, die das in meinen Daten gut machen, bewerten deutlich höher bei dem, was ich Tool-Demo nenne, die sichtbare Verbindung zwischen dem Besprochenen und dem Gezeigten. Die, die sich schwertun, sind nicht schlecht in der Demo; sie haben nur das Produkt geöffnet, bevor sie wussten, welches Problem sie lösen.

Was Demo Training tatsächlich aufbauen sollte

Mit dem Szenen-Library-Framework im Kopf deckt ein richtiges Demo Training fünf Dinge ab, ungefähr in dieser Reihenfolge:

1. Die Pre-Demo-Synthese-Gewohnheit. Bevor das Produkt sich öffnet, sollte der Rep, laut, und sei es nur für sich selbst, die zwei oder drei Probleme benennen können, die dieser Käufer genannt hat, die Konsequenz, sie nicht zu lösen, und die drei Szenen, die er daraufhin zeigen wird. Das dauert neunzig Sekunden. Die meisten Reps überspringen es. Es ist der Moment, der aus einer Standard-Demo eine relevante macht.

2. Die Szenen-Library bauen. Das ist die kollektive Arbeit, die das Team gemeinsam leistet, nicht etwas, das Einzelne improvisieren. Jeder wichtige Use Case und Stakeholder-Typ in deinem ICP sollte eine benannte Szene haben. Jede Szene wird auf die Probe gestellt: Kann ein Rep sie ohne Slides und mit einem Screen-Share liefern? Beginnt sie mit einem Problem-Statement, nicht mit einem Feature-Namen? Endet sie mit einer Frage, die Informationen erzeugt, nicht Applaus?

3. Sequencing-Regeln. Die Reihenfolge der Szenen ist nicht beliebig. Strukturelle Szenen (wie das Produkt organisiert ist, wer es administriert) kommen spät. Impact-Szenen (wo der Käufer das Problem am stärksten spürt) kommen zuerst. Multi-Stakeholder-Demos brauchen eine Sequencing-Logik danach, wer im Raum welchen Pain besitzt. Die Person zu finden, die den eigentlichen Prozess treibt, was ich als den Dominostein betrachte, und sie zuerst einzubinden, macht den Rest des Raums leichter.

4. Check-in-Disziplin. Eine Demo ohne Check-ins ist eine Präsentation. Check-ins sind nicht "ergibt das Sinn?", diese Frage hat eine Ja-Quote von 99% unabhängig vom Verständnis. Nützliche Check-ins sind diagnostisch: "Welcher Use Case kommt dir jetzt in den Sinn, wo du das gesehen hast?" oder "Wie würde das ändern, wie dein Team X an einem Montag handhabt?" Sie erzeugen Informationen, die dir helfen zu entscheiden, ob du tiefer gehst oder zur nächsten Szene wechselst.

5. Der Abschluss. Close Rates fallen, wenn am Ende der Demo keine nächsten Schritte besprochen werden. Dieser Befund überrascht nicht, aber der Fehler ist fast immer strukturell: Reps verbringen zu lange mit dem Produkt und haben keine Zeit mehr für den Abschluss. Die Szenen-Library hilft hier, denn wenn du weißt, dass du acht Szenen zur Verfügung hast und vier auswählen musst, baust du die Zeit am Ende bewusst ein, nicht zufällig.

Das Problem mit generischem Social Proof in Demos

Ein konsistentes Muster, das ich in Demo-Reviews sehe: Reps nutzen Logos für Glaubwürdigkeit und Käufer entwerten sie sofort. Der Grund ist einfach, ein Käufer schaut auf einen Slide mit Nike, Adidas und Zalando und denkt: Sind diese Unternehmen wie meines? Wenn nicht, überträgt sich der Social Proof nicht.

Ein szenenbasierter Ansatz löst das von Grund auf. Die Story jeder Szene sollte auf einen Kunden aus einer vergleichbaren Situation verweisen: ähnliche Unternehmensgröße, ähnlicher Pain, ähnliche Teamstruktur. Der Käufer muss den Namen nicht erkennen. Er muss das Problem erkennen. Eine Story über ein 60-Personen-SaaS-Team in Deutschland mit einer zweiköpfigen Ops-Funktion ist für diesen Käufer glaubwürdiger als eine global bekannte Marke in einem völlig anderen Sektor.

Warum Demo Training oft depriorisiert wird, und was das kostet

Das meiste Enablement-Investment in SaaS fließt in Prospecting und Onboarding. Demo Training bekommt Aufmerksamkeit, wenn die Conversion Rates sichtbar fallen. Das ist der falsche Auslöser. Wenn die Demo-to-Close-Rate zur Priorität wird, sind die Pipeline-Konsequenzen für das nächste Quartal bereits festgeschrieben.

Die nützlichere Intervention ist früher: Bewerte Demos regelmäßig, zähl sie nicht nur. Aus meiner Erfahrung mit über 1.400 ausgewerteten Calls ist die Lücke zwischen dem besten Demo-Performer eines Teams und seinem Median-Performer meist kein Talent, sondern dass der Top-Rep eine implizite, aus Erfahrung gebaute Szenen-Library hat, während alle anderen um ein gemeinsames Slide-Deck improvisieren. Diese Library explizit zu machen und den Rest des Teams darauf zu trainieren, verkürzt die Zeit, die das Schließen der Lücke braucht.

Eine Call-Review-Scorecard mit einem eigenen Demo-Abschnitt, der Tool-Relevanz, Szenenauswahl, Check-in-Qualität und Next-Step-Abschluss abdeckt, gibt dir den Frühindikator, bevor die Conversion Rate dir sagt, dass du zu spät bist.

Bau die Library, bevor die nächste Demo live geht

Das häufigste Ergebnis von Demo Training ohne Szenen-Library ist, dass Reps die Session verlassen und verstehen, wie eine gute Demo aussieht, und dann zum Slide-Deck zurückgehen, das sie immer genutzt haben. Die Szenen-Library ist das, was das Training hängenbleiben lässt: Sie ist ein konkretes Artefakt, das das ganze Team gemeinsam baut, gegen echte Käufersituationen testet und aktualisiert, wenn sich das Produkt ändert. Ohne sie verbessert Demo Training das Bewusstsein. Mit ihr ändert es, was auf dem Call tatsächlich passiert.

Wenn du verstehen willst, wo die Demos deines Teams Punkte verlieren, ob es das Discovery-Fundament, die Szenenauswahl oder der Abschluss ist, ist der Ausgangspunkt ein strukturiertes Call-Review, kein Trainingstag. Siehe auch: wie du deine Demo-to-Close-Conversion-Rate verbesserst und das Discovery-Call-Framework, das die Szenen speist.