Architektura platformy omnichannel od środka: jeden model ticketa, kolejki i integracja z CRM

Prezentacje platform obsługi klienta wyglądają niemal identycznie: ładny widok skrzynki, kolorowe statusy, wykres na koniec. Pytania, które naprawdę rozstrzygają o powodzeniu wdrożenia, padają dopiero wtedy, gdy do rozmowy siada dział IT: jak wygląda model danych, co się dzieje z wiadomością między kanałem a agentem, jak platforma zachowa się, gdy CRM odpowie błędem 500 w środku synchronizacji. Ten tekst jest odpowiedzią na te pytania - opisujemy architekturę naszej platformy omnichannel tak, jak opisujemy ją na sesjach technicznych z CTO. Bez marketingu, z decyzjami projektowymi i ich uzasadnieniem.

Cztery kanały, jeden kanoniczny model ticketa

Fundamentalna decyzja architektoniczna platformy omnichannel zapada na samym wejściu: czy kanały pozostają osobnymi światami ze wspólnym interfejsem „na wierzchu”, czy są normalizowane do jednego modelu danych. Wybraliśmy drugą drogę - i to ona determinuje wszystko dalej.

Każdy kanał obsługuje dedykowany adapter: poczta przez IMAP/SMTP albo API dostawcy, telefonia przez Twilio, czat przez własny widget na stronie klienta, Messenger i Instagram przez API Meta. Adapter robi dokładnie jedną rzecz: tłumaczy zdarzenia swojego kanału na zdarzenia kanonicznego modelu. Od tego miejsca reszta systemu - kolejki, routing, SLA, raporty, integracja z CRM - nie wie i nie musi wiedzieć, czy sprawa przyszła mailem, czy telefonem.

Kanoniczny ticket składa się z kilku warstw:

• sprawa (ticket) - status, priorytet, kategoria, przypisanie, terminy SLA, powiązanie z klientem,
• wątek wiadomości - uporządkowane czasowo wpisy: treść, załączniki, kierunek (przychodząca/wychodząca), autor,
• tożsamość klienta - rozwiązana referencja do rekordu klienta (o tym niżej),
• koperta kanałowa - surowe metadane źródłowe: nagłówki maila, identyfikatory rozmowy z API Meta, dane połączenia z centrali.

Kopertę przechowujemy zawsze, w niezmienionej formie. To decyzja z gatunku nudnych, które ratują projekty: gdy pół roku po wdrożeniu trzeba wyjaśnić, dlaczego wiadomość trafiła do złego wątku, odpowiedź znajduje się w surowych nagłówkach, a nie w domysłach.

Dla telefonu normalizacja ma jeszcze jeden krok: rozmowa staje się wpisem w wątku z nagraniem i transkrypcją, a zdarzenia połączenia (odebrane, przekazane, zakończone) - metadanymi sprawy. Dzięki temu telefon przestaje być „innym rodzajem kontaktu”, którego historia żyje w centrali: w widoku sprawy rozmowa telefoniczna wygląda i wyszukuje się tak samo jak mail.

Wątkowanie: najtrudniejsze jest sklejanie, nie odbieranie

Odebranie wiadomości z kanału jest proste. Trudność zaczyna się przy pytaniu, do której sprawy ta wiadomość należy. Każdy kanał wymaga innej strategii:

• E-mail - najpierw nagłówki In-Reply-To i References, potem token sprawy w adresie zwrotnym, na końcu heurystyka po nadawcy i temacie. Kolejność ma znaczenie: nagłówki są wiarygodne, heurystyki tylko prawdopodobne, więc heurystyczne dopięcie do wątku oznaczamy i pozwalamy agentowi je jednym kliknięciem rozpiąć.
• Czat i social - dostawca daje identyfikator konwersacji, ale konwersacja u dostawcy nie równa się sprawie u nas: klient potrafi w jednym oknie Messengera wrócić po trzech tygodniach z zupełnie nową sprawą. Rozdzielamy po oknie czasowym i zmianie tematu, z możliwością ręcznej korekty.
• Telefon - numer dzwoniącego plus otwarte sprawy klienta. Jeżeli klient z aktywną reklamacją dzwoni ponownie, konsultant dostaje propozycję dopięcia rozmowy do istniejącej sprawy zamiast tworzenia duplikatu.

Tożsamość klienta: jedna osoba, pięć identyfikatorów

Ten sam człowiek pisze z adresu prywatnego, dzwoni z komórki, a na Instagramie występuje pod pseudonimem. Warstwa tożsamości utrzymuje mapowanie identyfikatorów kanałowych na jeden rekord klienta - z jawnym stanem „niepowiązany”, gdy dopasowania brak. Celowo nie łączymy tożsamości agresywnie: fałszywe scalenie dwóch różnych klientów jest znacznie droższe w skutkach niż chwilowy duplikat, bo miesza historie spraw i dane osobowe. Scalanie powyżej progu pewności wykonuje się automatycznie, poniżej - jest podpowiedzią dla człowieka.

