Marketingfacts stelde deze week de goede vraag: hackers waren de schuldige, waarom zijn klanten dan toch boos op jouw organisatie? Het antwoord is dat mensen niet oordelen over de oorzaak maar over hoe je ermee omgaat. Hieronder wat je zegt bij een storing, een lek of een eigen fout, en in welke volgorde.
Je gebruiker heeft een relatie met jou, niet met je leverancier.
Als je hostingpartij eruit ligt, je betaaldienst een storing heeft of een pakket dat je gebruikt een lek blijkt te bevatten, is dat feitelijk niet jouw fout. Toch is het jouw naam die op het scherm staat en jouw product dat niet werkt. Voor je gebruiker is de vraag wie er precies verantwoordelijk is een interne kwestie van jouw kant.
Sterker nog: uitleggen dat het aan iemand anders lag, maakt het meestal erger. Het klinkt als een excuus, het lost niets op, en het roept de vervolgvraag op waarom jij een partij had gekozen bij wie dit kon gebeuren. De schuldvraag is voor jou relevant en voor je gebruiker niet.
Wat mensen wel onthouden is of ze het van jou hoorden of van iemand anders, hoe snel dat ging, en of je hebt gezegd wat ze zelf moesten doen. Die drie bepalen of een incident een verhaal wordt dat ze doorvertellen of iets dat over een maand vergeten is.
Wat je zegt hangt af van wat er is gebeurd, en die drie lopen vaak door elkaar.
Iets doet het niet. Hier telt vooral snelheid en herhaling: meld het zodra je het weet, ook als je nog geen oorzaak hebt, en geef een moment waarop je opnieuw iets laat horen. Dat tweede is belangrijker dan het eerste, want stilte na een eerste melding voelt als iets verzwijgen.
Er is iets bij gegevens gekomen. Hier telt precisie boven snelheid, maar niet oneindig: zeg welke gegevens het betreft, wat je hebt gedaan en wat de gebruiker zelf moet doen. Zit er een wachtwoord bij, dan is de handeling die je vraagt het belangrijkste deel van het bericht.
Je hebt iets kapot gemaakt of gegevens verloren. Hier telt eerlijkheid boven alles. Zeg wat er is gebeurd zonder het te verpakken, wat je eraan doet en wat je doet om het te voorkomen. Dit is de categorie waar mensen je het meest voor vergeven, mits je het zelf vertelt.
De verschillen zitten in de formulering, en die is bepalend.
Op het moment zelf schrijf je slecht. Daarom schrijf je het nu.
Zet drie korte teksten klaar met lege plekken erin: één voor een storing, één voor een lek en één voor een eigen fout. Vijf regels per stuk is genoeg. Op het moment dat het gebeurt, vul je ze in en verstuur je ze, in plaats van dat je onder druk gaat formuleren met iemand die over je schouder meekijkt.
Bepaal vooraf ook hoe je mensen bereikt. Een statuspagina is nuttig maar niemand bezoekt hem uit zichzelf; je hebt een kanaal nodig dat naar mensen toe gaat. Als je alleen e-mailadressen hebt van accounts die op dat moment misschien niet werken, is dat een probleem dat je nu kunt oplossen en straks niet.
En zorg dat je kunt vaststellen wát er is gebeurd, want zonder dat is elk bericht giswerk. Dat vraagt om registratie die je vooraf hebt ingebouwd; zie wat log je en hoe lang bewaar je dat. Bij een lek in een component dat je gebruikt is de eerste vraag bovendien of jij die functie draait, en dat weet je alleen met het overzicht uit wat zit er in je app.
Omdat je gebruiker een relatie met jou heeft en niet met je leverancier. Wie er technisch verantwoordelijk was, is voor hem een interne kwestie van jouw kant. Wat hij onthoudt is of hij het van jou hoorde, hoe snel dat ging en of je hebt gezegd wat hij zelf moest doen.
Bij een storing meteen, ook zonder oorzaak, met een moment erbij waarop je opnieuw iets laat horen. Bij een lek eerst vaststellen welke gegevens het betreft, maar niet oneindig: zodra je kunt zeggen wat er is gebeurd en wat mensen zelf moeten doen, ga je naar buiten. Wachten op het hele verhaal betekent dat iemand het eerder van een ander hoort.
Feitelijk klopt het vaak, maar het helpt je niet. Het leest als een excuus, het lost niets op en het roept de vraag op waarom je die partij had gekozen. Beschrijf liever wat er is gebeurd en wat je eraan doet; de keten is jouw verantwoordelijkheid om op te lossen, niet die van je gebruiker om te begrijpen.
De handeling die de gebruiker zelf moet doen, als die er is. Wachtwoord wijzigen, controleren of er iets is gewijzigd, tijdelijk iets anders gebruiken. Zet die niet onder de uitleg, want een deel van je lezers komt niet zo ver. De uitleg mag daarna.
Ja, en dat is contra-intuïtief. Expliciet zeggen wat je nog niet weet, wekt meer vertrouwen dan een bericht dat volledigheid suggereert. Bovendien voorkomt het dat je later moet terugkomen op iets wat je te stellig hebt geformuleerd, en dat kost meer vertrouwen dan de onzekerheid zelf.
Nee. Een statuspagina is nuttig als naslagwerk maar niemand bezoekt hem uit zichzelf. Je hebt een kanaal nodig dat naar mensen toe gaat. Zorg daarbij dat dat kanaal ook werkt als je product plat ligt, want mailen vanuit het systeem dat eruit ligt is precies dan geen optie.
Drie korte teksten met lege plekken: één voor een storing, één voor een lek en één voor een eigen fout, vijf regels per stuk. Op het moment zelf vul je ze in in plaats van onder druk te formuleren. Bepaal daarnaast vooraf via welk kanaal je mensen bereikt en of dat kanaal onafhankelijk van je product werkt.
Nee. Dat kun je niet waarmaken en het wordt onthouden. Zeg in plaats daarvan concreet wat je hebt veranderd om deze specifieke oorzaak weg te nemen. Dat is verifieerbaar, terwijl een belofte over de toekomst alleen maar een tweede probleem creëert als het opnieuw misgaat.
Stuur ons je idee. Wij kijken in een intake mee welke flow je wilt testen en leveren in één werkdag een klikbaar prototype, met de juiste tools voor jouw geval.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.