Helpdesk IT: SLA, ticket i routing do właściwej kolejki
W IT telefon to kanał “pilny” — ale tylko część spraw faktycznie jest krytyczna. Ten scenariusz łączy DTMF (numer zgłoszenia), routing wg priorytetu/SLA oraz dyżury po godzinach, tak żeby P1 trafiało szybciej, a reszta nie przeciążała on-call.
Flow: ticket → priorytet → kolejka → eskalacja
- IVR: „Jeśli masz numer zgłoszenia, podaj go i zakończ #”.
- GetDTMF → webhook dostaje ticketId (albo timeout/brak numeru).
- Webhook sprawdza ticket: SLA/priorytet, klienta i (opcjonalnie) usługę.
- Routing: P1 → kolejka krytyczna / dyżur; P2/P3 → support; billing/administracja → osobna kolejka.
- CallStatus Busy/Noanswer/timeout → eskalacja/backup (zamiast pętli bez końca).
Dobra praktyka: ticket przyspiesza, ale nie jest wymagany. Jeśli ktoś nie ma numeru zgłoszenia, kierujesz do krótkiej ścieżki “triage” (np. wybór: awaria / pytanie / rozliczenia) i dopiero potem do kolejki.
Routing, który działa w praktyce
1) P1 / krytyczne incydenty
- osobna kolejka P1 (albo dyżur),
- krótszy timeout, szybsza eskalacja,
- po braku odpowiedzi: backup (drugi dyżurny / druga kolejka).
2) P2/P3 / standardowy support
- kolejka support z komunikatem o czasie oczekiwania,
- po godzinach: bez budzenia dyżuru dla wszystkiego — tylko jasny fallback (oddzwonienie / zgłoszenie),
- opcjonalnie: routing wg klienta/umowy (SLA).
3) Billing / administracja
- osobna kolejka, żeby nie mieszać tematów,
- krótki IVR: „rozliczenia / faktury / umowa”,
- po godzinach: komunikat i przekierowanie do kanału asynchronicznego.
4) Po rozmowie
- aktualizacja ticketu w systemie (notatka + czas + wynik),
- powiązanie rozmowy po UniqueCallId,
- opcjonalnie: automatyczne utworzenie zgłoszenia, gdy klient nie ma ticketu.
Stabilność (production-ready)
- timeout webhooka → fallback do kolejki głównej (z krótkim komunikatem),
- limit prób DTMF → przełączenie do konsultanta (zamiast pętli),
- po godzinach: on-call tylko dla P1 (reszta do kolejki/oddzwonienia),
- zawsze zdefiniowany finał (komunikat + kolejka lub zakończenie) — bez “ciszy”.
Loguj: UniqueCallId + ticketId + EventName + czas odpowiedzi + wybraną kolejkę + CallStatus. To daje pełną rozliczalność procesu i skraca diagnozowanie problemów.
Chcesz, żeby SLA działało już na wejściu rozmowy?
Zacznij od jednej ścieżki: ticket → priorytet → routing. Potem dołóż dyżury, eskalacje i reguły według umowy/SLA. Najważniejsze jest to, żeby P1 miało krótszą drogę, a reszta nie przeciążała dyżuru.