ITSM - Processer og Værktøjer

• Opret altid en ny kommentar, hvor du opsummerer problemstillingen og beskriver, hvad der forudgående er gjort i forsøg på løsning (benyt evt highlight entry knappen for fremhævelse af kommentaren). Hermed hjælper du din kollega med et hurtigt overblik, så denne hurtigere kan igangsætte en løsning.  

• Hold altid en god tone i kommentartråden. Vi er 300 operators, hvoraf mange tilsvarende er slutbrugere, så skriv ikke noget, der ikke kan tåle at blive læst af alle.  

• Alle handlinger, du foretager dig på sagen, skal du dokumentere med en ny kommentar. F.eks. at man har forsøgt at kontakte slutbrugeren, har gentestet fejlen, udstyr er modtaget i supporten, tjekket SDwiki, knowledgebase-artikler eller lignende. Med andre ord skal det være nemt for en kollega at danne sig et hurtigt overblik over, hvad der er sket på sagen. 

• Ved løsning af en sag, som du returnerer til en anden operator group eller operator, skal du altid oprette en ny kommentar, hvor du beskriver løsningen. En sag overdrages ikke til en operator group eller en operator ved blot at skrive “done”.  

• Som udgangspunkt er det supportens ansvar at kommunikere med slutbrugeren. Det gælder ved indhentning af supplerende oplysninger samt ved formidling af løsning.  

• Driften må dog gerne tage den direkte kommunikation med slutbruger – der kan være mange situationer, hvor det giver god mening.  

• Husk at ændre Target date, hvis sagen ikke forventes løst inden for denne dato. Det er vigtigt, da forfaldsdatoen er synlig for slutbruger. Ved oprettelse af nye sager er Target date som default sat til 13dg.  

• Hvis sagen eskaleres til anden operator group, så orienter brugeren om dette. 

• Den operator group/operator, der har fået tildelt sagen, har ansvaret for at kommunikere statusopdateringer ud til slutbrugeren. En statusopdatering til slutbrugeren kan fx være en længere behandlingstid, at sagen overdrages til anden operator group eller afventer svar fra leverandør. Har du ikke tid til at løse sagen med det samme, så notér forventet behandlingstid i en kommentar så dine kollegaer kan videregive status til bruger på forespørgsel. 

• Hvis der skal rykkes for status på en sag, der ligger i en anden operator group, så opret først en kommentar på sagen. Hvis sagen haster, så send evt. en Teams-chat til den ansvarlige dispatcher i den pågældende operator group, om de kan angive et forventet løsningstidspunkt.  

• Dispatcheren i den enkelte operator group har overblikket over ferie og fravær, samt hvem der har tid til at løse problemet. Dette gælder også, når sagen skal retur til supporten efter en løsning er fundet i drift.  

