Dokumentacja

Automatyzacja obsługi - 3 przypadki

Autor: Dominika Stelmach

Utworzono: 2017-05-08. Aktualizacja: 2017-05-08.

Drzewo IVR Thulium to nie tylko narzędzie do kierowania połączeń do właściwego działu/ osoby na podstawie wyboru klienta. To IVR nowej generacji, gdzie połączenia mogą być dystrybuowane zgodnie z naszymi założeniami i wiedzą o klienta, bez udziału samego klienta. Postanowiliśmy opisać jak możliwości IVR wykorzystują niektórzy nasi klienci.

Przypadek 1

Firma obsługuje klientów w dwóch językach. Nie chce jednak, by klienci nie musieli dokonywać wyboru języka na drzewie IVR. Badanie pokazują bowiem jasno, że klienci preferują proste IVR-y.

Zdecydowano więc, że system będzie sprawdzał w karcie klienta jaki język jest przypisany do tego klienta i na tej podstawie kierował połączenie do odpowiednich konsultantów.

Analogicznie system mógłby sprawdzać posiadany pakiet obsługi (np. klienci VIP) lub wartość dowolnego pola w karcie klienta i na tej podstawie kierować połączenie do odpowiedniej kolejki.

Aby zrealizować powyższy scenariusz, w zakładce “Klienci” w systemie Thulium utworzone zostało pole dodatkowe o nazwie “Język”. Dodając nowego klienta konsultant wybiera dla niego odpowiednią wartość w tym polu np: “polski” lub “angielski”, a system sam kieruje połączenie do właściwej kolejki.

W IVR zastosowano dwie funkcje:

• crmidentifybycallerid
• crmgoto

Funkcja “crmidentifybycallerid” wyszukuje dzwoniącego na Infolinię klienta w naszej bazie klientów na podstawie numeru, z którego klient wykonuje połączenie. Jeśli klient zostanie znaleziony to możemy sprawdzić, jaki język należy ustawić klientowi. Jeśli nie zostanie znaleziony - kierujemy klienta do gałęzi z wyborem języka.

Określeniem języka, zajmuje się funkcja “crmgoto”, która sprawdza w karcie klienta wartość pola. W naszym przypadku jest to pole “język”. Jeśli wartość tego pola to “angielski”, połączenia są kierowana do kolejki obsługiwanej przez konsultantów anglojęzycznych, w przeciwnym przypadku, kierujemy klienta na obsługę w języku polskim.

Zatem cały proces będzie wyglądał następująco:

1. Klient dzwoni.
2. System sprawdza czy w systemie jest osoba, o takim numerze telefonu.
3. Jeśli jest, to sprawdza wartość pola o nazwie “język” i na tej podstawie skieruje połączenie do osób pracujących w tym języku.

Przykład 2

Jeden z klientów Thulium oferuje swoim klientom wiele produktów, a swoich klientów liczy w dziesiątkach tysięcy. Gdy zdarza się jakiś problem techniczny z którąś z usług, wielu klientów jednocześnie dzwoni, by powiadomić dostawcę, że coś nie działa. Powstaje wtedy nagły wzrost liczby połączeń, który trudno obsłużyć. Ponadto wzmożony ruch klientów nie ma na celu konsultacji, a jedynie powiadomienie firmy o problemie.

Ustalono, że najlepiej byłoby automatycznie powiadamiać klientów dzwoniących w tej sprawie, że firma wie o awarii i pracuje nad jej usunięciem.

Obsługa tego procesu wygląda podobnie, ale udział w nim biorą systemy klienta.

Dzwoniący klient jest identyfikowany w Thulium (funkcja crmidentifybycallerid). Jego dane są za pomocą API pobierane z Thulium przez system klienta, który sprawdza dwie rzeczy: z jakich usług korzysta klient. czy na którejś z tych nie zarejestrowano awarii

Za pomocą API te informacje są zwrotnie wysyłane do Thulium i analogicznie jak w poprzednim przykładzie jeśli jest awaria, to system kieruje połączenie do specjalnie w tym celu przygotowanej gałęzi IVR z komunikatem o tej awarii. Tu zastosowana została funkcja crmgoto.

Dzięki takiemu ustawieniu na IVR pozostają tylko osoby, które dzwonią w innych sprawach niż awaria, a cały pozostały ruch zostaje obsłużony bez obciążania konsultantów.

Przykład 3

Firma zajmuje się produkcją i dystrybucją mebli. Klienci kontaktują się z firmą różnymi kanałami, a informacje o statusie zamówień klienta są w innym systemie (poza Thulium). Dla szybkości obsługi istotne jest, by niezależnie od kanału kontaktu klienta, możliwe było szybkie sprawdzenie statusu (jednego lub kilku) zamówień klienta.

W Thulium w karcie klienta utworzono pole specjalne o nazwie “zamówienia”. Za pomocą API wartość tych pól jest na bieżąco aktualizowana. Dodatkowo polu zamówienia nadano specjalny parametr, który zapewnia, że wartość tego pola jest zawsze widoczna jako podstawowa informacja o kliencie. Dzięki temu niezależnie od tego czy klient pisze na czacie, dzwoni czy wysyła wiadomość, konsultant ma pod ręką numery jego zamówień.

Dodatkowo numery zamówień są linkami, które kierują do systemu klienta. Tak zbudowany proces obsługi jest znacznie krótszy i prostszy dla konsultantów niż wcześniej.