Kilka marek, jeden zespół supportu: co osobno, a co wspólnie

Najważniejsze wnioski

• Decyzja zapada w czterech miejscach: wiedza, Centrum pomocy, Widget i skrzynka. Tam, gdzie choć jedno z nich musi się różnić w zależności od marki, marka potrzebuje własnej instancji.
• Odrębna instancja na markę oznacza w większości narzędzi jeden abonament na markę. Kto tego nie policzy wcześniej, policzy później.
• Współdzieli się zespół, nie wiedzę: ta sama osoba pracuje w wielu instancjach, ale każdą bazę wiedzy pielęgnuje się osobno.
• Wiedza wspólna dla wszystkich marek to właściwy ciężar pielęgnacji. Nie należy jej wkładać do wspólnej bazy, lecz do jednego źródła, z którego każda marka wyprowadza swoją wersję.
• Ton, odpowiedzi dotyczące ochrony danych i statystyki per marka to trzy miejsca, w których wspólna baza w praktyce zawodzi.

Cztery miejsca, w których rozstrzyga się ta kwestia

Pytanie „jedna instancja czy kilka” brzmi jak pytanie o narzędzia. Jest pytaniem o produkt: co widzą klienci jednej marki, czego klienci drugiej widzieć nie powinni? W architekturze oprogramowania nazywa się to separacją danych klientów, a Microsoft w swoim przewodniku po modelach wielodostępności opisuje sedno tak: kto współdzieli infrastrukturę, musi zapewnić, że przy odpowiadaniu na zapytanie nie zostaną zwrócone dane innego klienta¹. Dla narzędzi supportowych obowiązuje to samo, tylko w odniesieniu do czterech konkretnych miejsc.

Po pierwsze wiedza. Jeśli agent AI odpowiada na pytania o markę A na podstawie artykułów napisanych dla marki B, jest to w najlepszym wypadku mylące, a w najgorszym błędne: inne terminy, inne ceny, inne osoby do kontaktu. Po drugie Centrum pomocy. Jeśli działa pod domeną marki, musi nosić jej nazwę, kolory i język; Centrum pomocy, w którym pojawia się druga marka, zdradza strukturę koncernu, której klientka nigdy nie powinna zobaczyć. Po trzecie Widget. Nosi kolor, logo i powitanie marki, na której stronie jest osadzony. Po czwarte skrzynka. Jeśli zapytanie do marki A ma być niewidoczne dla współpracowników obsługujących wyłącznie markę B, potrzebuje własnej skrzynki.

Reguła brzmi: gdy tylko jedno z czterech miejsc musi się różnić w zależności od marki, marka potrzebuje własnej instancji. W praktyce prawie zawsze różnią się wszystkie cztery. Wspólna baza to wyjątek, nie norma, i pasuje tylko wtedy, gdy marki i tak występują na zewnątrz jako jedna, na przykład marka główna z linią produktów noszącą tę samą nazwę.

Ile kosztuje odrębna instancja na markę

Oddzielne instancje to czyste rozwiązanie, a mają cenę, która często staje się widoczna dopiero po decyzji: w większości narzędzi supportowych instancja jest zarazem jednostką rozliczeniową. Instancja na markę oznacza wtedy abonament na markę, z własnymi stanowiskami i własnymi limitami. Kto planuje trzy marki na jednej osobie, planuje trzy abonamenty.

W przypadku Comlayer jest to wyraźnie określone: jeden obszar roboczy to dokładnie jedna marka. Każdy obszar roboczy ma własną wiedzę, własne Centrum pomocy, własny Widget, własną skrzynkę i własny abonament z własnymi stanowiskami. Dwie marki to dwa obszary robocze, a więc dwa abonamenty; wspólna taryfa obejmująca kilka obszarów roboczych nie istnieje. Ta sama osoba może być członkiem kilku obszarów roboczych i zajmuje w każdym jedno stanowisko. To nie jest przypis, lecz rachunek, który przed decyzją musi leżeć na stole.

Przeciwną pozycją w tym rachunku jest praca, którą kosztuje wspólna baza i która rzadko jest wliczana: każdą odpowiedź trzeba sprawdzać, czy jest prawdziwa dla wszystkich marek; każdy artykuł wymaga informacji, której marki dotyczy; a agent AI przy każdym pytaniu musi zgadywać, o którą markę chodzi, co w oknie czatu na stronie marki A zdołałby, w e-mailu już nie. Rozdzielenie kosztuje pieniądze, wspólna baza kosztuje błędy. Które z obu jest droższe, zależy od tego, jak często marki sobie przeczą.

Jak zespół pracuje w kilku instancjach

Dobra wiadomość przy oddzielnych instancjach: oddziela się wiedzę, nie zespół. Ci sami ludzie obsługują kilka instancji, a do tego potrzebne są trzy rzeczy, które każde narzędzie rozwiązuje trochę inaczej.

Przełączanie między instancjami.

Kto obsługuje trzy marki, potrzebuje sposobu, by między nimi przełączać się bez ponownego logowania. W Comlayer służy do tego przełączanie obszarów roboczych w panelu bocznym: osoba jest członkiem kilku obszarów roboczych i tam między nimi przełącza. Tego, czego nie ma, to skrzynka wspólna dla wszystkich obszarów roboczych; każde zapytanie leży w tym obszarze roboczym, którego Widget lub Centrum pomocy je wywołało. To skutek rozdzielenia, nie luka: wspólna skrzynka byłaby dokładnie tym miejscem, w którym zapytanie do marki A leżałoby obok zapytania do marki B.

Odpowiedzialności i powiadomienia.

