Co kryje w sobie Omnichannel Salesforce?

Queue-based routing, czyli od tego wszystko się zaczęło

Albo, inaczej to ujmując, jak to się dzieje, że zlecenia trafiają do agentów?

Omnichannel w Salesforce początkowo funkcjonował tylko w modelu queue-based routing. Znaczy to, że agenci byli przypisani do kolejki bez uwzględniania umiejętności, a pojawienie się zlecenia w kolejce oznaczało, że zostanie wyświetlone agentom z automatu. Plusem tego rozwiązania było przede wszystkim szybkie wdrożenie, za pomocą dosłownie kilku kliknięć.

Jednak gdy pojawiła się potrzeba zaprojektowania zaawansowanej konfiguracji i lepszego dopasowania zleceń do agentów, powstał problem. Okazało się, że Salesforce nie oferuje zbyt wielu opcji konfiguracji i jeśli chcemy “poczarować”, szybko zderzymy się ze ścianą. Ale – gdzie Salesforce nie może, tam developerów pośle i tak powstał skill-based routing. Tu kończy się praca administratorów, a zaczyna – developerów.

Skill-based routing krok po kroku i jeszcze więcej

Konfigurację zaczynamy oczywiście od zdefiniowania listy umiejętności agentów, na przykład znajomości języków obcych. Definiując je i przypisując do agentów, określamy stopień znajomości w skali 1-10. Co ważne – tutaj sami decydujemy o tym, kiedy sprawa powinna trafić do Omni-Channel. Albowiem dzieje się to w kodzie Apex, co pokazuje poniższy obraz.

Obraz 1. Konfiguracja Omnichannel – zdefiniowanie listy umiejętności agentów. Źródło: trialhead.

Przydatną opcją jest możliwość rozszerzenia ustawień, poprzez powiązanie konkretnych umiejętności z czasem oczekiwania na realizację zlecenia. Przyjmijmy, że dana sprawa wymaga znajomości angielskiego i francuskiego, nie chcemy jednak, by obsługa klienta wydłużyła się z powodu braku właściwego agenta. Wówczas konfiguracja oznacza ustalenie limitu czasu: jeśli na przykład w ciągu trzech minut nie będzie dostępny agent ze znajomością obu języków, odrzucony zostanie język francuski i system zacznie szukać osoby tylko z angielskim. Być może jakość obsługi nieco spadnie, ale za to będzie ona szybsza. Coś za coś 🙂

Kolejna możliwość to attribute setup. Pozwala on na wykorzystanie skill-based routing bez użycia Apex. W jaki sposób? Pokazuje to poniższy obraz.

Obraz 2. Konfiguracja Omni-Channel – ustawienie attribute setup. Źródło: trialhead.

To narzędzie przydaje się jednak tylko w prostszych konfiguracjach, w których występuje mniej zależności. Trzeba też pamiętać, że tutaj praca trafia do Omni-Channel podobnie jak w przypadku queue-based routing – wtedy, gdy trafi na kolejkę.

Co jeszcze możecie wdrożyć w Omnichannel?

• Opcja kontynuacji. Dotyczy zlecenia, które zostało już zamknięte. Z różnych przyczyn jednak klient może wrócić ze sprawą, ponieważ nadal coś jest nie tak. Można oczywiście skierować tę sprawę do wszystkich agentów: w efekcie trafi ona do aktualnie dostępnego. Znacznie lepszym rozwiązaniem jest jednak przypisanie jej agentowi, który zajmował się nią wcześniej. Zyskujemy spójność obsługi i czas: agent zna temat, więc klient nie będzie musiał tłumaczyć wszystkiego od początku. A może, gdy agent zaloguje się do Omni-Channel, warto przypomnieć mu, gdzie ostatnio skończył pracę? Możliwości mamy całkiem sporo. Zdecydowanie warto zajrzeć do dokumentacji obiektu agent work.
• Pomijanie capacity. Niezależnie od tego, nad iloma zleceniami pracuje agent, można dodać mu kolejne – mimo że Omni-Channel nie uwzględnia takiej opcji. Wyjaśnienie znajdziesz na poniższym obrazie.

Obraz 3. Konfiguracja Omni-Channel – pomijanie capacity. Źródło: trialhead.

Omnichannel może Cię zaskoczyć

Bądźcie przygotowani, że to, co wydaje się oczywiste, nie zawsze takie jest, a niemożliwe okazuje się możliwe. Oto konkrety.

Kiedy zamyka się agent work? W idealnym świecie prawdopodobnie zamykałby się w tej chwili, kiedy zamyka się case. Agent skończył pracę nad sprawą, więc może zająć się kolejną. Nic bardziej mylnego. Capacity zwalnia się dopiero po zamknięciu taba w serwisowej konsoli. Każdy kij ma dwa końce – i tak jest również w tym przypadku.

Pierwsza sytuacja: agent nie skończył pracy, ale chce zająć się nią później, więc zamyka tab i zwalnia capacity – dla Omni-Channel oznacza to, że można przypisać mu kolejne zlecenie.

Jest też drugi typ użytkownika: ten zostawia otwarty tab w konsoli, mimo że zamknął case. Nie zwolnił jednak capacity i kolejne sprawy się do niego nie przypiszą. Co dzieje się dalej? Możliwe są trzy scenariusze. Agent zrobi sobie przerwę – jeśli przełożony nie zaobserwuje przestoju. W drugim przypadku – zlecenie trafi do Jiry. Trzecia opcja, niestety, nie wygląda już tak różowo, bo oznacza, że wszystko się wydało i wkrótce zadzwoni telefon od przełożonych z komunikatem: Nie po to tyle wydaliśmy na licencję, żeby serwis nie działał.

Oliwy do ognia (z punktu widzenia developerów) dolewa fakt, że agent work nie może zostać zamknięty z poziomu kodu Apex. W ostateczności, kiedy agenci nie chcą z wami współpracować, z pomocą przychodzi Lightning API, ze swoją sprawdzoną metodą. Pokazuje ją poniższy obraz.

Obraz 4. Konfiguracja Omni-Channel – użycie Ligtning API. Źródło: trialhead.

Kiedy zmienia się właściciel rekordu? To kolejny problem, który może napsuć krwi. Oto przykład: agentowi w Omni-Channel zaczyna dzwonić sprawa. Konfiguracja nie pozwala mu na odrzucenie, tylko na zaakceptowanie. On jednak tego nie zrobił. I w tym momencie można zdziwić się pierwszy raz – jest on już właścicielem sprawy, mimo braku akceptacji. Jednak dalej czeka drugie zaskoczenie – agent nie może odrzucić przychodzącej pracy, ale może zmienić swój status na offline. Wówczas sprawa zostanie przekazana dalej. Kto będzie jej właścicielem, wyjaśnia poniższy obraz.

Obraz 5. Konfiguracja Omni-Channel – ustawienia właściciela rekordu. Opracowanie własne.

Największa niespodzianka została jednak na koniec. Na slajdzie widzimy, że zaszły co najmniej trzy zmiany właściciela rekordu. Możemy zatem wysnuć teorię, że rekord został zaktualizowany trzy razy. Pytanie zatem brzmi: ile razy wykonały się triggers, workflows, process builders? Odpowiedź może wielu programistom napsuć nieco krwi, ponieważ nie wykonały się ani razu.

Na zakończenie mam do Was pytanie. Czy dobra konfiguracja Omnichannel równa się skill-based routing i Apex? A może da się robić cuda bez napisania ani jednej linijki kodu?