SYSTEM TICKETOWY · WORKFLOW · ŚLEDZENIE
Status zgłoszenia — aktualny etap obsługi ticketu
Pole określające na jakim etapie obsługi znajduje się zgłoszenie — od „nowy” po „zamknięty”. Statusy to szkielet workflow helpdesk: pozwalają śledzić postęp, mierzyć SLA, identyfikować zatory i raportować wydajność zespołu.
Definicja
Status zgłoszenia to pole określające aktualny etap obsługi ticketu w cyklu życia (np. nowy, w toku, oczekuje na klienta, rozwiązany, zamknięty) — kluczowe dla śledzenia postępu i pomiaru SLA.
Jak Status zgłoszenia działa w praktyce
Standardowe statusy: Nowy / Otwarty (zgłoszenie wpłynęło, nieprzypisane), W toku / Open (agent pracuje), Oczekuje na klienta / Pending (czekamy na odpowiedź/dane od klienta — SLA timer zatrzymany), Oczekuje na stronę trzecią / On Hold (czekamy na dostawcę, inny dział), Rozwiązany / Resolved (problem rozwiązany, klient jeszcze nie potwierdził), Zamknięty / Closed (sprawa zakończona i potwierdzona). Niektóre systemy dodają: Eskalowany, Ponownie otwarty (reopened).
Dlaczego statusy są kluczowe dla SLA: SLA timer reaguje na status. Czas „oczekuje na klienta” zazwyczaj NIE liczy się do SLA (firma nie odpowiada za zwłokę klienta). Czas „w toku” i „nowy” liczy się. Bez statusów nie da się sprawiedliwie mierzyć SLA — sprawa czekająca 3 dni na odpowiedź klienta wyglądałaby jak naruszenie, choć wina leży po stronie klienta.
Status vs etap workflow: status to wysokopoziomowy stan (otwarty/zamknięty), workflow może mieć szczegółowe etapy w ramach statusu „w toku” (np. diagnostyka → naprawa → testy → weryfikacja). Proste helpdeski używają 5-6 statusów, złożone service desk (ITIL) dodają substatusy i etapy workflow. Zbyt wiele statusów = chaos, zbyt mało = brak widoczności.
Pułapki zarządzania statusami: „rozwiązany” mylony z „zamknięty” (rozwiązany = czekamy na potwierdzenie klienta, zamknięty = potwierdzony — pomieszanie zaburza metryki), tickety wiszące w „w toku” bez aktywności (potrzeba auto-flagowania stale tickets), nadużywanie „oczekuje na klienta” (agent ustawia by zatrzymać SLA timer, choć faktycznie nie czeka na klienta — gaming metryk), brak auto-zamykania (rozwiązane tickety bez odpowiedzi klienta wiszą tygodniami).
Benchmark branżowy
| Poziom | Wartość | Komentarz |
|---|---|---|
| Liczba statusów (zalecane) | 5-7 | Powyżej chaos, poniżej brak widoczności |
| Auto-close po rozwiązaniu | 3-7 dni | Bez odpowiedzi klienta → zamknięcie |
| Stale ticket flag | >48h bez aktywności | W statusie 'w toku' |
| Reopen rate target | <10% | % ponownie otwartych — wyżej = słaba jakość |
Jak Debesis zarządza statusami zgłoszeń
System Debesis pozwala definiować własne statusy i przepływy między nimi (workflow). SLA timery inteligentnie reagują na status — czas „oczekuje na klienta” nie liczy się do SLA. Auto-zamykanie rozwiązanych ticketów bez odpowiedzi klienta (konfigurowalny próg). Flagowanie stale tickets (wiszące bez aktywności). Real-time dashboard pokazuje rozkład ticketów per status — natychmiast widzisz zatory (np. 50 spraw w „oczekuje na stronę trzecią” = problem z dostawcą). Pełna historia zmian statusu z znacznikami czasu dla audytu.
Zobacz zarządzanie statusami w systemie →PORADNIK KROK PO KROKU
Zobacz, jak to zrobić w praktyce
Praktyczna instrukcja krok po kroku z prawdziwymi zrzutami ekranu: Akcje systemu, statusy i stopki.
Najczęstsze pytania
Czym różni się status „rozwiązany” od „zamknięty”?
Rozwiązany (Resolved) — agent uważa że problem rozwiązany, ale klient jeszcze nie potwierdził. Zamknięty (Closed) — klient potwierdził lub minął czas auto-close. Różnica jest ważna dla metryk: reopen rate liczy się od „rozwiązany” (klient niezadowolony ponownie otwiera). Pomieszanie tych statusów zaburza pomiar jakości obsługi.
Czy czas „oczekuje na klienta” liczy się do SLA?
Zazwyczaj nie. Gdy firma czeka na odpowiedź/dane od klienta, SLA timer się zatrzymuje — firma nie odpowiada za zwłokę klienta. Po odpowiedzi klienta timer rusza dalej. To dlatego statusy są kluczowe dla sprawiedliwego SLA. Uwaga na gaming: agenci czasem nadużywają tego statusu by „zatrzymać zegar” — wymaga monitoringu.
Ile statusów powinienem mieć?
5-7 dla większości helpdesk. Minimum: Nowy, W toku, Oczekuje na klienta, Rozwiązany, Zamknięty. Dodatki przydatne: Oczekuje na stronę trzecią, Eskalowany. Powyżej 8-10 statusów agenci się gubią i niespójnie ich używają. Złożone procesy lepiej obsłużyć etapami workflow w ramach statusu „w toku” niż mnożeniem statusów.