O czym jest ten film
- Autor pokazuje, jak w swojej firmie rozwiązał 51 z 52 zgłoszeń obsługi klienta z pomocą AI — i dlaczego 98% skuteczności wcale go nie zadowoliło.
- Kluczowa zmiana myślenia: podejście z 2026 roku patrzy nie na koniec zgłoszenia, lecz na cały proces i całą ukrytą pracę, która do niego prowadzi.
- Przykładowy problem — ludzie nie mogli dostać się do społeczności na Slacku — okazał się splotem czterech–pięciu różnych przyczyn wskazujących na jedne „zepsute drzwi”.
- Rozwiązanie u źródła (samoobsługowy dostęp dla zaufanych domen, niewygasające zaproszenie) zbiło łączną liczbę zgłoszeń z 52 do 19 w porównywalnym tygodniu.
- AI pomaga na każdym etapie: analizy, znajdowania przyczyn źródłowych, projektowania rozwiązania i wdrożenia — zwłaszcza w nieliniowej, „researcherskiej” pracy rozproszonej po wielu narzędziach.
- Metoda startowa: spisać cały proces tak, jak wygląda naprawdę, zmierzyć czas i wskazać, gdzie leży realny ból (nie pisanie odpowiedzi, lecz gromadzenie kontekstu).
- Autor zachowuje ludzką akceptację przy każdej decyzji dotyczącej dostępu i pieniędzy — automatyzacja ma zdejmować obciążenie, nie psuć jakości obsługi.
- Przykład Gumroada pokazuje, jak daleko może pójść agent z dostępem do kodu: odtworzył błąd, napisał test, otworzył pull request, a klient stał się częścią procesu zatwierdzania poprawki.
- Support to dobry pierwszy projekt agentowy, bo wynik jest trudny do sfałszowania — klient albo wchodzi na konto, albo nie; surowy materiał już leży w skrzynce.
- Praktyczny plan wdrożenia: zebrać 50–100 zgłoszeń, oczyścić z danych wrażliwych, kazać agentowi pogrupować je według przyczyn, samemu sprawdzić grupowanie, wybrać bezpieczny problem, prowadzić w trybie roboczym i prowadzić kartę wyników.
Redakcyjne tłumaczenie
98% to nie był powód do dumy
W ciągu ostatnich kilku tygodni rozwiązaliśmy w mojej firmie 51 z 52 zgłoszeń obsługi klienta z pomocą AI — i w tym materiale pokażę wam, jak to zrobić. Na papierze był to tydzień z wynikiem 98% i wydawało mi się, że idzie nam dobrze. Ale spędziłem dość lat w Amazonie, żeby wiedzieć, że ta obsesja na punkcie klienta nigdy mnie nie zostawi w spokoju. A AI jest fantastycznym narzędziem, żeby się w to zagłębić.
Jeśli więc jesteś gdziekolwiek blisko klientów, ten materiał pokaże ci, jak zautomatyzować twoją pracę. A jeśli nie jesteś — da ci zasady, które i tak możesz wykorzystać. Możesz je zastosować do dowolnego powtarzalnego procesu.
Anatomia jednego głupio małego problemu
Będę konkretny. Nasz największy problem wyglądał niemal absurdalnie błaho: ludzie nie mogli dostać się do społeczności na Slacku. Zanurkowaliśmy więc w to — co tu się właściwie dzieje? Dlaczego to takie trudne? Kiedy się przyjrzeliśmy, okazało się, że problemy z dostępem do Slacka układają się w przewidywalne wzorce. To były rzeczy, które wcześniej robiliśmy ręcznie, ale AI ogromnie ułatwiło ich rozgryzienie.
Same problemy były bardzo proste. Część osób nigdy nie dostała zaproszenia. Część otrzymała link do logowania i usłyszała, że już wygasł. Część zapłaciła jednym adresem e-mail, a chciała dołączyć innym. Kluczem było przyjrzenie się ręcznej pracy, którą wykonywaliśmy, a która nie była od razu widoczna w samym odpowiadaniu na maila — całej tej ukrytej robocie, która wchodzi w sukces klienta.
Strategia 2026 zamiast 2024
I to właśnie odróżnia strategię automatyzacji AI z 2026 roku od tej z lat 2024–2025. W 2024 i 2025 patrzyłeś na koniec zgłoszenia. Patrzyłeś, jak dostarczyć klientowi wartość i czy da się to uprościć. W 2026 patrzysz na cały proces. Patrzysz na całą ukrytą pracę, którą wykonujesz, żeby do tego dojść.
My znajdowaliśmy maila. Sprawdzaliśmy płatność. Zaglądaliśmy do Slacka. Wysyłaliśmy kolejne zaproszenie. Pisaliśmy kolejne przeprosiny. Zamykaliśmy kolejne zgłoszenie. A to zmienia pytanie — bo pytanie nie brzmi już tylko „jak odpowiedzieć tym ludziom szybko”. To jest pytanie z 2024 roku. Brzmi ono: „jak sprawić, żeby ludzie w ogóle nie musieli nas o to prosić?”.
Rozwiązaliśmy to u źródła z pomocą AI i faktycznie udało się to usunąć całkowicie. Ostatecznie zmieniliśmy sposób, w jaki ludzie uzyskują dostęp. Wprowadziliśmy zatwierdzone domeny e-mail, które mogły wejść do przestrzeni roboczej w trybie samoobsługowym. Stworzyliśmy niewygasające zaproszenie do społeczności. I powtarzalny krok zatwierdzania po prostu zniknął dla ludzi, którzy powinni być wpuszczani automatycznie.
Efekty zobaczyliśmy od razu. W kolejnym porównywalnym tygodniu nasza łączna liczba zgłoszeń spadła do 19. A Slack nie tylko przestał być problemem obsługi klienta — on się w ogóle nigdzie nie pojawił. Dostęp do Slacka był naszą największą kupą pracy. I w jeden tydzień, z pomocą AI, zmieniliśmy tę ścieżkę dostępu, a cała ta kategoria zniknęła.
„Przecież dałoby się to bez AI”
Możesz teraz pomyśleć: „no dobrze, ale czy nie dałoby się tego zrobić bez AI?”. Tak, dałoby się. Ale sęk w tym, żeby przejść przez cały proces analizy tego, co poszło nie tak — zrozumieć pełen ból, który złożył się na ten problem. Bo problemy, o których mówiłem, to nie był jeden typ dostępu, tylko cztery czy pięć splecionych ze sobą. Potem trzeba znaleźć przyczynę źródłową każdego z osobna, potem je rozwiązać, a potem to wdrożyć. To zajęłoby dłużej. To było trudniejsze. AI było pomocne na każdym etapie — przy analizie, przy szukaniu przyczyn źródłowych, przy zrozumieniu, jak rozwiązać te konkretne kwestie, i przy wdrożeniu rozwiązania.
Takie historie w epoce AI sprawiają, że inaczej patrzę na obsługę klienta. Wcześniej pytałem, jak agent może nam pomóc odpowiadać ludziom szybciej. A to jest przykład sytuacji, w której zadałem lepsze pytanie, na miarę 2026 roku. Praca pokazała nam, że z pomocą AI wsparcie może więcej, niż od niego wymagaliśmy. Mogliśmy pomóc osobie, która stoi przed nami, mogliśmy powstrzymać zespół przed powtarzaniem tego samego sprawdzania i ostatecznie mogliśmy poprawić całą jakość doświadczenia dla tysięcy ludzi, którzy na ten problem jeszcze nie natrafili.
Niewiele jest miejsc w firmie, gdzie ta sama praca może jednocześnie usunąć wewnętrzne niespójności, poprawić doświadczenie klienta i podnieść jakość produktu. Sukces klienta jest jednym z takich miejsc — i to jeden z powodów, dla których wybrałem go na dzisiaj.
(Informacja dodatkowa: MCP — Model Context Protocol — to standard łączenia asystentów AI z zewnętrznymi narzędziami i źródłami danych. „Computer use” oznacza zdolność agenta do obsługi aplikacji tak jak człowiek: klikania, czytania ekranu, wypełniania pól.)
Co ma zrobić czytelnik do końca filmu
Oto, co chcę, żebyś potrafił po obejrzeniu tego materiału. Weźmiemy jeden problem obsługi, który wraca w kółko. Damy agentowi dość informacji, żeby naprawdę go zrozumiał, pozwolimy mu pomóc przy następnym kroku, sprawdzimy, czy w kolejnym tygodniu mniej osób potrzebuje pomocy, zamkniemy tę pętlę i zobaczymy, jak to skalować dalej. Innymi słowy — weźmiemy dokładnie to, co przed chwilą opisałem w swojej firmie, i zadbamy, żebyś miał narzędzia, by zrobić to u siebie.
Masz tu dużą swobodę. Tę pierwszą pętlę możesz zbudować z Claude’em. Możesz zbudować ją z Codeksem albo dowolnym innym agentem, który korzysta z wiadomości i zapisów, które już masz. A kiedy zobaczysz to w obsłudze klienta, chcę, żebyś rozpoznał tę samą okazję w sprzedaży, w finansach, w IT i w produkcie.
Najpierw pokażę, co agent może obsłużyć, a co nadal musi robić człowiek — co jest szczególnie istotne w epoce sukcesu klienta. Relacjonowałem przypadki, w których ludzie przesadnie zawierzyli agentom. A potem porozmawiamy o tym, jak rozpoznać, czy naprawdę usunąłeś problem, czy tylko go zautomatyzowałeś i sprawiłeś, że zła odpowiedź przychodzi szybciej.
Zacznij od spisania i zmierzenia procesu
Zanim cokolwiek zautomatyzowaliśmy, usiedliśmy i przegadaliśmy cały proces obsługi. Spisaliśmy każdy pojedynczy krok tak, jak wygląda naprawdę — nie idealnie i nie na papierze. Zapisaliśmy, ile trwa. Zapisaliśmy, które części wymagają osądu, a które da się zautomatyzować.
To daje mnóstwo korzyści. Można to podać AI jako kontekst. A my jesteśmy mali, więc każdy robi wiele rzeczy naraz. Wszyscy rozumieją, jak to działa w praktyce, i potrafią ocenić, czy dane rozwiązanie AI faktycznie zdejmie im obciążenie umysłowe, czy nie. Wszystko zaczyna się od spisania, a potem mierzymy czas — bo napisanie odpowiedzi nie jest kosztowną częścią, jeśli chodzi o czas.
Naprawdę zrozumienie, gdzie leży ból, wymaga tej klasycznej, nudnej roboty w stylu badania czasu pracy — trzeba usiąść, przejść przez swój proces i powiedzieć: „O rany, to zajęło o wiele dłużej, niż myślałem”. Ustalenie, co się tu naprawdę dzieje, jest tą bolesną częścią, bo jest nieliniowe i wymaga dużo osądu. Musisz sprawdzić pięć różnych narzędzi, potem wrócić, potem napisać aktualizację, zredagować ją i spróbować wszystko poskładać w głowie. A to wszystko dzieje się w wielu miejscach naraz. Żaden pojedynczy serwer MCP tego nie rozwiąże. To nie jest problem AI z 2024 ani nawet z 2025 roku. To jest problem AI z 2026 roku.
Bo przekopujesz się przez maile, przez Slacka, przez wiadomości bezpośrednie, przez pytania o płatności w Stripe, przez Substacka, i przeszukujesz stare rozmowy. To tyle różnych miejsc, z których trzeba pozbierać kontekst. To okropny sposób poznawania problemu. I to była wyjątkowo ludzka udręka. A nie musi być.
(Informacja dodatkowa: Stripe to platforma płatności, Substack — platforma do newsletterów i publikacji. Nate B. Jones prowadzi na Substacku odpłatną część swoich materiałów.)
Zamień ból w bilety z kontekstem
W 2026 roku pierwsze, co zrobiliśmy, to zapisaliśmy ból. Mówimy o spisywaniu, ale dbamy też o to, żeby każdy pojedynczy kawałek bólu miał własne zgłoszenie (bilet). Bilet jest w istocie małym rusztowaniem — możesz na nim zawiesić wszystkie informacje potrzebne do rozwiązania problemu.
Dla typowego problemu z zaproszeniem na Slacka zmieniło to pracę z 5–10 minut nieukierunkowanego researchu do niecałej minuty. Zorientowaliśmy się, że jest zestaw poszukiwań, które i tak musimy przeprowadzić — i mogliśmy to zautomatyzować AI, dołączyć do biletu, a potem wystarczyło otworzyć zgłoszenie i zobaczyć, co jest w środku: co ustalono o płatności, co o koncie, co o wcześniejszych rozmowach. I powiedzieć: „Dobra, wszystko tu jest. Teraz tylko muszę to wykonać”.
W całym tym przepływie osoba, która go prowadziła, oszacowała, że jakieś 90% obciążenia umysłowego zniknęło — po prostu dzięki ustaleniu, gdzie leży ból, spisaniu kroków, wskazaniu największego obciążenia, które dźwigał człowiek, uświadomieniu sobie, że to obciążenie nikomu nie pomaga być bardziej ludzkim, i wymyśleniu, jak rozwiązać to za pomocą computer use i wielu MCP z 2026 roku.
Człowiek zostaje tam, gdzie w grę wchodzą dostęp i pieniądze
Czy w pełni to zautomatyzowaliśmy? Nie. Zachowaliśmy ludzką akceptację przy każdej decyzji dotyczącej dostępu albo pieniędzy, bo jakość naprawdę się liczy. Chcę, żeby ludzie mieli doświadczenie, które faktycznie sprawia wrażenie prowadzonego przez człowieka, nawet w epoce AI. Ale to właśnie oznacza, że mamy więcej możliwości, by skuteczniej obsługiwać ten rodzaj pytań — bo część innej roboty, której nie musi wykonywać człowiek, została zautomatyzowana.
To świetny przykład decyzji, którą musisz umieć podjąć, żeby skutecznie wdrożyć AI w sposób, który nie pogarsza obsługi klienta. Wszyscy tam byliśmy. Ja też — rozmawiałem z automatycznym botem AI na dość znanej stronie i miałem ochotę wyrzucić komputer przez okno, bo tak kiepsko pozwalał mi faktycznie uzyskać odpowiedzi na pytania. Nie chcesz być w takiej sytuacji. Chcesz być w pozycji, w której zdejmujesz ciężar ludzkiego bólu, dostarczasz szybsze odpowiedzi, rozwiązujesz problemy u źródła — ale nie stajesz na drodze jakości doświadczenia.
Jak to skalować — 26 wzorców i dwie awarie u źródła
Jak to skalować? Przeszliśmy przez wszystkie zgłoszenia, gdy tylko zaczęliśmy kopać, i znaleźliśmy 26 różnych wzorców wsparcia, z których każdy miał osobną procedurę operacyjną (SOP). I znów odzywa się ta obsesja na punkcie klienta. Zbudowaliśmy z tych zgłoszeń osobną procedurę, a potem w każdym z 26 wzorców wskazaliśmy miejsca, w których dało się użyć AI do zautomatyzowania najbardziej bolesnych części procesu.
Tak jak przy dostępie do Slacka, gdzie masz te nieliniowe, trudne, researcherskie rzeczy, które wcześniej nie nadawały się do automatyzacji AI, celowaliśmy w ten najbardziej bolesny fragment i braliśmy go na cel jak dziesiątkę na tarczy — bo w 2026 roku można tak robić. Agenci są już na tyle dobrzy, że potrafią wziąć te skomplikowane, researcherskie problemy i ułożyć kontekst tak, że człowiek może podjąć naprawdę użyteczne decyzje.
I właśnie tak wychwyciliśmy dwie awarie u źródła, które na pierwszy rzut oka wyglądały jak osobne skargi klientów. Uporządkowanie się z pomocą AI i przejrzenie wzorców pozwoliło nam znaleźć rzeczy, których inaczej byśmy nie zobaczyli. Nasz kod zaproszenia do Slacka miał na tyle dużo aktywności, że wygasał po dwóch–trzech dniach zamiast trwać miesiącami. Dobry problem do posiadania, ale jednak problem. Druga rzecz: literówka w kodzie dostępu, który opublikowaliśmy dla członków „executive circle”, psuła onboarding w sposób, którego nigdy nie zamierzaliśmy — i była tylko na jednej powierzchni, którą musieliśmy naprawić. Kiedy zaczynasz kategoryzować i rozumieć wzorce, takie skoki stają się widoczne i można je szybko wyzerować.
Przykład Gumroada — kiedy agent sięga aż do kodu
Ale wyjdźmy poza mnie. Pokażmy inny przykład. Gumroad pokazuje, jak daleko można pójść, gdy agent ma większy dostęp i więcej pola do działania. Twórca na Gumroadzie, Jordie Breuan, zgłosił, że przez jego wykres sprzedaży na telefonie w Gumroadzie przelatywały trzy wielkie kreski — po prostu katastrofa. Agent wsparcia Gumroada odtworzył błąd, prześledził go w kodzie, napisał test, otworzył pull request i poczekał, aż poprawka trafi na produkcję.
(Informacja dodatkowa: Gumroad to platforma sprzedaży produktów cyfrowych; jej założyciel to Sahil Lavingia. Pull request to propozycja zmiany w kodzie, którą włącza się do głównej wersji po zatwierdzeniu.)
Innymi słowy, Gumroad wziął ideę sukcesu klienta, o której mówiłem, i podpiął ją bezpośrednio pod bazę kodu. Agent powiedział Jordy’emu, że poprawka jest na żywo, i przyznał mu standardowy firmowy kredyt 25 dolarów za zgłoszenie błędu. Wszystko zautomatyzowane, na całej długości. To bardzo mocno reakcja w stylu 2026 roku.
I Jordy odpisał: zmiana w kodzie przesunęła znacznik na właściwe miejsce, ale to wciąż nie było naprawione tak, jak agentowi się wydawało. Wykres nadal wyglądał źle — dołączył zrzut ekranu. Nowy projekt używał zacieniowanego słupka, mimo że pozostałe słupki oznaczały liczności. Było mnóstwo konkretnych problemów UX. Naprawa techniczna zadziałała, ale decyzja produktowa, którą podjął agent, nie.
Sahil, założyciel Gumroada, podjął decyzję projektową. Agent wyprodukował kolejną wersję i tym razem zatwierdzenie Jordy’ego stało się częścią procesu. Zaakceptował, pull request został scalony, a poprawka ponownie przeszła przez proces wydawniczy. Innymi słowy, klient stał się częścią procesu zatwierdzania wydania kodu — co uważam za naprawdę ciekawy wzorzec w 2026 roku.
Co dla mnie ważne: problem klienta nie umarł w skrzynce wsparcia po tym, jak agent napisał trochę kodu. Jest tu pełna, domknięta pętla. Wiadomość doprowadziła do realnej zmiany stanu konta i produktu. Potem weszła do inżynierii. Weszła na produkcję. I wróciła do klienta po walidację. A gdy klient powiedział, że pierwszy wynik wciąż jest zły, Gumroad go wysłuchał, agent go wysłuchał, praca została wznowiona, i Gumroad miał innowacyjne podejście — faktycznie poprosił klienta o indywidualne potwierdzenie rozwiązania. Dzięki temu za drugim razem naprawdę zostało rozwiązane.
Nie każdy potrzebuje dostępu do kodu
My w biznesie medialnym nie mamy sterty kodu. Ja opowiadam tu historie. Nasz system nie miał takiego poziomu swobody, bo nie jest to konieczne. Zbierał kontekst, łączył incydenty i pomagał przygotować pracę, podczas gdy ludzie wciąż byli właścicielami wiadomości i zmian na koncie. Możemy jak najbardziej pójść tą drogą, gdy w grę wejdzie więcej kodu, ale Gumroad pokazuje, jak agent potrafi pociągnąć rutynowe przypadki i pracę produktową znacznie dalej — w firmach, gdzie kod jest rdzeniem produktu.
A podstawowa idea jest wciąż ta sama: musisz połączyć wiadomość klienta z faktami, z działaniem, z wynikami. A AI jest akceleratorem na każdym z tych etapów.
Dlaczego wsparcie to dobry pierwszy projekt
Support jest też dobrym miejscem na start, bo wyniku trudno sfałszować. Klient albo dostaje się na konto, albo otrzymuje zwrot, albo odpisuje — albo nie. Albo wciąż jest zepsuty, albo problem nie został w pełni rozwiązany, co właśnie uwielbiam w historii Gumroada. To daje ci niezależny test jakości automatyzacji AI w twoim systemie.
Ściągnij ostatnie 50 albo 100 przypadków wsparcia w jedno miejsce. A jeśli zaczynasz w małej skali — jeśli twój dodatkowy biznes ma 20 wiadomości — to też w porządku. Użyj 20. Cokolwiek to jest — maile, posty w społeczności, zgłoszenia z formularza kontaktowego, wiadomości bezpośrednie — jakkolwiek dociera do ciebie ból klienta, spisz to i włóż do systemu, którego już używasz, bo chcesz zagregować ten ból w jednym miejscu.
Higiena danych i zadanie dla agenta
A kiedy już to zrobisz, umieść to gdzieś zatwierdzonego dla takich informacji. Bądźmy tu szanujący dla bezpieczeństwa informacji — usuń hasła, dane płatnicze, dane osobowe. Miałem o tym cały materiał w niedzielę, o „airlocku” i o tym, jak zadbać o usuwanie danych osobowych (PII). Moglibyśmy jak najbardziej użyć airlocka do tego.
(Informacja dodatkowa: PII to dane osobowe umożliwiające identyfikację. „Airlock” to omawiany przez autora wzorzec śluzy oczyszczającej dane z informacji wrażliwych, zanim trafią do agenta AI.)
A potem daj agentowi to zadanie. Powiedz mu: zrób wiersz dla każdego pojedynczego przypadku w arkuszu. Powiedz mi, czego doświadczył klient. Powiedz mi w formie przyczyny źródłowej, co faktycznie zawiodło. Powiedz, co zespół sprawdził. Powiedz, co ludzie naprawdę zrobili, żeby to rozwiązać. Powiedz, czy klient wrócił. A potem pogrupuj przypadki według ich przyczyny źródłowej, nie według tematu wiadomości.
Na przykład u nas: „moje zaproszenie na Slacka nigdy nie dotarło”, „link wygasł” i „zapłaciłem innym adresem e-mail” brzmią przy pobieżnej analizie jak trzy różne wiadomości — ale u nas wskazywały na te same zepsute drzwi, którymi musieliśmy się zająć.
Sam przeczytaj największą grupę
Potem przeczytaj największą grupę samodzielnie. Agenci są bardzo dobrzy w tym, żeby bałagan wyglądał na uporządkowany — również wtedy, gdy porządek jest błędny. Poświęć więc czas, żeby oswoić się z doświadczeniem klienta „na wyczucie”. Otwórz oryginalne przypadki, sprawdź, czy grupowanie zrobione przez AI faktycznie się broni, czy trzeba je skorygować.
A potem wybierz swój problem. Wybierz bolesny. Wybierz nudny. Wybierz powtarzalny. Nie radziłbym zaczynać od oszustw, spraw prawnych, incydentów bezpieczeństwa, zawieszeń kont, dużych zwrotów ani od najbardziej wściekłego klienta, jakiego masz. Wybierz coś, gdzie właściwe fakty leżą w systemach, które kontrolujesz, gdzie normalny następny krok jest już zrozumiały i gdzie błąd da się wychwycić i cofnąć. Chcesz być w takiej sytuacji przy pierwszej automatyzacji, bo chcesz grać pieniędzmi kasyna — być w pozycji, w której twoja automatyzacja ma duże szanse powodzenia.
Wypełnij notatkę problemu i zapytaj agenta o wątpliwości
Teraz wypełnij notatkę dla swojego problemu. Zapisz, jak rozumiesz to, co zawiodło, któremu zapisowi ufasz, jakie małe działanie zwykle to naprawia, kiedy w tej chwili muszą wkroczyć ludzie i co dowodzi, że praca faktycznie została wykonana — skąd wiesz, że klient jest zadowolony.
Na przykład w naszej sytuacji ze Slackiem „utworzono zaproszenie” to za mało. Musieliśmy wiedzieć, że płatność jest przypisana do osoby, że zaproszenie jest przypisane do adresu e-mail, że klient może wejść do przestrzeni roboczej, a potem że może to potwierdzić, wysyłając wiadomość. Musieliśmy mieć cały łańcuch wartości od końca do końca. Poproś agenta, żeby pokazał, który rekord klienta znalazł, co jest prawdą w tej chwili, skąd wziął się każdy fakt, które wcześniejsze przypadki wyglądały podobnie, co nadal rekomenduje — i naprawdę zapytaj go, co do czego nie ma pewności. Ludzie robią to za rzadko. A jeśli zapytasz agenta, czego nie jest pewien, wydobędziesz mnóstwo myślenia i założeń, które możesz skorygować.
Kiedy systemy się nie zgadzają
A gdy systemy się nie zgadzają — a przy wielu paskudnych bólach klienta, którymi zajmujemy się z AI w 2026 roku, masz do czynienia z niezgadzającymi się systemami — agent powinien pokazać ci tę rozbieżność i podnieść ją jako problem. Nie powinien po cichu wybierać odpowiedzi, która najłatwiej pozwala zamknąć zgłoszenie. To klasyczny tryb awarii.
Uruchom rozwiązanie. Na tym etapie będziesz miał proponowane przez AI rozwiązanie. Uruchom je w trybie roboczym. Pozwól, żeby człowiek przejrzał pierwsze 20 czy 30 przypadków, które agent zaproponuje, i zapisz, dlaczego każdy szkic został zmieniony albo nie. Możesz, nawiasem mówiąc, przegadać i nagrać ekranem swój sposób rozwiązywania tego problemu, dać to AI, a ono po prostu to teraz przetworzy. Jest już tak dobre. I zadziała to z Claude’em, zadziała z Codeksem.
Ten przegląd staje się twoją procedurą operacyjną. Zbuduj ją z prawdziwych zgłoszeń i prawdziwych korekt, zamiast spędzać miesiąc na zgadywaniu, na co agent może albo nie może natrafić. Dopiero gdy agent potrafi znaleźć właściwą osobę i właściwe fakty oraz podjąć działanie w sposób przewidywalny, jesteś gotów powiedzieć: „Dobra, możemy to zrobić agentem AI i mieć pewność, że jest poprawnie”. Potrzebujesz tego okresu docierania.
Prowadź kartę wyników
Co robisz, gdy AI już zautomatyzowało? To bardzo proste. Prowadź kartę wyników. Ile spraw wpłynęło? Ile rozwiązano? Ile pochodziło z każdej przyczyny? Ile szkiców ludzie skorygowali albo klienci ponownie otworzyli? Ile agent w pełni zautomatyzował? I ile czasu wciąż spędzasz ręcznie? W skrócie — zmierz, a potem policz jeszcze raz w następnym tygodniu.
Twoim celem jest móc opowiedzieć historię taką, jaką opowiadam teraz na YouTubie. Chcesz móc powiedzieć: „Zeszliśmy z 52 do 19. Zbiliśmy nasz największy pojedynczy problem sukcesu klienta z pomocą AI, ponieważ…” — i wtedy możesz wymienić wszystko, co po drodze zrobiłeś.
Reszta jest trudniejsza — i to normalne
Jedna rzecz, której należy się spodziewać: gdy łatwe, powtarzalne przypadki się kurczą, praca, która zostaje dla reszty, staje się trudniejsza. Nam też się to przydarzyło. Pozostałe przypadki częściej dotyczą niezgadzających się systemów, polityki, która nie była tak jasna, jak powinna, albo problemu produktowego, który wymaga osądu i udziału ludzi. Dlatego nie schodzisz z 52 do zera w tydzień. Schodzisz z 52 do 19, a potem zaczynasz rozgryzać niektóre z tych trudniejszych przypadków. I to ustawia cię do zajęcia się rzeczami, które na razie potrafią tylko ludzie, albo które ludzie muszą lepiej przygotować, zanim postawisz je przed agentami AI.
Kiedy raz zobaczysz ten wzorzec, zaczniesz go dostrzegać wszędzie. Ten powtarzalny wzorzec bólu widać w prośbach o dostęp do oprogramowania, w handlowcach odbudowujących historię konta, w nowych klientach proszących wciąż o ten sam dokument, w grupie klientów opisujących jeden błąd produktu na wiele różnych sposobów. Dlatego uważam, że obsługa klienta to tak dobry pierwszy projekt agentowy — bo ludzie już mówią ci, co zawiodło, własnymi słowami. Surowy materiał leży w twojej skrzynce, w twoich wiadomościach, gdziekolwiek jest. Wszystko, co musisz zrobić, to słuchać.
Jeśli chcesz pełny przewodnik, jak to zrobiłem, pełny zestaw promptów i narzędzi, których użyłem, żeby zautomatyzować sukces klienta dla siebie i mojej firmy, i jak zszedłem z 52 do 19 — wszystko jest na Substacku. Zgarnij to, a widzimy się za tydzień.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zmień pytanie z „jak odpowiedzieć szybciej” na „jak sprawić, by nie musieli pytać”
Na czym polega: Podejście z 2026 roku patrzy nie na koniec zgłoszenia, lecz na cały proces i jego przyczynę źródłową. Zamiast usprawniać odpowiedź, likwidujesz powód, dla którego klient w ogóle się zgłasza.
Jak stosować: Przy każdej kategorii powtarzalnych zgłoszeń zapytaj, jaka zmiana w produkcie lub procesie sprawi, że ta kategoria po prostu zniknie. U autora były to samoobsługowe domeny i niewygasające zaproszenie — kategoria spadła z pierwszego miejsca do zera.
Na co uważać: Automatyzacja szybkiej odpowiedzi na zły proces tylko przyspiesza dostarczanie kiepskiego rozwiązania. Najpierw usuwaj przyczynę, dopiero potem automatyzuj to, co zostaje.
2.Zmapuj i zmierz proces taki, jaki jest naprawdę
Na czym polega: Największy koszt to nie pisanie odpowiedzi, lecz nieliniowe zbieranie kontekstu z wielu narzędzi. Widać to dopiero po spisaniu każdego kroku „jak jest”, nie „jak być powinno”, i zmierzeniu czasu.
Jak stosować: Zrób klasyczne badanie czasu: przejdź przez proces, zapisz każdy krok, ile trwa, które fragmenty wymagają osądu, a które da się zautomatyzować. Ten zapis podajesz potem AI jako kontekst.
Na co uważać: Nie opieraj się na wyobrażeniu procesu ani na oficjalnej procedurze — realny przebieg bywa dużo dłuższy i bardziej rozgałęziony, niż się wydaje.
3.Ból zamieniaj w bilety z dołączonym researchem
Na czym polega: Każdy pojedynczy problem dostaje własne zgłoszenie-rusztowanie, na którym AI zawiesza wcześniej ustalone fakty (płatność, konto, wcześniejsze rozmowy). Człowiek otwiera bilet i już tylko „wykonuje”.
Jak stosować: Zleć agentowi automatyczne zebranie powtarzalnego researchu i podpięcie go do zgłoszenia. U autora skróciło to 5–10 minut nieukierunkowanego szukania do niecałej minuty i zdjęło ok. 90% obciążenia umysłowego.
Na co uważać: To działa dla powtarzalnego, przewidywalnego researchu. Nietypowe przypadki nadal wymagają, by człowiek sam pozbierał kontekst.
4.Zostaw człowieka przy decyzjach o dostępie i pieniądzach
Na czym polega: Autor świadomie nie zautomatyzował w pełni — każda decyzja dotycząca dostępu lub płatności przechodzi przez ludzką akceptację, by jakość obsługi nie ucierpiała.
Jak stosować: Wyznacz wyraźną granicę: automatyzuj gromadzenie kontekstu i przygotowanie rozwiązania, ale zostaw człowiekowi ostateczne kliknięcie tam, gdzie błąd jest kosztowny lub trudny do cofnięcia.
Na co uważać: Przesadne zawierzenie agentowi w sprawach dostępu/pieniędzy prowadzi do doświadczeń typu „bot, przez którego chce się wyrzucić komputer przez okno”. Automatyzacja ma zdejmować ciężar, nie zastępować osądu.
5.Grupuj zgłoszenia według przyczyny źródłowej, nie tematu
Na czym polega: Trzy różnie brzmiące wiadomości („zaproszenie nie dotarło”, „link wygasł”, „zapłaciłem innym mailem”) wskazywały na jedne zepsute drzwi. Grupowanie po temacie by tego nie pokazało.
Jak stosować: Poproś agenta, by dla każdego przypadku wypisał: czego doświadczył klient, co zawiodło (w formie przyczyny źródłowej), co sprawdzono, co zrobiono, czy klient wrócił — i pogrupował według przyczyny.
Na co uważać: Agenci potrafią sprawić, że bałagan wygląda na uporządkowany, także gdy porządek jest błędny. Sam przeczytaj największą grupę i sprawdź, czy grupowanie się broni.
6.Zacznij od bezpiecznego problemu — „graj pieniędzmi kasyna”
Na czym polega: Pierwsza automatyzacja powinna dotyczyć problemu, gdzie fakty są w systemach, które kontrolujesz, następny krok jest znany, a błąd da się wychwycić i cofnąć.
Jak stosować: Wybierz problem bolesny, nudny i powtarzalny. Świadomie odłóż na później oszustwa, sprawy prawne, incydenty bezpieczeństwa, zawieszenia kont, duże zwroty i najbardziej wściekłych klientów.
Na co uważać: Rozpoczęcie od przypadków wysokiego ryzyka przy niedojrzałym procesie może wyrządzić realną szkodę klientowi i podkopać zaufanie do całej inicjatywy.
7.Każ agentowi ujawniać niepewność i rozbieżności między systemami
Na czym polega: Wiele trudnych przypadków to niezgadzające się ze sobą systemy. Agent powinien pokazać rozbieżność jako problem, a nie po cichu wybrać odpowiedź, którą najłatwiej zamknąć zgłoszenie.
Jak stosować: W promptcie żądaj: który rekord znalazłeś, co jest prawdą teraz, skąd każdy fakt, co rekomendujesz i — wprost — czego nie jesteś pewien. Pytanie o niepewność wydobywa założenia, które możesz skorygować.
Na co uważać: „Ciche” domykanie zgłoszeń to klasyczny tryb awarii. Jeśli nie wymusisz ujawniania rozbieżności, dostaniesz gładkie, ale błędne rozwiązania.
8.Buduj procedurę na trybie roboczym i realnych korektach
Na czym polega: Zamiast miesiąc zgadywać, na co agent trafi, uruchamiasz rozwiązanie w trybie draft, człowiek przegląda pierwsze 20–30 przypadków i zapisuje, dlaczego każdy szkic zmienił lub nie. Z tego powstaje SOP.
Jak stosować: Możesz nawet nagrać ekran i głos, jak sam rozwiązujesz sprawę, i podać to AI do przetworzenia (działa z Claude’em i z Codeksem). Automatyzację włączasz dopiero po okresie docierania, gdy agent działa przewidywalnie.
Na co uważać: Pomijanie okresu „bake-in” i włączanie pełnej automatyzacji zbyt wcześnie to proszenie się o błędy na produkcji, zanim zaufasz, że agent jest poprawny.
9.Prowadź kartę wyników i licz ponownie co tydzień
Na czym polega: Miernikiem sukcesu jest twarda, tydzień-do-tygodnia zmiana liczb: ile spraw wpłynęło, ile rozwiązano, z jakich przyczyn, ile szkiców skorygowano, ile klient otworzył ponownie, ile czasu wciąż idzie ręcznie.
Jak stosować: Support jest dobry na start, bo wyniku trudno sfałszować — klient albo wchodzi na konto/dostaje zwrot, albo nie. To daje niezależny test jakości twojej automatyzacji (jak w historii Gumroada, gdzie klient sam potwierdzał poprawkę).
Na co uważać: Spodziewaj się, że nie zejdziesz z 52 do zera w tydzień. Gdy łatwe przypadki znikną, reszta jest trudniejsza (sprzeczne systemy, niejasna polityka, decyzje produktowe) i wymaga ludzi.
10.Rozpoznaj ten sam wzorzec poza obsługą klienta
Na czym polega: Ten sam powtarzalny ból widać w prośbach o dostęp do oprogramowania, w handlowcach odbudowujących historię konta, w nowych klientach proszących o ten sam dokument czy w wielu opisach jednego błędu produktu.
Jak stosować: Zbuduj pierwszą pętlę w supporcie (bo klienci sami mówią, co zawiodło, własnymi słowami), a potem przenieś ten sam schemat na sprzedaż, finanse, IT i produkt. Gumroad pokazuje, jak daleko to sięga, gdy agent ma dostęp do kodu — aż po pull request i domkniętą pętlę z walidacją klienta.
Na co uważać: Poziom swobody agenta dobierz do ryzyka danego obszaru. Dostęp do kodu i wydań (jak w Gumroadzie) daje ogromny zasięg, ale wymaga realnych bramek zatwierdzania — u autora w biznesie medialnym taki poziom nie był potrzebny.