Kolejki i routing: jawne reguły zamiast magii

Drugi filar architektury to sposób, w jaki znormalizowany ticket trafia do właściwej osoby. Kolejka jest u nas pełnoprawnym obiektem domenowym z własną konfiguracją - nie zapisanym filtrem na liście zgłoszeń. To rozróżnienie brzmi akademicko, dopóki nie policzy się konsekwencji: kolejka jako obiekt ma pojemność, priorytety, godziny pracy, zasady eskalacji i metryki. Filtr nie ma nic.

Nowy ticket przechodzi przez potok routingu:

1. Klasyfikacja - kategoria sprawy, język, wykryty sentyment i wstępny priorytet. Tu pracuje model językowy, ale jego wynik jest sugestią z pewnością, nie wyrocznią: poniżej progu pewności ticket dostaje kategorię „do ręcznej klasyfikacji” zamiast błędnej etykiety.
2. Reguły przypisania - deterministyczne i jawne: kategoria plus język plus segment klienta wskazują kolejkę; wewnątrz kolejki działa przydział po kompetencjach i bieżącym obciążeniu agentów.
3. Zegary SLA - termin pierwszej reakcji i rozwiązania startują w momencie przypisania, z kalendarzem godzin pracy per kolejka.
4. Eskalacje - zbliżający się termin, wykryta eskalacja emocjonalna albo jawne żądanie rozmowy z człowiekiem przenoszą sprawę wyżej według zdefiniowanej ścieżki.

Zasada nadrzędna: model klasyfikuje, reguły decydują. Dzięki temu każda decyzja routingu jest odtwarzalna - w logu widać, która reguła zadziałała i na podstawie jakich atrybutów. W środowiskach regulowanych to wymóg audytu; wszędzie indziej to po prostu jedyny sposób, żeby debugować routing zamiast go zaklinać.

Kolejki pełnią też rolę bufora na piki. Skok wolumenu - kampania, awaria produktu, sezon - nie wywraca systemu, tylko wydłuża kolejkę, a priorytety pilnują, żeby wydłużała się od właściwego końca: sprawy o wysokim priorytecie i bliskim SLA wyprzedzają masowe pytania powtarzalne, które w międzyczasie w dużej części domyka automatyzacja.

Integracja z CRM: webhooki, polling i idempotencja

Najwięcej wdrożeń systemów obsługi nie wywraca się na funkcjach, tylko na integracji z CRM. Dlatego ta warstwa dostała u nas najwięcej inżynierskiej uwagi - i dlatego poświęcamy jej najdłuższą sekcję.

Zacznijmy od podziału odpowiedzialności, bez którego każda integracja gnije: CRM pozostaje źródłem prawdy o kliencie (dane firmowe, właściciel relacji, wartość), platforma jest źródłem prawdy o interakcjach (sprawy, wiadomości, rozmowy). Synchronizujemy referencje i zdarzenia, nie kopiujemy całych obiektów w obie strony. Większość integracji, które widzieliśmy w audytach przejmowanych systemów, cierpi dokładnie na to: dwa systemy uważają się za właściciela tych samych danych i nadpisują się nawzajem.

Webhook czy polling? W praktyce: jedno i drugie

Podręcznikowa odpowiedź brzmi „webhooki, bo niska latencja”. Praktyka jest mniej elegancka:

• Webhooki dają zmiany w czasie niemal rzeczywistym i zerowy koszt pustych odpytań, ale ich dostarczenie nie jest gwarantowane: endpoint bywa niedostępny, dostawca ponawia próby według własnego uznania albo wcale, a przy awarii po naszej stronie zdarzenia przepadają bezpowrotnie. Do tego dochodzi weryfikacja podpisów i ochrona endpointu przed zdarzeniami podrobionymi.
• Polling jest przewidywalny i odporny - sami kontrolujemy rytm - ale wprowadza opóźnienie równe interwałowi, zjada limity API (rate limits w CRM-ach to zasób deficytowy) i wymaga dyscypliny przy oknach czasowych: pobieranie „zmienionych od ostatniego razu” z zakładką na zegary rozjechane między systemami.

Nasz wzorzec to webhooki jako ścieżka główna, polling jako rekonsyliacja: zdarzenia z webhooków obsługujemy natychmiast, a niezależny proces co ustalony interwał porównuje stan obu systemów i domyka rozjazdy - zdarzenia zgubione, dostarczone podwójnie albo w złej kolejności. Rekonsyliacja to przyznanie się do prawdy o systemach rozproszonych: cokolwiek może pójść źle, kiedyś pójdzie, więc zamiast zakładać niezawodność ścieżki zdarzeniowej, projektujemy tanią ścieżkę naprawczą.

Idempotencja: operacja wykonana dwa razy równa się wykonanej raz