W praktyce nie każda osoba obsługuje każdą markę. Kto którą markę obsługuje, reguluje członkostwo: osoba obsługująca tylko markę B jest członkiem tylko jej obszaru roboczego i otrzymuje powiadomienia tylko stamtąd. To zastępuje reguły, które inaczej trzeba byłoby odtwarzać jako filtry w skrzynce. Role obowiązują per obszar roboczy; kto w jednym obszarze roboczym jest administratorem, w innym może być zwykłym pracownikiem.

Podwójna pielęgnacja wiedzy wspólnej dla wszystkich.

To nieprzyjemna strona i nie należy jej upiększać: wiedzę wspólną dla wszystkich marek, na przykład proces zwrotu towaru lub godziny pracy supportu, trzeba pielęgnować osobno w każdej instancji. Kto robi to dziesięć razy ręcznie, ma po trzeciej aktualizacji dziesięć różnych wersji. Wyjściem nie jest wspólna baza wiedzy, lecz wspólne źródło: dokument wewnętrzny, z którego każda marka wyprowadza swoją wersję, z nazwą marki, jej terminami i jej tonem. Jak taki cykl recenzyjny zaczepia się o oryginał i uruchamia w każdej wersji obowiązek, opisaliśmy we własnym wpisie o bazie wiedzy w siedmiu językach; dla kilku marek obowiązuje ten sam mechanizm.

Trzy miejsca, w których wspólna baza zawodzi

Kto mimo wszystko rozważa wspólną bazę, powinien sprawdzić trzy miejsca, w których w praktyce pęka ona najczęściej. Nie są teoretyczne; to powody, dla których zespoły po roku jednak rozdzielają.

Ton. Jedna marka mówi do klientów na ty, druga per pan i pani. Jedna jest zwięzła i techniczna, druga ciepła i obszerna. Agent AI, który obsługuje obie z jednej bazy wiedzy, trafia w ton najwyżej dla jednej. Przy oddzielnych instancjach ton i język ustawia się per obszar roboczy, a agent zna tylko ten jeden. Jak wyglądają wytyczne dotyczące tonu, które sprawdzają się na co dzień, opisujemy w naszym wpisie o tonie AI; przy kilku markach jest to kilka takich zestawów wytycznych, a nie jeden z wyjątkami.

Odpowiedź w sprawie ochrony danych. Jeśli klientka pyta, jakie dane są o niej przechowywane, odpowiedź musi zawierać dane tej marki i, w zależności od tego, kto prawnie stoi za marką, tylko te. Jeśli wszystkie marki leżą w jednej instancji, przy eksporcie trzeba ręcznie rozdzielić to, co zapisano razem. Przy oddzielnych instancjach rozdzielenie jest już wcześniej. Działa to też w drugą stronę: jeśli kilka marek to ta sama firma, wspólna instancja nie jest w tym miejscu żadnym problemem.

Statystyka. Przy oddzielnych instancjach raport supportu per marka to zajrzenie do odpowiedniego obszaru roboczego. Przy wspólnej bazie to kwestia filtra, a filtr zakłada, że każde zapytanie zostało poprawnie przypisane do marki, co przy e-mailach na wspólny adres zdarza się rzadko. Kto chce wiedzieć, czy marka B generuje więcej pytań o zwroty niż marka A, potrzebuje rozdzielenia już przy wpływie zapytania.

Przypadek szczególny: agencja lub dostawca usług

Agencje supportowe i dostawcy usług, którzy przejmują obsługę klienta dla kilku zleceniodawców, stoją przed tą samą decyzją z jednym dodatkowym warunkiem: zleceniodawcy to różne firmy i wspólna instancja nie wchodzi w grę. Tu rozdzielenie nie jest kwestią wyważenia, lecz warunkiem wstępnym.

Model jest wtedy taki sam jak przy kilku markach jednej firmy, tylko z odwróconą własnością: zleceniodawca jest właścicielem instancji, agencja jest w niej członkiem. W Comlayer zleceniodawca zakłada swój obszar roboczy, zaprasza agencję jako członków zespołu i zachowuje wiedzę, Centrum pomocy i abonament w swoich rękach. Gdy współpraca się kończy, członkostwo zostaje usunięte i nic nie trzeba przenosić. Agencja obsługująca dziesięciu zleceniodawców jest tym samym członkiem dziesięciu obszarów roboczych i przełącza się między nimi; własnej zbiorczej instancji nie potrzebuje i nie powinna jej chcieć.

Podjęcie decyzji w jedno popołudnie

Decyzję można podjąć na podstawie czterech pytań w jedno popołudnie i powinna zapaść przed pierwszym artykułem w Centrum pomocy, bo rozdzielanie po fakcie oznacza przypisanie każdego artykułu i każdego zapytania do marki.

1. 01Dla każdego z czterech miejsc (wiedza, Centrum pomocy, Widget, skrzynka) zapisz, czy musi się różnić między markami. Jedno jedyne „tak” rozstrzyga na rzecz oddzielnych instancji.
2. 02Zbierz w jednej liście wiedzę wspólną dla wszystkich marek. To zakres podwójnej pielęgnacji; powinien pozostać mały, a to, co się w nim znajdzie, dostaje wspólne wewnętrzne źródło.
3. 03Policz abonamenty: jedna instancja na markę, stanowiska per osoba i instancja. Liczba leży na stole, zanim zapadnie decyzja.
4. 04Ustal dla każdej osoby, w których instancjach jest członkiem. Kto obsługuje tylko jedną markę, jest członkiem tylko tam.

Kto ma cztery odpowiedzi, ma decyzję. Comlayer nie wymusza jej w żadną stronę, ale jedno stawia jasno: obszar roboczy to jedna marka, a wszystko, co do niej należy, zostaje w nim. Co to oznacza dla bezpieczeństwa i ochrony danych per obszar roboczy, opisano na stronie o bezpieczeństwie i ochronie danych.

Najczęściej zadawane pytania