Jaki problem to rozwiązuje
Jeden pipeline dla każdego typu sprawy oznacza, że reset hasła i eskalacja kontraktu siedzą w tej samej kolejce z tymi samymi statusami. Zgłoszenia starzeją się bez kolejnego kroku, bo status W toku obejmuje wszystko od zaczęte pięć minut temu po utknięte od dwóch tygodni. Tymczasem kontrakt obiecuje klientom pierwszą reakcję w kilka godzin, a jedynym mechanizmem egzekucji jest to, czy ktoś akurat zauważy. Managerowie dowiadują się o naruszeniach od klienta, nie od systemu.
Jak pracujemy
Prowadzimy sesję roboczą nad Twoimi typami spraw: co wpływa, czego każdy typ potrzebuje żeby przejść od nowego do rozwiązanego, i gdzie obecny pipeline kłamie na temat rzeczywistości. Na tej podstawie projektujemy architekturę pipeline'ów - czasem jeden pipeline z lepszymi statusami, czasem osobne dla wsparcia, onboardingu i spraw wewnętrznych, każdy z etapami, które znaczą jedną konkretną rzecz.
Potem wdrażamy polityki SLA w Service Hub: cele czasu pierwszej odpowiedzi i czasu zamknięcia, godziny pracy żeby weekendowe zgłoszenia nie liczyły się jako naruszenia, oraz workflow eskalacyjne, które odpalają się przed naruszeniem, a nie po. Wymagane właściwości na każdym etapie trzymają zgłoszenia skategoryzowane na tyle dobrze, żeby raportowanie pozostało uczciwe.
Efekt to system zgłoszeń, w którym status coś znaczy, starzenie jest widoczne, a realizacja SLA to raport, który wyciągasz, a nie domysł, którego bronisz.
Deliverables
- Dokument architektury pipeline'ów pokrywający wszystkie typy spraw
- Skonfigurowane pipeline'y z pisemnymi definicjami etapów
- Polityki SLA z godzinami pracy i poziomami priorytetów
- Workflow eskalacyjne i alerty przed naruszeniem
- Reguły wymaganych właściwości na etap dla czystej kategoryzacji
- Dashboard realizacji SLA i starzenia się zgłoszeń