Zo meet je failure demand in de klantenservice

Failure demand is klantcontact dat alleen bestaat doordat een eerder onderdeel van de dienstverlening misging. Je meet het met een representatieve steekproef van inkomende contacten. Vraag per contact of het nog nodig was geweest wanneer het eerdere werk correct en volgens afspraak was uitgevoerd. Rapporteer daarna zowel het aandeel contacten als het aandeel behandeltijd.

Dat is minder eenvoudig dan één label aanbrengen. Een herhaalcontact is niet automatisch failure demand. De klant kan een nieuwe vraag hebben, gevraagde informatie aanleveren of reageren op een nieuwe gebeurtenis. De oorzaak is belangrijker dan het aantal contacten.

De Schotse overheid omschreef failure demand in 2026 als vermijdbare of door het systeem veroorzaakte behoefte die ontstaat doordat een eerdere interventie ontbrak, onvoldoende was of niet werkte. In klantenservice gaat het bijvoorbeeld om navraag naar een beloofde update, opnieuw gedeelde informatie na een slechte overdracht, een te vroeg gesloten probleem of een verwachte actie die uitbleef.

Begin bij het contact dat niet nodig hoorde te zijn

Gebruik tijdens elke beoordeling dezelfde controlevraag.

Was dit contact nog nodig geweest als het bedrijf het eerdere werk goed had uitgevoerd en de klant duidelijk had geïnformeerd?

Als het eerlijke antwoord nee is, gaat het waarschijnlijk om failure demand. Als de klant een nieuw verzoek doet of een afgesproken vervolgstap uitvoert, is het eerder waardevraag, dus contact waarvoor de service juist bestaat.

Stel dat een klant vraagt wanneer een bestelling aankomt. Die eerste vraag kan normaal zijn. Support belooft dinsdag een update. Donderdag neemt de klant opnieuw contact op omdat er niets kwam. Dat tweede bericht is veroorzaakt door een gemiste belofte. Vraagt de klant na levering om een btw-factuur, dan is dat een andere behoefte.

Dit onderscheid voorkomt dat de meting klanten de schuld geeft omdat ze hulp zoeken.

Classificeer ook de oorspronkelijke oorzaak

Eén label toont hoeveel vermijdbaar werk er is, maar niet wat je moet repareren. Geef elk geclassificeerd contact daarom een oorspronkelijke oorzaak. Houd de lijst kort genoeg om consequent te gebruiken.

• Ontbrekend beleid of mandaat
• Onbekend na beoordeling

Bewaar de klantbehoefte apart van de oorzaak. Een bezorgvraag is de behoefte. Een gemiste verzendupdate is de oorzaak. Zo zie je of één gebrekkige controle meerdere soorten contact veroorzaakt.

Wijs de oorzaak niet automatisch toe aan de medewerker die het latere bericht ontvangt. De fout kan in fulfilment, facturering, productontwerp, een leverancier, een automatiseringsregel of een eerdere supportbeslissing zitten. De ontvangende medewerker maakt het probleem vaak zichtbaar en heeft het niet veroorzaakt.

Bouw een verdedigbare steekproef

Neem een tijdgebonden steekproef uit elk belangrijk inkomend kanaal. Verdeel die over dagen, uren, talen, teams en veelvoorkomende contactredenen. Beoordeel genoeg gesprekken om verschillen tussen reviewers zichtbaar te maken en vergroot de steekproef voor grote of risicovolle categorieën.

Leg per contact zes feiten vast. Dat zijn de klant en behoefte, de eerdere belofte of gebeurtenis, wat werkelijk gebeurde, waarom de klant nu contact opnam, het oordeel met zekerheid en de oorspronkelijke oorzaak met eigenaar van de verbetering.

Laat twee reviewers een eerste deel onafhankelijk classificeren. Bespreek verschillen en verfijn de regels voordat je de hele periode meet. Gebruik een categorie onzeker in plaats van zwak bewijs in een harde uitkomst te dwingen.

Heropende cases, herhaalde berichten, kanaalwissels en zinnen als “is er al nieuws” zijn nuttige signalen, maar geen bewijs. De actuele supportrapportage van Zendesk adviseert om heropeningen, meerdere verzoeken van dezelfde klant, ticketleeftijd, prioriteit en categorie samen te bekijken. Een betrouwbare beoordeling verbindt deze signalen met dezelfde klantbehoefte en de eerdere servicegebeurtenis.

