Kiedy Agent AI Ma Sens, A Kiedy Jest Drogim Błędem? | AI Optimization

Za chwilę pokażę Ci dokładnie, jak Agent AI działa u jednego z naszych klientów w LaboPrint i dlaczego to wdrożenie zadziałało, choć wcale nie zaczynało się od AI. Najpierw fakty. To nie była magia AI. To był agent osadzony w czystym, zdefiniowanym procesie. Zendesk, Naten, Rejestr.io lub Company API, OpenAI, Airtable, I znowu, Pipedrive lub Zendesk. I właśnie dlatego to miało sens. Krok pierwszy, trigger. Do firmy wpada mail, na przykład z zapytaniem ofertowym od nowego klienta. Na tej podstawie automatycznie zakładany jest ticket w Zendesku, czyli narzędziu, którego firma używa do obsługi takich ticketów, takich zgłoszeń. Jeśli klienta nie ma w bazie, no to cały workflow nam startuje. System automatycznie tworzy taki rekord w Airtable, który służy nam tutaj za bazę danych.

Są tam takie informacje jak imię, nazwisko, mail, NIP, adres domeny firmowej. Jest to kluczowe, żeby agent najpierw zrozumiał z kim ma do czynienia, a dopiero potem zdecydował co ma z nim zrobić. Krok drugi to weryfikacja podmiotu. Czyli zanim agent cokolwiek mądrze zdecyduje, musi ustalić z kim w ogóle rozmawia. Dlatego wchodzi warstwa weryfikacji podmiotu. Źródła danych, z których pobieraliśmy informacje, no to w przypadku polskich firm było rejestr I.O., czyli stabilne, tanie rozwiązanie kosztujące 50 złotych za około 1000 zapytań. Jeśli natomiast klient pochodził z zagranicy, to wykorzystywaliśmy kompany API, oferujące płatność w modelu Pay As You Go. Czyli w zależności od tego, ile danych będziemy pobierać. Nasze minimum to zawsze ostatni znany przychód roczny i dane rejestrowe firmy.

W Zendesk z kolei agent nadaje odpowiedni tag do tego zgłoszenia, które wpłynęło. Czyli na przykład, że nowy strategiczny klient albo nowy klient, ale nie zweryfikowany i tak dalej. W Airtable ląduje natomiast pełny dziennik zdarzeń, czyli czas, z którego API przyszły te dane, po jakim kursie były przeliczone waluty, jeśli były przeliczane, jaka była podjęta decyzja co do tego klienta i do kogo przypisano sprawę, czy ticket, czy jakkolwiek to określimy. I do tego dochodzi warstwa optymalizacji kosztów. Agent korzysta z listy wcześniej sprawdzonych firm, żeby nie dublować zapytań. Co jest szczególnie ważne przy company API, gdzie każdy request, każde zapytanie do tej bazy nas kosztuje. Ale jest jeszcze jeden ważny element. Nawet najlepiej zaprojektowany agent musi wiedzieć, kiedy oddać pałeczkę człowiekowi.

Tylko szybciej, konsekwentniej i bez momentów nie mam czasu. We wdrożeniu w Laboprint agent nie działał magicznie, po prostu łączył dane z interpretacją, czyli robił coś, czego klasyczna automatyzacja nie potrafi. Pobierał dane z rejestr.io i company API, porównywał przychody z progami, przeliczał waluty, żeby wszystko było porównywalne i dopiero wtedy dzięki OpenAI oceniał, jaką wartość ma ten klient. W praktyce wyglądało to tak. Jeżeli trafiła do drukarni duża firma z Niemiec, agent podnosił priorytet i uruchamiał dedykowanego handlowca. Jeśli wpadał mikropodmiot z dziwną domeną XYZ i bez danych w rejestrach, dostawał tag Unverified. To właśnie różnica między automatyzacją a agentem.

Jeśli tego nie ma, agent nie ma po czym się poruszać. To jak wysłać autonomiczne auto, ale na drogę bez znaków. W praktyce rozrysuj ten proces, albo go przynajmniej rozpisz. Zastanów się, co się po kolei dzieje, jakie decyzje są konieczne do podjęcia, w jakich systemach ten agent będzie się poruszać, jakie są metryki, którymi chcesz zmierzyć skuteczność tego procesu. I dopiero wtedy idź dalej. Krok drugi. Zautomatyzuj to, co oczywiste. Jeśli jakiś fragment procesu da się opisać regułą, jeśli A to B, zrób to bez AI. Dlaczego? Bo automatyzacja to fundament, na którym agent dopiero później może stanąć. W Laboprint, zanim agent dostał dostęp do OpenAI, działało już pobieranie danych z rejestr.io i kompany API, przeliczanie walut, zapisywanie tych informacji w Airtable.