Hvis dit team håndterer indgående forespørgsler, hvad enten det er kundesupportbilletter, IT-helpdesk-sager, kontraktgennemgange eller interne godkendelser, har du sandsynligvis en uformel fornemmelse af, hvad en acceptabel svartid ser ud. Et kritisk problem kræver opmærksomhed inden for en time. Et faktureringsspørgsmål fra en klient er vigtigere end et generelt spørgsmål. En billet, der kom ind i går morges og ikke er blevet rørt, er et problem.

Du bærer alt dette i hovedet. Det samme gør alle andre på teamet. Problemet er, at når det kun eksisterer i folks hoveder, er det usynligt på boardet. En billet, der har stået ubesvaret i fire timer, ser nøjagtig ud som en, der netop kom ind. Du skal læse hvert element for at vide, hvad der rent faktisk er i brand. Ting går galt. Og når noget går galt, er samtalen altid den samme: “Hvorfor flaggerede ingen det tidligere?”

Det er det SLA-sporing er meningen at løse. Og de fleste værktøjer tilbyder det teknisk. Men opsætningsprocessen har altid været det, der stopper teams fra at bruge det.

Konfigurationsmuren

Når du leder efter SLA i et typisk enterprise-værktøj, finder du et indstillingspanel, der antager, at du allerede ved, hvad du laver. Arbejdstid. Eskaleringskæder. Prioritetsmatricer. Brugerdefinerede brudregler pr. niveau. Tilknyttede notifikationsworkflows. Det er genuint kraftfuldt, hvis du har en dedikeret IT-administrator til at sætte det hele op, og genuint ubrugeligt, hvis du ikke har.

Så de fleste teams springer det over. De bruger forfaldsdatoer og håber på det bedste. Nogle bygger sporing i regneark. Nogle giver op og kører bare et morgenmøde for at se, hvad der har ventet for længe, hvilket betyder at tilføje et møde til et problem, der burde have en teknisk løsning.

Vi ønskede at ændre det. Ikke ved at gøre konfigurationen lettere. Ved at eliminere det meste af den.

Start med en skabelon, ikke et blankt ark

Det første vi byggede var et bibliotek af SLA-skabeloner organiseret efter branche og teamtype. IT-support, kundesucces, HR-helpdesk, juridisk gennemgang, faciliteter, softwareudvikling og mere. Hver skabelon kommer forudindlæst med de svar- og løsningsmål, der er standard for den type arbejde. Første svar inden for 1 time for kritiske problemer, 4 timer for høj prioritet, 24 timer for normal. Tal, der matcher virkelige forventninger frem for tal, du selv skal efterforske og begrunde.

Du vælger den skabelon, der passer bedst til din situation, justerer alt, der ikke passer, og du er færdig med konfigurationen. Det hele tager et par minutter.

Det lyder måske som en lille ting, men det fjerner den største barriere: det blanke ark. De fleste teams springer ikke SLA over, fordi de ikke ønsker det. De springer det over, fordi det at starte fra bunden føles som et projekt i sig selv.

En kolonne. Tre ting sker.

Her er den del, der stadig overrasker folk, første gang de ser det.

Du går til boardet, hvor du vil spore SLA. Du tilføjer SLA-kolonnen. Det er det.

Gript opretter automatisk tre sammenkædede kolonner: Status (SLA), Prioritet (SLA) og SLA-timeren selv. De er forbundet til hinanden og til din skabelon. Når du sætter en billets prioritet til Kritisk, ved timeren, at den har et svartidsvindue på 1 time. Når nogen ændrer status til Afventer bruger, stopper uret automatisk. Når status skifter til Løst, stopper timeren og resultatet registreres.

Du konfigurerer intet af det. Det er indbygget i forholdet mellem de tre kolonner.

Hvad boardet faktisk fortæller dig

Når SLA-kolonnen kører, kommunikerer dit board på en måde, det ikke kunne før. Du kan med et øjekast se, hvilke billetter der er nye og urørte, hvilke der venter på kunden, og hvilke der allerede har overskredet deres vindue. SLA-cellen viser en live-timer og en farvekodet bar i bunden. Mørk betyder, at uret stadig kører. Rød betyder, at vinduet er passeret.

Prioritet (SLA)-kolonnen håndterer logikken for, hvilket mål der gælder. En kritisk (P1) billet har et snævrere vindue end en høj (P2). Det samme board kan håndtere begge på samme tid, og systemet kender forskel uden at du gør noget ekstra.

Status (SLA)-kolonnen er adskilt fra din normale opgavestatus, og det er bevidst. Når en billet flyttes til Afventer bruger, holder uret pause. Den tid bør ikke tælle mod dit svartidsmål. Når den er Lukket, er den ude af køen helt. Disse tilstande har specifik betydning i SLA-konteksten, og de tre kolonner arbejder sammen for at spore dem korrekt.

Fejlbudget og Vandmelon-Detektor

Fejlbudget kommer fra software-pålidelighedsteknik. Det repræsenterer, hvor meget plads du har tilbage, før du misser dit SLA-mål for perioden. Hvis du forpligter dig til at løse 95% af billetterne til tiden og du er på 91,2%, fortæller dit fejlbudget dig, hvor mange flere misser du kan absorbere, før du falder under den tærskel. Teams med et sundt budget kan tage mere volumen på. Teams, der kører tæt på nul, skal enten sænke farten eller tilføje kapacitet. De fleste teams har ikke synlighed ind i dette, før det er for sent. Vi sætter det i forgrunden.

Vandmelon-Detektor er anderledes. Navnet kommer fra et almindeligt udtryk i forretningsverdenen: grøn på ydersiden, rød på indersiden. En vandmelonmåling er en, hvor tallene ser gode ud, men den underliggende virkelighed er anderledes.

I forbindelse med SLA er den klassiske vandmelonsituation denne: din score viser 96% af billetter løst til tiden, men din kundetilfredshedsvurdering er lav. Det, der typisk sker, er, at teams optimerer for den rapporterede måling. Hvis målingen er “lukkede vi teknisk set dette inden for 4 timer”, finder folk måder at teknisk lukke ting inden for 4 timer, selv når det faktiske problem ikke er løst.

Vandmelon-Detektor markerer dette hul. Når din SLA-score er høj men tilfredshedssignaler er lave, fremhæver vi det som en advarsel. Ikke som en anklage, og ikke som et definitivt svar på, hvad der gik galt. Bare som et signal, der er værd at være opmærksom på.

Ikke for IT-afdelinger. For alle.

Vi byggede dette til supportteams først, fordi det er den oplagte brugssag. Men nogle af de teams, der har fået mest ud af det, var slet ikke supportteams.

Interne IT-anmodningskøer. Juridisk kontraktgennemgang. Finansgodkendelsesworkflows. Overalt, hvor forespørgsler kommer ind og nogen skal svare inden for en defineret tid, hjælper SLA-sporing. Og fordi Gript lader dig se flere boards sammen på analysesiden, kan du se, hvordan SLA går på tværs af forskellige teams og projekter ét sted.

Målet var aldrig at bygge noget til SLA-specialister. Det var at få det til at virke for det team, der ved, at de har brug for svartidssporing, kiggede på de eksisterende værktøjer, og lukkede browser-fanen. Vælg en skabelon, tilføj en kolonne, begynd at måle.

Det er alt.