Tracker SLA: twórz terminy, wstrzymania i raporty zespołów

Dlaczego zespoły operacji klienta tracą kontrolę nad terminami SLA

Zespoły operacji klienta rzadko przekraczają SLA dlatego, że ktoś ignoruje datę. Terminy się przesuwają, zgłoszenia zmieniają właścicieli, a odpowiedzi klientów mogą wstrzymać pracę na kilka dni. Arkusz z jedną kolumną terminu szybko przestaje działać, jeśli ktoś nie aktualizuje go po każdej zmianie.

Pierwszy problem polega na traktowaniu każdego celu SLA jak jednego terminu. Cel pierwszej odpowiedzi mierzy, jak szybko agent potwierdza otrzymanie nowej prośby. Cel rozwiązania mierzy, ile czasu zespół ma na jej zamknięcie. Zgłoszenie może spełnić cel odpowiedzi w 15 minut, a trzy dni później przekroczyć cel rozwiązania. Jeden termin nie pokaże, które zobowiązanie nie zostało spełnione.

Odpowiedzialność tworzy kolejny problem. Agent może odpowiedzieć, specjalista zbadać sprawę, a menedżer zatwierdzić rozwiązanie. Jeśli nikt nie odpowiada za aktywny licznik SLA, każdy może uznać, że pilnuje go ktoś inny. Zgłoszenie pozostaje w kolejce, aż skończy się czas.

Wyobraźmy sobie problem z dostępem do konta zgłoszony o 10:00. Agent odpowiada o 10:12, spełniając cel 30-minutowej odpowiedzi, a o 10:20 prosi o zrzut ekranu. Klient odpisuje następnego popołudnia. Jeśli tracker wlicza ten czas oczekiwania do celu rozwiązania, obciąża wsparcie czasem, którego zespół nie mógł wykorzystać. Jeśli zatrzyma licznik, ale go nie wznowi, wynik będzie błędny w drugą stronę.

Tracker powinien zapewniać każdemu zgłoszeniu jeden wspólny rekord operacyjny: właściciela, zespół, priorytet, terminy odpowiedzi i rozwiązania, stan licznika, powód wstrzymania oraz historię zmian. Agenci mogą wtedy skupić się na pracy bliskiej naruszenia, a menedżerowie wskazywać opóźnienia wynikające z obsady, przekazywania zgłoszeń lub oczekiwania na klienta.

Ręczne arkusze mogą wystarczyć przy małej i stabilnej kolejce. Gdy terminy zależą od priorytetu, godzin pracy, przekazania i wstrzymań, tracker potrzebuje spójnych zasad.

Zdecyduj, czego potrzebuje każdy rekord SLA

Każde zgłoszenie powinno zawierać wystarczająco dużo informacji, aby wyjaśnić, kto za nie odpowiada, jaka obietnica ma zastosowanie i czy licznik powinien działać. Zacznij od podstaw: klient lub konto, priorytet, przypisany zespół, właściciel zgłoszenia i bieżący status.

Następnie dodaj pola, które sterują terminem:

• zasada SLA, na przykład «Standardowe wsparcie» lub «Wsparcie priorytetowe»
• czas rozpoczęcia
• termin pierwszej odpowiedzi i termin rozwiązania
• powód wstrzymania i czas rozpoczęcia wstrzymania
• czas wznowienia lub łączny czas wstrzymania

Pierwszą odpowiedź i pełne rozwiązanie trzymaj osobno. Zespół może obiecać pierwszą odpowiedź w ciągu czterech godzin pracy, ale potrzebować dwóch dni roboczych na rozwiązanie. Jeden termin pozwala szybkiej odpowiedzi ukryć nierozwiązane zgłoszenie.

Nie proś agentów o ręczne wybieranie statusu «naruszone». Obliczaj go na podstawie bieżącego czasu, terminu, statusu zgłoszenia i prawidłowych wstrzymań. Zgłoszenie narusza SLA rozwiązania na przykład wtedy, gdy minął jego termin, nadal jest otwarte, a licznik jest aktywny.

AppMaster pozwala przechowywać tę logikę w jednym miejscu. Data Designer może modelować pola zgłoszeń, a wizualny Business Process może obliczać terminy i status naruszenia za każdym razem, gdy agent tworzy lub aktualizuje zgłoszenie.

Ustal zasady SLA przed zbudowaniem trackera

