SLA-policyer i kundtjänst – så fungerar de

Ett serviceavtal (service level agreement, SLA) är ett löfte om hur snabbt du ska svara på och lösa förfrågningar. En SLA-policy är hur din helpdesk upprätthåller det löftet för varje ärende. De flesta policyer har samma delar:

• Villkor: vilka ärenden policyn gäller, till exempel utifrån kund, kanal eller typ av förfrågan
• Mål: tidsgränser för första svar, senare svar och lösning, oftast satta per prioritet
• Tider: om klockan räknar kontorstid eller kalendertimmar
• Pausregler: vilka statusar som stoppar klockan
• Åtgärder vid överträdelse: påminnelser innan ett mål missas och eskaleringar efteråt

Ordningen spelar roll när du har flera policyer. Zendesk kör först triggers, jämför sedan ärendet med sina SLA-policyer uppifrån och ned i listan och tillämpar den första vars villkor uppfylls. Lägg specifika policyer, till exempel en för enterprise-kunder, ovanför generella. Zendesk kräver också att ärendets prioritet är satt i systemets standardfält för prioritet; ett anpassat prioritetsfält matchar inte en policy.

Zendesk definierar next reply time som tiden mellan den äldsta obesvarade kundkommentaren och agentens nästa publika kommentar. Zendesk erbjuder också ett mått för periodiska uppdateringar (periodic update), som mäter tiden mellan agentens publika kommentarer. För lösning har Zendesk tre mått och rekommenderar att du bara väljer ett per policy: requester wait time (tid i New, Open och On-hold), agent work time (tid i New och Open) och total resolution time (hela livscykeln från att ärendet skapas tills det är löst).

Freshdesk sätter mål för first response, every response och resolution per prioritet i varje SLA-policy. I Jira Service Management är varje SLA en namngiven timer: du definierar när den startar, pausas och stoppas och lägger sedan till mål som använder JQL för att välja vilka förfrågningar de gäller, med tidsmål skrivna som 4h 30m.

Kontorstid räknar bara tid inom ditt arbetsschema; kalendertimmar räknar varje timme varje dag. Zendesk låter dig välja kontorstid eller kalendertimmar för varje prioritet i en policy. Freshdesk frågar om varje SLA ska använda den kontorstid du har ställt in eller kalendertimmar (24x7). Jira Service Management kopplar en kalender till varje mål, med tidszon, arbetsdagar och arbetstider samt helgdagar.

Ett mål på 4 timmar i kontorstid för ett ärende som skapas sent på fredagen kanske inte förfaller förrän på måndagen. Det är rättvist mot ditt team, men det är inte så kunden upplever det, så använd kalendertimmar för alla prioriteter där du lovar täckning dygnet runt.

Paus är den andra halvan. Tid då ni väntar på kunden bör oftast inte räknas mot er, och varje verktyg hanterar det på olika sätt:

• Zendesk: requester wait time pausas i Pending; agent work time pausas i Pending och On-hold; total resolution time pausas inte vid någon statusändring förrän ärendet är löst.
• Freshdesk: statusen Pending pausar SLA-timrarna, och du kan stänga av SLA-timern för vilken status som helst, även anpassade som Waiting on Third Party. Ärenden med avstängd timer visas som On Hold, och när kunden svarar flyttas ärendet tillbaka till Open och klockan fortsätter.
• Jira Service Management: en SLA kan ha pausvillkor, till exempel medan ni väntar på att kunden ska svara, utöver sina start- och stoppvillkor.

En SLA är bara användbar om någon agerar innan den missas. Ställ in en varning före tidsfristen och en eskalering efter den:

• Zendesk: bygg en automatisering med villkoret Hours until next SLA breach för att avisera ett team eller en person när ett ärende är nära att överskrida sin SLA. Automatiseringar körs en gång i timmen, så larmet kan komma upp till en timme före eller efter tröskeln, aldrig exakt i rätt ögonblick. I Zendesks exempel läggs en tagg till i samma automatisering så att den bara körs en gång per ärende.
• Freshdesk: varje SLA-policy kan påminna agenter från 5 minuter till 4 timmar innan ett mål för första svar eller lösning förfaller, och eskalera när ett mål överskrids till den tilldelade agenten eller andra personer du väljer, till exempel en teamledare. Båda ställs in under Admin > Workflows > SLA Policies.
• Alla verktyg: skicka larm om överträdelser dit ditt team faktiskt tittar, till exempel en Slack-kanal, och inte bara till mejl.

• Zendesk: skapa SLA-policyer med villkor och mål per prioritet, välj kontorstid eller kalendertimmar för varje prioritet och ordna listan så att specifika policyer kommer först. Lägg till en automatisering för larm när en överträdelse närmar sig.
• Freshdesk: under Admin > Workflows > SLA Policies anger du mål för first response, every response och resolution per prioritet, väljer kontorstid eller kalendertimmar och lägger sedan till påminnelser och eskaleringar. Bestäm i inställningarna för ärendestatusar vilka statusar som stänger av SLA-timern.
• Jira Service Management: skapa varje SLA med start-, paus- och stoppvillkor. Flera startvillkor fungerar som OR, och SLA:n stoppas så snart något stoppvillkor uppfylls. Lägg sedan till mål som väljer förfrågningar med JQL, ange ett tidsmål och välj en kalender.

Oavsett verktyg: börja med en policy och några prioriteter, kör den i några veckor och jämför sedan faktiska tider till första svar och lösning med målen innan du skärper dem.

TascaLab sätter upp SLA-relaterad automatisering ovanpå Zendesk, Freshdesk och Jira: routning som sätter prioritet så att rätt policy tillämpas, larm om överträdelser till Slack och schemalagda SLA-rapporter. Relevanta engångspriser är Ticket Routing & Categorization (7 700 kr), Automated Reports (6 900 kr) och Custom Automation (från 11 900 kr). Projekten inkluderar grundläggande dokumentation, 30 dagars support efter lansering och inga dolda avgifter, och de flesta tar 1–3 veckor. Börja med ett kostnadsfritt Health Check-samtal på 30 minuter.