For mange år siden arbejdede jeg som IT-tekniker. Det var før jeg læste psykologi og jeg har ofte tænkt, at de erfaringer, jeg fik i det job, var med til at skubbe mig i retning af psykologistudiet. For der var noget spændende og udfordrende ved at skulle løse problemer, hvor den eneste beskrivelse, jeg fik, var: “Jeg har ikke gjort noget, men nu er den helt gal!?”.
Det krævede i virkeligheden en uddannelse som detektiv at finde frem til, hvad årsagen til problemet var. For årsagen var jo et sted: Det kunne være en utilsigtet handling, en fejl et helt andet sted i systemet eller en kollega, der havde gjort noget.
“Context is king”
Når brugeren ikke kan sige, hvad der er sket, er man nødt til at kigge på konteksten: Hvornår skete det, hvad var det sidste, brugeren gjorde, og hvad var brugeren i gang med at gøre. Man må lave kvalificerede gæt og se, om man kommer tættere på en forklaring på, hvad der skete.
Derfor er konteksten afgørende. Men at forstå en anden persons kontekst over telefonen er svært – meget svært endda.
Mit bedste trick er at genskabe brugerens kontekst: Navigere hen til det samme sted i programmet, hvor det gik galt, hvad var brugeren i gang med og hvad prøvede brugeren at opnå? At genskabe konteksten kan give den nødvendige indsigt i, hvad årsagen er, så du kan løse problemet.
Andre gange er der ikke nogen vej udenom: Man er nødt til at tage ud til brugeren og se med egne øjne, hvad der er galt. Det tager længere tid – til gengæld bliver brugeren ofte meget glad for, at problemet bliver taget så alvorligt, at du ligefrem kommer forbi.
I de tilfælde, hvor jeg ikke kan forstå konteksten godt nok til at gennemskue, hvad der er sket, og hvor jeg ikke har tid til at køre ud til brugeren, er min bedste løsning stadig: “Har du prøvet at genstarte?”. Og ja, det løser overraskende ofte problemet!
Mine bedste supporthistorier
Jeg har samlet mine bedste supporthistorier. Nogen af dem kunne løses nemt, andre blev løst, da jeg genskabte brugerens kontekst og en god håndfuld krævede en køretur ud til brugeren.
Eksemplerne er ikke for at vise, at brugere lyver eller at de er dumme. Eksemplerne viser, at de ikke ved nok om det, de faktisk gør, eller hvad der sker, til at de kan sætte ord på det. Så den forklaring, du får af problemet, kan du bruge til lige præcis ikke en dyt. Det er nemlig en, de har fundet på for at forklare problemet – ikke en, der beskriver problemet.
Jeg håber, at de kan give lidt inspiration til måder, du kan finde frem til problemet på – og måske et godt grin.
“En kunde ringede en dag og sagde, at deres nye computer ikke kunne starte. Alt var som det skulle være. Men de havde ikke trykket hårdt nok på startknappen… Det tog kun en køretur på 3 timer hver vej at løse det problem.”
“En kunde ringede og sagde, at deres backupsystem ikke ville starte. De havde trykket flere gange på startknappen, der sad på tastaturet. Det var bare det forkerte tastatur, de havde trykket på. Det havde jeg meget sjov ud af, men det var selvfølgelig heller ikke mig men min kollega, der blev kaldt ud til denne hastesag en fredag sidst på eftermiddagen.”
“”Den VPN-router, I har solgt os, er ustabil”, ringede en meget frustreret kunde og sagde. Routeren gik ned hver nat og det gav problemer med at genetablere VPN-forbindelsen. Det var noget ustabilt skrammel, vi havde solgt ham. Det var han helt overbevist om! Årsagen var en helt anden: Strømstikket til routeren sad i den kontakt, som rengøringen brugte til støvsugeren hver nat kl 04.00.”