Jasne zasady sprawiają, że wyniki SLA są uczciwe. Zdefiniuj cel dla każdej kategorii zgłoszeń, zanim utworzysz formuły lub raporty. W przeciwnym razie dwaj agenci mogą obsłużyć tę samą prośbę inaczej, a liczba naruszeń straci znaczenie.

Większość zespołów różnicuje cele według priorytetu, planu klienta i typu prośby. Pierwszą wersję utrzymaj w niewielkim zakresie. Pilne incydenty produkcyjne mogą na przykład wymagać pierwszej odpowiedzi w ciągu godziny, problemy z dostępem dla klientów płatnych w ciągu czterech godzin pracy, a zwykłe pytania w ciągu dwóch dni roboczych.

Zapisuj każdą zasadę prostym językiem. «Problem z rozliczeniem o wysokim priorytecie u klienta premium wymaga pierwszej odpowiedzi w ciągu dwóch godzin pracy» dokładnie wskazuje, jakie dane trzeba przechowywać: priorytet, plan, typ prośby, czas utworzenia i czas pierwszej odpowiedzi.

Zdefiniuj kalendarz pracy

Zdecyduj, czy cele działają przez całą dobę, czy tylko w godzinach wsparcia. Jeśli wsparcie pracuje od poniedziałku do piątku w godzinach 9:00-17:00, zgłoszenie otrzymane w piątek o 16:30 z celem dwóch godzin powinno mieć termin w poniedziałek o 10:30, a nie w piątek wieczorem.

Udokumentuj dni robocze, godziny wsparcia, strefę czasową, święta oraz osobny kalendarz incydentów działający 24/7, jeśli jest potrzebny. W miarę możliwości używaj jednego nazwanego kalendarza dla każdej zasady. Zespoły obsługujące klientów w różnych krajach mogą potrzebować kalendarzy regionalnych, ale osobny kalendarz dla każdego klienta tworzy zbędne koszty utrzymania.

Ustal moment rozpoczęcia i właściciela zasad

Wybierz dokładny moment rozpoczęcia licznika. Nowe zgłoszenia zwykle zaczynają się w chwili ich otrzymania przez system. Ponownie otwarte zgłoszenia wymagają osobnej reguły: kontynuacji pozostałego czasu, ponownego uruchomienia pierwotnego licznika albo rozpoczęcia nowego celu. Wybierz jedną metodę i stosuj ją konsekwentnie.

Przypisz zmiany zasad jednej osobie lub małej grupie. Agenci mogą poprawiać dane zgłoszeń, ale nie powinni zmieniać terminów, aby usunąć naruszenie. Przechowuj wersję zasady przy każdym rekordzie, a zatwierdzone wyjątki zapisuj wraz z powodem i datą.

Aplikacja AppMaster może przechowywać zasady w jednym obszarze administracyjnym i stosować właściwą regułę, gdy zgłoszenie trafia do systemu. Zastępuje to osobne formuły arkusza jednym spójnym licznikiem.

Zmapuj dane stojące za trackerem

Pierwszą wersję utrzymaj na tyle prostą, aby lider operacji mógł sprawdzić zgłoszenie i zrozumieć, dlaczego zmienił się jego termin.

Zacznij od tabeli zgłoszeń zawierającej identyfikator, temat, klienta, priorytet, status, czas utworzenia, czas pierwszej odpowiedzi, czas rozwiązania, terminy, przypisanego właściciela i odpowiedzialny zespół. Każde zgłoszenie powinno mieć jednego aktualnego właściciela i jeden zespół, nawet jeśli komentuje je kilka osób.

Utwórz osobne rekordy zespołów i zasad SLA. Rekord zespołu może zawierać jego nazwę i harmonogram godzin pracy. Każda zasada powinna określać, których zgłoszeń dotyczy, jakie są cele odpowiedzi i rozwiązania, jaki typ licznika stosuje oraz czy czas oczekiwania na klienta wstrzymuje licznik.

Dodaj rekord świąt z datą, odpowiednim zespołem lub lokalizacją i krótką etykietą. Przechowuj wszystkie znaczniki czasu w jednej spójnej strefie, zwykle UTC, a w interfejsie pokazuj czas lokalny, gdy jest potrzebny. Mieszanie stref czasowych powoduje błędy w okolicach weekendów i zmian czasu.

