Klantfeedback vragen in een softwareproduct
7 min lezen
Om klantfeedback te vragen in een softwareproduct stel je één concrete vraag over iets wat de gebruiker net deed, op de plek waar hij het deed. “Hoe ging het exporteren van dat rapport?” direct na een export levert een antwoord op. “Vertel ons wat je van ons product vindt” in een footer levert stilte op. De rest van deze pagina bestaat uit de momenten, de kanalen en de exacte formuleringen.
Het meeste advies over dit onderwerp is geschreven voor winkels en servicedesks. Een softwareteam weet precies wat de gebruiker een seconde geleden deed, dus de vraag kan daarover gaan.
| Moment | Waar vragen | Kant-en-klare vraag |
|---|---|---|
| Direct nadat een taak klaar is | In de app, naast het resultaat | “Deed die export wat je nodig had?” |
| Na het eerste gebruik van een nieuwe feature | In de app, één keer | “Wat probeerde je te doen met Bulk Edit?” |
| Nadat een supportticket is opgelost | In de supportthread | “Heeft dat het opgelost, of klopt er nog iets niet?” |
| Nadat een gebruiker vastloopt of een flow verlaat | E-mail, een dag later | “Je stopte bij stap 3 van de setup. Wat zat in de weg?” |
| Na 30 dagen regelmatig gebruik | E-mail van een persoon met naam | “Wat is het ene wat je zou veranderen?” |
| Wanneer een gebruiker opzegt | In de opzegflow | “Waarom besloot je vandaag te vertrekken?” |
| Nadat je iets uitbrengt waar ze om vroegen | Waar ze erom vroegen | “Je vroeg om CSV-import. Het is live. Dekt het jouw situatie?” |
Wat is het juiste moment om feedback te vragen?
Het juiste moment is direct nadat de gebruiker iets heeft afgerond, terwijl de details nog in zijn hoofd zitten. Een vraag die op een actie volgt, krijgt een antwoord over die actie. Een vraag die uit het niets komt, krijgt een antwoord over de stemming van de persoon, of geen antwoord.
Vraag niet bij de aanmelding, want niemand heeft nog iets gebruikt. Vraag niet midden in een taak, want dan onderbreek je precies wat je wilt leren kennen. Laat iemand die heeft geantwoord met rust tot je iets te melden hebt.
Waar vraag je klantfeedback het best?
Vraag op de plek waar de ervaring plaatsvond. Een prompt in de app past bij een vraag over een scherm. De supportthread past bij een vraag over een oplossing. E-mail past bij een vraag over een week gebruik, of over een flow die iemand afbrak. Een gesprek past bij de vragen die je niet kunt voorspellen.
Elk kanaal levert een ander soort antwoord op:
- In de app: kort, direct en concreet, maar alleen van mensen die er op dat moment zijn. Van gebruikers die al weg zijn hoor je niets.
- Supportthread: van mensen die al gefrustreerd genoeg waren om te schrijven. Goed om kapotte dingen te vinden, slecht om de rest van het product te beoordelen.
- E-mail: langere antwoorden van minder mensen, en de enige manier om gebruikers te bereiken die stil zijn geworden. Schrijf het als een korte notitie van een persoon met naam, met één vraag erin.
- Interview: de manier om te leren waarom mensen dingen doen. Vraag ze te laten zien hoe ze werken, en zwijg terwijl ze dat doen.
Kwaliteit van feedbacksignalen behandelt hoe je weegt wat elk kanaal je vertelt.
Hoe vraag je op een professionele manier om feedback?
Wees specifiek over het onderwerp, zeg waarom je het vraagt en zorg dat het antwoord minder dan een minuut kost. Een professionele vraag noemt het moment, maakt duidelijk dat een mens het antwoord leest en verontschuldigt zich niet voor de onderbreking.
Noem de exacte actie (“de export die je zojuist draaide”), vraag om één ding, gebruik een vrij tekstveld zonder verplichte velden en onderteken met een voornaam.
Wat is een goede zin om feedback te vragen?
Een goede zin is een vraag over een specifiek moment die in een paar woorden te beantwoorden is. Vergelijk de twee kolommen hieronder. De linkse kun je met een schouderophalen beantwoorden. De rechtse vragen de persoon iets echts te herinneren.
| Zwakke vraag | Sterkere vraag |
|---|---|
| “Nog feedback?” | “Wat was het lastigste bij het instellen hiervan?” |
| “Wat vind je van ons product?” | “Waarvoor gebruikte je dit vorige week?” |
| “Beoordeel je ervaring van 1 tot 10.” | “Heb je vandaag gedaan wat je kwam doen?” |
| “Vertel ons hoe we kunnen verbeteren.” | “Wat is één ding dat je deze week ophield?” |
| “Zou je ons aanbevelen?” | “Aan wie liet je dit laatst zien, en wat zei je?” |
Nog een vraag die bijna overal werkt: “Wat gebruik je in plaats daarvan als dit voor jou niet werkt?” Die brengt de echte concurrent naar boven, en dat is vaak een spreadsheet.
Wat zijn de slechtste manieren om feedback te vragen?
De slechtste vragen zijn breed, vroeg, lang of sturend. Ze hebben één probleem gemeen: de persoon kan niet antwoorden zonder het denkwerk te doen dat jij had moeten doen.
- “Vul onze enquête van 20 vragen in.” De mensen die hem afmaken hebben de meeste vrije tijd of de sterkste mening.
- Een popup op de eerste pagina na het inloggen. De gebruiker kwam iets doen en jij blokkeerde het. Wegklikken is het enige verstandige antwoord.
- “We horen graag je feedback!” zonder vraag. Het vraagt de gebruiker het onderwerp te verzinnen.
- Een sturende vraag: “Hoe dol ben je op het nieuwe dashboard?” Je krijgt instemming en leert niets.
- Een score zonder vervolgvraag. Een 6 uit 10 vertelt je de stemming. Het vertelt je niet wat je moet veranderen.
- Vragen, en dan zwijgen. Dat kost je de volgende ronde, zoals hieronder staat.
Hoe noem je klantfeedback over een product?
Feedback over een product heet meestal productfeedback, en die valt in twee soorten uiteen. Een bugmelding zegt dat iets niet werkt zoals bedoeld. Een featureverzoek zegt dat iets ontbreekt. Het onderscheid bepaalt wie het eerst bekijkt, en featureverzoek of bug trekt die lijn. Een derde soort, lof, is het bewaren waard en het citeren met toestemming.
Een feedbackformulier dat “Bug” en “Featureverzoek” als eerste keuze aanbiedt, doet die eerste sortering voor je.
Wat doe je met de antwoorden?
Zet elk antwoord waar het team al werkt, met de woorden van de persoon intact. Een enkele geciteerde regel is beter dan jouw samenvatting ervan. Tag het op type en grove urgentie, voeg herhalingen samen en beslis: bouwen, parkeren of afwijzen.
Afwijzen telt ook als antwoord. “We gaan dit niet bouwen, en dit is waarom” maakt een einde aan het wachten, en featureverzoeken afwijzen heeft formuleringen daarvoor. Voor de leidingen beschrijft featureverzoeken bijhouden hoe je verzoeken uit vijf kanalen in één lijst krijgt. Als je verzoeken schriftelijk aanneemt, houdt een feature request template ze vergelijkbaar.
De widget van Changeloop maakt van elke inzending een GitHub-issue, zodat feedback landt naast de code die het gaat oplossen. Met elk tool is de regel hetzelfde: één lijst, één eigenaar, geen antwoord dat in iemands inbox blijft liggen.
Waarom vertel je wat er live ging?
Het laat de persoon zien dat antwoorden de moeite waard was. Een gebruiker die je iets vertelde en later hoort “dit is uitgebracht, bedankt” heeft een reden om weer te antwoorden. Wie niets hoort, concludeert dat het vakje niet wordt gelezen.
De laatste stap van het vragen is dus een antwoord. Vertel elke persoon die erom vroeg wanneer zijn verzoek live gaat, in zijn eigen termen, op het kanaal dat hij gebruikte. De feedback-loop met klanten sluiten beschrijft het mechanisme: de gepubliceerde changelog-entry is wat het bericht activeert, zodat de aanvrager pas wordt ingelicht als de wijziging live is. Als in Changeloop widgetfeedback een GitHub-issue werd en de gemergede pull request die sluit, plaatst het goedkeuren van de entry een “Shipped”-reactie op die issue en toont het de entry aan de indiener in de widget; handmatig aangemaakte issues en GitLab- of Bitbucket-repositories krijgen geen reactie. Onze docs beschrijven de setup van widget en feed.
Een antwoord kan kort zijn: “Je vroeg in maart om CSV-import. Het is vandaag live, en zo werkt het.” Het geeft je ook de beste volgende vraag, namelijk of het dekt wat ze nodig hadden.
Een beginplan
Kies één moment uit de tabel bovenaan, het moment waarop gebruikers het vaakst slagen of afhaken. Schrijf er één vraag voor, zet hem in één kanaal en lees twee weken lang elk antwoord voordat je een tweede prompt toevoegt. Antwoord iedereen die je iets concreets gaf.
FAQ
Hoe vaak moet je klanten om feedback vragen? Koppel vragen aan gebeurtenissen, niet aan een kalender. Een gebruiker mag hoogstens één prompt per week zien, en geen direct na het beantwoorden van een andere. Het eerste bericht na feedback moet een antwoord zijn over wat ermee gebeurde.
Hoe vraag je feedback zonder gebruikers te irriteren? Vraag na een taak, nooit midden in een taak, houd het bij één vraag en maak wegklikken makkelijk. Respecteer een afwijzing een paar weken.
Moet je een beloning voor feedback aanbieden? Meestal is dat niet nodig. Een concrete vraag en een zichtbaar antwoord wegen zwaarder dan een cadeaubon, en beloningen trekken mensen aan die de beloning willen. Bewaar ze voor interviews, waar je om 20 minuten van iemands tijd vraagt.
Wat als niemand antwoordt? Maak de vraag smaller en breng hem dichter bij het moment, bijvoorbeeld één scherm, gevraagd direct nadat het is gebruikt. Blijft het stil, mail dan een handvol gebruikers rechtstreeks en gebruik die gesprekken om betere prompts te schrijven.
De technische beweringen in dit artikel zijn niet onafhankelijk gecontroleerd. Klopt er iets niet, laat het ons weten, dan corrigeren we het.