Omnichannel to… socjalista
Dlaczego? Ponieważ jednym z celów tego narzędzia jest dać każdemu po równo – zautomatyzować pracę serwisu i przydział zleceń dla agentów w taki sposób, aby ich obłożenie pracą było w miarę jednakowe. Omnichannel powstał z myślą o przyspieszeniu obsługi: sprawne funkcjonowanie serwisu zależy w dużym stopniu od uporządkowania przepływu zleceń.
Dlaczego klienci kochają Omnichannel?
Po pierwsze – podnosi efektywność. Miałem okazję tworzyć wiele serwisów i wiem, że niezależnie od branży zawsze pojawiają się tzw. trudne zgłoszenia. Jest to problem przede wszystkim dla agentów, którzy są rozliczani ilościowo: muszą zamknąć określoną liczbę zleceń, aby odpowiednie słupki w odpowiednim raporcie zaświeciły się na zielono. Dla developerów ten problem może wydawać się obcy, bo w naszej pracy bardziej liczy się jakość, a nie ilość linijek napisanego kodu.
Druga zaleta to szybkość działania. Omnichannel powoduje, że w momencie, gdy pojawia się zlecenie, agent od razu otrzymuje o nim powiadomienie. Dzięki temu ma bieżącą orientację, czym powinien się zająć.
Trzeci atut to oszczędność. Jeśli firma wykorzystuje Service Cloud, nie trzeba ponosić dodatkowych kosztów licencji związanych z Omnichannel.
Po czwarte – Omnichannel supervisor. Niektórzy nazywają go magicznym narzędziem, ale to nie magia – to po prostu funkcjonalność, dzięki której można monitorować pracę agentów w tzw. widoku 360 stopni. W jednym miejscu zebrane jest wszystko, co w danym momencie dzieje się w obszarze obsługi klienta – widoczna jest lista agentów i ich dostępność, zlecenia, nad którymi pracują, dostępny jest tu także backlog serwisu.
Jak skonfigurować Omnichannel?
Zamiast typowych ustawień, pokażę Wam kilka sztuczek, których nie znajdziecie w Trailhead.
Gotowi na tips and tricks?
- Pierwszym krokiem jest wybranie obiektu, jaki będziemy obsługiwać w Omnichannel. Mamy do wyboru kilka standardowych obiektów, na czele ze sprawami. Możemy również używać niestandardowych obiektów. Jedynym ograniczeniem jest to, aby nie miały one nad sobą rodzica w relacji master-detali.
- Następnym etapem jest zdefiniowanie capacity. Można je porównać do pudełka, w którym zmieścimy określoną liczbę klocków. Te klocki to nic innego jak praca, którą muszą zająć się agenci. A my decydujemy, jak duże będzie to pudełko. Dla przykładu przyjmijmy, że w naszym serwisie zajmujemy się sprawami oraz czatami. Czaty to proste zgłoszenia, więc przyjmijmy, że zajmują one 1 capacity. Sprawy wymagają nieco więcej uwagi, więc niech zabierają nam 3 jednostki capacity. Jeśli przyjmiemy, że całkowite capacity naszych agentów będzie wynosić 5, będzie to oznaczać, że agent może jednocześnie pracować maksymalnie nad 1 sprawą i 2 czatami lub 5 czatami.
- Wreszcie – tak istotna kwestia, jak wybór routing model. Do wyboru są dwie opcje: least active oraz most available. Pierwsza oznacza kierowanie zlecenia do agenta, który ma w danym momencie mniejsze obłożenie. Druga przypisuje zlecenie agentowi, dla którego różnica między maksymalnym capacity a obecnie wykorzystanym jest największa. Brzmi nie do końca jasno? Poniższy obraz powinien rozwiać wszelkie wątpliwości.
Obraz 1. Rutowanie spraw do agentów. Opracowanie własne.
Trzeba jednak pamiętać, że wybór routing model ma znaczenie dopiero od chwili, kiedy mamy agentów z różnym maksymalnym capacity. Jeśli jest ono dla agentów równe, to, niezależnie od wybranej opcji, sprawa zawsze trafi w to samo miejsce.
Przeszliśmy przez podstawy konfiguracji. Jesteście ciekawi bardziej zaawansowanych opcji? Zapraszam do lektury kolejnego tekstu! Przekonacie się, że Omnichannel nie raz Was zaskoczy!
- Salesforce Developer
-
Salesforce developer od 2014 roku specjalizujący się również w szkoleniu mniej doświadczonych kolegów z branży. Zafascynowany rozwijaniem umiejętności miękkich oraz udowadnianiem tego, jak bardzo są istotne w pracy developera. Prywatnie człowiek o wielu zainteresowaniach i nikłej wytrwałości, który paradoksalnie bywa nieustępliwy. Pilny obserwator ludzi i życia.