Zachowaj historię statusów zamiast nadpisywać przeszłość. Każdy wpis powinien zawierać identyfikator zgłoszenia, stary i nowy status, czas zdarzenia oraz osobę lub regułę, która wprowadziła zmianę. Rejestruj między innymi zdarzenia «Oczekiwanie na klienta», «Klient odpowiedział», «Przypisano» i «Rozwiązano».

Ta historia wyjaśnia zmiany terminów. Jeśli termin przesunie się z wtorkowego poranka na wtorkowe popołudnie, menedżer zobaczy, że zespół wstrzymał SLA na trzy godziny podczas oczekiwania na klienta. Wizualny Data Designer w AppMaster może modelować te powiązane rekordy, a Business Process Editor aktualizować terminy po zmianach statusu.

Obliczaj terminy zgłoszeń

Uruchamiaj licznik po jednym jasno określonym zdarzeniu, na przykład po otrzymaniu zgłoszenia przez system wsparcia. Nie zaczynaj go w chwili, gdy ktoś przypadkowo wyświetli zgłoszenie. Zapisz czas rozpoczęcia, aby wszystkie późniejsze obliczenia korzystały z tego samego punktu odniesienia.

Następnie wybierz właściwą zasadę SLA na podstawie planu klienta, typu zgłoszenia, priorytetu lub regionu. Potem oblicz termin:

1. Odczytaj cel zgłoszenia, na przykład cztery godziny na odpowiedź.
2. Dodaj wyłącznie czas pracy dozwolony przez zasadę.
3. Pomiń godziny zamknięcia, weekendy i święta, jeśli zasada je wyklucza.
4. Zapisz termin przy zgłoszeniu.
5. Przelicz go ponownie, jeśli zmiana priorytetu, planu lub kategorii wybierze inną zasadę.

Godziny pracy sprawiają, że obliczenie nie jest tak oczywiste, jak się wydaje. Jeśli czterogodzinne SLA zaczyna się o 16:00, a wsparcie działa od 9:00 do 17:00, tego dnia pozostaje jedna godzina. Termin wypada w południe następnego dnia roboczego, a nie o 20:00.

Gdy zmienia się priorytet zgłoszenia, zachowaj pierwotny czas rozpoczęcia i zastosuj udokumentowaną regułę eskalacji. Niektóre zespoły stosują pilny cel od pierwotnego rozpoczęcia, inne rozpoczynają nowy cel w chwili eskalacji. Każde podejście może działać, jeśli wszyscy stosują je tak samo.

Pokazuj dokładny termin i pozostały czas. Etykiety takie jak «Pozostały 2 godz. 15 min», «Termin za 1 dzień» i «Po terminie o 35 min» pomagają agentom szybciej przeglądać kolejkę niż same znaczniki czasu. Używaj neutralnego stanu dla zgłoszeń bez zagrożenia, ostrzeżenia zbliżającego się terminu i wyraźnego stanu naruszenia po jego przekroczeniu.

Wstrzymuj liczniki na czas oczekiwania na klienta

Wstrzymuj licznik tylko wtedy, gdy zespół nie może posunąć zgłoszenia naprzód bez udziału klienta. Typowe powody to oczekiwanie na informacje, potwierdzenie, dostęp, zgodę lub pliki. Wewnętrzne opóźnienie, takie jak oczekiwanie na współpracownika, nie powinno wstrzymywać SLA.

Używaj krótkiego i jasnego zestawu statusów:

• Oczekiwanie na informacje od klienta
• Oczekiwanie na zgodę klienta
• Oczekiwanie na dostęp od klienta
• Oczekiwanie na pliki od klienta

Gdy agent wybierze jeden z tych statusów, zapisz dokładny czas i powód wstrzymania. Zarejestruj także wiadomość lub zdarzenie, w którym poproszono klienta o odpowiedź. Przełożeni będą mogli sprawdzić, czy wstrzymanie było uzasadnione.

Po odpowiedzi klienta wznowić licznik w chwili jej otrzymania. Dodaj czas oczekiwania do total paused time, a następnie przelicz pozostały czas zgodnie z zasadami godzin pracy. Dziewięćdziesięciominutowe oczekiwanie na klienta przesuwa termin o 90 minut, z uwzględnieniem godzin zamknięcia.

Pokazuj czas wstrzymania w widoku zgłoszenia. Agenci muszą wiedzieć, czy zgłoszenie czekało 15 minut, czy trzy dni, a przełożeni powinni móc zauważyć zgłoszenia wielokrotnie wracające do statusu oczekiwania.

