Een wetenschappelijke benadering voor verbetering van de klantervaring
Resultaat: inspanningen worden efficiënter en hebben meer effect bij klanten
26 oktober 2022 -
"Een belangrijk aspect van elke succesvolle klantgerichte professional is het kunnen vaststellen van verschillende drijfveren, doelen en behoeften van klanten," aldus Marwan Al Shawi, Solutions & Cloud Architect bij Amazon Web Services. Om die te identificeren is het volgens Al Shawi belangrijk om de juiste vragen te stellen. Dat wil volgens hem zeggen: "vragen die leiden tot het verkrijgen van meer inzicht over de data of het onderwerp. Dit vereist een objectieve benadering met zo min mogelijk menselijke vooroordelen."
Met het bovenstaande in het achterhoofd, gaat Al Shawi dieper in op twee technieken van kritisch denken die kunnen helpen om een complex scenario op te splitsen in kleinere delen, zodat de situatie beter te analyseren is en de juiste actie ondernomen kan worden.
Het analyseren van de data: welke informatie ontbreekt of kan misleidend zijn voor de statistische informatie?
Het identificeren van de oorzaak van een probleem vs. symptoom: Wat is de werkelijke hoofdoorzaak van het probleem dat moet worden opgelost?
Het scenario in de realiteit
Al Shawi neemt een voorbeeld van een detailhandelsbedrijf waarbij de eigenaar ook beheerder van verschillende winkelcentra is. Deze eigenaar besloot een cloud-gebaseerde Software-as-a-Service oplossing te introduceren, waarmee de verschillende afdelingen gegevens kunnen verzamelen om een beter inzicht te krijgen in het traject van hun klanten, hun winkelervaring en meer. Het bedrijf bouwde en testte een proof-of-concept-oplossing. De klant vertelde: "We konden data verzamelen en snel dashboards maken en publiceren, waardoor we inzichten kregen die hiervoor niet mogelijk waren voor ons. Ook bereikten we 25 procent snellere respons van applicaties met onze nieuwe hybride connectiviteit met behulp van een SD-WAN-oplossing die ons zal helpen met onze uitbreidingsplannen." Al Shawi: "Het ontwikkelingsteam miste echter consequent deadlines omdat ze verschillende pogingen deden om tal van technische wijzigingen op te nemen, waardoor de verwachte lancering van de productie software-as-a-service-oplossing vertraging opliep."
Identificeer ontbrekende informatie en statistische feiten
"In het algemeen kunnen ontbrekende informatie of statistieken die niet in de juiste context zijn geplaatst, de perceptie van de situatie en de optimale oplossing ervan aanzienlijk veranderen. Wanneer informatie ontbreekt of uit zijn verband wordt gerukt, kan dit leiden tot slechte besluitvorming of incorrecte aanbevelingen," aldus Al Shawi.
Statistieken als "40 procent hoger", "tien procent sneller" of "vijf procent langzamer" kunnen volgens hem verkeerd worden geïnterpreteerd zonder extra context voor vergelijking. Wanneer een bijvoeglijk naamwoord als "hoger" wordt gebruikt als een kwalificerende waarde, moeten er opvolgvragen gesteld worden - "40 procent hoger dan wat; in welk tijdsbestek; en tegen welke parameters?"
In het voorbeeld zei de klant: "We hebben een 25 procent snellere respons van applicaties bereikt met onze nieuwe hybride connectiviteit met behulp van een SD-WAN-oplossing." Hoewel dit een volledige verklaring lijkt te zijn, is het volgens Al Shawi erg algemeen.
Opvolgvragen om te overwegen zijn onder andere:
Welke applicaties worden er gebruikt?
Heeft "25 procent sneller" betrekking op de toegang van gebruikers tot de Software-as -a-Service-, POC-applicatie?
Wanneer werden deze gegevens verzameld? Meer specifiek, werd het gemeten onder dezelfde omstandigheden (bijvoorbeeld tijdens piekuren)?
De klant in het voorbeeld van Al Shawi gaf aan dat uit het prestatieverslag van het applicatieteam bleek, dat 65 procent van de applicaties sneller is. Toch wijst het percentage volgens de Solutions & Cloud Architect op misleidende of onduidelijke feiten. Dat betekent volgens hem: doorvragen.
Wat betekent 65 procent sneller?
Betekent dit dat alle applicaties zijn gemeten, en dat slechts 65 procent van hen sneller was? Of zijn slechts 65 procent van de toepassingen in aanmerking genomen en gemeten?
Zijn deze applicaties toegankelijk in de cloud, on-premises, of een mix?
Gaat het vooral om de nieuwe Proof of concept, Software as Service-applicatie?
Na het stellen van deze vragen gaf de klant aan dat sommige applicaties niet waren beoordeeld vanwege bepaalde security- en compliancebeperkingen. Daarom werd slechts 65 procent van de applicaties die in de cloud werden gehost, inclusief de nieuwe POC- en SaaS-applicatie, in aanmerking genomen en gemeten voor de prestatieoptimalisatie tijdens piekuren.
Hieruit leerde Al Shawi: "65 procent van al onze applicaties die in de cloud worden gehost en die voor meting in aanmerking komen, hebben 25 procent snellere prestaties tijdens piekuren. Het is duidelijk dat dit een relatief ander verhaal vertelt, en daarom is het van cruciaal belang om kritisch door te vragen, om de volledige context van de gegevens te begrijpen en eventuele verkeerde aannames te vermijden."
Al Shawi: ‘’Na het analyseren en verduidelijken van de toegangsprestaties van de applicaties, zullen we vervolgens proberen de hoofdoorzaak van de vertraging van het project te identificeren en te analyseren met behulp van een andere techniek.’’
Identificeer de oorzaak van het probleem versus het symptoom
Is haast geboden om een aanbeveling te doen die uiteindelijk nieuwe problemen veroorzaakte in een later stadium, waardoor een onbedoelde keten van problemen ontstond die afweken van het oorspronkelijke probleem? Om dat te voorkomen, is het belangrijk om de oorzaken van een probleem versus symptomen te identificeren. Voor ons doel duidt een symptoom op een toestand van een resultaat dat niet werkte zoals bedoeld. Een oorzaak is de reden waarom iets in de eerste plaats gebeurde.
Voor deze techniek gebruikte Al Shawi de ‘vijf waarheden’, oorspronkelijk ontwikkeld door Skichi Toyoda, om de onderliggende oorzaak en gevolg relaties van een specifiek probleem te identificeren. "Tegen de tijd dat je bij de vierde of vijfde 'waarom' bent, heb je waarschijnlijk de oorzaak geïdentificeerd die moet worden verbeterd of opgelost."
In het voorbeeld wil hij weten waarom het projectteam de go-live deadline heeft gemist. De klant legde uit: "De deadline werd gemist omdat het ontwikkelingsteam verschillende pogingen deed om tal van technische wijzigingen op te nemen."
De volgende vragen zijn volgens Al Shawi belangrijk om te overwegen:
Is dit een oorzaak of een symptoom? Het kan beide zijn. Als aangenomen wordt dat dit het eigenlijke probleem is, is er een grote kans dat u te maken heeft met een symptoom en niet met de eigenlijke hoofdoorzaak.
Hoe weet u dat? Stel vast wat tot verschillende technische veranderingen heeft geleid. Als er een symptoom is, moet er een oorzaak zijn.
Tot slot zegt Al Shawi: "Begin elke analyse door te kijken naar de algemene use case of het scenario, identificeer het uiteindelijke doel en werk van daaruit terug. Splits het vervolgens op in kleinere onderdelen, waarbij je de technieken die in deze blog zijn besproken toepast waar relevant. Hoewel er geen vaste formule of volgorde van technieken is, moet u altijd beginnen met het identificeren van ontbrekende informatie die je zou kunnen helpen de hoofdoorzaak te identificeren. Als er geen kan worden gevonden, stel dan vragen en vermijd het maken van veronderstellingen. Met als resultaat: inspanningen worden efficiënter en hebben meer effect bij klanten."
