Flowchart for eskalering i kundesupport (beslutningstræ) — Excel

Kort fortalt

• 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

Kildetabellen: Flowchart for eskalering i kundesupport (beslutningstræ)

Skriv ét trin pr. række i Excel. Brug en entydig nøgle, en beskrivelse, næste trin og en ansvarlig rolle. 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.

Overfør beskrivelsen til Box text, målet til Line to, grenens navn til Line text og den ansvarlige til Vertical lane. 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. Kontrollér alle grene og ansvarlige i diagrammet mod regnearket. Se også /da/guides/sadan-struktureres-excel-data-til-et-rutediagram.

Sådan fungerer det

1. Navngiv de fire beslutningstagere

   Skriv ét trin pr. række i Excel. Brug en entydig nøgle, en beskrivelse, næste trin og en ansvarlig rolle. 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

   Overfør beskrivelsen til Box text, målet til Line to, grenens navn til Line text og den ansvarlige til Vertical lane. '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

   Følg både normalforløb, afvisninger og tilbagekoblinger i det viste diagram, før du deler det. 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.

Faldgruber du skal undgå

• Manglende forbindelser

  En opgaveliste er ikke et procesdiagram, før hvert trin har en tydelig destination og beslutningerne har navngivne udfald. Eskalering i jeres team afgøres af temperament, og to medarbejdere håndterer den samme sag forskelligt

Ofte stillede spørgsmål

Kan jeg bruge min egen Excel-fil?

Ja. Tilpas kolonnerne til QueryCharts arkindtastning, og kontrollér destinationerne, når rækkerne ændres. 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.