Flowchart for eskalering i kundeservice: niveau 1 til niveau 2

Sådan fungerer det

1. Omdøb banerne til jeres rigtige roller

   Erstat Kunde, Niveau 1-support, Niveau 2 / specialist, Supportchef og Udvikling med de funktioner, I faktisk har. Små teams slår typisk niveau 2 sammen med udvikling, og teams med navngivne kundeansvarlige deler ofte supportchef-banen op i en vagthavende chef og en kundeansvarlig. Behold kundebanen, selvom den kun rummer to noder — det er præcis dér, kunden og ikke jer styrer flowet.

2. Definér, hvad niveau 1 må

   'Løst på niveau 1?' har brug for både et mandat og en tidsgrænse: hvilke systemer en medarbejder må tilgå, hvilke handlinger vedkommende må foretage, og hvor længe et forsøg på niveau 1 løber, før sagen går videre. Uden begge dele svinger mængden af eskaleringer med, hvem der har vagten. Skriv eksplicit, at det er det rigtige udfald at eskalere inden for tidsgrænsen — ellers holder folk på sager for at beskytte deres tal.

3. Fastlæg indholdet af overleveringsnotatet

   Beslut, hvad 'Skriv overleveringsnotat' skal indeholde, og gør det til en skabelon i jeres helpdesk: berørt kunde og miljø, trin til at genskabe fejlen, hvad der er prøvet og udelukket, konsekvensen for kunden, og hvad kunden allerede har fået at vide. En overlevering, der er klippet ind fra en chattråd, er den klart hyppigste grund til, at specialisten gentager den første times arbejde.

4. Skriv objektive kriterier for den kritiske gren

   'Kritisk eller nøglekunde?' må ikke afhænge af, hvor højt kunden skrev. Brug betingelser, I kan tjekke: en blokeret forretningskritisk arbejdsgang, en navngiven strategisk kunde, en kontraktlig svarfrist i fare, eller en sag der allerede er genåbnet én gang. Skriv, hvem der orienteres ved hvert kriterium, og at en orientering ikke i sig selv rykker sagen frem i køen — ellers bliver alt kritisk.

5. Beslut, hvad der sker, når udvikling ikke kan rette det endnu

   Når en fejl først er accepteret, følger den udviklingens releasekadence, som er langsommere end supportens. Bliv enige om, hvem der ejer kundeforholdet i den periode, hvor ofte der sendes en opdatering — også når der ingen nyheder er — og om I lover en målrelease frem for en dato. Grenen 'Ikke endnu' findes netop for, at den midlertidige løsning bliver en udtrykkelig aftale med kunden i stedet for tavshed.

6. Aftal reglen for genåbning, og udgiv derefter en versioneret udgave

   Skabelonen sender en mislykket bekræftelse tilbage gennem overleveringstrinnet, så en genåbnet sag bliver dokumenteret og vurderet på ny frem for at lande i en kø. Lav det om, hvis genåbninger hos jer skal tilbage til den seneste ejer direkte. Gå derefter diagrammet igennem med hver bane, ret trinnene til det, folk faktisk gør, og udgiv det som den gældende version med en godkendelse, så enhver senere læser ved, hvilken revision der var i kraft.

Ofte stillede spørgsmål

Hvad er en eskaleringsproces i kundeservice?

Det er den dokumenterede vej, en supportsag følger, når niveau 1 ikke kan løse den. Den dækker ikke hele sagsforløbet, men netop den del, der begynder ved grænsen for, hvad niveau 1 kan: beslutningen om at eskalere, overleveringen til en specialist, en ny vurdering af alvorlighed og SLA-påvirkning nu hvor sagen vil tage længere tid, selve undersøgelsen, og den bekræftelse og evaluering, der lukker sagen. Værdien ligger ikke i de enkelte trin, som de fleste teams allerede udfører, men i at blive enige om, hvem der ejer sagen hvornår, og hvad der skal skrives ned, før den skifter hænder.

Hvornår skal en supportsag eskaleres fra niveau 1 til niveau 2?

Brug betingelser, en medarbejder kan tjekke — ikke skøn. De tre, der dækker de fleste sager, er: medarbejderen mangler den adgang eller det værktøj, diagnosen kræver; symptomet ligger uden for det dokumenterede mandat på niveau 1; eller tidsgrænsen for et forsøg på niveau 1 er udløbet uden en løsning. En fjerde, som bevidst holdes adskilt, er, at sagen kræver en beslutning, kun andre kan træffe, for eksempel en kreditnota eller en kontraktlig indrømmelse. Det, der ikke bør være et kriterium i sig selv, er, at kunden beder om at få sagen eskaleret — så bliver niveaufordelingen til en forhandling. Håndtér den anmodning gennem orienteringsgrenen i stedet.

Hvad er forskellen på funktionel og hierarkisk eskalering?

Funktionel eskalering flytter sagen sidelæns til en med mere fagligt overblik, for eksempel når niveau 1 giver den videre til en specialist. Hierarkisk eskalering flytter den opad til en med mere beslutningskraft eller mere overblik, for eksempel når supportchefen og den kundeansvarlige orienteres. De løser hver sit problem, og begge optræder i diagrammet som selvstændige grene: eskaleringsgrenen ud af 'Løst på niveau 1?' er funktionel, og den kritiske gren ud af 'Kritisk eller nøglekunde?' er hierarkisk. Den klassiske fejl er at gøre det ene og gå ud fra, at det dækker det andet — så sidder en specialist i stilhed med en sag, den kundeansvarlige først hører om fra kunden.

Hvordan adskiller det sig fra incident management?

Eskalering flytter én kundes sag til nogen, der er bedre placeret til at løse den. Incident management genskaber en service for alle, der er ramt af den samme fejl. Både udløseren, uret og succeskriteriet er forskellige: en eskaleret sag måles på, om netop den kunde er løst og har bekræftet det, mens en hændelse måles på, hvor hurtigt driften er tilbage. Når flere eskalerede sager viser sig at pege på samme fejl, overtager incident-processen, sagerne kobles til den, og de lukkes, når driften er genskabt, og hver kunde har bekræftet. Netop den adskillelse er det, der forhindrer en servicedesk i at køre et nedbrud som halvtreds parallelle undersøgelser.

Hvem ejer sagen efter eskaleringen, og hvad skal overleveringen indeholde?

Ejerskabet af undersøgelsen flytter til specialisten, mens ejerskabet af kundeforholdet typisk bliver hos den oprindelige medarbejder — og det afspejler diagrammet ved at vende tilbage til niveau 1 for 'Bekræft løsningen med kunden'. Aftal den opdeling eksplicit, for en sag, hvor begge parter tror, at den anden opdaterer kunden, er den hyppigste kilde til tavshed. Overleveringsnotatet skal bære berørt kunde og miljø, trin til at genskabe fejlen, hvad der er prøvet og udelukket, konsekvensen for kunden, og hvad kunden allerede har fået at vide. Hold det som ét dokument frem for en tråd, så en genåbnet sag, der passerer samme trin igen, lægger til én samlet historik.