Een demo voorbereiden met één echte klantvraag

Een rondleiding door alle functies dwingt de prospect om zelf te vertalen wat hij ziet naar zijn eigen werk. Met één werksituatie als uitgangspunt draai je dat om: jij laat zien hoe je aanpak met een herkenbaar probleem omgaat, en de prospect beoordeelt of dat klopt.

Een bruikbare werksituatie is concreet en afgebakend. 'Een offerteaanvraag via het contactformulier komt binnen en moet binnen een werkdag beantwoord zijn' is een situatie. 'Betere marketing' is dat niet. Kies er één, hooguit twee. Meer verwatert de demo weer tot een rondleiding.

Let op wat dit niet doet. Een demo rond één situatie toont niet alles, en dat is de bedoeling. Spreek vooraf af dat andere onderwerpen in een vervolggesprek komen, zodat niemand zich afgescheept voelt. En maak geen beloftes over wat de prospect na de demo zal bereiken: je toont een werkwijze, geen garantie.

De werksituatie moet je vóór de demo kennen, en het aanvraagformulier is daarvoor de logische plek. De cursus over formulieren van web.dev behandelt onder meer hoe je gebruikers helpt de juiste gegevens in te vullen en hoe je formulieren test (web.dev: Learn Forms). Gebruik dat als technische basis, en lees de bron zelf voor de precieze implementatie.

Praktisch betekent dit voor jouw formulier: houd het kort, want de W3C-tutorial over formulieren benadrukt dat gebruikers meestal korte, eenvoudige formulieren verkiezen en eerder afhaken als er overbodige gegevens worden gevraagd (W3C WAI: Forms tutorial). Vraag dus alleen wat je nodig hebt om de demo voor te bereiden. Gebruik zichtbare labels bij elk veld, groepeer samenhangende velden en zet instructies bij de velden waar ze nodig zijn. Volgens de W3C-tutorial helpt dit iedereen, onder meer mensen met cognitieve beperkingen, mensen die spraakinvoer gebruiken en mensen die een schermlezer gebruiken.

Een open veld voor de werksituatie geeft meer dan een keuzelijst, omdat prospects hun probleem in eigen woorden beschrijven. Vraag er expliciet bij geen namen of persoonsgegevens van klanten of collega's in te vullen. Combineer dat met één gesloten vraag, bijvoorbeeld hoe vaak de situatie voorkomt, zodat je het gewicht ervan kunt inschatten.

Kun je bij twee of meer criteria alleen de rechterkolom invullen, vraag dan een tweede gesprek van tien minuten om de situatie scherper te krijgen, nog voor je de demo bouwt. Een scherpe vraag levert een betere demo op dan extra voorbereidingstijd op een vage vraag.

Een aanvraag die half binnenkomt, kost je een extra mailwisseling. MDN legt uit dat clientzijdige validatie helpt om te controleren dat verplichte velden zijn ingevuld en dat de gegevens in het verwachte formaat staan, maar dat ze geen volledige beveiliging is en dat je gegevens altijd ook op de server moet controleren (MDN: Client-side form validation). Dat onderscheid doet ertoe: gebruik validatie voor gebruiksgemak, niet als enige verdediging.

Voor een demoformulier betekent dat: markeer alleen de velden echt verplicht die je nodig hebt (e-mailadres, werksituatie), geef een duidelijke foutmelding bij het veld zelf en zeg wat de bezoeker moet aanpassen. Bevestig na verzenden dat de aanvraag is aangekomen en wat er daarna gebeurt, zonder een specifieke antwoordtermijn te beloven die je niet kunt waarmaken.

Laat de W3C-tutorial je ook helpen bij meerstapsformulieren: heb je meer vragen dan past op één scherm, splits ze dan in logische stappen en toon de voortgang. Voor een demoaanvraag is één scherm doorgaans beter.

Stel dat een prospect via het formulier de volgende werksituatie invult. Dit is een verzonnen voorbeeld om de procedure te tonen, zonder bedrijfsnaam en zonder resultaten.

• Ingevulde situatie: 'Aanvragen via ons contactformulier belanden in een gedeelde mailbox, en niemand weet wie ze opvolgt.'
• Frequentie (gesloten vraag): meerdere keren per week.
• Jouw herformulering voor de demo: 'Een nieuwe aanvraag komt binnen en iemand moet duidelijk zien dat hij hem moet opvolgen.'
• Demoscript: (1) toon het formulier waarmee de aanvraag binnenkomt; (2) toon waar de aanvraag daarna terechtkomt; (3) toon hoe zichtbaar wordt wie hem oppakt; (4) vraag de prospect wat in zijn eigen werkwijze anders zou lopen.
• Wat je bewust niet toont: rapportages, integraties en andere functies, tenzij de prospect erom vraagt.
• Controle achteraf: heeft de prospect met eigen woorden kunnen zeggen of de situatie opgelost werd, ja of nee?

Merk op dat het script de vraag van de prospect centraal zet en eindigt met een toetsvraag. Dat maakt de demo een gesprek in plaats van een presentatie.

Evalueer elke demo kort met drie vragen. Eén: kon de prospect de situatie in eigen woorden herhalen en zei hij of ze opgelost werd? Twee: welk deel van de situatie bleef open? Drie: welke velden in je formulier zouden die informatie eerder hebben opgeleverd? Pas het formulier alleen aan als hetzelfde probleem zich herhaalt, niet na elke afzonderlijke demo.

Test ook het formulier zelf: vul het in met alleen een toetsenbord, controleer of elke foutmelding bij het juiste veld verschijnt en probeer het op een telefoon. Zo'n handmatige check vangt gebreken op maar bewijst geen volledige toegankelijkheid of WCAG-conformiteit. Web.dev besteedt in dezelfde cursus aandacht aan formulieren testen op verschillende apparaten en platformen, dus lees die onderdelen voor de details.

Wees eerlijk over de grenzen. De bronnen in dit artikel gaan over webformulieren, toegankelijkheid en validatie, niet over verkooppsychologie of conversiecijfers. Dat een demo rond één situatie beter werkt dan een rondleiding is hier een werkhypothese die je met eigen demo's toetst, geen bewezen regel. Privacyregels voor de gegevens die je via het formulier verzamelt, vallen buiten dit artikel en vragen eigen controle of juridisch advies.

Wil je zien welke publieke signalen je website uitstraalt rond contact en aanvragen, kijk dan via Marketing Scan. De scan meet zichtbare signalen en voert niet elke controle uit dit artikel uit.