Pytanie o status uruchamia śledztwo
Klient pyta, gdzie jest zamówienie, a odpowiedź leży w arkuszu, w wątku na czacie i w pamięci osoby, która akurat jest na urlopie. Żeby odpowiedzieć na proste pytanie, trzeba złapać trzy osoby.
Automatyzuję tę część obsługi klienta, która się powtarza: statusy zamówień, potwierdzenia, akceptacje wycen i odpowiedzi na pytania zadawane każdego dnia. Rozmowy, które naprawdę potrzebują człowieka, zostają przy ludziach, a to, kiedy automat oddaje sprawę człowiekowi, jest zapisaną regułą, a nie decyzją modelu.
Pojedynczo żadne z nich nie wygląda groźnie. Razem decydują o tym, czy klient wraca, czy szuka kogoś innego.
Klient pyta, gdzie jest zamówienie, a odpowiedź leży w arkuszu, w wątku na czacie i w pamięci osoby, która akurat jest na urlopie. Żeby odpowiedzieć na proste pytanie, trzeba złapać trzy osoby.
„Zamówienie wyszło”, „przesyłka przeszła odprawę”, „część dotarła”. Te same wiadomości pisane ręcznie, jedna po drugiej, zjadają dzień komuś, kto mógłby zająć się klientem z prawdziwym problemem.
Klient akceptuje wycenę albo odmawia, ale nikt nie przenosi tego do systemu. Zamówienie stoi, a ciepły kontakt stygnie, bo decyzja utknęła w mailu, którego nikt nie oznaczył.
Chatbot podał termin dostawy, którego nikt nie potwierdził, albo cenę z nieaktualnego cennika. Potem ktoś musi dzwonić i to odkręcać, a zaufanie traci się szybciej, niż się je buduje.
Ponowna próba po błędzie sieci, podwójne kliknięcie, dwa systemy wysyłające to samo. Klient dostaje zdublowane SMS-y albo kolejnego maila, choć już napisał, że nie jest zainteresowany.
Tylko ona wie, co obiecano któremu klientowi i na jakim etapie jest jego sprawa. Gdy jej nie ma, klienci słyszą „oddzwonimy” i czekają.
Nie zaczynam od chatbota. Zaczynam od tego, skąd bierze się odpowiedź na pytanie klienta, i dopiero potem decyduję, co może ją wysłać bez udziału człowieka.
Zamówienie przechodzi przez nazwane etapy zapisane w systemie, a nie w niczyjej głowie. SMS o zmianie statusu wychodzi z jednego konkretnego etapu i znikąd indziej, więc nie może pójść dwa razy ani z etapu, którego zamówienie naprawdę nie osiągnęło. Gdy klient pyta, gdzie jest zamówienie, aktualizacje ma już w telefonie, a nikt nie musiał pamiętać o ich wysłaniu.
Połączenia i SMS-y o statusie mogą działać bez nadzoru człowieka, po polsku i po angielsku. Połączenie o statusie to stały skrypt czytany przez syntezator mowy, bez udziału modelu językowego. W dwukierunkowym agencie głosowym model tylko formułuje zdania i wybiera ścieżkę, a każdą zmianę zamówienia i każdą wysyłkę wykonuje zwykły, przewidywalny kod. Ten rodzaj agenta wciąż wymaga dopracowania i nie nazywam go gotowym produktem.
Oferta idzie mailem z linkiem. Kliknięcie zmienia status zamówienia i zapisuje godzinę akceptacji, a dalej idą faktura i SMS do klienta. Decyzja klienta nie czeka, aż ktoś ręcznie przeniesie ją z maila do arkusza zamówień.
Asystent na kamiljan.com odpowiada wyłącznie z faktów, które wcześniej spisałem i zatwierdziłem. Gdy czegoś tam nie ma, mówi to wprost i kieruje do mnie, zamiast zgadywać. Ta sama zasada obowiązuje przy asystencie dla Twoich klientów: odpowiada z Twoich cen i warunków, a nie z ogólnej wiedzy modelu.
Wykrywanie odpowiedzi i blokada kolejnych wiadomości po reakcji klienta muszą działać, zanim wyjdzie pierwsza wysyłka, a nie zostać dopisane później. Bez tego ciepły kontakt czeka na odpowiedź zbyt długo, a klient, który już odmówił, dostaje kolejne wiadomości.
Kilka typowych zastosowań w tym obszarze. Twój proces może wyglądać inaczej, dlatego zaczynam od rozmowy o nim.
Klient dostaje wiadomość przy każdej zmianie etapu, więc nie musi dzwonić.
Godziny, ceny, dostawa: asystent odpowiada z Waszych danych, trudniejsze sprawy oddaje człowiekowi.
Mail, formularz i WhatsApp w jednej kolejce, więc zgłoszenie nie ginie między kanałami.
System przydziela sprawę według tematu i pilnuje terminu odpowiedzi.
Przypomnienie o wizycie albo odbiorze wysłane dzień wcześniej, z możliwością odpowiedzi.
Wysyłana raz, po zamknięciu sprawy, a nie przy każdej zmianie statusu.
Każda reklamacja ma swoje etapy i osobę prowadzącą, a klient widzi, na czym stoi.
Pracownik dostaje gotowy szkic na podstawie historii klienta, poprawia go i wysyła.
Otwierasz sprawę i widzisz krótkie podsumowanie wcześniejszych rozmów, zamiast czytać cały wątek.
Szablon sam uzupełnia numer, termin i nazwisko, więc nikt nie przepisuje ich ręcznie.
Cztery kroki. Pierwszy jest bezpłatny i często wystarcza, żeby wiedzieć, czy w ogóle jest o czym rozmawiać.
Rozmawiamy o jednym procesie: co się w nim dzieje, ile razy w miesiącu i gdzie ucieka czas. Jeśli nie ma tu czego automatyzować, powiem to na tej rozmowie.
Dostajesz proces opisany z zaznaczonymi miejscami strat, proponowany zakres, widełki kosztu i szacowany czas, razem z listą rzeczy, których nie warto ruszać.
Każdy etap kończy się czymś, co da się włączyć do pracy i ocenić w liczbach, zanim ruszy kolejny. Zamiast kwartału ciszy i jednego dużego uruchomienia.
Zespół uczy się na Waszych danych, dokumentacja i dostępy zostają po Waszej stronie. Jestem przy pierwszych nietypowych przypadkach, bo te pojawiają się po starcie, nie w dniu uruchomienia.
Nie i nie po to go buduję. Automat przejmuje powtarzalne wiadomości i pytania, na które odpowiedź jest już w systemie. Rozmowa wymagająca decyzji, reklamacja albo nietypowa sytuacja trafia do człowieka, a to przekazanie jest zapisaną regułą, a nie oceną modelu.
Dlatego projektuję go tak, żeby nie wychodził poza zapisane fakty i nie wykonywał żadnych działań sam. Cenę i termin podaje z systemu albo wcale, a zmianę zamówienia wykonuje zwykły kod, nie model. Gdy nie zna odpowiedzi, mówi to i przekazuje sprawę dalej. Nie mam jeszcze formalnego zestawu testów jakości modelu i mówię o tym od razu.
Od jednego pytania, które klienci zadają najczęściej, na przykład „gdzie jest moje zamówienie?”. Jeśli odpowiedź da się odczytać z systemu, wysyłamy ją automatycznie z właściwego etapu. Pierwsza rozmowa trwa 30 minut i jest bezpłatna: przechodzimy przez jeden proces, a ja mówię wprost, od czego zacząć.
Zależy od liczby kanałów, od tego, skąd płyną dane, i od tego, czy system pod spodem już wie, na jakim etapie jest sprawa klienta. Widełki podaję po obejrzeniu procesu. Większe wdrożenia realizuję z rzeszowskim software house'em CetusPro: ich developerzy dołączają, gdy projekt wymaga większego zespołu.
Kod piszą agenty AI. Ja odpowiadam za specyfikację, architekturę, przegląd tego, co wraca, wdrożenie i za to, co dzieje się na produkcji, gdy klient po drugiej stronie dostaje wiadomość. W ten sposób powstały wszystkie systemy opisane na tej stronie.
Dostępu do danych pilnuje sama baza danych, a nie ukryty przycisk w aplikacji, więc handlowiec technicznie nie odczyta cudzych klientów. Klucze i hasła do usług są poza kodem. Każda zmiana, zanim trafi na produkcję, przechodzi automatyczne sprawdzenia, w tym skan pod kątem wycieku sekretów. Kod i dane zostają po Waszej stronie.
Tak, i zwykle tak to wygląda: zaczynamy od jednego procesu, a kolejne dochodzą etapami. Kod jest w Waszym repozytorium razem z dokumentacją, więc rozbudowę może zrobić też ktoś inny niż ja.
Trzydzieści minut wystarczy, żeby powiedzieć, czy jest tu co automatyzować. Jeśli nie ma, usłyszysz to wprost, zanim powstanie jakakolwiek oferta.
Bez zobowiązań. Bez oferty, zanim zrozumiem proces.
Zobacz, co już zbudowałem →albo napisz na hello@kamiljan.com · LinkedIn