Skoro zdarzenia mogą docierać podwójnie i w złej kolejności, każda operacja zapisu musi być idempotentna. Konkretnie:

• Klucze zewnętrzne zamiast „utwórz” - zapis kontaktu czy sprawy do CRM to zawsze upsert po stabilnym kluczu (identyfikator platformy przechowywany w polu zewnętrznym CRM), nigdy ślepe „create”. Powtórzone zdarzenie aktualizuje istniejący rekord zamiast tworzyć duplikat.
• Klucz idempotencji na żądaniach - wywołania, które nie są naturalnie idempotentne, dostają identyfikator operacji; odbiorca (nasz albo CRM, jeśli wspiera) rozpoznaje powtórkę i zwraca poprzedni wynik.
• Porządek przez wersjonowanie - zdarzenie niesie znacznik wersji lub czasu źródła; starsza wersja przychodząca po nowszej jest odrzucana, zamiast cofać dane.
• Ponowienia z wykładniczym odstępem i kolejka spraw martwych - nieudane wywołanie wraca do kolejki z rosnącym opóźnieniem; po wyczerpaniu prób ląduje w kolejce DLQ z pełnym kontekstem, którą człowiek przegląda z poziomu panelu, a nie logów serwera.

Te cztery mechanizmy brzmią jak inżynierska pedanteria, dopóki nie zderzy się ich z codziennością: CRM ma okno serwisowe w nocy, ktoś zmienia uprawnienia klucza API w piątek, dostawca wprowadza limit żądań bez zapowiedzi. Integracja bez idempotencji przeżywa demo. Integracja z idempotencją przeżywa produkcję.

Jeśli po tej sekcji masz pytania o konkretny CRM albo nietypowy system wewnętrzny - umów rozmowę techniczną. Mapowanie istniejącego stacku to standardowy element naszego discovery i najszybszy sposób, żeby sprawdzić, czy integracja jest trywialna, czy ciekawa.

Dlaczego time-to-value liczy się w tygodniach, nie kwartałach

Wszystko powyższe - model kanoniczny, adaptery, potok routingu, warstwa integracyjna z rekonsyliacją i idempotencją - istnieje, zanim projekt u klienta w ogóle wystartuje. To jest cała pointa modelu produktowego: rdzeń platformy nie jest budowany na zamówienie, tylko konfigurowany. Praca wdrożeniowa sprowadza się do trzech strumieni:

1. Konfiguracja domeny - kolejki, kategorie, reguły routingu, kalendarze SLA, uprawnienia zespołu. Praca warsztatowa z ludźmi, którzy znają proces obsługi.
2. Adapter i mapowanie CRM - podłączenie istniejącego CRM: mapowanie pól, decyzje o kierunkach synchronizacji, uzgodnienie kluczy zewnętrznych. Dla popularnych systemów mamy gotowe adaptery, dla niszowych piszemy warstwę pośrednią na sprawdzonym szkielecie.
3. Kanały - przepięcie skrzynek, numerów i kont social na adaptery platformy, z okresem równoległego działania starego i nowego przepływu.

Typowe wdrożenie zamyka się w 4-8 tygodniach, zależnie głównie od liczby integracji - a działający prototyp na realnych danych klienta pokazujemy w 48 godzin od kick-offu discovery (wartości typowe z naszych wdrożeń; dokładny harmonogram zawsze wynika z discovery). Z doświadczenia: czas konsumują nie funkcje platformy, tylko trzy rzeczy, które warto zaplanować z góry - jakość danych w istniejącym CRM (duplikaty klientów wychodzą przy pierwszej synchronizacji), przegląd bezpieczeństwa po stronie IT klienta oraz decyzje procesowe typu „kto właściwie odpowiada za sprawy z Instagrama”. Żadna z nich nie jest techniczna, każda potrafi zatrzymać projekt - dlatego wszystkie trzy adresujemy w pierwszym tygodniu, nie w ostatnim.

Tak zbudowaną architekturę wdrożyliśmy produkcyjnie w e-commerce - od konsolidacji kanałów po integrację ze sklepem. Jak wyglądałoby to u Ciebie, przejdziemy na bezpłatnej konsultacji.

Architektura, którą można audytować, zanim się ją kupi

Napisaliśmy ten tekst z prostego powodu: uważamy, że decyzja o platformie obsługi klienta powinna zapadać na poziomie modelu danych i wzorców integracji, a nie zrzutów ekranu. Jeżeli po lekturze chcesz zejść głębiej - schemat modelu, przebieg konkretnego zdarzenia przez system, zachowanie przy awarii CRM - umów sesję techniczną albo zobacz platformę omnichannel w działaniu. Przychodzimy z architektem, nie z handlowcem, i odpowiadamy na pytania „co się stanie, gdy…” tak długo, aż skończą się scenariusze. System, który wdrożysz, zostaje własnością Twojej firmy - więc masz prawo prześwietlić go przed decyzją, nie po niej.