Uruchomienie bota w drugim kraju: lista kontrolna

Pierwszy bot powstawał na oczach wszystkich. Wymagania omawiane linijka po linijce, baza wiedzy składana dokument po dokumencie, ktoś z góry czytający każdą pojedynczą odpowiedź przed startem. A drugi? Zupełnie inne przyjęcie. Wygląda na robotę kopiuj-wklej. Duplikat z podmienionym językiem. I właśnie to założenie rozwala wdrożenia na drugim rynku.

Drugi rynek to nie projekt tłumaczeniowy. To drugi produkt, który przypadkiem dzieli część elementów z pierwszym. Rozjeżdża się baza wiedzy, rozjeżdża się sposób mówienia, rozjeżdżają się godziny pracy, rozjeżdża się ścieżka eskalacji - ale rzadko w tym samym momencie, dlatego nikt tego nie zauważa, dopóki klienci nie zaczną narzekać.

Widziałem dość nieudanych drugich wdrożeń, żeby znać ich schemat. Albo odpowiedzi są merytorycznie poprawne, ale podane w rejestrze, którego na miejscu nikt nie używa, albo ton jest idealny, tyle że opakowuje zasady, które w tym kraju nie obowiązują. Ten tekst jest dla zespołów, które mają już jednego działającego bota i szykują się do jego zduplikowania - etap, który regularnie wraca w naszych wpisach o transformacji cyfrowej.

Zdecyduj, co jest wspólne, a co lokalne, zanim cokolwiek skopiujesz

Wyznacz tę granicę raz, na piśmie, zanim zduplikujesz choć jeden dokument. Dorabianie podziału, gdy oba rynki już działają, to droga wersja tego zadania, bo wtedy nikt nie pamięta, które odpowiedzi były celowo zlokalizowane, a które po prostu się rozjechały.

Wspólne to opisy produktów, zasada działania, specyfikacje techniczne, zabezpieczenia tonu marki i granice zakresu - lista pytań, na które bot ma odmówić odpowiedzi. Lokalne to cennik i metody płatności, terminy dostaw, zapisy o zwrotach i gwarancji, informacje prawne, kanały kontaktu i kalendarze świąt.

Kategoria, o której się zapomina, leży pośrodku: treści, które wyglądają na uniwersalne, a takie nie są. Obietnice wysyłki i godziny wsparcia siedzą w odpowiedziach FAQ, które poza tym czyta się jak czystą informację produktową. Jedna reguła wyłapuje większość z nich: jeśli zdanie zawiera liczbę, datę, walutę albo obietnicę, traktuj je jako lokalne, dopóki ktoś nie udowodni czegoś innego.

Skala zmienia tu odpowiedź. Mały zespół może utrzymywać jeden zestaw źródeł nadrzędnych z nadpisaniami dla poszczególnych rynków i mieć to w głowie. Firma z osobnymi wynikami finansowymi na kraj powinna dać każdemu rynkowi własną bazę wiedzy i świadomie synchronizować wspólny rdzeń, według harmonogramu, zamiast liczyć na to, że zmiany same się rozejdą. Nadzieja nie jest mechanizmem synchronizacji. Warto przy okazji tego podziału przeczytać, jak wygląda mechanika dodawania drugiego języka do istniejącego bota, bo decyzje konfiguracyjne wynikają właśnie z niego.

Źródła tłumaczone kontra pisane lokalnie

Tłumaczenie sprawdza się przy materiałach faktograficznych i stabilnych: specyfikacjach, instrukcjach krok po kroku, definicjach produktu. Ta treść odpowiada na to samo pytanie niezależnie od tego, kto je zadaje, więc dobry tłumacz da dobry wynik i temat jest zamknięty.

Sypie się wtedy, gdy lokalny klient zadaje inne pytanie, a nie to samo pytanie w innym języku. Oto pułapka w konkretnej postaci. Twoje FAQ powstało wokół pytań, które zadaje pierwszy rynek. Potem zostało przetłumaczone słowo w słowo. Nowy bot ma teraz świetne odpowiedzi na pytania, których w tym kraju nikt nie wpisuje.

