Ten tekst dotyczy odpowiedzi na maile, które klienci piszą do firmy — pytania o zamówienie, fakturę, termin, reklamację. Nie dotyczy wysyłki newsletterów ani kampanii. Na stronie o automatyzacji obsługi klienta ten układ mieści się w jednym punkcie: system przygotowuje projekt odpowiedzi, konsultant go zatwierdza, poprawia albo odrzuca. Ten jeden punkt kryje jednak pytanie, od którego zależy, czy cały układ jest bezpieczny: z czego ten projekt został złożony.
Projekt odpowiedzi jest tak bezpieczny, jak to, z czego go złożono. Gładko napisany mail z błędną datą wysyłki jest groźniejszy od niezgrabnego, bo pod presją kolejki łatwiej przechodzi bez sprawdzenia. Dlatego rozdzielamy w projekcie dwie rzeczy, które narzędzia często mieszają: fakty o sprawie tego klienta i ogólny tekst z bazy wiedzy.
Ogólnych zasad zatwierdzania przez człowieka — trzech wariantów nadzoru, kolejki z właścicielem, testu na klikanie i reguły poluzowania nadzoru — tu nie powtarzamy. Są w tekście human in the loop w praktyce. Tu stosujemy je do jednego kanału: maila od klienta.
Z czego składa się projekt odpowiedzi: fakty z systemu i tekst z bazy wiedzy
Zanim system napisze choć jedno zdanie, musi coś przeczytać. Do odpowiedzi wolno użyć dwóch źródeł, a każde służy do czego innego. Trzeci rodzaj materiału, z którego korzystają niektóre narzędzia, nie powinien dostarczać faktów, a w stylu pomaga dopiero po usunięciu danych klientów.
- Fakty z systemu, w którym są zapisane. Status zamówienia, data wysyłki i numer przesyłki z systemu zamówień albo systemu ERP (oprogramowania do zarządzania firmą), numer i kwota faktury z systemu księgowego, historia zgłoszenia z helpdesku (programu do obsługi zgłoszeń) albo z CRM (systemu do obsługi klientów i sprzedaży). Odczytane w chwili przygotowania projektu, z identyfikatorem zapisu w systemie (rekordu) i godziną odczytu, a przy danych przepisywanych z innego systemu — na przykład od przewoźnika — także z godziną ostatniej aktualizacji. Za fakty o sprawie uznajemy potwierdzone dane z właściwego systemu, a nie każdą treść zapisaną w historii zgłoszenia. Wcześniejsze wiadomości klienta i odpowiedzi modelu można przywołać jako czyjeś słowa, ale nie wolno traktować ich jako sprawdzonych faktów ani pozwalać im zmieniać adresata, uprawnień lub zasad. To jedyne źródło, na podstawie którego projekt może twierdzić cokolwiek o sprawie tego klienta.
- Tekst z bazy wiedzy. Procedura, regulamin, warunki zwrotu, opis produktu — z nazwą wpisu i datą wersji, która obowiązuje dla danego zamówienia albo umowy. Baza wiedzy mówi, jakie są zasady. Nie wie, co się stało z zamówieniem tego klienta.
- Podobne sprawy z przeszłości. Niektóre narzędzia używają ich jako dodatkowego źródła. Zendesk pisze w dokumentacji funkcji auto assist, że gdy brakuje pasującej procedury albo artykułu, do przygotowania odpowiedzi może użyć podobnych rozwiązanych zgłoszeń (dokumentacja Zendesk, stan na 12 października 2026 r.). Fakty z takiej sprawy należą jednak do innego klienta — termin, kwota czy obietnica z cudzej sprawy nie mają miejsca w Twojej odpowiedzi, a samo polecenie „nie używaj tych danych” ich przed modelem nie ukrywa. Jeżeli wcześniejsze sprawy mają podpowiadać ton, bezpieczniej przygotować z nich osobno wytyczne stylu albo usunąć z nich dane klientów — także daty, kwoty i obietnice z tych spraw — zanim trafią do modelu.
Z tego wynika jedna reguła, na której opiera się reszta tekstu: każdy fakt o sprawie klienta — status, termin, kwota — pochodzi z rekordu w systemie, a baza wiedzy dostarcza tylko zasad. To, co klient sam napisał w mailu, projekt może przywołać jako jego słowa albo prośbę, ale nie jako sprawdzony fakt. Projekt, który miesza te rodzaje materiału i nie oznacza, co jest czym, utrudnia wykrycie błędu — bo zdanie „paczka dotrze do piątku” wygląda tak samo, niezależnie od tego, czy przyszło z systemu przewoźnika, czy z ogólnej informacji o czasie dostawy.
Mail przychodzi z zewnątrz, więc system nie może mu ufać na słowo. To, którego klienta i której sprawy dotyczy odpowiedź, ustala system według stałych reguł, a nie model na podstawie treści maila. Zanim sięgnie po dane sprawy, najpierw potwierdza tożsamość klienta zgodnie z zasadami firmy, na przykład przez zalogowane konto klienta — sam adres nadawcy da się podrobić — a potem sprawdza, czy klient ma prawo do danych tego zamówienia. Jeżeli nie może tego potwierdzić, przekazuje maila konsultantowi bez ujawniania danych sprawy. Żadne zdanie w mailu nie może zmienić adresata, uprawnień ani zasad, i to samo dotyczy poleceń znalezionych w bazie wiedzy, w polach zgłoszenia czy w podobnych sprawach.
Gdy faktu brakuje, dwa źródła sobie przeczą albo dane są nieaktualne, projekt nie zgaduje — mail trafia do konsultanta, także w kategorii, która zwykle wychodzi automatycznie. W takiej kategorii system tuż przed wysyłką odczytuje fakty jeszcze raz i sprawdza, czy każde twierdzenie zgadza się z właściwym źródłem, a odpowiedź nie składa żadnej obietnicy z listy niżej. Samo wskazanie źródła ani zapewnienie modelu nie wystarcza. Jeżeli fakty się zmieniły, sprawdzenie wypadło źle albo nie działa, wiadomość trafia do konsultanta. Załącznik, na przykład kopię faktury, dobiera system z potwierdzonego rekordu tego klienta, a nie model, i sprawdza go tuż przed wysyłką.
Przykład: ten sam mail, dwa projekty odpowiedzi
Poniższa para to przykład skonstruowany na potrzeby tego tekstu, nie zapis z wdrożenia u klienta. Dane w nawiasach kwadratowych są wypełniaczami.
Mail od klientki:
Dzień dobry, zamówiłam [produkt] [data], zamówienie nr [numer]. Kiedy dotrze? Jeśli nie do piątku, proszę o zwrot pieniędzy.
Projekt złożony z samej bazy wiedzy:
Dzień dobry, standardowy czas dostawy wynosi [czas z bazy wiedzy], więc przesyłka powinna dotrzeć do piątku. Gdyby się spóźniła, zwrócimy pieniądze. Pozdrawiamy.
Wygląda poprawnie i ma dwa błędy, które bez źródeł łatwo przeoczyć. Termin dostawy nie pochodzi z danych tego zamówienia, tylko z ogólnej reguły. A obietnica zwrotu pochodzi znikąd — baza wiedzy opisuje zasady zwrotów, ale nie podejmuje decyzji za firmę.
Projekt złożony z faktów i zasad, z oznaczonymi źródłami:
| Zdanie w projekcie | Skąd pochodzi | Co robi konsultant |
|---|---|---|
| „Zamówienie nr [numer] wysłaliśmy [data wysyłki], numer przesyłki [numer].” | System zamówień, rekord zamówienia, odczyt [godzina] | Sprawdza, czy rekord dotyczy tej klientki |
| „Według przewoźnika przesyłka jest w drodze; przewidywaną datę doręczenia przewoźnik podaje na stronie śledzenia: [link].” | Status przewoźnika zapisany w systemie zamówień, z godziną ostatniej aktualizacji | Sprawdza, czy status jest świeży, i nie dopisuje własnej daty |
| „Zasady zwrotu opisuje [punkt regulaminu]: [streszczenie].” | Baza wiedzy, wpis „Zwroty”, wersja z [data] | Sprawdza, czy to wersja obowiązująca dla tego zamówienia |
| [Klientka warunkuje zwrot terminem — decyzja konsultanta] | Mail klientki: prośba, która wymaga decyzji | Odpowiada sam albo przekazuje sprawę dalej |
Druga wersja jest mniej gładka i właśnie o to chodzi. Każde zdanie o sprawie ma rekord, zasady mają wpis z datą, a miejsce, w którym potrzebna jest decyzja, jest puste i oznaczone, zamiast wypełnione uprzejmym zdaniem. Konsultant nie musi zgadywać, co sprawdzić — widzi to w trzeciej kolumnie.
Szkic odpowiedzi do zatwierdzenia: co konsultant widzi przy mailu
Ogólny projekt ekranu decyzji opisaliśmy w tekście o zatwierdzaniu przez człowieka. Przy mailu od klienta ekran musi pokazać do tego cztery rzeczy:
- Projekt odpowiedzi w wątku, obok maila klienta, a nie w osobnym oknie — konsultant porównuje pytanie z odpowiedzią.
- Źródło przy każdym fakcie: z jakiego systemu, który rekord, kiedy odczytany. Przy tekście z bazy wiedzy: nazwa wpisu i data wersji. Źródła widzi tylko zespół — w osobnym panelu albo wewnętrznej notatce, nigdy w treści wiadomości do klienta.
- Wyróżnione zdania bez źródła — to te, które konsultant czyta najuważniej albo usuwa.
- Trzy decyzje: wyślij bez zmian, popraw i wyślij, odrzuć i napisz od nowa. Każda zostaje zapisana razem z tym, co konsultant zmienił.
Każdy konsultant widzi przy tym tylko te dane, do których ma dostęp w systemie źródłowym — system sprawdza to, zanim pokaże je w projekcie, w panelu źródeł albo w notatce.
Czego na tej liście celowo nie ma: liczby, którą model podaje o własnej pewności. Taka liczba nie jest niezależnym potwierdzeniem, że odpowiedź zgadza się ze źródłami — model potrafi być bardzo pewny zdania, które jest błędne — i sama nie uzasadnia automatycznej wysyłki. Podstawą jest to, czy fakt ma źródło, i to, co pokazuje dziennik zatwierdzeń.
Część tych elementów helpdeski dają gotowe. Tak opisują je dokumentacje producentów:
| Narzędzie | Co robi konsultant z projektem | Czy widać źródła | Uwagi |
|---|---|---|---|
| Zendesk, auto assist | Zatwierdza (Approve), poprawia w edytorze albo odrzuca sugestię (Dismiss suggestion); wysłane odpowiedzi idą pod jego nazwiskiem i są widoczne w historii zdarzeń zgłoszenia | Tak, jeśli konsultant ma odpowiednie uprawnienia, a sugestia opiera się na procedurach, publicznych artykułach centrum pomocy albo podobnych rozwiązanych zgłoszeniach; innych źródeł uzasadnienie nie pokazuje | Procedury mogą odwoływać się do niektórych pól zgłoszenia i łączyć się z czynnościami (actions) — dane z Twojego systemu zamówień trzeba im udostępnić przez integrację. |
| Intercom, Copilot | Przenosi odpowiedź do edytora (Add to composer) i sam decyduje, co wysłać | Tak, pod odpowiedzią; źródła wewnętrzne są oznaczone i przed przeniesieniem do edytora pojawia się ostrzeżenie | Dokumentacja zaleca sprawdzenie odpowiedzi przed wysłaniem |
| LiveChat, Reply suggestions | Prosi o sugestię (Suggest reply) i po jej przejrzeniu wybiera Use; artykuł pomocy opisuje to jako wysłanie sugestii w czacie | Dokumentacja opisuje źródła, z których powstają sugestie (bazy wiedzy, strony produktów), ale nie mówi, czy są one pokazywane przy sugestii | Dostępne w planach Team, Business i Enterprise; to kanał czatu, nie maila |
Wiersze pochodzą z dokumentacji czytanej 12 października 2026 r. (Zendesk, Intercom, LiveChat) i mogą się zmienić; nazwy w kursywie pochodzą z interfejsów. Zendesk i Intercom pokazują źródła z bazy wiedzy, a Zendesk także z podobnych rozwiązanych zgłoszeń. Fakty o konkretnym zamówieniu pojawią się na ekranie dopiero wtedy, gdy ktoś udostępni je z systemu, w którym są zapisane — i to jest zwykle główna praca we wdrożeniu, a nie samo włączenie funkcji. Przy Zendesku warto też wiedzieć, że auto assist może korzystać z wewnętrznych materiałów udostępnionych mu przez grupy uprawnień (segmenty) także w odpowiedziach dla osób spoza tych grup (dokumentacja Zendesk). Dlatego udostępniaj mu tylko materiały, które nadają się do odpowiedzi klientom i które może zobaczyć każdy konsultant korzystający z tej funkcji.
Gdzie ten krok działa: wspólna skrzynka, helpdesk czy CRM
Odpowiedzi do zatwierdzenia nie wymagają konkretnego narzędzia. Projekt może trafić w trzy miejsca i każde ma inne wady i zalety.
Wspólna skrzynka w Outlooku albo Gmailu. Oba systemy pozwalają aplikacji utworzyć szkic odpowiedzi w istniejącym wątku: w Microsoft 365 służy do tego operacja tworzenia szkicu odpowiedzi (Microsoft Learn), w Gmailu szkic to niewysłana wiadomość z etykietą systemową DRAFT (Google for Developers). Konsultant otwiera wątek, widzi gotowy szkic i wysyła go z programu, którego używa codziennie. Zaleta: zespół nie uczy się nowego narzędzia. Koszt: skrzynka sama nie daje pełnego dziennika zatwierdzeń ani porównania szkicu z wysłaną wiadomością — to trzeba zbudować osobno. Zapisy audytu skrzynki, jeżeli są włączone, mogą być tylko częścią takiego dziennika. Źródła trzeba pokazać poza treścią szkicu, na przykład w osobnym panelu obok wątku, tak żeby przed wysłaniem w wiadomości nie zostały ani znaczniki źródeł, ani puste miejsca na decyzję.
Helpdesk. Historia zdarzeń i podpięta baza wiedzy zwykle są na miejscu, a przyciski do zatwierdzania projektu — tylko w narzędziach, które mają taką funkcję. Helpdesk zna jednak tylko to, co do niego trafi: zgłoszenie, historię kontaktów z klientem i artykuły. Żeby projekt opierał się na statusie zamówienia, ten status trzeba helpdeskowi udostępnić przez integrację — na przykład w polu zgłoszenia albo przez odczyt z systemu zamówień.
CRM. Dane klienta i historia współpracy są pod ręką, co ma znaczenie przy klientach firmowych, gdzie odpowiedź zależy od umowy albo warunków handlowych. Możliwości przygotowywania odpowiedzi do zatwierdzenia różnią się tu bardziej niż w helpdeskach, więc zanim wybierzesz to miejsce, sprawdź, co Twój CRM zapisuje przy wysłanej wiadomości.
Niezależnie od miejsca jedno trzeba zaprojektować zawsze: dokąd trafia poprawka konsultanta. Najpierw trzeba ustalić przyczynę, bo ta sama poprawka może mieć różne źródła. Błędny zapis w systemie źródłowym poprawia właściciel tego systemu. Błąd w odczycie albo w dopasowaniu pól naprawia ten, kto utrzymuje integrację. Gdy fakt i zasada były poprawne, a model je przekręcił, poprawka trafia do konfiguracji systemu, który składa projekt. Nieaktualny wpis w bazie wiedzy poprawia właściciel wpisu, a poprawka tonu trafia do wytycznych stylu. Jeżeli poprawki nigdzie nie trafiają, konsultant robi tę samą korektę codziennie, a dziennik pokazuje „poprawki” bez przyczyny.
Czego projekt odpowiedzi nie może obiecać
Ta zasada jest techniczna, nie prawna: projekt może twierdzić tylko to, co zawiera odczytane źródło, a ekran pokazuje to źródło. W praktyce oznacza to listę rzeczy, których projekt nie pisze sam z siebie, tylko zostawia jako oznaczone miejsce na decyzję konsultanta:
- terminu dostawy, realizacji albo naprawy, którego nie ma w rekordzie;
- zwrotu pieniędzy, rabatu, rekompensaty i wyjątku od cennika;
- uznania albo odrzucenia reklamacji;
- stanowiska w sprawie prawnej, w tym oceny, czy klientowi coś przysługuje;
- zobowiązań w imieniu innego działu („serwis oddzwoni jutro”).
Klient czyta odpowiedź jako stanowisko firmy, niezależnie od tego, kto przygotował zdanie. Sprawę Moffatt v. Air Canada, w której linia lotnicza odpowiadała za to, co powiedział jej chatbot, opisaliśmy przy kosztach voicebota.
Kiedy kategoria maili może wychodzić bez konsultanta — i jak wraca pod nadzór
Regułę poluzowania nadzoru, test na klikanie i trzy liczby, które czyta się razem, opisaliśmy w tekście o human in the loop. Tu tylko to, co jest specyficzne dla maili.
Decyzja zapada dla kategorii, nie dla systemu. „Gdzie jest moje zamówienie” i „chcę złożyć reklamację” to różne kategorie z różnym ryzykiem. Naturalny pierwszy kandydat to kategoria, w której odpowiedź składa się z faktów z jednego rekordu — status zamówienia, numer przesyłki, kopia faktury. Reklamacje, zwroty, rekompensaty i wszystko, co dotyczy zdrowia albo ma skutki prawne, zostają pod pełnym nadzorem na stałe. Mail, który łączy kategorię dopuszczoną do automatycznej wysyłki z taką prośbą — jak w przykładzie wyżej, gdzie pytanie o status idzie w parze z prośbą o zwrot — albo którego kategorii nie da się pewnie ustalić, trafia w całości do konsultanta. Automatyczna wysyłka obejmuje tylko kategorie z zamkniętej listy, a przypisanie kategorii sprawdza się osobno, nie tylko według oceny modelu. To zgodne z regułą z tekstu o human in the loop, że działań nieodwracalnych — przelewu, wysyłki towaru, zobowiązania wobec klienta — nie zwalnia się spod nadzoru: automatycznie wolno wysłać tylko informację z rekordu, czyli węższy zakres tego działania, a wszystko, co byłoby zobowiązaniem, zostaje pod zatwierdzaniem.
Podstawą jest dziennik zatwierdzeń, nie pewność modelu. Najpierw, w okresie, w którym system działa obok dotychczasowej pracy, porównujesz jego projekty z odpowiedziami pisanymi przez zespół — opisujemy to w kroku 6 przewodnika po wdrożeniu AI. Dopiero potem, w ograniczonym wdrożeniu z zatwierdzaniem, zbierasz serię odpowiedzi zatwierdzonych bez poprawek i równolegle przeprowadzasz niezależną kontrolę losowej próbki, opisaną w tekście o human in the loop. Konkretnej długości tej serii nie podajemy, bo zależy od wolumenu kategorii i kosztu pomyłki, a nie od narzędzia.
Wyłącznik: jak kategoria wraca pod nadzór. Każda kategoria zwolniona z zatwierdzania musi mieć jeden przełącznik, który natychmiast przywraca pełne zatwierdzanie — bez wdrożenia, bez zgłoszenia do dostawcy, z zapisem, kto i kiedy go użył. Gdy wystąpi którykolwiek z poniższych sygnałów, natychmiast przywróć zatwierdzanie każdej odpowiedzi w tej kategorii — automatycznie albo ręcznie. Automatyczna wysyłka może wrócić dopiero po wyjaśnieniu problemu i ponownym sprawdzeniu kategorii. Sygnały to sytuacje, gdy:
- kontrola wykaże, że nie został spełniony którykolwiek uzgodniony warunek automatycznej wysyłki — na przykład błędny fakt, obietnica z listy wyżej, cudze dane, zły adresat albo zły załącznik;
- zmieni się wpis w bazie wiedzy, na którym kategoria się opiera, na przykład regulamin zwrotów;
- zmieni się integracja z systemem, z którego kategoria czyta fakty;
- zmieni się model, polecenia dla modelu albo wersja funkcji u dostawcy — wtedy kategoria wraca do ponownego sprawdzenia, zanim odpowiedzi znów wyjdą automatycznie;
- klient zakwestionuje odpowiedź, którą dostał bez udziału konsultanta.
Wyłącznik, którego nikt nie przetestował, nie istnieje. Datę ostatniego testu wpisz do polityki zatwierdzania razem z nazwiskiem osoby, która może go użyć.
Co zapisać przy każdym projekcie odpowiedzi
Pełny zakres dziennika decyzji i okres przechowywania omawiamy przy zatwierdzaniu przez człowieka, w części o tym, co zapisywać w dzienniku decyzji. Przy mailu od klienta zapis powstaje dla każdego projektu, także odrzuconego, a minimum wygląda tak:
| Pole | Po co |
|---|---|
| Unikalny identyfikator każdej wiadomości przychodzącej, identyfikator wątku albo zgłoszenia i kategoria maila | Decyzje o nadzorze zapadają osobno dla każdej kategorii; system używa tego samego identyfikatora przy ponownym przetwarzaniu wiadomości i blokuje ponowną wysyłkę odpowiedzi na tę samą wiadomość, także gdy treść projektu się zmieni |
| Wersja projektu odpowiedzi | Żeby wiedzieć, co dokładnie zobaczył konsultant |
| Źródła użyte w projekcie: rekordy z odczytanymi wartościami i godziną odczytu, wpisy bazy wiedzy z wersją, wersja modelu i poleceń, identyfikator wysłanego załącznika | Żeby przy błędzie wiedzieć, czy zawiodło źródło, czy model |
| Tryb (z zatwierdzaniem albo automatyczny), wynik (wysłano bez zmian, poprawiono, odrzucono) i kto zdecydował — konsultant albo reguła z numerem wersji | Bez tego nie ma dziennika zatwierdzeń, tylko lista wysłanych maili |
| Różnica między projektem a wysłaną wiadomością oraz przyczyna poprawki albo odrzucenia (dopóki jej nie ustalono: „nieustalona”) | Pokazuje, co poprawiono i dlaczego; z niej wynika seria odpowiedzi bez poprawek |
| Czas wysłania albo informacja, że nic nie wysłano | Żeby odtworzyć kolejność zdarzeń, gdy klient zakwestionuje odpowiedź |
Maile od klientów zawierają dane osobowe, a dziennik jako całość też je zawiera, bo jest powiązany z treścią maili. Kto ma dostęp do dziennika, jak długo go przechowywać i jaki dostawca modelu widzi treść maili, to decyzje do podjęcia przed startem. Piszemy o nich w tekście o RODO (ogólnym rozporządzeniu o ochronie danych) przy wdrożeniu modelu językowego i na stronie o bezpieczeństwie i RODO.
Kiedy odpowiedzi do zatwierdzenia nie mają sensu
- Nie ma systemu, z którego da się odczytać fakty. Jeżeli status zamówienia żyje w głowie handlowca albo w arkuszu aktualizowanym raz w tygodniu, projekt może powstać tylko z bazy wiedzy, a wtedy przy pytaniach o konkretne zamówienie nie może potwierdzić statusu i każdy taki mail i tak trafia do konsultanta. Najpierw uporządkuj źródło.
- Odpowiedź jest negocjacją, a nie faktem. Gdy każdy mail to rozmowa o warunkach, cenie albo wyjątku, projekt oszczędza niewiele, a wymaga przeczytania i przepisania prawie w całości.
- Maili jest tak mało, że przeczytanie projektu kosztuje tyle co napisanie odpowiedzi. Ekran, dziennik i wyłącznik trzeba utrzymywać niezależnie od liczby maili.
- Odpowiedź nie potrzebuje żadnego faktu z systemu. Gdy maile to pytania o godziny pracy, adres albo ogólne warunki, wystarczy dobra strona pomocy albo wzorzec odpowiedzi w programie pocztowym.
- Zespół już odpowiada szybko z gotowych wzorców. Jeżeli wzorce działają, sprawdź najpierw, czy problemem nie jest raczej rozpoznanie tematu i skierowanie maila do właściwej osoby — to osobny, zwykle prostszy krok, opisany w przykładach automatyzacji AI.
O co zapytać dostawcę
- Czy każde twierdzenie w projekcie ma przypisane źródło i czy konsultant je widzi?
- Czy system odczytuje status zamówienia i historię sprawy z naszych systemów, czy pisze tylko z bazy wiedzy i podobnych spraw?
- Czy zapisujecie każdy projekt, także odrzucony, i różnicę między projektem a wysłaną wiadomością? Czy zobaczymy odsetek poprawek osobno dla każdej kategorii?
- Czy kategorię zwolnioną z zatwierdzania można jednym ruchem przywrócić pod pełny nadzór i czy to zdarzenie zostaje zapisane?
- Gdzie są przechowywane treści maili i dziennik decyzji i kto ma do nich dostęp?
Jeżeli na pierwsze dwa pytania odpowiedź brzmi „to zależy od modelu”, rozmawiasz o narzędziu do pisania, a nie o odpowiedziach do zatwierdzenia.
Co dalej
Zacznij od jednej kategorii, w której odpowiedź składa się z faktów z jednego systemu, i sprawdź, czy ten system da się odczytać. Jeżeli odpowiedzi mają nie tylko informować, ale i coś zmieniać — wystawić korektę, zmienić zamówienie — potrzebna jest kontrolowana integracja z odpowiednimi uprawnieniami, zatwierdzaniem i rejestrem działań. Często wystarczy zwykła automatyzacja według stałych reguł. Agent AI, czyli system, który nie tylko pisze, ale i sam dobiera kolejne czynności w innych programach, ma sens dopiero wtedy, gdy wybór czynności wymaga interpretacji sprawy. Opisaliśmy to na stronie o wdrożeniu agentów AI. Szerszy obraz automatyzacji procesów, do którego należy ten krok, jest na stronie o automatyzacji AI w firmie.
Co robimy w obsłudze klienta i od czego zaczynamy, opisaliśmy na stronie o automatyzacji obsługi klienta. Napisz nam, jakie maile najczęściej trafiają do Twojej skrzynki i gdzie są zapisane dane, z których powstają odpowiedzi. Odpowiemy, od której kategorii zaczęlibyśmy — albo że na razie wystarczą dobre wzorce odpowiedzi.