SLA, kalender en escalaties

Termijnen stel je in onder “Settings → SLA”. De pagina zelf zegt bovenaan wanneer er geen richtlijn actief is. Een richtlijn heeft drie delen: een naam, de voorwaarden en de doelen. Nieuwe richtlijnen worden bewust inactief aangemaakt — zodat je ze kunt afmaken voordat ze iets doen.

De voorwaarden zijn “Team”, “Priority”, “Main category” en “Subcategory”. Leeg betekent “Any”, dus “geldt voor alles” — niet “geldt voor niets”. Passen er meerdere richtlijnen, dan wint die met het laagste getal onder “Order”; daarom staat de smalle richtlijn bovenaan en de algemene eronder.

De twee categorievelden staan per team gegroepeerd, omdat categorieën bij een team horen — maar je krijgt ze allemaal aangeboden, ook die van andere teams. Dat is bewust: bij een overdracht verhuist het ticket, de categorie niet. Een ticket dat de helpdesk aan het netwerkteam heeft gegeven, draagt nog steeds de indeling van de helpdesk, en een richtlijn mag precies daarop wijzen. Zodra je een hoofdcategorie kiest, biedt het veld eronder alleen nog de subcategorieën aan die eraan gekoppeld zijn — een paar dat op een ticket niet kan bestaan, wordt bij het opslaan geweigerd.

Elke richtlijn heeft twee doelen. “Time to first response” eindigt met het eerste openbare antwoord van een agent — een automatische ontvangstbevestiging en een interne notitie tellen uitdrukkelijk niet mee. “Time to resolution” eindigt zodra het ticket een status bereikt die als opgelost telt (welke dat is, stel je in onder “Settings → General → Status”). Beide doelen hebben eigen minuten, een eigen kalender en een eigen reactie op een overschrijding.

Op het ticket staan de termijnen rechts in de kaart “Details”, eronder “Show deadline history”: een logboek dat elke stap vastlegt — gestart, gepauzeerd, hervat, gehaald, gemist — telkens met een reden en de gebruikte werktijd. Alleen agenten en beheerders zien het; voor klanten is het niet op te vragen.

Wijzigt iemand later de prioriteit of het team, dan schakelt de klok naar de richtlijn die dan past: de tot dan gebruikte werktijd wordt met de oude kalender afgerekend, daarna gelden de nieuwe waarden. Past er geen richtlijn meer, dan eindigt de klok zonder oordeel — ze telt noch als gehaald noch als overschreden.

Paste er bij het aanmaken van het ticket geen richtlijn, dan start de klok de eerste keer dat er na een wijziging een richtlijn past, bijvoorbeeld door een hogere prioriteit. Ze telt vanaf dat moment. De klok voor de eerste reactie start alleen als nog niemand heeft geantwoord.

Nieuwe klokken ontstaan alleen wanneer een ticket wordt heropend. Andere statuswijzigingen maken geen nieuwe klokken.

Een kalender zegt wanneer de klok loopt. Hij heeft een naam, een eigen tijdzone en een willekeurig aantal blokken per weekdag — een lunchpauze is gewoon een dag met twee blokken. Een blok mag over middernacht heen lopen; dan staat er “ends next day” naast.

Welke kalender voor een team geldt, stel je op het team in (“Settings → Teams”). Op het afzonderlijke doel van een richtlijn kun je hem overschrijven: “From the team” neemt die van het team, of je kiest een andere. Precies dat levert het gebruikelijke geval op — storingen tellen rond de klok, al het andere alleen tijdens kantooruren.

Geteld wordt de tijd die werkelijk binnen het blok verstrijkt, niet het verschil tussen de klokstanden. Bij de omschakeling naar zomer- en wintertijd maakt dat verschil: een 24/7-dag in oktober heeft 25 uur, een nachtdienst van 22:00 tot 06:00 in het voorjaar zeven in plaats van acht. Een kantoorblok van 09:00 tot 17:00 wordt nooit geraakt, omdat de omschakeling in de EU 's nachts gebeurt.

Is er geen kalender met openingstijden te vinden, dan wordt er geen termijn aangemaakt — liever geen dan een geraden termijn. Op het ticket verschijnt dan een opmerking in plaats van een datum.

Onder elke kalender staat de lijst “Closed days”. Een klik op “Import holidays (.ics)” neemt een kalenderbestand aan en meldt daarna vier getallen: hoeveel dagen zijn overgenomen, hoeveel vervangen, hoeveel onleesbaar en hoeveel er al waren. Losse dagen kun je ook met de hand invoeren.

Het teken ↻ achter een dag betekent “herhaalt zich jaarlijks”. Dat klopt alleen bij vaste data: 3 oktober valt elk jaar op dezelfde datum, Goede Vrijdag en Tweede Pinksterdag hangen aan de datum van Pasen en schuiven op. Verschuivende feestdagen staan daarom per jaar met hun concrete datum in de lijst — op de afbeelding “Good Friday” zonder het teken.

Een gesloten dag slokt het hele blok van die dag op, ook het deel dat tot in de volgende dag doorloopt. En kent een kalender voor de komende twaalf maanden helemaal geen gesloten dag, dan zegt de pagina dat uitdrukkelijk — anders telt het systeem stilletjes door de feestdagen heen en levert het verkeerde termijnen op.

