Service Cloud

Service Cloud i omnichannel routing w praktyce

Jeden silnik routingu dla chatu, e-maila, spraw i telefonu. Jak skonfigurować Omni-Channel w Service Cloud, uniknąć typowych pułapek i co mierzyć po starcie.

10 czerwca 2026 · 7 min · CloudInfinity Team

Klient pisze na czacie, potem dzwoni, a na końcu odpowiada na e-mail — i oczekuje, że firma pamięta całą rozmowę. Według danych branżowych organizacje z dojrzałą strategią omnichannel utrzymują 67% klientów, wobec 28% w modelu multichannel (osobne, niepołączone kanały). W Salesforce sercem takiego podejścia jest Omni-Channel: jeden silnik routingu, który kieruje pracę ze wszystkich kanałów do właściwych ludzi — a od czerwca 2025, dzięki Unified Voice Routing z Amazon Connect, obejmuje to również telefon.

Jedna konsola dla całego zespołu

Service Console spina wszystkie kanały: sprawy (cases), e-mail, Messaging for In-App and Web, media społecznościowe i voice. Uwaga na ważną datę: legacy Chat (Live Agent) został wycofany 14 lutego 2026. Następcą jest Messaging for In-App and Web — konwersacje asynchroniczne i persystentne, zbudowane na Hyperforce i kompatybilne z Agentforce Service Agent. Jeśli nadal używasz starego chatu, migracja to pierwszy punkt na roadmapie.

Konfiguracja routingu

Omni-Channel oferuje dwa modele:

  • Queue-based routing — kolejka odpowiada działowi lub typowi sprawy. Prostszy w konfiguracji, polecany mniejszym zespołom i na start.
  • Skills-based routing — praca trafia do agenta o wymaganych umiejętnościach (np. hiszpańskojęzyczny billing → dwujęzyczny agent finansowy). Daje wyższe first contact resolution i mniej eskalacji, ale wymaga utrzymywania katalogu umiejętności.
  • Omni-Channel Flow — logika routingu budowana deklaratywnie we Flow Builderze: priorytety, fallbacki, transfery między kolejkami. To dziś rekomendowane podejście do niestandardowego routingu.

Do tego dochodzi model pojemności: każdy typ pracy ma wagę, agent ma łączną capacity, a dystrybucja działa w trybie „Least Active” lub „Most Available”.

Największa pułapka konfiguracji to zbyt wysoka pojemność agenta. Przy capacity ustawionym na 100 spraw agent wracający z urlopu dostaje lawinę case’ów w minutę. Dla pracy długotrwałej używaj status-based capacity, dla kanałów real-time — tab-based.

AI w obsłudze klienta

Z raportu Salesforce State of Service (7. edycja, 2025, ankieta wśród 6 500 profesjonalistów): 85% agentów korzystających z AI deklaruje oszczędność czasu — średnio około 4 godzin tygodniowo na rutynowych sprawach. Prognoza na 2027: połowa spraw rozwiązywana przez AI, wobec ~30% w 2025.

W praktyce oznacza to trzy warstwy: Einstein Case Classification (automatyczna kategoryzacja i priorytetyzacja spraw), Einstein Service Replies i Work Summaries (generatywne odpowiedzi i podsumowania rozmów) oraz Agentforce Service Agent — autonomiczny agent działający 24/7 w kanałach cyfrowych, który rozwiązuje sprawy samodzielnie, a do człowieka eskaluje tylko wyjątki. Omni-Channel spina to w całość: sprawa nierozwiązana przez agenta AI trafia przez ten sam routing do właściwego człowieka, z pełnym kontekstem rozmowy.

Mierzenie efektów

Bez baseline’u sprzed wdrożenia nie udowodnisz wartości projektu. Minimum, które warto śledzić:

  • FCR (first contact resolution) — benchmark branżowy powyżej 70%; śledzi go już 80% organizacji serwisowych
  • AHT (average handle time) — typowo 5–10 minut zależnie od branży
  • CSAT — cel powyżej 75–80%
  • Deflection rate — odsetek spraw rozwiązanych przez AI/self-service bez udziału człowieka
  • FRT (first response time) i koszt na kontakt

Dobrze poprowadzone wdrożenia raportują skrócenie czasu oczekiwania nawet o 39% po integracji narzędzi w jedną konsolę. Klucz to zacząć prosto — queue-based routing, kilka kolejek, rozsądna capacity — i rozbudowywać na podstawie danych, nie przeczuć.


Źródła: Salesforce — State of Service Report (7th ed., 2025), Salesforce Help — Omni-Channel Routing Options, Salesforce Ben — Salesforce to Retire Chat, UnofficialSF — Unified Routing, Plivo — Omnichannel Statistics