En delad inkorg fungerar tills den slutar göra det. Brytpunkten kommer när ingen längre vet vilka mejl som är besvarade, två personer råkar svara samma kund olika, och den som var sjuk i en vecka har trettio olästa ärenden som ingen tog över.
Ärendehantering löser det genom att göra varje fråga till ett objekt med ägare, status och historik.
Kön ger ansvaret en adress
Det första ett ärende behöver är en kö. En kö är en definierad grupp som äger sina ärenden, till exempel support, teknik, order eller ekonomi.
Poängen är inte att sortera för sorterandets skull. Det är att ansvar som ligger på alla inte ligger på någon. Ett ärende i en kö plockas upp av någon i den kön, och blir det liggande syns det i just den kön och inte i ett gemensamt hav.
Triagen, alltså det första beslutet om vart ärendet hör, är därför det viktigaste momentet i hela flödet. Går den fel förbrukas hela den utlovade svarstiden på att skicka ärendet rätt.
Statusar som säger vem som väntar
Den vanligaste designmissen är statusar som bara beskriver hur långt arbetet kommit. Det som faktiskt behövs är att kunna se vem som är nästa part att agera.
| Status | Vem som är nästa part |
|---|---|
| Ny | Vi, ingen har tagit i den |
| Pågående | Vi, någon arbetar |
| Väntar på kund | Kunden |
| Väntar internt | Vi, men på någon annan |
| Löst | Ingen, invänta bekräftelse |
| Stängd | Ingen |
Skillnaden mellan väntar på kund och väntar internt avgör två saker samtidigt: om SLA-klockan ska ticka, och om ärendet ska ligga kvar i handläggarens lista. Utan den uppdelningen blir uppföljningen orättvis, och den som ställer många frågor till kunden ser sämst ut i statistiken.
SLA mäter två saker
Ett serviceavtal utlovar normalt två tider:
- Första svarstid: hur snabbt kunden får ett bemannat svar. Ett automatiskt kvittensmejl räknas inte.
- Åtgärdstid: hur snabbt problemet är löst.
Tiderna varierar med prioritet, och prioriteten bör sättas av två faktorer i kombination: hur allvarlig påverkan är och hur många som berörs. Ett stopp i produktionen hos en kund är inte samma sak som en fråga om en inställning, även om båda kom in samtidigt.
Kopplingen till avtal är det som gör SLA meningsfull. En kund med premiumavtal ska få sin avtalade svarstid utan att någon minns vilka kunder som har vilket avtal.
Eskalering behöver en mottagare
När tiden håller på att ta slut ska något hända. En eskalering som bara innebär en röd markering i en lista är ingen eskalering, den är en påminnelse.
Fungerande eskalering flyttar ärendet till någon med annan kompetens eller mandat, eller höjer prioriteten så att det går före annat. Båda kräver att det finns någon som tar emot, och att den personen vet att det är deras jobb.
Vad man bör mäta
Fyra tal räcker för att se om ärendehanteringen mår bra:
- Andel inom SLA, uppdelat på svarstid och åtgärdstid.
- Antal öppna ärenden per kö, som visar var det växer.
- Andel som löses vid första kontakten, som säger något om kompetensen i första ledet.
- Återöppnade ärenden, som avslöjar ärenden som stängdes för tidigt.
Det fjärde är underskattat. En kö som stänger snabbt och återöppnar mycket har inte hög produktivitet, den har en mätning som belönar fel sak.
I Fluit
Fluit har ärenden med kö, ägare, bevakare, taggar och kommentarer, samt ett statusflöde som skiljer på att arbeta, vänta på kund och vänta internt. SLA-policyer sätter tiderna, och triagen fördelar inkommande ärenden till rätt kö.
Ärenden kan skapas ur inkorgen från inkommande meddelanden, och som service- eller RMA-ärenden kopplade till order och artiklar. Det sista är skillnaden mot ett fristående supportverktyg: den som svarar ser vad kunden köpt och när det levererades, utan att fråga.