Ograniczaj powody wstrzymania do tych dozwolonych przez zasadę SLA. Wymagaj zdarzenia związanego z prośbą do klienta przed zaakceptowaniem wstrzymania. W AppMaster Business Process może sprawdzić nowy status, zapisać czas rozpoczęcia wstrzymania i odrzucić nieprawidłową zmianę przed aktualizacją rekordu SLA.

Automatyczna wiadomość «otrzymaliśmy Twoją wiadomość» nie powinna wznawiać licznika. Używaj przychodzącej wiadomości klienta lub odpowiedzi potwierdzonej przez agenta, zachowując pełną historię wstrzymań przy zgłoszeniu.

Prześledź przykład obsługi klienta

Klient wysyła pytanie dotyczące rozliczenia we wtorek o 10:00: «Dlaczego moja faktura pokazuje dwie opłaty?». Tracker tworzy zgłoszenie B-184, przypisuje je do zespołu Support i stosuje zasadę SLA dla rozliczeń. Zespół ma cztery godziny pracy na pierwszą użyteczną odpowiedź i osiem godzin pracy na rozwiązanie.

Support działa od 9:00 do 17:00, od poniedziałku do piątku. O 10:35 agent potwierdza, że zespół sprawdza konto. Licznik pierwszej odpowiedzi zatrzymuje się po 35 minutach, więc pozostają 3 godziny i 25 minut. Zgłoszenie spełnia cel pierwszej odpowiedzi.

O 11:00 agent potrzebuje numeru faktury i oznacza zgłoszenie jako «Oczekiwanie na klienta». Licznik rozwiązania zatrzymuje się po godzinie aktywnej pracy. Tracker zapisuje czas rozpoczęcia i powód wstrzymania.

Klient odpowiada o 15:30. Tracker dodaje 4 godziny i 30 minut oczekiwania do terminu. Pierwotny termin rozwiązania przypadał na wtorek o 18:00, więc po przeniesieniu pozostałego czasu na kolejny dzień roboczy skorygowany termin wypada w środę o 14:30.

Agent rozwiązuje problem w środę o 15:10. Zgłoszenie jest spóźnione o 40 minut. Liczy się jako jedno opóźnione rozwiązanie dla zespołu Support, podczas gdy pierwsza odpowiedź pozostała terminowa.

Raport naruszeń powinien jasno pokazywać rozdzielenie wyników: Support otrzymał jedno zgłoszenie dotyczące rozliczenia, spełnił cel pierwszej odpowiedzi, przekroczył cel rozwiązania o 40 minut i spędził 4 godziny i 30 minut na oczekiwaniu na klienta. Sam wiek zgłoszenia pokazałby błędny obraz sytuacji.

Raportuj naruszenia SLA według zespołu

Zgłoszenie narusza SLA, gdy termin mija, zanim nastąpi wymagane działanie. Korzystaj ze skorygowanego terminu po prawidłowych wstrzymaniach z powodu oczekiwania na klienta.

Oddziel otwarte zgłoszenia po terminie od zamkniętych zgłoszeń rozwiązanych z opóźnieniem. Otwarte zgłoszenia po terminie wymagają natychmiastowej uwagi. Zamknięte zgłoszenia z opóźnieniem należą do raportowania wyników. Połączenie obu grup ukrywa pilną pracę i utrudnia korzystanie z raportu.

W każdym okresie grupuj wyniki według zespołu, który był właścicielem zgłoszenia w chwili upływu terminu. Filtruj je według zasady, priorytetu i zakresu dat. Zespołu rozliczeń z zasadą czterogodzinnej odpowiedzi nie należy bezpośrednio porównywać z zespołem eskalacji technicznych, który ma dwa dni robocze na rozwiązanie.

Używaj zarówno liczby, jak i wskaźników:

• łączna liczba zgłoszeń z aktywnym SLA
• zgłoszenia rozwiązane w terminie
• otwarte zgłoszenia po terminie
• zgłoszenia rozwiązane po terminie
• wskaźnik naruszeń, obliczany jako liczba naruszonych zgłoszeń podzielona przez liczbę zgłoszeń z SLA

