Helpdesk eller servicedesk?
Orden används om vartannat, men de beskriver olika ambitionsnivåer.
En helpdesk är reaktiv. Något går sönder, någon anmäler det, någon åtgärdar det. Funktionen fungerar bra så länge volymen är hanterbar och kraven låga.
En servicedesk är kontaktytan för hela IT-leveransen. Utöver fel hanterar den beställningar ur en tjänstekatalog, behörigheter, förändringar och uppföljning mot överenskomna svarstider. Den är därmed en av kärnfunktionerna inom ITSM.
De flesta organisationer börjar i det första och växer in i det andra. Problemet uppstår när volymen växer men arbetssättet inte gör det.
Den delade mejlkorgen och varför den slutar fungera
Nästan alla börjar där, och brytpunkten kommer sällan som en dramatisk händelse utan som en långsam försämring.
Ingen vet vad som är på gång. Två personer svarar på samma fråga, en tredje tror att någon annan tagit den.
Ingenting går att mäta. Hur många ärenden kommer in? Vilka återkommer? Var går tiden? Utan registrering blir prioritering en känslofråga.
Kvaliteten varierar med personen. Samma fråga får olika svar beroende på vem som råkar svara. Det märks hos användarna långt innan det märks i statistiken.
Kunskapen sitter i huvuden. När någon slutar försvinner den, och introduktionen av nya medarbetare blir lång.
Så bör en servicedesk byggas upp
En väg in, flera kanaler
Användarna ska kunna höra av sig som de vill – e-post, portal, telefon, chatt eller Microsoft Teams – men allt ska landa i samma kö. Flera parallella ingångar utan gemensam kö är samma problem som den delade mejlkorgen, fast med fler ställen att glömma något på.
Kategorisering från början
Ett ärende som registreras utan kategori går inte att analysera i efterhand. Håll listan kort. En kategoristruktur med sextio val fylls i slarvigt och blir värdelös ändå.
Prioritering efter påverkan och brådska
Prioritet ska sättas av hur många som drabbas och hur bråttom det är, inte av vem som ringer. Det är en av de svåraste principerna att upprätthålla och en av de mest värdefulla.
En första linje som faktiskt löser saker
En första linje som bara vidarebefordrar är en fördröjning, inte en avlastning. Ge den mandat, dokumenterade rutiner och tillgång till kunskapsbasen.
Kunskapsbas kopplad till ärendeflödet
Lösta ärenden blir artiklar, artiklar blir färre ärenden. Det fungerar bara om artikeln kan skrivas i samma ögonblick som ärendet löses. Hur strukturen bör se ut går vi igenom under IT-dokumentation.
Självservice för det repetitiva
Lösenordsåterställningar, behörigheter och standardbeställningar behöver sällan en människa. En portal med tjänstekatalog och godkännandeflöden tar bort just de ärenden som är minst utvecklande att arbeta med. Steget därefter är automation av själva utförandet.
SLA som följs upp löpande
Svars- och lösningstider kopplade till ärendetyp och prioritet, med automatisk eskalering innan tiden löper ut. Uppföljning i efterhand talar bara om vad som redan gått fel.
Servicedesk internt eller mot kund?
Funktionen ser likadan ut men systemkraven skiljer sig, och det är här felvalen görs.
Mot den egna organisationen ligger tyngdpunkten på ITIL-processer, tjänstekatalog, tillgångar och intern uppföljning.
Mot externa kunder som betalar faktura tillkommer avtal, tid, prislistor och fakturering. Ett rent ärendesystem klarar inte den delen – där behövs ett PSA-system, och det som saknas hanteras annars i ett kalkylblad vid sidan av.
Mot kunder i en kundtjänstroll, alltså support på en produkt snarare än på IT, ligger tyngdpunkten i stället på svarstider, kundnöjdhet och många kanaler.
Vi levererar plattformar för alla tre. Skickar den som hör av sig en faktura till er, eller får den en från er? Det är oftast den frågan som avgör.
