Flowchart for eskalering i kundesupport (beslutningstræ)

Hvad er flowchart for eskalering i kundesupport (beslutningstræ)?

Denne side er et beslutningstræ, ikke et procesdiagram. Et procesdiagram svarer på, hvad der sker bagefter, og hvem der gør det, fra registreret sag til lukning. Et beslutningstræ svarer på et smallere og langt mere omstridt spørgsmål inde i den proces: bliver denne konkrete sag i første linje, og hvis ikke, hvem tager den så? Til det samlede forløb med registrering, prioritering, håndtering af større hændelser og lukning bruger I flowchartet for incident management. Til utilfredshed med servicen frem for en fejl i den bruger I flowchartet for kundeklageprocessen. Brug dette diagram, når uenigheden handler om selve vejvalget.

Eskalering går galt i to modsatte retninger, og begge er dyre. Eskalerer I for let, bliver tier 2 til endnu en kø for sager, første linje kunne have lukket: det hæver omkostningen pr. sag og forlænger ventetiden for de sager, der reelt har brug for en specialist. Eskalerer I for sjældent, hører en kontraktligt beskyttet kunde om et brudt løfte fra sine egne brugere. Ingen af de to fejl løses med mere opsyn. De løses med skrevne tests (her otte af dem), som hver især kan besvares ud fra sagen og kundeoplysningerne frem for ud fra, hvordan samtalen føles.

Banerne navngiver beslutningsbeføjelser, ikke afdelinger. Førstelinjemedarbejderen afgør råderummet og om en dokumenteret løsning rent faktisk virker. Supportteamlederen ejer testene for eksponering, SLA og fejl. Den kundeansvarlige besvarer, om kunden er strategisk eller kontraktligt beskyttet. Den vagthavende leder besvarer ét spørgsmål (om en kritisk kunde er ramt) og først når eksponeringen allerede er fastslået. At køre testene i den rækkefølge betyder, at den højeste beføjelse vinder: en sag med juridisk eksponering kan ikke stille og roligt lægge sig selv i udviklings backlog.

Hvad dette flowchart dækker

I denne skabelon

• En port i første linje, før eskalering overhovedet overvejes: både 'Inden for førstelinjens råderum?' og 'Løser en dokumenteret løsning den?' skal svare Ja for at nå udfaldet 'Løst i første linje'. Et Nej i én af dem sender sagen til 'Teamlederen vurderer eskaleringen'
• Eksponering testes først, ikke sidst. Et Ja i 'Omdømme- eller juridisk eksponering?' går direkte til 'Er en kritisk kunde ramt?' i den vagthavende leders bane, hvor Ja ender i 'Vagthavende leder tager kommandoen' og Nej i 'Kundeansvarlig overtager sagen'
• 'Er SLA-målet i fare?' deler sig i I fare og Inden for målet: I fare drejer om ad kundetesten, før der overhovedet vælges teknisk vej, mens Inden for målet går direkte videre til fejlspørgsmålet
• 'Strategisk eller beskyttet kunde?' ligger i den kundeansvarliges bane. Ja ender i 'Kundeansvarlig overtager sagen'; Nej går tilbage til den tekniske vej i stedet for at åbne endnu en parallel kø
• Den tekniske vej gennem 'Bekræftet produktfejl?': Nej ender i 'Eskaleret til tier 2-support', mens Ja går videre til 'Findes der en workaround?', hvor Nej ender i 'Eskaleret til udvikling som fejl'
• Et bevidst udfald uden eskalering: findes der en workaround, sender medarbejderen den til kunden, og sagen ender i 'Registreret som fejl, ikke eskaleret', så fejlen ryger i udviklings normale backlog i stedet for at bruge en eskalering

Hvornår du skal bruge skabelonen

• Eskalering i jeres team afgøres af temperament, og to medarbejdere håndterer den samme sag forskelligt
• Tier 2 eller udvikling skubber tilbage på kvaliteten af eskaleringerne, og I har brug for aftalte adgangskriterier frem for en strengere tone
• De kundeansvarlige hører gentagne gange om alvorlige sager fra kunden, før de hører om dem internt
• I skriver eller reviderer en eskaleringspolitik og vil have tests og beslutningsbeføjelser aftalt, før nogen formulerer teksten
• I introducerer nye supportmedarbejdere og har brug for én side, der viser, hvornår der eskaleres og til hvem, som supplement til det samlede procesdiagram

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.