Demo Training: wat het zou moeten behandelen (en waarom de meeste teams het moeilijke deel overslaan)

Diagnosticeer voordat je traint: is de demo echt het probleem?

Als een demo-to-close-rate daalt, is de reflex om demo training te boeken. De slides polijsten, het verloop repeteren, de overgangen coachen. Soms is dat juist. Vaak niet, omdat het conversie-probleem niet in de demo is ontstaan.

Hier is het ongemakkelijke patroon dat ik bij het reviewen van calls steeds weer zie. De demo zelf is competent. De rep is zelfverzekerd, het product ziet er goed uit, het tempo klopt. En toch wordt de deal daarna stil. Als ik het terugvolg, ligt het probleem bijna nooit in de dertig minuten screen-share. Het ligt in de twintig minuten daarvoor: een discovery die aan de oppervlakte bleef, pain die werd benoemd maar nooit ontwikkeld, impact die nooit ter sprake kwam. De rep ging met een halfaf beeld van de wereld van de koper de demo in, en geen enkele gepolijste presentatie compenseert dat.

In mijn EU Sales Call Benchmark, 1.400+ geanalyseerde calls over 140+ B2B SaaS- en AI-bedrijven in Benelux en DACH, scoren demo's gemiddeld 6,5 van 10. Dat is de hoogste waarde van alle skills die ik meet. Discovery scoort 4,2. De gap tussen die twee cijfers is de plek waar de meeste conversie-problemen werkelijk wonen.

De demo is de kers op de taart. Als de taart slechte discovery is, lost betere decoratie dat niet op.

Voordat je je dus vastlegt op demo training, voer de diagnose uit: luister naar vijf van de recentste verloren deals van je team. In hoeveel procent bracht de discovery echte impact op executive-niveau naar boven, een consequentie die de koper persoonlijk voelde, niet alleen een probleem dat hij abstract erkende? Ligt dat cijfer onder de helft, begin dan met Discovery. Is de discovery consistent diep en converteert de demo toch niet, dan heb je een echt demo-probleem en zal training iets bewegen.

De verkeerde helft van demo training

Als sales leaders zeggen dat ze demo training willen, bedoelen ze meestal dat hun reps zelfverzekerder moeten presenteren, bezwaren soepeler moeten afhandelen en niet meer halverwege een veertig minuten durende feature-doorloop de zaal moeten verliezen. Allemaal legitieme problemen. Geen daarvan het hoofdprobleem.

Het hoofdprobleem is selectie: welke delen van het product laat je zien, in welke volgorde, en hoe verbind je die met wat precies deze koper je een half uur of twee weken geleden heeft verteld? Dat is de skill die een demo die een deal beweegt scheidt van een demo die, in Robert Falcones heldere woorden, op het product in plaats van op de koper is gericht. Teams hebben hun demo's geoefend. De structuur is er. Maar de verbinding tussen wat in de discovery naar boven kwam en wat wordt getoond, is de plek waar de punten verdwijnen. Een demo die goed scoort op presentatie en slecht op relevantie, is nog steeds een producttour met betere verlichting.

Een gepolijste demo van het verkeerde ding is nog steeds het verkeerde ding.

De scène-library: hoe een echt demo-playbook wordt gebouwd

Het praktische antwoord op het selectieprobleem is een scène-library: een set modulaire, zelfstandige demo-eenheden die reps voor elk gesprek anders kunnen samenstellen, afhankelijk van wat de discovery heeft opgeleverd.

Elke scène dekt een concrete pain en de features die hem adresseren. Wat de aanpak laat werken, is dat elke scène op zichzelf compleet is. Hij heeft vijf componenten die ik gebruik in een demo-storyboard-template wanneer ik met teams playbooks bouw:

1. Pain: het concrete probleem dat deze scène adresseert, geformuleerd in de taal van de koper. Geen feature-categorie, een echt wrijvingspunt. "Je noemde dat je ops-team elke maandag drie uur besteedt aan het trekken van data uit twee systemen" is een pain. "Onze reporting-module" is er geen.

2. Impact: de consequentie van deze pain als hij onopgelost blijft. Dat is wat de scène urgent laat aanvoelen in plaats van informatief. Je benoemt de kosten, tijd, omzet, risico of een persoonlijke consequentie voor iemand in de ruimte, voordat je het product opent.