Wskaźnik naruszeń na poziomie 50% oznacza coś innego, gdy wynika z jednego spóźnionego zgłoszenia na dwa, niż gdy oznacza 50 spóźnionych zgłoszeń na 100. Analizuj trendy razem ze szczegółami zgłoszeń. Częste naruszenia dotyczące wysokich priorytetów mogą wskazywać na zasady eskalacji lub przekazywanie zgłoszeń, a nie na ogólne przeciążenie pracą.

Dobry raport pozwala menedżerowi otworzyć listę spóźnionych zgłoszeń, zobaczyć zasadę i priorytet oraz sprawdzić odpowiedzialność w chwili naruszenia. Powinien wspierać praktyczny przegląd pracy wymagającej poprawy, a nie nagradzać zespołów za zbyt szybkie zamykanie zgłoszeń.

Zbuduj widoki dla agentów i menedżerów

Agenci potrzebują krótkiej listy roboczej, a nie raportu pełnego starych zgłoszeń. Każde otwarte zgłoszenie powinno pokazywać właściciela, zespół, priorytet, termin, stan licznika i pozostały czas. Zapisuj zmianę odpowiedzialności od razu, gdy zgłoszenie przechodzi między zespołami.

Używaj prostych etykiet licznika. «Aktywne» oznacza, że zespół odpowiada za następne działanie. «Wstrzymane - oczekiwanie na klienta» oznacza, że licznik jest zatrzymany. Pokazuj czas aktywny osobno od czasu wstrzymania, aby użytkownicy rozumieli, dlaczego zgłoszenie pozostaje otwarte od kilku dni.

Widok agenta może obejmować zgłoszenia z terminem w ciągu najbliższych czterech godzin, zgłoszenia po terminie, zgłoszenia oczekujące na odpowiedź klienta oraz zgłoszenia przekazane dzisiaj. Wysyłaj ostrzeżenia przed upływem terminu. Cel czterogodzinnej odpowiedzi wymaga wcześniejszych przypomnień niż trzydniowy cel rozwiązania.

Menedżerowie potrzebują innego widoku. Cotygodniowy raport może grupować zgłoszenia po terminie według zespołu i pokazywać liczbę naruszeń, odsetek celów spełnionych, średni czas opóźnienia oraz zgłoszenia nadal otwarte po terminie. Przy każdym zaległym zgłoszeniu dodaj właściciela i datę ostatniej aktualizacji.

Zachowaj zapis audytowy zmian zasad. Jeśli zespół operacyjny zmieni cel z ośmiu godzin na 12, zapisz, kto i kiedy dokonał zmiany oraz których nowych zgłoszeń dotyczy reguła. Historyczne wyniki powinny zachować zasadę obowiązującą w chwili rozpoczęcia każdego zgłoszenia.

AppMaster pozwala zespołom tworzyć osobne widoki internetowe dla agentów i menedżerów, przy zachowaniu tych samych danych zgłoszeń i reguł biznesowych w obu widokach.

Błędy zniekształcające wyniki SLA

Nawet przejrzyste wykresy mogą przedstawiać błędny obraz, jeśli podstawowe zasady są nieprawidłowe.

Stosowanie reguł czasu dosłownie

Nie obliczaj terminów na podstawie godzin kalendarzowych, gdy umowa określa godziny pracy. Zgłoszenie otwarte w piątek o 16:30 z celem ośmiu godzin pracy nie narusza SLA o 00:30 w sobotę. Uwzględniaj wyłącznie godziny pracy i święta zdefiniowane w zasadzie.

Taką samą uwagę poświęć wstrzymaniom. Status «Oczekiwanie na klienta» powinien wstrzymywać SLA tylko wtedy, gdy zespół wysłał jasną prośbę i nie może kontynuować bez odpowiedzi. Wstrzymywanie każdego zgłoszenia z tą etykietą ukrywa opóźnienia należące do zespołu.

Zachowaj daty wyjaśniające każdy wynik: pierwotny termin, używaną zasadę, każdy czas rozpoczęcia i zakończenia wstrzymania, powód wstrzymania, skorygowany termin, czas rozwiązania oraz osobę, która zamknęła zgłoszenie. Bez tej historii nikt nie sprawdzi, dlaczego zgłoszenie pojawiło się jako terminowe.

Licz odpowiedzialność tylko raz

Używaj jednej zasady odpowiedzialności w raportach zespołowych. Jeśli Support przekazuje zgłoszenie do Billing, nie licz tego samego naruszenia dla obu zespołów. Możesz przypisać wynik zespołowi, który był właścicielem zgłoszenia w chwili upływu terminu, a przekazania raportować osobno.

