Flowchart for eskalering i kundesupport (beslutningstræ)

Sådan fungerer det

1. Navngiv de fire beslutningstagere

   Erstat Førstelinjemedarbejder, Supportteamleder, Kundeansvarlig og Vagthavende leder med de roller, der findes hos jer. Små teams slår ofte kundeansvarlig sammen med teamlederen; organisationer med vagtdækning uden for normal arbejdstid holder typisk den vagthavende leder adskilt, fordi rollen skifter efter vagtplan. Hver bane skal være en person, der kan fanges, og som har beføjelsen — ikke et afdelingsnavn.

2. Skriv ned, hvad førstelinjens råderum betyder

   'Inden for førstelinjens råderum?' afgør, hvor stor en del af jeres volumen der aldrig eskalerer, og fortjener derfor en skreven definition. Afgræns den efter kompetence frem for efter indsats: en udgivet vejledning, en dokumenteret konfigurationsændring eller en standardhandling på kundens konto er inden for råderummet — alt, der kræver kode, adgang til produktionsdata eller en kontraktlig indrømmelse, ligger uden for pr. definition, uanset hvor gerne medarbejderen vil forsøge.

3. Sæt SLA-triggeren før fristen

   Beslut, hvor stor en andel af den resterende svar- eller løsningstid der udløser 'Er SLA-målet i fare?', og aftal det på forhånd, så værktøjet kan udløse den automatisk. Hele værdien af grenen er, at den kører, mens målet stadig kan nås. En trigger sat ved selve fristen fortæller kun, at løftet allerede er brudt.

4. Fastlæg listen over beskyttede kunder på forhånd

   'Strategisk eller beskyttet kunde?' skal kunne besvares fra CRM'et på sekunder. Vedligehold en eksplicit liste, og skriv, hvad der gør en kunde beskyttet: udpeget strategisk status eller svar- og løsningstider skrevet ind i aftalen. At afgøre det fra sag til sag er præcis det, der lader den mest højlydte kunde — frem for den vigtigste — få prioriteret behandling.

5. Aftal triggerne for eksponering med juridisk

   'Omdømme- eller juridisk eksponering?' er grenen, der tilsidesætter alle andre tests, så kriterierne bør godkendes uden for support: personoplysninger eksponeret, en myndighed eller revisor involveret, en sikkerhedsrisiko, et offentligt opslag eller en presseforespørgsel, eller en kontraktlig bod i spil. Hold listen så kort, at den kan huskes under pres, og lad hver enkelt trigger være tilstrækkelig i sig selv.

6. Aftal, hvad der tæller som bekræftet fejl og en acceptabel workaround

   Sæt en dokumentationstærskel for 'Bekræftet produktfejl?' — for eksempel reproduceret på en understøttet version med trin, en anden udvikler kan følge — så ureproducerede rapporter går til tier 2 til diagnose frem for til udvikling. Beslut derefter, hvem der vurderer en workaround acceptabel. Ligger den vurdering kun hos support, vil udfaldet 'Registreret som fejl, ikke eskaleret' blive bestridt af kunder, der aldrig har accepteret den.

Ofte stillede spørgsmål

Hvordan adskiller dette sig fra et procesdiagram for eskalering i kundesupport?

Et procesdiagram er en rækkefølge: registrer sagen, visiter den, arbejd på den, løs den, luk den — med baner, der viser, hvem der udfører hvert trin. Dette diagram er et beslutningstræ, så dets rygrad er en kæde af spørgsmål frem for en kæde af opgaver, og dets grene ender i fem forskellige navngivne udfald i stedet for at samles i ét lukketrin. Brug procesdiagrammet til at se hele sagens livscyklus, og brug dette træ på det ene punkt i livscyklussen, hvor nogen skal vælge en vej. De to supplerer hinanden: procesdiagrammet for incident management viser, hvor eskaleringsbeslutningen ligger, og dette diagram viser, hvordan den træffes.

Hvornår bør en supportsag eskaleres?

Når en af et lille antal skrevne tests svarer ja — ikke når sagen blot har været åben længe. Fem af diagrammets otte tests afgør, om der overhovedet skal eskaleres: sagen ligger uden for første linjes kompetence, ingen dokumenteret løsning løser den, SLA-målet er i fare, kunden er strategisk eller kontraktligt beskyttet, eller der er omdømme- eller juridisk eksponering. De tre øvrige afgør, hvor den skal hen. Forløbet tid er en god trigger til at gense en sag, men en dårlig trigger til at eskalere den alene, fordi den flytter arbejde uden at tilføre nogen kompetence, sagen faktisk manglede.

Hvad er forskellen på at eskalere til tier 2 og at eskalere til en leder?

De løser forskellige problemer, og ITIL skelner mellem dem som funktionel og hierarkisk eskalering. Funktionel eskalering flytter en sag til personer med mere specialiseret viden eller dybere systemadgang — det er, hvad 'Eskaleret til tier 2-support' og 'Eskaleret til udvikling som fejl' repræsenterer her. Hierarkisk eskalering inddrager nogen med større beføjelse til at genforhandle kundens forventninger, godkende en undtagelse eller frigive ressourcer — det er, hvad udfaldene med kundeansvarlig og vagthavende leder repræsenterer. En sag kan have brug for begge dele. At sende en sag op ad ledelseslinjen, når den i virkeligheden mangler en specialist, spilder en leders tid og flytter ikke sagen.

Skal enhver bekræftet produktfejl eskaleres til udvikling?

Nej, og at behandle enhver fejl som en eskalering er præcis den måde, eskalering mister sin betydning på. Dette diagram deler sig på 'Findes der en workaround?'. Uden en acceptabel workaround er kunden blokeret, så sagen ender i 'Eskaleret til udvikling som fejl' og bærer driftspåvirkende prioritet. Med en workaround sender medarbejderen den til kunden, og sagen ender i 'Registreret som fejl, ikke eskaleret': fejlen når stadig frem til udvikling gennem den normale modtagelse og prioritering af fejl — den afbryder bare ingen. Det andet udfald er bevidst tegnet som en afvisningsterminator, fordi det at beslutte ikke at eskalere er et legitimt resultat af vurderingen og bør registreres som ét.

Hvem må sige nej til en eskalering?

Den, der ejer den test, som fejlede — det er derfor, banerne i dette diagram er beslutningsbeføjelser og ikke afdelinger. Teamlederen kan afvise en sag, der falder igennem testene for eksponering, SLA og fejl, og sende den tilbage til første linje. Den kundeansvarlige, ikke support, afgør om en kunde er beskyttet. Den vagthavende leder afgør, om en kunde er kritisk, og spørges først, når eksponeringen allerede er fastslået — det holder rollen fri til reelle kommandosituationer. Eskaleringer, der afvises uden en registreret begrundelse, er dem, der kommer tilbage, så notér hvilken test der fejlede, på sagen.