SLA, kalendarz i eskalacje

Terminy ustawiasz pod „Settings → SLA”. Strona sama mówi na górze, kiedy żadna zasada nie jest aktywna. Zasada ma trzy części: nazwę, warunki i cele. Nowe zasady powstają celowo nieaktywne, żebyś mógł je dokończyć, zanim cokolwiek zrobią.

Warunki to „Team”, „Priority”, „Main category” i „Subcategory”. Puste znaczy „Any”, czyli „dotyczy wszystkiego”, a nie „nie dotyczy niczego”. Jeśli pasuje kilka zasad, wygrywa ta z najniższą liczbą pod „Order”. Dlatego zasada wąska stoi na górze, a ogólna pod nią.

Oba pola kategorii są pogrupowane według zespołów, bo kategorie należą do zespołu, ale oferowane są wszystkie, także te z innych zespołów. Jest to zamierzone: przy przekazaniu zgłoszenie wędruje, a kategoria nie. Zgłoszenie przekazane przez helpdesk zespołowi sieciowemu nadal niesie klasyfikację helpdesku, a zasada może wskazywać właśnie na nią. Gdy wybierzesz kategorię główną, pole poniżej oferuje tylko podkategorie z nią powiązane, a para, która nie może istnieć przy zgłoszeniu, zostaje odrzucona przy zapisie.

Każda zasada ma dwa cele. „Time to first response” kończy się pierwszą publiczną odpowiedzią agenta, a automatyczne potwierdzenie i notatka wewnętrzna wyraźnie się nie liczą. „Time to resolution” kończy się, gdy tylko zgłoszenie osiąga status liczony jako rozwiązany (który to jest, ustawiasz pod „Settings → General → Status”). Oba cele mają własne minuty, własny kalendarz i własną reakcję na przekroczenie.

Przy zgłoszeniu terminy stoją po prawej na karcie „Details”, a pod nimi „Show deadline history”: dziennik zapisujący każdy krok, czyli start, wstrzymanie, wznowienie, dotrzymanie i przekroczenie, każdy z powodem i zużytym czasem pracy. Widzą go tylko agenci i administratorzy, a dla klientów nie da się go pobrać.

Jeśli ktoś zmieni później priorytet albo zespół, zegar przełącza się na zasadę, która wtedy pasuje: dotychczas zużyty czas pracy jest rozliczany starym kalendarzem, a potem obowiązują nowe wartości. Jeśli żadna zasada już nie pasuje, zegar kończy się bez werdyktu i nie liczy się ani jako dotrzymany, ani jako przekroczony.

Jeśli przy zakładaniu zgłoszenia nie pasowała żadna zasada, zegar startuje, gdy po jakiejś zmianie po raz pierwszy zasada zacznie pasować, na przykład przy wyższym priorytecie. Liczy od tej chwili. Zegar pierwszej odpowiedzi startuje tylko wtedy, gdy nikt jeszcze nie odpowiedział.

Nowe zegary powstają tylko przy ponownym otwarciu zgłoszenia. Inne zmiany statusu nie tworzą nowych zegarów.

Kalendarz mówi, kiedy biegnie zegar. Ma nazwę, własną strefę czasową i dowolnie wiele okien na każdy dzień tygodnia, bo przerwa obiadowa to po prostu dzień z dwoma oknami. Okno może przechodzić przez północ, a wtedy obok pojawia się „ends next day”.

To, który kalendarz obowiązuje zespół, ustawia się przy zespole („Settings → Teams”). Przy pojedynczym celu zasady możesz to nadpisać: „From the team” bierze kalendarz zespołu albo wybierasz inny. Właśnie tak powstaje typowy przypadek: awarie liczą się bez przerwy, a cała reszta tylko w godzinach biurowych.

Liczy się czas, który naprawdę upływa wewnątrz okna, a nie różnica wskazań zegara. Przy zmianie czasu robi to różnicę: dzień całodobowy w październiku ma 25 godzin, a zmiana nocna od 22:00 do 06:00 ma na wiosnę siedem zamiast ośmiu. Okno biurowe od 09:00 do 17:00 nigdy tego nie odczuwa, bo w Unii Europejskiej zmiana odbywa się w nocy.

Jeśli nie da się znaleźć kalendarza z otwartymi godzinami, żaden termin nie powstaje. Lepiej żaden niż zgadnięty. Przy zgłoszeniu zamiast daty pojawia się informacja.

Pod każdym kalendarzem stoi lista „Closed days”. Kliknięcie „Import holidays (.ics)” przyjmuje plik kalendarza i podaje potem cztery liczby: ile dni przejęto, ile zastąpiono, ilu nie dało się odczytać i ile już było. Pojedyncze dni możesz też wpisać ręcznie.

Symbol ↻ przy dniu znaczy „powtarza się co roku”. Jest poprawny tylko przy stałych datach: 3 października wypada co roku tego samego dnia, a Wielki Piątek i Poniedziałek Zielonych Świątek wiszą przy dacie Wielkanocy i się przesuwają. Święta ruchome stoją więc na liście z konkretną datą na dany rok, na obrazku „Good Friday” bez symbolu.

Dzień zamknięty połyka całe okno tego dnia, także tę część, która sięga w następny dzień. A jeśli kalendarz nie zna żadnego dnia zamkniętego przez najbliższe dwanaście miesięcy, strona mówi to wprost. Inaczej system po cichu liczyłby przez dni wolne i dawałby błędne terminy.

Najczęstszy spór o terminy jest właśnie taki: zgłoszenie czeka od trzech dni na odpowiedź klienta, a zegar i tak biegnie. Dlatego każdy cel ma przełącznik „Pause while waiting for the requester”, osobno, a nie dla całej zasady.