Podziel więc pracę. Przetłumacz materiały referencyjne, a FAQ i prowadzone ścieżki rozmowy napisz lokalnie, na podstawie prawdziwych zgłoszeń z tego rynku. Zdobycie lokalnej listy pytań kosztuje mniej, niż zespoły zakładają: wyciągnij maile z ostatnich kilku miesięcy i transkrypcje czatów z tego kraju, pogrupuj je według intencji, pisz pod te grupy. Nudna robota, ale zajmuje popołudnie, nie kwartał.

Lokalne sformułowania tego samego pytania

Ta sama intencja, inne słownictwo. Klienci na nowym rynku inaczej nazywają twój produkt, proces i problem - czasem sięgają po termin angielski, czasem po lokalny, czasem po nazwę marki konkurenta używaną potocznie. Wszystkie trzy muszą prowadzić do tej samej odpowiedzi.

Zróżnicowanie regionalne wewnątrz jednego języka znaczy więcej, niż większość zespołów się spodziewa, a konwencje grzecznościowe różnią się mocno. Na jednych rynkach zwracanie się per pan czy pani to podstawowa uprzejmość. Na innych dokładnie to samo sformułowanie brzmi chłodno i urzędowo. Ta decyzja należy do kogoś, kto tam mieszka, a nie do osoby, która zatwierdzała pierwszy rynek.

Przy voicebotach to w równym stopniu problem rozpoznawania mowy, co doboru słów. Rozpoznawanie mowy najpierw psuje się na nazwach miejscowości, nazwach ulic, nazwach produktów i wszystkim, co literuje się litera po literze - a to właśnie od tych szczegółów zależy rozmowa z obsługą. Testuj z ludźmi, którzy mówią tym językiem codziennie w tym kraju. Nie z dwujęzycznym kolegą z centrali, który już wie, co bot chce usłyszeć.

Godziny pracy, święta i luka w przekazaniu rozmowy

Bot działa bez przerwy. Ludzie za nim już nie. Rozjazd wychodzi najpierw w dni ustawowo wolne, których centrala nie obchodzi, kiedy kolejka eskalacji po cichu przestaje się ruszać i przez dobę nikt tego nie zauważa.

Zbuduj lokalny kalendarz świąt przed startem, razem ze świętami regionalnymi, które różnią się w obrębie jednego kraju, i wprost ustal, co bot mówi, gdy nie może się do nikogo dodzwonić. Trzeba też zaplanować przesunięcie stref czasowych: zespół wsparcia obsługujący dwa rynki traci wygodne nakładanie się godzin, dzięki któremu pierwsze wdrożenie wydawało się bezwysiłkowe.

Przekazanie rozmowy człowiekowi to standardowa praktyka, którą warto zaplanować. To, do czego zespoły przygotowują się najsłabiej, to komunikat podawany wtedy, gdy przekazanie akurat nie jest możliwe. Jasne „odpowiemy do X” bije obietnicę, która przez noc zostaje bez odzewu.

Dalej pytanie, które większość zespołów pomija całkowicie: kto odpowiada, gdy osoba po drugiej stronie eskalacji nie mówi językiem klienta? Są trzy realne odpowiedzi. Zatrudnić ludzi lokalnie. Kierować do wspólnego zespołu pracującego w języku pośrednim i powiedzieć o tym od razu. Albo ograniczyć zakres bota na tym rynku do tego, co jest w stanie załatwić sam do końca. To, na którą z trzech cię stać, zwykle sprowadza się do tego, jak wdrożenie jest zasobowo obstawione, a nasze pakiety wdrożeniowe pokazują, jak takie wsparcie wygląda w praktyce.

Lista kontrolna przed startem

Punkty do odhaczenia przed uruchomieniem drugiego rynku. Każdy nieodhaczony to decyzja, którą przerzucasz na klientów.