Wymagaj znacznika czasu rozwiązania przed zamknięciem zgłoszenia. Sam status zamknięcia nie potwierdza, kiedy zakończyła się praca. Jeśli na przykład zgłoszenie przechodzi z Support do Billing o 14:00, a naruszenie następuje o 15:00, zgodnie z zasadą odpowiedzialności w chwili naruszenia odpowiada za nie Billing. Raport może nadal pokazywać wcześniejsze przekazanie przez Support, bez dodawania drugiego naruszenia.

Sprawdź tracker przed uruchomieniem

Przejrzyj każdą zasadę SLA, zanim agenci zaczną polegać na trackerze. Każda zasada potrzebuje jasnego celu, na przykład czterogodzinnej pierwszej odpowiedzi lub rozwiązania w ciągu dwóch dni roboczych, oraz przypisanego kalendarza. Ustal domyślną zasadę dla zgłoszeń, które nie pasują do reguły klienta, planu ani priorytetu.

Testuj trudne sytuacje czasowe, nie tylko zwykłe przypadki:

• Utwórz zgłoszenie tuż przed końcem dnia pracy i sprawdź, czy pozostały czas przechodzi na kolejny dzień roboczy.
• Utwórz zgłoszenie przed weekendem lub świętem i sprawdź, czy termin pomija okres zamknięcia.
• Wstrzymaj zgłoszenie z powodu oczekiwania na klienta, dodaj odpowiedź i sprawdź, czy licznik poprawnie się wznawia.
• Przenieś zgłoszenie między zespołami i sprawdź, który zespół odpowiada za późniejsze naruszenie.
• Zamknij zgłoszenie po terminie i sprawdź, czy tracker rejestruje naruszenie.

Porównuj sumy z pulpitu z listą zgłoszeń, która za nimi stoi. Jeśli raport mówi, że zespół A ma 12 naruszeń, odfiltruj rekordy i policz je. W ten sposób wykryjesz zduplikowane zgłoszenia, brakujące przypisania zespołów i zgłoszenia ponownie otwarte, które policzono dwa razy.

Ustal zasady dostępu przed publikacją. Agenci powinni aktualizować obsługiwane zgłoszenia, menedżerowie potrzebują raportów zespołów, a administratorzy powinni kontrolować ustawienia zasad. W AppMaster przetestuj każdą rolę na osobnym koncie, aby menedżer nie potrzebował dostępu administratora do przeglądania raportów naruszeń SLA.

Zacznij od małego zakresu i rozwijaj przepływ pracy

Zacznij od jednego typu zgłoszeń i jednej zasady SLA. Zespół wsparcia może rozpocząć od standardowych próśb przesyłanych e-mailem i celu pierwszej odpowiedzi wynoszącego 24 godziny. To wystarczy do przetestowania terminów, zatwierdzonych wstrzymań i rejestrów naruszeń.

Poproś kilku pracowników operacji klienta o przeprowadzenie rzeczywistych zgłoszeń przez cały przepływ, w tym zwykłego przypadku, oczekiwania na klienta i przekroczenia terminu. Zbieraj konkretne uwagi. Agentom mogą być potrzebne osobne statusy oczekiwania na klienta i oczekiwania na inny zespół. Menedżerowie mogą uznać, że ogólna etykieta «wstrzymane» ukrywa zbyt wiele informacji.

Gdy arkusz ogranicza proces, zbuduj tracker jako aplikację no-code w AppMaster. Możesz tworzyć formularze zgłoszeń, definiować logikę liczników w wizualnym Business Process Editor oraz udostępniać agentom i menedżerom osobne pulpity. AppMaster może wygenerować backend, aplikację internetową i natywną aplikację mobilną, gdy tracker ma działać poza współdzieloną tabelą.

Na początku ogranicz raportowanie do najważniejszych danych: otwarte zgłoszenia, zgłoszenia bliskie naruszenia, zgłoszenia wstrzymane i naruszenia według zespołu. Porównuj przykładowe terminy z ręcznymi obliczeniami, przeglądaj zgłoszenia po terminie oraz okresy wstrzymania i zmieniaj jedną zasadę naraz, zanim ponownie ją przetestujesz. Gdy pracownicy zaufają obliczeniom, dodaj kolejny typ zgłoszenia lub zasadę priorytetu i powtórz te same kontrole.