Serwis: dyżury po godzinach, eskalacje i fallback
W serwisie liczą się minuty, ale dyżur działa tylko wtedy, gdy jest przewidywalny: kwalifikacja → dyżur → eskalacja → finał. Webhook pozwala decydować według umowy/SLA i typu sprawy — bez ręcznego “przełączania telefonu”.
Flow po godzinach (dyżur + eskalacja)
- IVR/DTMF: “pilne” vs “standard” (krótko, bez wielopoziomowego menu).
- Webhook: priorytet wg umowy/SLA i typu sprawy.
- Call… do dyżurnego (krótki timeout) → CallStatus.
- Busy/Noanswer → eskalacja do kolejnej osoby / backup.
- Brak odbioru → komunikat + zakończenie / zostawienie kontaktu (jeśli używasz voice2email/oddzwaniania).
Najważniejsze: po kilku próbach rozmowa ma jasny finał. Bez pętli i bez “spróbuj później” bez planu.
Co dopracować, gdy rośnie skala
- jasne definicje “pilne” (żeby nie rozmyć dyżuru),
- osobne kolejki tematów (awaria vs serwis planowy vs rozliczenia),
- eskalacje (kto jest backupem i po ilu sekundach/próbach),
- logowanie UniqueCallId + ścieżka + CallStatus (rozliczalność),
- stabilność webhooka + fallback (dyżur musi działać nawet przy problemie aplikacji).
Praktyczny wzorzec eskalacji: 1) dyżurny A (10–15s) → 2) dyżurny B (10–15s) → 3) backup (np. kolejka) → 4) komunikat + zostawienie kontaktu. Prosto, przewidywalnie, bez zgadywania.
Chcesz zautomatyzować dyżury i eskalacje?
Zacznij od jednego scenariusza “po godzinach” (pilne/standard + eskalacja). Potem dopracuj priorytety i backup, aż proces będzie przewidywalny nawet przy większym ruchu.