Elegante fallbacks en overdrachten ontwerpen
Voor situaties waarin uw conversationele gebruikerservaring (CUX) de bedoeling van de gebruiker niet kan bepalen of vervullen, moet u een reeks terugvalreacties ontwikkelen. Het woord "serie" is hier opzettelijk. Denk niet dat een enkel "Oeps, sorry daarvoor" voldoende is. U wilt het vertrouwen van de gebruiker niet beschamen en mogelijk ook uw merkloyaliteit schaden door een ervaring te creëren die tot een doodlopende weg leidt. Goede fallbacks en handoffs helpen de gebruiker om de taak die hij/zij voor ogen had, met zo min mogelijk frustratie te voltooien.
Stel vooraf duidelijke verwachtingen vast
Gesprekservaringen zijn niet geschikt voor het uitvoeren van taken die een mens beter kan. Tijdens uw ontwerpproces hebt u vastgesteld wat uw CUX wel en niet doet. Een manier om de noodzaak voor uitwijkmogelijkheden te verminderen, is om vanaf het begin duidelijk te maken wat die uitwijkmogelijkheden zijn.
Als u bijvoorbeeld een bank-app agent ontwerpt, kunt u klanten in de begroeting vertellen dat ze hun saldo kunnen controleren of een overschrijving tussen rekeningen kunnen doen. Als u een reis agent ontwerpt, vertel klanten dan dat ze een retourvlucht kunnen boeken, een hotelkamer kunnen reserveren of hun reisschema kunnen wijzigen.
Wanneer u bij aanwijzen bent, waarbij een gebruiker uw agent heeft gevraagd iets te doen wat het niet kan, kunt u met behulp van de fallback-code overdracht hier duidelijkheid in scheppen. Terugvalreacties zoals: "Sorry, dat heb ik niet begrepen. Ik kan je helpen [X] of [Y]. Wil je een van die dingen proberen?" helpt de gebruiker om te leiden naar de dingen die jouw agent kan doen.
Denk aan fallbacks op basis van functie
Ongeacht of uw CUX niet kan begrijpen of niet kan leveren wat de gebruiker wil, is het handig om uw vangnetten te baseren op hun functie: begrip verkrijgen, duidelijkheid scheppen en domeinexpertise opbouwen.
Probeer begrip te kweken: als uw CUX de bedoeling van de gebruiker niet begrijpt, vraag de gebruiker dan om zijn of haar verzoek te herformuleren of te verduidelijken. Bijvoorbeeld:
- "Dat snapte ik niet. Kun je het anders zeggen?"
- "Ik begrijp het niet helemaal. Kunt u het anders formuleren?"
- "Ik weet niet zo goed hoe ik kan helpen. Probeer het nog eens, maar gebruik hierbij slechts een paar trefwoorden."
Zoek andere manieren om onduidelijkheden te verduidelijken. Soms is een fallback een goede manier om meer duidelijkheid te krijgen, zodat u beter kunt bepalen wat de gebruiker wil. Geef een suggestie of twee die nauw aansluiten bij de bedoeling van de gebruiker. Bijvoorbeeld:
- "Bedoelde u [suggestie]?"
- "Het lijkt erop dat je [suggestie] wilt. Klopt dat?"
- "Ik heb [suggestie 1] of [suggestie 2] gevonden. Is het er een van?"
Als uw CUX de bedoeling begrijpt, maar deze niet kan waarmaken, wees dan transparant naar uw gebruikers. Stuur ze door naar wat de CUX kan doen of bied andere bronnen aan die wellicht kunnen helpen. Bijvoorbeeld:
- "Sorry, daar kan ik je niet mee helpen. "Wil je [suggestie 1] of [suggestie 2] proberen?"
- "Sorry, ik denk niet dat ik je daarmee kan helpen. Zeg "hoofdmenu" om te zien wat ik kan doen."
- "Ik heb er geen informatie over, maar ik vond deze onderwerp die misschien kan helpen: [onderwerp]."
Wees voorzichtig met het gebruik van zinnen die suggereren dat de CUX leert hoe het de intentie van de gebruiker moet aanpakken, zoals "Dat kan ik nog niet" of "Ik ben nog aan het leren hoe ik dat moet doen", tenzij u concrete plannen hebt om die mogelijkheid in uw ervaring te integreren.
Maak fallback-variaties
Stel dat je een gesprek hebt met iemand en die persoon maakt meerdere fouten achter elkaar. Dan zou het vreemd zijn als die persoon steeds dezelfde excuses aanbiedt. Hetzelfde geldt voor uw CUX. Wanneer je terugvalscenario's schrijft, is het een goed idee om voor elke situatie een paar variaties te bedenken. Op die manier voelt de ervaring niet te robotachtig aan als klanten meer dan eens een terugval ervaren. Het aantal fallbacks dat u nodig hebt, hangt af van het aantal paden dat klanten kunnen volgen in uw gesprek, maar probeer er over het algemeen minimaal drie te schrijven.
Weet wanneer je het moet overdragen
Het is belangrijk om een overdracht-proces te bouwen voor het geval dat uw CUX de gebruiker niet begrijpt of niet kan helpen. U kunt de klant doorverwijzen naar een menselijke ondersteuningsmedewerker of naar bronnen zoals ondersteuningswebsites of online documentatie. Een van de lastigere vragen die u moet beantwoorden is: Wanneer moet de CUX de gebruiker doorverwijzen naar een menselijke of andere bron?
Het kan nuttig zijn om na te denken over hoe vaak u bereid bent om een vraag tijdens een gesprek te herhalen of te herformuleren voordat u gefrustreerd raakt. Wij adviseren om de gebruiker niet meer dan twee terugvalvragen in één sessie te stellen voordat u hem of haar naar een andere sessie doorverwijst.
Maak de idee zo vloeiend mogelijk. Zorg ervoor dat de gebruiker weet wat er gebeurt, of hij/zij wordt verbonden met een mens of een andere bron, en wat hij/zij vervolgens moet doen. Ook al zijn ze vastgelopen, betekent dat niet per se dat ze opnieuw moeten beginnen. En dat willen ze ook niet. Een goede overdracht onthoudt effectief waar de gebruiker gebleven was en helpt hem/haar om door te gaan met het taak dat hij/zij wilde bereiken. Als je de gebruiker vraagt om hetzelfde proces te herhalen dat de CUX heeft gestart, is dat geen prettige ervaring en kan het ertoe leiden dat de gebruiker de poging afbreekt.
Vraag om feedback
Wanneer uw CUX het gesprek heeft afgerond, ongeacht of het de klant heeft geholpen of niet, is dit een goed moment om om feedback te vragen. Maak het verzoek eenvoudig en snel. Hier zijn enkele eenvoudige manieren om mensen naar hun ervaringen te vragen:
- Duim omhoog/duim omlaag
- Glimlach/frons
- Numerieke beoordeling (typisch zijn vijfpuntsschalen)
- Positief/negatief (hetzij een binaire schaal of een bredere vijfpuntsschaal)
Idealiter voegt u na de beoordeling een open tekstveld toe, zodat de klant kan aangeven wat hij wil. U kunt meer vragen stellen, maar hoe meer vragen u stelt, hoe kleiner de kans dat mensen het feedbackformulier invullen.
Feedback kan waardevol zijn, maar het is.Net zo belangrijk om goed na te denken over hoe vaak u erom vraagt. Te vaak vragen is in het beste geval vervelend en in het slechtste geval vervreemdend. Probeer indien mogelijk frequentiesignalen van uw klanten te gebruiken, zodat u hen niet vaker dan één keer per week om een beoordeling vraagt. Maar zelfs dan wilt u misschien prioriteit geven aan ervaringen waarbij feedback het meest nuttig zou zijn, zoals nieuwe ervaringen of complexere ervaringen. U kunt ook beter niet om feedback vragen op een moment dat de gebruiker snel iets anders wil doen, bijvoorbeeld nadat hij een telefoonnummer heeft gekregen. Zorg ervoor dat de taak die ze willen invullen, Gereed is voordat je ze afleidt met de taak van het invullen van jouw enquête.
Vraag echter niet om feedback als u er geen manier voor hebt om dit te beheren. Als feedback van klanten op niets uitloopt, als er geen proces is voor het beoordelen, labelen, taggen, opslaan en rapporteren ervan, vraag er dan niet om. Als klanten het gevoel krijgen dat hun feedback niet wordt beoordeeld, verliezen ze hun vertrouwen en is de kans groot dat ze in de toekomst geen feedback meer zullen geven.