De meestvoorkomende discussie over termijnen is deze: het ticket wacht al drie dagen op het antwoord van de klant, en de klok loopt toch door. Daarom heeft elk doel de schakelaar “Pause while waiting for the requester” — afzonderlijk, niet voor de hele richtlijn.

Of er wordt gewacht, bepaalt de status: onder “Settings → General → Status” draagt elke status een markering of ze als “wachten op de aanvrager” telt. Staat de schakelaar aan, dan rust de termijn zolang het ticket in zo'n status staat. De wandklok loopt door — daarom toont de lijst “Paused” in plaats van een resterende tijd, en bevat de termijnhistorie “Paused” en “Resumed” met hun tijdstippen. De wachttijd telt ook niet mee als het ticket rechtstreeks vanuit zo'n status wordt opgelost.

Voor de eerste reactie laat je de schakelaar meestal uit: het eerste antwoord ben je hoe dan ook verschuldigd, waar er ook op wordt gewacht. Voor de oplossing staat hij meestal aan. De afbeelding toont precies die instelling.

Zodra er een richtlijn actief is, krijgt de ticketlijst de kolom “Deadline”. Die toont de resterende tijd van de volgende openstaande termijn (“14h 53m”). Loopt er op het ticket geen termijn meer, dan staat het oordeel er: het label “In time” bij een gehaalde, het rode “Breached” bij een gemiste. Een ticket zonder enige klok krijgt een neutraal streepje, en dat is bewust: een ticket van vóór de richtlijn is geen mislukking.

Is er geen richtlijn actief, dan ontbreekt de kolom helemaal — ze staat er niet leeg bij. Hetzelfde geldt voor het filter: onder “Filter” verschijnt het vakje “Breached only” alleen wanneer er überhaupt termijnen zijn.

Een ticket heeft twee klokken maar de kolom heeft maar één plek — ze toont de dringendste OPENSTAANDE termijn. Is de eerste reactie gemist en loopt de oplossing nog, dan toont de kolom de resterende tijd van de oplossing met een rode “!” ernaast. Die markering zegt: op dit ticket is al een termijn overschreden — en precies zo vindt het filter “Breached only” het, want dat vraagt naar elke overschreden termijn, ook naar een die allang is afgelopen. Welke van de twee het betrof, staat in het ticket zelf.

Je kunt er ook op sorteren: onder dezelfde kop “Deadline” staat een veld met “Due soonest first” en “Due latest first”. Tickets zonder lopende klok komen altijd achteraan — ze zijn niet het minst dringend, ze zijn alleen niet betrokken. Sorteren op termijn gaat vóór sorteren op “Updated at”: geen enkele lijst kan twee volgordes tegelijk aanhouden.

Per doel stel je onder “When breached” in wat er bij een overschrijding gebeurt: “Record only” legt het alleen vast, “Notify assignee and observers” stuurt een mail naar de behandelaar en de volgers (niet naar het hele team), “Hand over to another team” draagt het ticket over. Voor de overdracht moet je een doelteam kiezen — een richtlijn zonder doelteam wordt bij het opslaan geweigerd, omdat ze ingesteld zou lijken en niets zou doen.

De actie loopt precies één keer per klok. Zonder die grendel zou een herstart van de server dezelfde mail opnieuw versturen. De markering “al gedaan” wordt ook gezet wanneer het versturen mislukte — een mail die niet is aangekomen is beter dan een lus die elke minuut een nieuwe stuurt.

De overschrijding zelf wordt gedateerd op het moment waarop ze verviel, niet op de controleronde — anders zou de rapportage aan het ritme van de controledienst hangen. En ze wordt gemeten tegen de gebruikte werktijd: een gepauzeerde klok kan niet overschrijden, ook al is de vervaldatum allang voorbij.

De overdracht zet de status terug op “Open”. De regels in de historie daarover zijn intern; de klant ziet alleen de nieuwe status en het nieuwe team op het ticket.

Onder “Reports” kies je de periode en druk je op “Generate report” — zonder die klik blijft de pagina leeg. Het rapport bevat daarna het blok “Service level agreements” met per doel één regel: gehaald, overschreden, nog lopend, het behaalde percentage en de gemiddeld gebruikte tijd.

Er wordt per doel geteld, niet per ticket — dat staat ook onder de tabel. Een ticket met beide doelen komt dus twee keer voor, één keer in elke regel.

Het behaalde percentage telt alleen besliste klokken mee. Lopende horen niet in de noemer, anders zou elke net aangezette SLA er eerst rampzalig uitzien en vanzelf beter worden. Is er nog geen enkele besliste klok, dan verschijnt er een streepje — niet “0 %”.

Werk je met groepsstoringen, dan is er een extra regel “Achieved without group incidents”: één groepsstoring met honderd gekoppelde tickets zou het percentage anders in beide richtingen vertekenen. Die regel laat elk ticket weg dat aan een groepsstoring is gekoppeld.

Agenten zien in dit blok alleen hun eigen teams. Zonder Professional verschijnt het blok alleen als er termijngegevens van vroeger zijn; het blijft dan leesbaar.