En användare försöker genomföra en betalning, men möts av meddelandet ”Något gick fel”. Ingen förklaring ges, det är oklart om pengarna har dragits och nästa steg framgår inte, i det läget har kundtjänsten ännu inte kontaktats, men supportärendet har redan börjat.
På ett modernt Casino online behöver därför kundservicen ses som en del av ett större system än bara chatt, mejl och telefonsamtal. Det är direkt kopplat till felmeddelanden, hjälpsidor, statusrutor, instruktioner och de korta texter som visar vad användaren ska göra härnäst. De här är alla customer facing, del av gränssnittet och del av informationen som skickas ut till användarna.
När dessa fungerar väl löses många frågor innan någon behöver skriva till supporten. När de inte gör det så skapar själva tjänsten i stället de problem som kundtjänsten blir delegerade.
Det är skillnaden mellan att svara på frågor och att bygga en miljö där färre frågor behöver uppstå.
När tjänsten lämnar användaren att gissa
En dålig försupportmiljö är oftast inte ens tekniskt trasig som man kan tro. Istället har det mer att göra med att det informationen kunden får inte är självklar. Ett är genom språk – i instruktioner, meddelanden, rubriker och knappar.
Tydliga rubriker och felmeddelanden hjälper användare att undvika eller rätta till misstag, något som även lyfts fram i PTS vägledning om tillgängliga digitala tjänster.
Ett formulär kan avvisa en uppladdad fil utan att ange vilket format som krävs. En betalning kan visas som ”pågående” utan någon förklaring av vad det betyder. En verifieringssida kan efterfråga ytterligare dokument, men inte tydligt ange vilka uppgifter som måste vara synliga. Hjälpsidan kan innehålla svaret, men gömma det under en rubrik som användaren aldrig skulle söka efter.
Har betalningen misslyckats eller behandlas den fortfarande? Behöver dokumentet skickas på nytt? Är problemet tillfälligt? Ska användaren vänta, prova igen eller kontakta kundtjänsten?
När svaren saknas blir den naturliga reaktionen ofta att testa flera saker samtidigt. Knappen trycks in igen. Sidan laddas om. Samma dokument laddas upp i ett nytt format. Därefter kontaktas livechatten, ibland innan den första processen ens har hunnit avslutas.
Det finns föga anledning till att vidhålla användaren informationen för att lösa sina problem själva, utan det handlar om bra design.
Ett bra meddelande gör mer än att säga att något gått fel
Ett användbart felmeddelande behöver inte vara långt. Det måste däremot besvara rätt frågor.
I stället för:
Betalningen misslyckades.
Kan tjänsten förklara:
Betalningen genomfördes inte och inga pengar har dragits. Kontrollera uppgifterna eller välj en annan betalningsmetod.
Skillnaden är liten i antal ord men stor i praktiken. Användaren får veta både vad som har hänt och vad som kan göras.
Samma princip gäller när ett ärende tar tid. Ett besked som enbart visar ”behandlas” lämnar mycket åt fantasin. En tydligare status kan ange att uppgifterna har tagits emot, att användaren inte behöver skicka in dem igen och att ett nytt meddelande kommer när granskningen är klar.
Det löser inte processen snabbare, men det gör väntan begriplig och leder användarna till att förstå vad för aktioner de bör ta härnäst.
Hjälpen måste finnas där frågan uppstår
Många digitala tjänster har omfattande hjälpsidor men placerar dem långt från själva problemet. Användaren får först lämna sidan, öppna en FAQ och försöka formulera rätt sökord.
Det fungerar dåligt när frågan gäller något konkret som precis har inträffat. Och ett FAQ täcker sällan de flesta problem, och de som är så vanliga att de är nedskrivna borde istället fixas, inte formaliseras för att låta användarna fixa det.
Om ett dokument nekas bör informationen om godkända format finnas vid uppladdningsfältet. Om en transaktion behandlas bör förklaringen av statusen finnas bredvid den. Om ett lösenord behöver uppfylla vissa krav bör de visas innan formuläret skickas in, inte först efter att användaren har misslyckats. Samma grundprincip finns i Diggs rekommendationer för tillgängliga formulär, där tydliga ledtexter ska förklara vad varje fält används till.
Detta brukar kallas kontextuell hjälp, men principen är enkel: svaret placeras där behovet uppstår. Det är inte lika bra som bra design, men många steg bättre än ett separat FAQ. Det är en skylt som säger att dörren med ett platt handtag öppnas utåt, en FAQ är att låta användaren själv lista ut det efter de redan har gjort “fel”. Bra design är ett handtag som tyder på att man dra i den.
Färre frågor betyder inte mindre kundkontakt
Målet är inte att göra det svårt att nå supporten eller att pressa ned antalet kontakter till varje pris. Vissa ärenden kräver mänsklig bedömning, och då ska vägen dit vara tydlig.
Skillnaden ligger i vilken sorts frågor som når fram.
När enkla oklarheter löses direkt i gränssnittet kan supportmedarbetarna lägga mer tid på ärenden som faktiskt kräver undersökning, förklaring eller samordning. Kunden slipper köa för att få veta vad en status betyder, medan supporten slipper besvara samma grundfråga om och om igen. Ännu bättre om oklarheterna uppfattas och till slut fixas.
Det minskar stressen på båda sidor. Kundservice ska inte vara ett konstant plåster för dålig programmering eller design.
De bästa supportmiljöerna märks knappt när allt fungerar. De förebygger frågan, förklarar avvikelsen och visar nästa steg. Först när det inte räcker eller något fel händer tar en människa över, med tillräckligt mycket information för att faktiskt kunna hjälpa.