• Sagen overdrages altid til den primære operator group, når den returneres til support (BSS IT, Health IT, ARTS IT, FA IT, Nat-Tech IT Team 1 (Aarhus), Nat-Tech IT Team 2 (Lokationer) . Audit Trail kan hjælpe med et overblik over hvilken operator group eller supportcenter sagen er startet i.  

• Hvis sagen sendes direkte til en operator, må dette KUN ske efter forudgående aftale. Fx hvis der allerede kører en dialog om løsning mellem 2 operators – brug sund fornuft.  

• Kategorien er vigtig, da den kan ses af slutbruger og tilsvarende er definerende for hvilken operator group en sag evt skal eskaleres til. Inden overdragelse kontrolleres det, at den tilføjede kategori matcher sagens beskrivelse.  

• Omhandler sagen flere problemer, som skal løses af forskellige operator groups, er det operators ansvar i support inden overdragelse at dele sagen op i flere partial tickets. 

• Ved ferie og fravær har dispatcheren ansvaret for at holde øje med, om der sker updates på sager eller om deadlines overskrides.  

Prioriteter:

I TOPdesk opererer vi med i alt 3 prioriteter. Som default sættes prioritet 3 på alle nyoprettede tickets. Prioritet 1 og 2 må KUN anvendes når det virkelig haster (se eksempler nedenfor). Hvis du sætter prioritet 1 eller 2 skal du ALTID begrunde i en kommentar, hvorfor sagen haster. Og du skal efter oprettelse af sagen kontakte dispatcher/teamleder i den modtagende operator group, hvor du gør opmærksom på, at sagen er oprettet, og at den haster.  

Eksempler på højprioritetssager
 

Prioritet 1 vælges, hvis fx:

• Det trådløse netværk er nede og der er digital eksamen i bygningen. 
• En større mængde brugere kan ikke tilgå mail/filshare/netværk/forretningskritisk applikation.  
• WAYF er tilsyneladende nede. Der kan ikke logges på Brightspace. 

Prioritet 2 vælges, hvis fx:

• Der er et nedbrud på udstyr i et auditorium og undervisning skal til at starte. 
• En studerende kan ikke aflevere en besvarelse til digital eksamen.  
• Der er konstateret mistænkelig trafik/adfærd på en brugers pc. 
• Tre kurser med ca. 150 studerende og 5 undervisere er ramt af problemer med adgang til deres kurser i Brightspace.  
• Ny medarbejder mangler arbejdscomputer.  
• En ekstern konsulent er fremmødt for at udføre en opgave og mangler oprettelse i systemer.  

Statusser:

Vi anvender i alt 6 statuskoder i TOPdesk, som operators aktivt skal sætte på sagen (New, Assigned, In Progress, Pending, Resolved, ready for pickup). Statuskoderne kan ses af slutbrugeren i portalen, så det er vigtigt, at disse benyttes korrekt. Udover disse 6 statusser er der en række statusser, som systemet selv sætter. Disse statusser skal operators IKKE aktivt benytte. 

Typer af statusser der anvendes af operators: 
 

New: Alle nye sager, der er oprettet i TOPdesk Client eller indkommet fra slutbruger via portalen eller mail.  

Assigned: Når du tildeler en sag til en agent, vil statussen stadig stå som “New”. Det er derfor vigtigt, at du sætter sagen til Assigned, når den dispatches til anden operator. I portalen vil slutbrugeren kunne se sagen som assigned men ikke til hvilken operator group eller operator.  

In Progress: Så snart en operator påbegynder løsning af en sag, skal sagen sættes til In Progress. Slutbrugeren vil kunne se, at sagen er påbegyndt.  

Pending:  Vi har 3 pending statusser. Pending user, Pending 3. party (fx en leverandør), Pending other. Slutbrugeren vil kunne se den angivne pending status på portalen. 

Resolved: Statussen bruges, når slutbruger har fået svar, og sagen er endelig løst. Når statussen sættes, går der en automatisk mail af sted til slutbruger om at sagen er løst. Slutbruger vil her fra kunne genåbne sagen i op til 30dg inden sagen endelig lukkes (closed).  

Ready for pick-up: Kan anvendes på fx indkøbssager, der ligger klar for afhentning 
 

Typer af statusser, som systemet selv sætter. Disse skal operators IKKE selv aktivt vælge: 
 

Closed: En sag bliver automatisk Closed efter at have været “Resolved” i 30 dg. En closed sag kan ikke genåbnes. Hvis slutbrugeren forsøger at svare på en closed sag, vil det generere oprettelse af en ny sag.  

Updated by user: Statussen bliver automatisk sat, når en bruger svarer på en sag. HUSK at ændre statussen til fx pending user, når du har svaret brugeren. Ellers vil den ”forstyrre” i overblikket over ”My updated tickets”. 

Reopened by user: Statussen bliver automatisk sat, når en bruger genåbner/svarer ind på en resolved sag inden for 30dg. 

Rejected: Statussen bliver automatisk sat, hvis et automatisk flow (fx adgang til en postkasse) er blevet afvist. 

• Vi hjælper hinanden ved altid at holde kommunikationen i TOPdesk - tænk på din kollega som i dit fravær skal overtage eller følge op på dine sager.  

• Notér i sagen i en kommentar, hvad du har foretaget dig i forbindelse med fejlsøgning.  

• Hvis en slutbruger henvender sig direkte via mail til en operator, så henvis til at sagen i stedet registreres i portalen. Et forslag til ordlyden af en svarmail på en direkte henvendelse kunne være: ” Tak for din mail. Jeg kan desværre ikke tage imod din henvendelse/supporthenvendelse i min personlige indbakke. Du bedes oprette en henvendelse via selvbetjeningsportalen, som du finder via dette link: support.au.dk. Herefter vil din henvendelse blive distribueret til en operator, der løser din sag. Mvh XXXX”  

• I de tilfælde hvor man indmelder fejl til leverandør via eksternt ITSM, registreres leverandørens sagsid i TOPdesk-sagen