To, czy czekasz, decyduje status: pod „Settings → General → Status” każdy status nosi oznaczenie, czy liczy się jako „oczekiwanie na zgłaszającego”. Przy włączonym przełączniku termin odpoczywa, dopóki zgłoszenie stoi w takim statusie. Zegar ścienny biegnie dalej, dlatego lista pokazuje „Paused” zamiast pozostałego czasu, a historia terminu zawiera „Paused” i „Resumed” z ich czasami. Czas oczekiwania nie liczy się też wtedy, gdy zgłoszenie zostanie rozwiązane prosto z takiego statusu.

Przy pierwszej odpowiedzi zwykle zostawiasz przełącznik wyłączony: pierwszą odpowiedź jesteś winien niezależnie od tego, na co się czeka. Przy rozwiązaniu zwykle jest włączony. Obrazek pokazuje dokładnie takie ustawienie.

Gdy tylko zasada jest aktywna, lista zgłoszeń dostaje kolumnę „Deadline”. Pokazuje ona pozostały czas najbliższego otwartego terminu („14h 53m”). Gdy przy zgłoszeniu nie biegnie już żaden termin, stoi tam werdykt: etykieta „In time” przy dotrzymanym i czerwone „Breached” przy przekroczonym. Zgłoszenie bez żadnego zegara dostaje neutralną kreskę i jest to zamierzone: zgłoszenie sprzed zasady nie jest porażką.

Jeśli żadna zasada nie jest aktywna, kolumny w ogóle nie ma i nie stoi ona tam pusta. To samo dotyczy filtra: pod „Filter” pole „Breached only” pojawia się dopiero wtedy, gdy w ogóle są terminy.

Zgłoszenie ma dwa zegary, a kolumna tylko jedno miejsce, więc pokazuje najpilniejszy OTWARTY termin. Jeśli pierwszą odpowiedź przekroczono, a rozwiązanie jeszcze biegnie, kolumna pokazuje pozostały czas rozwiązania i czerwony znak „!” obok. Ten znak mówi: przy tym zgłoszeniu jakiś termin już został przekroczony. Dokładnie tak znajduje je filtr „Breached only”, bo pyta o dowolny przekroczony termin, także o taki, który dawno się skończył. Który z dwóch to był, stoi w samym zgłoszeniu.

Da się też po tym sortować: pod tym samym nagłówkiem „Deadline” stoi pole z „Due soonest first” i „Due latest first”. Zgłoszenia bez biegnącego zegara lądują zawsze na końcu. Nie są najmniej pilne, tylko po prostu nie są objęte. Sortowanie po terminie ma pierwszeństwo przed sortowaniem po „Updated at”, bo żadna lista nie spełni dwóch porządków naraz.

Przy każdym celu ustawiasz pod „When breached”, co dzieje się przy przekroczeniu: „Record only” tylko zapisuje, „Notify assignee and observers” wysyła wiadomość do osoby przypisanej i do obserwatorów (a nie do całego zespołu), a „Hand over to another team” przekazuje zgłoszenie. Przy przekazaniu musisz wybrać zespół docelowy, bo zasada bez niego zostaje odrzucona przy zapisie: wyglądałaby na skonfigurowaną i nic by nie robiła.

Działanie wykonuje się dokładnie raz na zegar. Bez tego zatrzasku ponowne uruchomienie serwera wysłałoby tę samą wiadomość jeszcze raz. Oznaczenie „już zrobione” jest stawiane także wtedy, gdy wysyłka się nie udała. Wiadomość, która nie dotarła, jest lepsza niż pętla wysyłająca nową co minutę.

Samo przekroczenie jest datowane na chwilę, w której termin upłynął, a nie na przebieg sprawdzania. Inaczej raporty wisiałyby na rytmie usługi sprawdzającej. A mierzone jest według zużytego czasu pracy: wstrzymany zegar nie może przekroczyć terminu, nawet jeśli data upłynęła dawno.

Przekazanie ustawia status z powrotem na „Open”. Wiersze historii na ten temat są wewnętrzne. Klient widzi przy zgłoszeniu tylko nowy status i nowy zespół.

Pod „Reports” wybierasz okres i naciskasz „Generate report”. Bez tego kliknięcia strona zostaje pusta. Raport zawiera potem blok „Service level agreements” z jednym wierszem na cel: dotrzymane, przekroczone, wciąż biegnące, osiągnięty wskaźnik i średni zużyty czas.

Liczenie odbywa się na cel, a nie na zgłoszenie, i stoi to również pod tabelą. Zgłoszenie z obydwoma celami pojawia się więc dwa razy, po jednym w każdym wierszu.

Osiągnięty wskaźnik liczy tylko rozstrzygnięte zegary. Biegnące nie należą do mianownika, bo inaczej każde świeżo włączone SLA wyglądałoby na początku katastrofalnie i poprawiałoby się samo. Jeśli nie ma jeszcze ani jednego rozstrzygniętego zegara, pojawia się kreska, a nie „0 %”.

Jeśli pracujesz z awariami zbiorczymi, dochodzi wiersz „Achieved without group incidents”: pojedyncza awaria zbiorcza ze stoma dopiętymi zgłoszeniami zniekształcałaby inaczej wskaźnik w obie strony. Pomija on każde zgłoszenie powiązane z awarią zbiorczą.

Agenci widzą w tym bloku tylko własne zespoły. Bez Professional blok pojawia się tylko wtedy, gdy istnieją wcześniejsze dane o terminach. Pozostaje wtedy czytelny.