Meet het aandeel contacten en het aandeel werk

Rapporteer minstens twee getallen.

Het contactaandeel van failure demand is het aantal geclassificeerde failure-demandcontacten gedeeld door alle geschikte inkomende contacten.

Het werkaandeel is de behandeltijd van failure demand gedeeld door de behandeltijd van alle geschikte contacten.

Het eerste getal laat zien hoe vaak de dienstverlening vermijdbaar contact creëert. Het tweede toont hoeveel capaciteit dat inneemt. Ze kunnen anders bewegen. Tien korte statusvragen zijn talrijker dan één lange correctie, terwijl die correctie meer tijd kost.

De beoordeling van DWP-klantenservice door de Britse National Audit Office is een bruikbaar praktijkvoorbeeld. Het onderzoek scheidde vermijdbare, mogelijk vermijdbare en onvermijdbare beltijd. Neem vooral die afbakening over, niet een percentage uit een heel andere dienstverlening.

Splits beide maten uit naar behoefte, oorzaak, kanaal, taal, productgebied en oorspronkelijk team. Publiceer de meetperiode, toelatingsregels, onzekere gevallen en eventuele tijdsschattingen bij de uitkomst.

Verbind de klantreis voordat je het label automatiseert

Failure demand verdwijnt uit beeld wanneer het eerste WhatsApp-gesprek, een later Instagram-bericht en een heropende case drie losse klanten lijken. Koppel contacten aan klant en behoefte waar toestemming en beleid dat toelaten. Bewaar beloofde datums, eigenaarschap, statuswijzigingen, automatiseringsversie, overdrachtsreden en bewijs van voltooiing.

Een gedeelde inbox van DripTell kan geschiedenis van ondersteunde kanalen, eigenaarschap, notities, status en volgende acties bij elkaar houden. Dat helpt een reviewer de volgorde te zien. Het vervangt de beoordeling niet en bepaalt niet dat de klant geen hulp had mogen vragen.

Automatiseer pas duidelijke kandidaatsignalen wanneer mensen de gevallen betrouwbaar kunnen classificeren. Laat regels werk voor review vinden, maar niet elk herhaalcontact automatisch veroordelen.

Gebruik de meting om één oorzaak te verwijderen

Kies de grootste vermijdbare oorzaak die een genoemd team kan veranderen. Beschrijf een concrete ingreep, zoals een eerlijke bezorgupdate vóór de beloofde tijd, behoud van context bij overdracht of pas sluiten nadat de vervolgactie is bevestigd.

Herhaal dezelfde classificatie na de verandering. Controleer of contactaandeel en werkaandeel voor die oorzaak daalden zonder meer afhakers, klachten of geblokkeerde toegang tot hulp. Daalt het aantal labels alleen omdat klanten je moeilijker bereiken, dan is de service niet verbeterd.

Het doel is geen perfect dashboard. Het doel is dat minder klanten het bedrijf hoeven te vragen om eerder beloofd werk alsnog af te maken.

Wil je het bewijs in je eigen service verbinden, neem dan contact op met DripTell.

Veelgestelde vragen

Wat is het verschil tussen failure demand en herhaalcontact

Herhaalcontact is een waarneembare gebeurtenis. Failure demand is een oordeel over de oorzaak. Een herhaling kan een nieuwe behoefte zijn, terwijl een eerste supportcontact door een eerdere procesfout kan ontstaan.

Is elke vraag om een statusupdate failure demand

Nee. Dat geldt wanneer het bedrijf een beloofde update miste of verwachtingen onduidelijk liet. Controleer eerst de afspraak en context.

Hoe groot moet de steekproef zijn

De steekproef moet elk belangrijk kanaal, reden, taal en operationeel moment dekken. Vergroot haar totdat de classificatie voor grote oorzaken stabiel is en rapporteer omvang en onzekerheid.

Is failure demand geschikt als medewerkerdoelstelling

Meestal niet. De oorzaak ligt vaak buiten de invloed van de ontvangende medewerker. Gebruik de maat om falende processen te vinden en wijs de verbetering toe aan de eigenaar van de oorspronkelijke controle.