Design yndefulde fallbacks og overleveringer
I situationer, hvor din samtalebrugeroplevelse (CUX) ikke kan bestemme eller opfylde brugerens hensigt, skal du udvikle en række fallback-svar. "Serie" er bevidst her. Tro ikke, at et isoleret "Ups, undskyld det" vil dække dig. Du ønsker ikke at bryde brugerens tillid – og muligvis skade din brandloyalitet – ved at skabe en oplevelse, der fører til en blindgyde. Gode fallbacks og afleveringer hjælper brugeren med at fuldføre den opgave, de har sat sig for at udføre, med så lidt frustration som muligt.
Sæt klare forventninger på forhånd
Samtaleoplevelser er ikke egnede til at håndtere opgaver, som et menneske håndterer bedre. Under din designproces identificerede du de ting, din CUX gør, og de ting, den ikke gør. En måde at reducere behovet for tilbagefald på er at være klar over det lige fra starten, hvad disse ting er.
Hvis du f.eks. designer en bank-Helpdesk-medarbejder, skal du fortælle kunderne i hilsenen, at de kan tjekke deres saldo eller foretage en overførsel mellem konti. Hvis du designer en Helpdesk-medarbejder rejse, skal du fortælle kunderne, at de kan booke en returflyvning, reservere et hotelværelse eller foretage ændringer i deres rejseplan.
Når du kommer til det punkt, hvor en bruger har bedt din Helpdesk-medarbejder om at gøre noget, som den ikke kan, er en fallback-svar et andet sted at give denne klarhed. Tilbagefald som "Undskyld, det fik jeg ikke. Jeg kan hjælpe dig [X] eller [Y]. Vil du prøve en af disse ting?" hjælpe med at omdirigere brugeren til de ting, din Helpdesk-medarbejder kan gøre.
Tænk på fallbacks efter funktion
Uanset om din CUX ikke kan forstå eller ikke kan levere det, som brugeren ønsker, er det nyttigt at tænke på dine fallbacks i henhold til deres funktion: at søge forståelse, udpege og etablere domæneekspertise.
Søg forståelse: Når din CUX ikke kan forstå brugerens hensigt, skal du bede brugeren om at omformulere eller præcisere sin anmodning. Eksempel:
- "Det forstod jeg ikke. Kan du sige det på en anden måde?"
- "Jeg forstår det ikke helt. Kan du prøve at omformulere?"
- "Jeg er lidt usikker på, hvordan jeg skal hjælpe. Prøv at spørge igen ved hjælp af nogle få nøgleord."
Find andre måder at adskille på. Nogle gange er en fallback et passende sted at søge mere klarhed, der hjælper dig med at bestemme, hvad brugeren ønsker. Giv et forslag eller to, der nøje matcher brugerens hensigt. Eksempel:
- "Mente du [forslag]?"
- "Det lyder som om du vil [forslag]. Er det rigtigt?"
- "Jeg fandt [forslag 1] eller [forslag 2]. Er det en af dem?"
Hvis din CUX forstår hensigten, men ikke kan opfylde den, skal du være gennemsigtig over for dine brugere. Omdiriger dem til, hvad CUX'en kan gøre, eller tilbyd andre ressourcer, der kan hjælpe. Eksempel:
- "Undskyld, jeg kan ikke hjælpe med det. Ville du prøve [forslag1] eller [forslag 2]?"
- "Undskyld, jeg tror ikke, jeg kan hjælpe dig med det. Sig "hovedmenu" for at lære, hvad jeg kan."
- "Jeg har ingen oplysninger om det, men jeg fandt dette emne, der måske kunne hjælpe: [emne]."
Vær forsigtig med at bruge sætninger, der antyder, at CUX'en lærer, hvordan man adresserer brugerens hensigt, såsom "Jeg kan ikke gøre det endnu" eller "Jeg er stadig ved at lære, hvordan man gør det", medmindre du har konkrete planer om at bygge denne funktion ind i din oplevelse.
Opret reservevarianter
Hvis du havde en samtale med nogen, og de lavede flere fejl i træk, ville det være mærkeligt for dem at give nøjagtig den samme undskyldning igen og igen. Det samme gælder for din CUX. Når du skriver fallbacks, er det en god idé at lave et par variationer til enhver situation. På den måde, når kunder støder på en fallback mere end én gang, føles oplevelsen ikke alt for robotagtig. Antallet af fallbacks, du har brug for, afhænger af, hvor mange stier kunderne kan følge i din samtale, men prøv generelt at skrive mindst tre.
Ved, hvornår du skal aflevere
Det er vigtigt at opbygge en overlevering-proces, når din CUX ikke kan forstå brugeren eller ikke kan hjælpe dem. Du kan henvise kunden til en medarbejder eller til ressourcer som f.eks. supportwebsteder eller onlinedokumentation. Et af de sværere spørgsmål, du skal besvare, er : Hvornår skal CUX'en dirigere brugeren til en menneskelig eller anden ressource?
Det kan være nyttigt at tænke over, hvor mange gange du ville være villig til at gentage eller omformulere et spørgsmål under en samtale, før du blev frustreret. Vi anbefaler, at du ikke stiller brugeren mere end to reservespørgsmål i én session, før du retter dem et andet sted hen.
Gør overleveringen så glat som muligt. Sørg for, at brugeren ved, hvad der sker, om de er forbundet med et menneske eller en anden ressource, og hvad de skal gøre næste gang. Selvom de gik i stå, betyder det ikke nødvendigvis, at de skal starte forfra – og det har de heller ikke lyst til. En god overlevering husker effektivt, hvor brugeren slap, og hjælper dem med at fortsætte den opgave, de har sat sig for at udføre. At bede brugeren om at gentage den samme proces, som CUX'en startede, er ikke en god oplevelse og kan resultere i, at brugeren opgiver indsatsen.
Bed om feedback
Når din CUX afslutter samtalen, uanset om det hjalp kunden eller ej, er det et godt tidspunkt at bede om feedback. Gør anmodningen enkel og hurtig. Her er nogle nemme måder at spørge folk om deres oplevelse på:
- Tommelfinger op/tommelfinger ned
- Smil/rynke panden
- Numerisk bedømmelse (fempunktsskalaer er typiske)
- Positiv/negativ (enten en binær skala eller en bredere fempunktsskala)
Ideelt set skal du inkludere et åbent tekstfelt efter bedømmelsen, så kunden kan sige, hvad de vil. Du kan tilføje flere spørgsmål, men jo flere spørgsmål du tilføjer, jo mindre sandsynligt er det, at folk engagerer sig i feedbackformularen.
Selvom feedback kan være værdifuld, er det lige så vigtigt at tænke over, hvor ofte du beder om det. At spørge for ofte er i bedste fald irriterende og i værste fald fremmedgørende. Hvis det er muligt, så prøv at bruge frekvenssignaler fra dine kunder, så du ikke beder dem om en bedømmelse mere end én gang om ugen. Selv da kan det være en god idé at prioritere oplevelser, hvor feedback ville være mest nyttig, f.eks. nye oplevelser eller mere komplekse. Du kan også undgå at bede om feedback, hvor brugeren måske hurtigt vil gå videre til noget andet, f.eks. efter at have fået et telefonnummer. Sørg for, at den opgave, de har sat sig for at udføre, er udført, før du distraherer dem med opgaven med at udfylde din undersøgelse.
Bed dog ikke om feedback, hvis du ikke har nogen måde at administrere det på. Hvis kundefeedback går ud i et tomrum, hvis der ikke er nogen proces til gennemgang, mærkning, mærkning, lagring og rapportering af det, skal du ikke bekymre dig om at bede om det. Hvis kunderne fornemmer, at deres feedback ikke bliver gennemgået, mister de tilliden og vil sandsynligvis ikke indsende feedback i fremtiden.