Klient pisze do sklepu: „Przesyłka przyszła dwa dni po terminie, a jeden z produktów ma uszkodzoną obudowę. Nie chcę go zatrzymywać. Proszę o zwrot pieniędzy za zamówienie, łącznie z kosztami dostawy”.
System AI rozpoznaje opóźnienie, znajduje zamówienie i ustala, że sklep prowadzi program dodatkowych rekompensat za nieterminową dostawę. Potrafi przygotować odpowiedź oraz zlecić zwrot opłaty za przesyłkę. Czy powinien zrobić to samodzielnie? A jeśli tak, czy ma prawo oznaczyć zgłoszenie jako zakończone?
Prawidłowe wykonanie jednej dozwolonej czynności nie oznacza prawidłowego rozstrzygnięcia całej sprawy. Dlatego granice automatyzacji trzeba ustalać nie tylko dla funkcji, które udostępniamy AI, lecz także dla rodzaju decyzji i zakresu spraw, które system może samodzielnie zakończyć.
AI nie musi mieć jednego poziomu samodzielności
Obsługa reklamacji obejmuje kilka różnych działań. AI może odczytać wiadomość, pobrać dane, przygotować propozycję odpowiedzi, wysłać ją, zlecić operację finansową albo zmienić status zgłoszenia. Przyznanie prawa do jednego działania nie powinno automatycznie oznaczać zgody na pozostałe.
Na przykład system może przekazać klientowi potwierdzony status jego przesyłki. Nie daje mu to prawa do udostępnienia informacji o dowolnym zamówieniu tylko dlatego, że ktoś podał jego numer. Może również przygotować propozycję zwrotu, nie mając prawa zlecenia płatności. Może wreszcie wykonać ściśle określoną rekompensatę, ale bez uprawnienia do rozstrzygania innych roszczeń.
Poziom samodzielności warto uzależnić od czterech kwestii: konsekwencji pomyłki, możliwości niezależnego sprawdzenia przesłanek, odwracalności skutku oraz tego, czy decyzja wymaga udziału uprawnionej osoby. Nie da się sprowadzić tej oceny do jednego limitu kwotowego. Mały zwrot może być nieuzasadniony, a pozornie niewinna wiadomość może błędnie informować klienta o jego prawach.
Kto ustala, że sprawa jest wystarczająco prosta?
Popularne założenie brzmi: AI obsłuży automatycznie proste przypadki, a trudne przekaże pracownikom. Problem zaczyna się od pytania, kto rozpoznaje, że przypadek jest prosty. To właściciel procesu musi wcześniej określić, jakie przesłanki pozwalają na samodzielne działanie, zamiast zostawiać modelowi swobodę ustalania tych granic.
W naszym przykładzie model może zauważyć opóźnienie przesyłki, ale przeoczyć uszkodzenie produktu i żądanie zwrotu pieniędzy za zamówienie. Jeśli aplikacja potraktuje etykietę „opóźniona dostawa” jako pełny opis zgłoszenia, może prawidłowo przyznać rekompensatę, a następnie błędnie zamknąć całą sprawę.
Wszystkie sprawdzenia finansowe mogą przy tym zadziałać poprawnie. Błąd powstanie wcześniej, przy ustalaniu, czego klient właściwie żąda.
Dlatego trzeba oddzielić rozpoznanie treści zgłoszenia, ustalenie podstaw konkretnego rozstrzygnięcia i prawo wykonania wynikającej z niego operacji. To trzy różne etapy. Kontrola ostatniego nie naprawi przeoczenia z pierwszego.
Jeśli system nie potrafi wiarygodnie ustalić, że rozpoznał pełny zakres swobodnej wiadomości, nie powinien samodzielnie zamykać całego zgłoszenia. Nie musi to jednak wykluczać automatyzacji pojedynczej czynności. Warunkiem jest to, że jej wykonanie nie zależy od poprawnego zinterpretowania pozostałych żądań i nie wpływa na sposób ich dalszego rozpatrzenia lub rozliczenia. Jeśli taka niezależność nie jest zapewniona, potrzebna jest dodatkowa weryfikacja albo decyzja człowieka.
Co można sprawdzić niezależnie od modelu?
Załóżmy, że sklep prowadzi dobrowolny program zwrotu opłaty za dostawę w określonych przypadkach opóźnienia. Program jest odrębny od ustawowych uprawnień klienta i nie może ich ograniczać.
AI może rozpoznać wiadomość o spóźnionej przesyłce i zaproponować zastosowanie programu. Jednak sama propozycja modelu nie powinna być dowodem spełnienia jego warunków. Aplikacja może pobrać uzgodniony termin dostawy, faktyczną datę doręczenia, pobraną opłatę i historię wcześniejszych rekompensat. Musi też wiedzieć, które źródło jest rozstrzygające. Termin przewidywany przez przewoźnika niekoniecznie jest terminem, do którego sklep się zobowiązał. Jeżeli dane są sprzeczne lub niewystarczające, automatyczne wykonanie nie ma podstaw.
Osobno aplikacja sprawdza, czy ma prawo zlecić właśnie taką operację: dla właściwego klienta, właściwej płatności i w kwocie wynikającej z programu. Prośba wpisana w wiadomości, na przykład o przelew na inny rachunek, nie może samodzielnie rozszerzyć tych uprawnień. Instrukcja przekazana modelowi opisuje oczekiwane zachowanie, ale to aplikacja i system docelowy muszą egzekwować ograniczenia.
Są to dwie odmienne kontrole. Jedna dotyczy merytorycznych podstaw rekompensaty, druga prawa do wykonania konkretnej operacji. Nawet ich poprawne działanie nie oznacza, że system rozstrzygnął reklamację uszkodzonego produktu.
Kiedy wolno wykonać część sprawy, a kiedy trzeba ją zatrzymać?
Wróćmy do klienta, który jednocześnie zgłasza opóźnienie i uszkodzenie produktu. Możliwe są dwa scenariusze.
W pierwszym program firmy przewiduje dodatkową rekompensatę za opóźnienie niezależnie od innych roszczeń. System potwierdza warunki na podstawie właściwych danych. Może też ustalić, że wypłata tej rekompensaty nie pomniejszy ani nie zdubluje kwoty, którą trzeba będzie rozliczyć przy pozostałych żądaniach. Dopiero wtedy można dopuścić automatyczne wykonanie tej jednej czynności. Całe zgłoszenie pozostaje otwarte, a klient otrzymuje precyzyjną informację o tym, co wykonano, bez deklaracji zakończenia reklamacji.
W drugim scenariuszu rekompensata zależy od znaczenia wiadomości, zgody klienta albo wzajemnego rozliczenia kilku żądań. Przykładowo sklep może nie wiedzieć, czy planowany zwrot całej zapłaty obejmie już koszt dostawy. Wtedy poprawne potwierdzenie opóźnienia nie wystarcza, żeby bezpiecznie zlecić osobny zwrot tej opłaty. System powinien wstrzymać operację i przekazać sprawę do wyjaśnienia.
Samo pozostawienie zgłoszenia otwartego nie zabezpiecza więc każdej częściowej automatyzacji. Trzeba również sprawdzić, czy wykonywane działanie ma niezależną podstawę i czy nie zmieni konsekwencji rozpatrzenia pozostałych żądań.
Taki podział pozwala automatyzować wybrane fragmenty pracy bez przyznawania AI prawa do samodzielnego rozstrzygania całej reklamacji. Nie można jednak mylić odmowy wykonania czynności przez automat z odmową uznania roszczenia klienta. To drugie nadal wymaga właściwego rozpatrzenia.
Zgoda człowieka musi dotyczyć konkretnej decyzji
W niejednoznacznej sprawie pracownik powinien zobaczyć nie tylko propozycję AI, ale również treść zgłoszenia, potwierdzone fakty, informacje sporne oraz skutek proponowanej decyzji. Musi mieć możliwość odmowy lub zmiany rozstrzygnięcia. Sam przycisk „Zatwierdź” nie zapewnia realnej kontroli, co na przykładzie niejednoznacznego zamówienia pokazuje tekst o obsłudze nietypowych przypadków.
Ważne jest również, co dokładnie zatwierdzono. Jeśli konsultant zaakceptował zwrot określonej kwoty, późniejsza zmiana tej kwoty nie może korzystać z poprzedniej zgody. Przed wykonaniem trzeba sprawdzić aktualny stan sprawy i istotne parametry operacji. Jeśli się zmieniły, konieczna może być ponowna decyzja.
Udział człowieka jest najbardziej potrzebny tam, gdzie niezależne sprawdzenia nie wystarczają do merytorycznego rozstrzygnięcia lub gdzie wymagają go właściwe przepisy. Nie oznacza to obowiązku zatwierdzania każdej czynności. Celem jest świadoma decyzja we właściwym miejscu procesu, a nie przeniesienie całej automatyzacji na kolejkę kliknięć.
Jak zapisać granice automatyzacji przed wdrożeniem?
Deklaracja „AI samodzielnie obsługuje proste reklamacje” jest zbyt ogólna. Dla opisanego programu firma i wykonawca mogą uzgodnić następujące zasady:
- Zakres działania. System może przyznać tylko dodatkową rekompensatę za dostawę. Nie ma prawa samodzielnie rozstrzygnąć roszczeń dotyczących produktu ani zamknąć zgłoszenia zawierającego inne, nierozpoznane lub nierozstrzygnięte żądania
- Podstawa decyzji. Automatyczna rekompensata wymaga potwierdzenia uzgodnionego terminu dostawy, rzeczywistego opóźnienia, pobranej opłaty i warunków programu. Brak wiarygodnego źródła blokuje automatyczne wykonanie
- Niezależność rozliczenia. Wypłata nie może zależeć od niewyjaśnionego znaczenia wiadomości ani kolidować z rozpatrywaniem i rozliczeniem innych żądań. Jeśli tego nie można potwierdzić, sprawę przejmuje pracownik
- Uprawnienia wykonawcze. Aplikacja może odczytywać wyłącznie potrzebne dane i zlecać dozwolony rodzaj rekompensaty. Model nie może sam zmienić jej odbiorcy, kwoty ani reguł programu
- Decyzja człowieka. Sprawy niejednoznaczne trafiają do osoby, która widzi źródła i skutki proponowanego rozstrzygnięcia. Zgoda dotyczy konkretnych parametrów, sprawdzanych ponownie przed wykonaniem
- Status i komunikacja. Informacja o wykonanej rekompensacie wymaga potwierdzenia operacji. Nie oznacza zakończenia innych roszczeń ani nie sugeruje, że klient utracił swoje uprawnienia
Wartość takich zasad nie polega na liczbie punktów, lecz na tym, że każdy można przełożyć na konkretne zachowanie aplikacji i warunek zablokowania działania. Granice trzeba też sprawdzać po uruchomieniu. Jak wykryć, że system mimo wszystko zamyka sprawy z pominiętym żądaniem, opisuje kolejna część o monitorowaniu i reagowaniu na błędy AI.
Najważniejsze pytanie nie brzmi, czy AI można powierzyć obsługę reklamacji. Trzeba ustalić, które decyzje i czynności może zakończyć samodzielnie, na jakich podstawach oraz co musi pozostać poza jej uprawnieniami. Dopiero wtedy określenie „automatyczna obsługa” ma precyzyjne znaczenie dla firmy i wykonawcy.