3. Features en hoe je ze toont: de demonstratie zelf, met concrete, uitgeschreven navigatiestappen. Niet "laat het dashboard zien", maar "open de integratie-tab, filter op databron, toon de geautomatiseerde pull". Die mate van concreetheid scheidt een herhaalbare scène van een rep die het uit het geheugen doet. Een scène kan één, twee of drie features hebben, alleen zoveel als de pain rechtvaardigt.

4. User story: een vergelijkbare klantsituatie die de scène verankert in iets echts. Concreet, niet generiek. Een story over een SaaS-bedrijf van 40 personen in Duitsland, waarvan de ops-lead elke maandag drie spreadsheets handmatig afstemde, is geloofwaardig voor de juiste koper. Een slide met vijftig logo's is dat niet. De koper hoeft de naam niet te herkennen, hij moet het probleem herkennen.

5. Anker-vragen: de check-in die de scène afsluit en informatie oplevert. Richard Harris verwoordt het goed: vervang "Klinkt dat logisch?" door "Hoe verhoudt zich dit tot jullie huidige werkwijze?" of "Welke use case komt nu bij je op, nu je dit hebt gezien?" Het antwoord vertelt je of je dieper gaat of doorschuift.

Een concrete scène voor een B2B SaaS-reporting-tool zou er zo uit kunnen zien:

Een typisch product heeft genoeg materiaal voor acht tot vijftien scènes. De meeste demo's gebruiken er drie of vier. Welke je kiest, hangt volledig af van wat de discovery naar boven heeft gebracht. Dat selectiemoment, voor je scène-library staan en kiezen, is de skill die bijna nooit wordt getraind.

Het demo-playbook is geen vast script. Het is een library waaruit je put, op basis van wat de koper je over zijn wereld heeft verteld.

Waarom discovery en demo gescheiden zouden moeten blijven, en wat te doen als dat niet lukt

De architectuur hierboven werkt alleen als je daadwerkelijk discovery-informatie hebt om mee te werken. Dat klinkt vanzelfsprekend. Dat is het blijkbaar niet.

In mijn call-data combineert meer dan de helft van de teams waarmee ik heb gewerkt discovery en demo in één enkele meeting. De bedoeling is efficiëntie. Het resultaat is dat beide eronder lijden. Als je door de vragen jaagt om bij het product te komen, krijg je oppervlakkige antwoorden. Als je in dezelfde call van vragen naar screen-share overschakelt, verlies je het moment om het gehoorde te synthetiseren voordat je beslist wat je toont.

Ik heb naar die opsplitsing in de cijfers gekeken. Impact-discovery, het begrijpen van kosten en consequentie van het probleem, niet alleen van zijn bestaan, gebeurt in 34% van de gevallen in een zelfstandige discovery call. In een gecombineerde meeting daalt dat naar 7%. De scènes waaromheen je je demo bouwt, zijn alleen zo goed als de informatie die ze selecteert.

Toch is een aparte discovery call niet altijd mogelijk. Vroeger in de salescyclus, lagere ACV, product-led motion, er zijn situaties waarin je één call krijgt. De hybride werkt, maar hij vraagt echte structuur: een hard stop bij de discovery voordat je het product opent, een moment van synthese waarin je de koper vertelt wat je gaat tonen en waarom, en de verplichting om alleen te tonen wat het eerste deel van de call heeft verdiend. De reps die dit in mijn data goed doen, scoren duidelijk hoger op wat ik tool-demo noem, de zichtbare verbinding tussen het besprokene en het getoonde. Degenen die het moeilijk hebben, zijn niet slecht in de demo; ze hebben alleen het product geopend voordat ze wisten welk probleem ze oplossen.

Wat demo training werkelijk zou moeten opbouwen

Met het scène-library-framework in gedachten dekt een goede demo training vijf dingen, ongeveer in deze volgorde:

1. De pre-demo-synthese-gewoonte. Voordat het product opengaat, zou de rep hardop, al is het maar voor zichzelf, de twee of drie problemen moeten kunnen benoemen die deze koper heeft genoemd, de consequentie van het niet oplossen ervan, en de drie scènes die hij daarop gaat tonen. Dat duurt negentig seconden. De meeste reps slaan het over. Het is het moment dat van een standaard demo een relevante maakt.

2. De scène-library bouwen. Dat is het collectieve werk dat het team samen doet, niet iets dat individuen improviseren. Elke belangrijke use case en stakeholder-type in je ICP zou een benoemde scène moeten hebben. Elke scène wordt op de proef gesteld: kan een rep hem leveren zonder slides en met één screen-share? Begint hij met een probleemstelling, niet met een feature-naam? Eindigt hij met een vraag die informatie oplevert, geen applaus?