• Lokalna baza wiedzy wgrana i sprawdzona przez rodzimego użytkownika języka, który pracuje z klientami, a nie tylko przez tłumacza.
• FAQ i prowadzone ścieżki rozmowy napisane na podstawie lokalnych zgłoszeń, a nie przetłumaczone z pierwszego rynku.
• Nazwa bota, ton i zakres skonfigurowane osobno dla nowego rynku w panelu administracyjnym.
• Kalendarz świąt i godzin pracy ustawiony dla nowego kraju, razem z różnicami regionalnymi.
• Ścieżka eskalacji opisana na piśmie, z podanym językiem zespołu przyjmującego i deklarowanym czasem odpowiedzi.
• Dwadzieścia do trzydziestu prawdziwych lokalnych pytań przetestowanych od początku do końca, w tym literówki, sformułowania gwarowe, a przy głosie mowa z akcentem i lokalne nazwy miejscowości.
• Podział treści na wspólne i lokalne udokumentowany, żeby kolejna aktualizacja po cichu nie nadpisała odpowiedzi specyficznych dla rynku.
• Wskazany z imienia opiekun na nowym rynku, który przez pierwszy miesiąc co tydzień czyta rozmowy.

Po starcie: czytanie rozmów z nowego rynku

Pierwsze tygodnie na drugim rynku dają najbardziej użyteczny materiał, jaki kiedykolwiek zbierzesz o tym, jak lokalni klienci formułują swoje sprawy. Traktuj przegląd rozmów jako zaplanowaną pracę z przypisaną osobą, a nie jako gaszenie pożaru, gdy coś zepsuje się na tyle widocznie, że nie da się tego przeoczyć.

Dwie rzeczy zasługują na uwagę. Po pierwsze, pytania, na które bot odpowiada pewnie, ale dla tego rynku błędnie - to są te groźne, bo pewność ukrywa je przed pobieżnym przeglądem. Po drugie, pytania, których pierwszy rynek nigdy nie zadawał, bo pokazują, gdzie lokalne FAQ wciąż ma dziury.

Te braki uzupełniaj w lokalnej bazie wiedzy, a nie łataj we wspólnym rdzeniu. Zmień rdzeń, żeby naprawić lokalny problem, a wytrącisz z równowagi odpowiedzi pierwszego rynku, zwykle bez tego, żeby ktokolwiek połączył te dwa zdarzenia. Kilka tygodni później ktoś z pierwszego rynku pyta, czemu odpowiedź się zmieniła. Nikt nie wie.

Przeglądanie transkrypcji i mierzenie efektów to dyscyplina po stronie twojego zespołu, z użyciem tych narzędzi analitycznych, które firma już ma. Po stronie bota chodzi po prostu o utrzymywanie źródeł w aktualnym stanie. Ustal rytm przeglądów i ustal zasadę awansowania lokalnej odpowiedzi do wspólnego rdzenia, gdy potrzebują jej oba rynki.

Potraktuj drugi rynek jako próbę generalną przed trzecim

Prawdziwy zwrot z porządnie zrobionego drugiego wdrożenia to szablon, który po nim zostaje. Rynek trzeci i czwarty powinny kosztować ułamek wysiłku, bo trudne decyzje zostały już przemyślane i spisane. Ten efekt kuli śnieżnej rzadko pojawia się w uzasadnieniu biznesowym.

Nie masz jeszcze bota? Wtedy sensownym punktem wyjścia jest zbudowanie pierwszego porządnie, z podziałem na wspólne i lokalne w głowie od pierwszego dnia, tak żeby drugi rynek był duplikacją, a nie budową od nowa. Jeśli wolisz najpierw omówić ten podział z kimś, porozmawiaj z nami o pilotażu. Rejestracja daje pierwszego voicebota za darmo, co jest mało ryzykownym sposobem na sprawdzenie podejścia, zanim postawisz na nie drugi rynek.