3. Sequencing-regels. De volgorde van de scènes is niet willekeurig. Structurele scènes (hoe het product is georganiseerd, wie het beheert) komen laat. Impact-scènes (waar de koper het probleem het sterkst voelt) komen eerst. Multi-stakeholder-demo's hebben een sequencing-logica nodig op basis van wie in de ruimte welke pain bezit. De persoon vinden die het eigenlijke proces aanjaagt, wat ik als de dominosteen beschouw, en hem als eerste betrekken, maakt de rest van de ruimte makkelijker.

4. Check-in-discipline. Een demo zonder check-ins is een presentatie. Check-ins zijn niet "klinkt dat logisch?", die vraag heeft een ja-percentage van 99% ongeacht het begrip. Nuttige check-ins zijn diagnostisch: "Welke use case komt nu bij je op, nu je dit hebt gezien?" of "Hoe zou dit veranderen hoe je team X op een maandag aanpakt?" Ze leveren informatie op die je helpt beslissen of je dieper gaat of naar de volgende scène wisselt.

5. De afsluiting. Close rates dalen wanneer aan het einde van de demo geen volgende stappen worden besproken. Die bevinding verrast niet, maar de fout is bijna altijd structureel: reps besteden te lang aan het product en hebben geen tijd meer voor de afsluiting. De scène-library helpt hier, want als je weet dat je acht scènes tot je beschikking hebt en er vier moet kiezen, bouw je de tijd aan het einde bewust in, niet toevallig.

Het probleem met generieke social proof in demo's

Een consistent patroon dat ik in demo-reviews zie: reps gebruiken logo's voor geloofwaardigheid en kopers devalueren ze onmiddellijk. De reden is simpel, een koper kijkt naar een slide met Nike, Adidas en Zalando en denkt: zijn deze bedrijven zoals het mijne? Zo niet, dan draagt de social proof niet over.

Een scène-gebaseerde aanpak lost dat vanaf de basis op. De story van elke scène zou moeten verwijzen naar een klant uit een vergelijkbare situatie: vergelijkbare bedrijfsgrootte, vergelijkbare pain, vergelijkbare teamstructuur. De koper hoeft de naam niet te herkennen. Hij moet het probleem herkennen. Een story over een SaaS-team van 60 personen in Duitsland met een ops-functie van twee mensen is voor deze koper geloofwaardiger dan een wereldwijd bekend merk in een compleet andere sector.

Waarom demo training vaak wordt gedeprioriteerd, en wat dat kost

De meeste enablement-investering in SaaS gaat naar prospecting en onboarding. Demo training krijgt aandacht wanneer de conversion rates zichtbaar dalen. Dat is de verkeerde trigger. Wanneer de demo-to-close-rate een prioriteit wordt, liggen de pipeline-consequenties voor het volgende kwartaal al vast.

De nuttigere interventie is eerder: beoordeel demo's regelmatig, tel ze niet alleen. Uit mijn ervaring met meer dan 1.400 geanalyseerde calls is de gap tussen de beste demo-performer van een team en zijn mediane performer meestal geen talent, maar dat de top-rep een impliciete, uit ervaring gebouwde scène-library heeft, terwijl alle anderen improviseren rond een gedeeld slide-deck. Die library expliciet maken en de rest van het team erop trainen, verkort de tijd die het dichten van de gap kost.

Eine Call-review-scorecard met een eigen demo-sectie die tool-relevantie, scèneselectie, check-in-kwaliteit en next-step-afsluiting dekt, geeft je de vroege indicator voordat de conversion rate je vertelt dat je te laat bent.

Bouw de library voordat de volgende demo live gaat

Het meest voorkomende resultaat van demo training zonder scène-library is dat reps de sessie verlaten met begrip van hoe een goede demo eruitziet, en dan teruggaan naar het slide-deck dat ze altijd hebben gebruikt. De scène-library is wat de training laat beklijven: het is een concreet artefact dat het hele team samen bouwt, test tegen echte kopersituaties en bijwerkt wanneer het product verandert. Zonder haar verbetert demo training het bewustzijn. Met haar verandert het wat er op de call werkelijk gebeurt.

Als je wilt begrijpen waar de demo's van je team punten verliezen, of het nu het discovery-fundament, de scèneselectie of de afsluiting is, dan is het startpunt een gestructureerde call-review, geen trainingsdag. Zie ook: hoe je je demo-to-close-conversion-rate verbetert und das Discovery-call-framework, dat de scènes voedt.