Zanim zespół rozpocznie kolejny dzień pracy, w systemie czeka już odpowiedź na najważniejsze pytania. Ile rozmów rzeczywiście się odbyło? Do ilu klientów trzeba oddzwonić? Które leady nie zrobiły kolejnego kroku? Jak wygląda pipeline? Co zostało sprzedane i z jakiego źródła przyszła transakcja?
Jeszcze niedawno każda z tych odpowiedzi wymagała osobnej pracy. Trzeba było otworzyć CRM, ustawić zakres dat, zbudować filtr, sprawdzić powiązania, porównać kilka ekranów, a czasem dodatkowo sięgnąć do danych o połączeniach. Samo posiadanie CRM nie rozwiązywało problemu. Informacje znajdowały się w systemie, ale ktoś nadal musiał umieć je wydobyć i właściwie zinterpretować.
Zbudowałem więc agenta AI działającego nad naszym wewnętrznym systemem CRM. Nie jest to kolejny kolorowy dashboard ani chatbot odpowiadający ogólnikami. Ten agent AI w CRM korzysta z lokalnej platformy OpenClaw, przygotowanych narzędzi, wiedzy o strukturze systemu i reguł naszego procesu sprzedażowego.
Dziś agent AI w CRM analizuje około 150 połączeń dziennie, obejmuje blisko 280 szans znajdujących się w 30-dniowym obrazie pipeline’u, przygotowuje raporty sprzedaży i aktywności oraz może oceniać jakość rozmów według wspólnych kryteriów. Łączy dane, które wcześniej trzeba było składać ręcznie: leady, klientów, szanse sprzedaży, notatki, historię obsługi i połączenia.
Najważniejsze jest jednak to, że agent AI w CRM nie zastępuje ludzi w rozmowie z klientem i nie podejmuje za nich decyzji. Wykonuje pracę, która wcześniej zużywała ich uwagę: zbiera fakty, kontroluje kompletność, porównuje okresy i pokazuje, gdzie potrzebna jest reakcja.
To artykuł o systemie, który zbudowałem i rozwijam w codziennej pracy. Pokażę nie tylko efekt widoczny w raporcie, ale również sposób myślenia stojący za rozwiązaniem: co liczy kod, gdzie wykorzystywany jest model językowy, jak ograniczam ryzyko błędnych wniosków i dlaczego największym problemem w automatyzacji CRM nie jest AI, tylko jakość definicji i danych.
CRM bardzo łatwo pomylić z uporządkowanym systemem wiedzy. W rzeczywistości jest przede wszystkim miejscem zapisu zdarzeń. Jeden użytkownik dodaje notatkę, drugi zmienia status, kolejny prowadzi rozmowę, a po pewnym czasie z leada powstaje szansa sprzedaży i powiązana firma.
Każdy z tych elementów może być poprawny osobno, ale pytania zarządcze zwykle przebiegają w poprzek struktury systemu:
Odpowiedź często wymaga połączenia kilku encji, zrozumienia historii rekordu i zastosowania stałych definicji. To dlatego dwa raporty wykonane przez dwie osoby potrafią różnić się mimo korzystania z tego samego CRM. Jedna osoba liczy próby połączeń, druga unikalnych klientów. Jedna patrzy na datę utworzenia szansy, druga na datę jej zamknięcia. Obie mogą uważać, że raportują „sprzedaż z miesiąca”.
Pierwszym krokiem nie było więc podłączenie modelu językowego. Najpierw musiałem opisać, co poszczególne liczby naprawdę znaczą i z których pól mają wynikać. Automatyzacja utrwala definicje — dlatego błędna definicja będzie generowała błędny raport szybciej i regularniej niż człowiek.
Pracuję z naszym CRM od strony użytkownika, administratora, integracji API i struktury danych. Wiem, jak proces wygląda na ekranie handlowca, ale również jak rekordy są ze sobą powiązane i gdzie pojawiają się rozbieżności pomiędzy tym, co formalnie zapisano, a tym, co naprawdę wydarzyło się w obsłudze klienta.
Ta znajomość procesu jest ważniejsza niż wybór modelu AI. Ogólny agent zobaczy pole status i spróbuje je zinterpretować. Agent zbudowany dla konkretnej organizacji wie, które statusy są techniczne, kiedy brak kontaktu ma znaczenie, które notatki należy pominąć i po czym rozpoznać, że szansa sprzedaży nie zrobiła realnego postępu.
Moja praca polegała na przełożeniu tej wiedzy na trzy warstwy:
W efekcie zespół nie musi znać nazw endpointów, relacji ani pól. Może zapytać zwykłym językiem: „Pokaż, co wydarzyło się wczoraj”, „Które leady wymagają kontaktu?” albo „Podsumuj sytuację tego klienta przed rozmową”. Agent dobiera właściwe narzędzia, zbiera dane i przedstawia odpowiedź w ustalonym formacie.
Rozwiązanie składa się z kilku współpracujących elementów:
| Element | Rola w systemie |
|---|---|
| System CRM | Źródło leadów, firm, szans, notatek, statusów i historii obsługi |
| Dane o połączeniach | Informacja o próbach kontaktu, odebranych i nieodebranych rozmowach |
| Narzędzia raportowe | Pobieranie, normalizacja, łączenie i deterministyczne obliczenia |
| OpenClaw | Orkiestracja zadań, wybór procedur i dostarczanie wyników |
| Lokalny LLM | Interpretacja kontekstu i przygotowanie czytelnych podsumowań |
| Człowiek | Definicje biznesowe, decyzje, zatwierdzanie zmian i ocena wyjątków |
Przepływ jest prosty na poziomie użytkownika, ale kontrolowany wewnątrz:
Nie powierzam modelowi swobodnego generowania zapytań modyfikujących dane. LLM nie powinien sam wybierać tabel, wykonywać przypadkowego UPDATE ani decydować o uprawnieniach. Jego zadaniem jest rozumienie polecenia i praca na możliwościach udostępnionych przez kontrolowane narzędzia. Platformę OpenClaw, na której działa agent, opisuję szerzej w osobnym wpisie: OpenClaw — asystent AI do automatyzacji pracy.
To jedno z najważniejszych rozróżnień w całym wdrożeniu.
Jeżeli raport mówi, że wykonano 147 prób połączeń, liczba nie powinna być wynikiem „rozumowania” modelu językowego. Powinna pochodzić z jednoznacznego przetworzenia rekordów. To samo dotyczy sum sprzedaży, prowizji, udziałów procentowych, liczby leadów i konwersji.
Kod odpowiada za:
Model językowy odpowiada za:
Takie rozdzielenie ogranicza halucynacje. Model może pomylić interpretację, ale nie powinien mieć możliwości zmiany podstawowej wartości raportu. Jeżeli brakuje danych, ma to powiedzieć, a nie tworzyć prawdopodobne wyjaśnienie.
Najbardziej widocznym zastosowaniem jest raport połączeń. Zespół prowadzi około 150 rozmów i prób kontaktu dziennie. Wcześniej odpowiedź na proste pytanie „jak wyglądał wczorajszy dzień?” wymagała przejrzenia logów i zestawienia ich z CRM.
Dzisiaj agent przygotowuje raport automatycznie. Pokazuje między innymi:
| Element | Co naprawdę oznacza |
|---|---|
| Próby kontaktu | Wszystkie połączenia objęte przyjętą definicją raportu |
| Połączenia odebrane | Rozmowy, w których doszło do połączenia |
| Połączenia nieodebrane | Próby wymagające sprawdzenia dalszego losu |
| Unikalne kontakty | Liczba klientów, a nie liczba wszystkich prób |
| Rozbicie na osoby | Aktywność przypisana do użytkowników CRM |
| Odbieralność | Relacja skutecznych kontaktów do prób według stałej definicji |
| Sprawy wymagające uwagi | Kontakty bez późniejszego oddzwonienia, notatki lub dalszego kroku |
Największa wartość nie znajduje się w liczbie nieodebranych połączeń. Sama taka liczba niewiele mówi. Agent może sprawdzić, czy później nastąpiło oddzwonienie, pojawiła się notatka albo klient przeszedł do kolejnego etapu. Dzięki temu raport nie tworzy sztucznej listy problemów, które zostały już rozwiązane.
Powtarzalny format pozwala porównywać dni i osoby. Definicje nie zmieniają się w zależności od autora zestawienia. Jeżeli zmieniamy sposób liczenia, jest to świadoma zmiana procedury, a nie różnica wynikająca z innego filtra ustawionego przez pracownika.
Dobry raport nie powinien kończyć się tabelą. Powinien ułatwiać decyzję.
Agent zestawia brak skutecznego kontaktu z historią klienta. Szuka późniejszych aktywności, statusu leada, powiązanych szans i notatek. Dopiero wtedy może przygotować listę spraw, przy których rzeczywiście brakuje następnego kroku.
Schemat wygląda następująco:
próba kontaktu → wynik połączenia → późniejsza aktywność → status CRM → rekomendacja dla człowieka
Rekomendacja nie oznacza automatycznej decyzji. Agent może wskazać, że klient wymaga oddzwonienia albo że rekord nie ma aktualnej notatki. To handlowiec ocenia priorytet i sposób kontaktu. Automatyzacja usuwa poszukiwanie informacji, ale nie przejmuje odpowiedzialności za rozmowę.
Liczba nowych leadów jest jednym z najmniej użytecznych wskaźników, jeżeli nie potrafimy odpowiedzieć, co wydarzyło się później.
Agent analizuje:
Pozwala to odróżnić źródło generujące dużą liczbę zgłoszeń od źródła dostarczającego realne szanse. Możemy również zobaczyć, czy problem występuje na wejściu, podczas pierwszego kontaktu czy dopiero na późniejszym etapie procesu.
Najciekawsze są rekordy formalnie aktywne, ale pozbawione realnego postępu. Sam status nie wystarcza. Agent sprawdza, czy pojawiła się nowa notatka, rozmowa, zmiana etapu albo inny ślad pracy. Dzięki temu pipeline przestaje być tylko sumą wartości przypisanych do statusów.
W 30-dniowym obrazie analizujemy około 280 szans sprzedaży. Przy takiej liczbie ręczne przeglądanie każdej pozycji jest nieefektywne, a sam dashboard nie pokazuje pełnego kontekstu.
Agent porządkuje szanse według:
Nie chodzi o to, aby model „przewidział przyszłość” na podstawie kilku pól. Celem jest wykrycie warunków, które menedżer i tak sprawdzałby ręcznie: szansa ma dużą wartość, ale nie ma świeżej aktywności; termin kolejnego kroku minął; brakuje wymaganej informacji; klient pozostaje aktywny, lecz proces nie przesuwa się dalej.
Taki raport nie zastępuje przeglądu pipeline’u. Sprawia, że przegląd zaczyna się od spraw najważniejszych zamiast od pierwszego rekordu na liście.
Raport sprzedaży powinien odpowiadać na więcej pytań niż „jaka jest suma zamkniętych szans?”.
Agent łączy:
Dzięki temu można odtworzyć drogę od pierwszego kontaktu do sprzedaży. Nie zawsze jest ona liniowa. Klient mógł pojawić się wcześniej, wrócić po kilku miesiącach, odpowiedzieć na kolejną kampanię albo zostać ponownie obsłużony przez inną osobę. Agent pomaga zebrać tę historię, ale fakty finansowe nadal pochodzą z danych i obliczeń, nie z interpretacji LLM-a.
To ma znaczenie również przy ocenie marketingu. Kanał generujący najwięcej leadów nie musi generować największej wartości sprzedaży. Dopiero połączenie źródła, historii kontaktu i wyniku finansowego pozwala ocenić rzeczywistą skuteczność.
Raport liczbowy mówi, że rozmowa się odbyła. Nie mówi, czy klient został dobrze obsłużony.
Agent może analizować treść rozmowy oraz historię powiązanego rekordu według zdefiniowanej karty oceny. Celem nie jest przyznanie przypadkowej noty, lecz sprawdzenie tych samych elementów w większej liczbie rozmów.
Przykładowe kryteria:
| Kryterium | Co jest sprawdzane |
|---|---|
| Rozpoznanie potrzeby | Czy doradca ustalił rzeczywisty cel klienta |
| Kompletność wywiadu | Czy padły pytania potrzebne w danym procesie |
| Jasność informacji | Czy komunikacja była zrozumiała i uporządkowana |
| Reakcja na zastrzeżenia | Czy obawy klienta zostały zauważone i omówione |
| Następny krok | Czy rozmowa zakończyła się konkretnym ustaleniem |
| Zgodność z procesem | Czy wykonano wymagane elementy obsługi |
| Jakość wpisu w CRM | Czy notatka odpowiada temu, co wydarzyło się w rozmowie |
Ocena AI nie może być traktowana jako niepodważalny wyrok. Model może źle odczytać ironię, skrót myślowy albo kontekst branżowy. Dlatego wynik powinien zawierać uzasadnienie i wskazanie podstawy oceny. Menedżer musi móc wrócić do rozmowy i sprawdzić, czy wniosek jest prawidłowy.
Największą wartością jest wykrywanie powtarzalnych wzorców. Jeżeli w wielu rozmowach brakuje ustalenia następnego kroku albo regularnie pomijane jest jedno pytanie, mamy materiał do poprawy procesu i szkolenia zespołu. Nie chodzi o łapanie pojedynczych osób na błędach, lecz o dostrzeżenie problemów, których nie widać po odsłuchaniu kilku przypadkowych nagrań.
Agent przygotowuje również obraz aktywności: połączenia, kontakty, notatki, zmiany statusów i pracę na szansach. Taki raport bardzo łatwo wykorzystać niewłaściwie, sprowadzając ocenę pracownika do liczby wykonanych czynności.
Dlatego traktuję go jako opis obciążenia i przepływu pracy, nie samodzielny ranking ludzi.
Duża liczba połączeń może oznaczać wysoką aktywność, ale może również wynikać z niskiej odbieralności. Mniejsza liczba rozmów może oznaczać brak pracy albo prowadzenie kilku złożonych spraw. Dopiero zestawienie aktywności z wynikiem, typem klientów i etapami procesu daje użyteczny kontekst.
Raport pomaga zauważyć:
Decyzja nadal należy do menedżera, który zna ludzi i sytuację. Agent ma dostarczyć pełniejszy obraz, a nie automatycznie oceniać pracowników.
CRM nie jest u mnie odizolowaną bazą. Jest częścią większego przepływu obejmującego telefonię, system newsletterowy i infrastrukturę wiadomości masowych.
Przed przygotowaniem listy agent może:
Techniczna możliwość wyeksportowania kontaktu nie oznacza prawa do prowadzenia komunikacji. Agent stosuje zapisane reguły, ale nie tworzy zgody ani podstawy prawnej. Organizacja nadal odpowiada za źródło danych, zakres kontaktu, obsługę sprzeciwów i zgodność całego procesu.
Połączenie CRM z kampaniami daje również możliwość zamknięcia pętli: źródło → kontakt → szansa → sprzedaż. Wtedy marketing nie kończy się na wysłanej wiadomości, a raport sprzedaży nie zaczyna się dopiero przy zamkniętej transakcji.
Najlepszy model językowy nie naprawi automatycznie niejednoznacznych danych. Jeżeli ten sam numer występuje przy kilku kontaktach, rekord nie ma właściciela albo status jest używany w różny sposób przez różne osoby, agent musi rozpoznać niepewność.
Kontroluję między innymi:
Nie każdą niespójność należy automatycznie poprawiać. Połączenie dwóch podobnych kontaktów może usunąć ważny kontekst, a zmiana właściciela szansy może uruchomić kolejne procesy. Dlatego agent może wskazać problem i przygotować propozycję, ale operacja zmieniająca historię CRM wymaga osobnej procedury oraz zatwierdzenia.
Największym zagrożeniem nie jest jawny błąd. Jest nim raport brzmiący przekonująco mimo niepełnych danych.
Stosuję kilka zasad:
Jeżeli agent nie potrafi jednoznacznie przypisać połączenia do właściwego klienta, powinien to zgłosić. Jeżeli API nie zwróciło kompletnego zakresu, raport nie powinien udawać pełnego. Jeżeli brak aktywności może mieć kilka przyczyn, model może je wymienić, ale nie powinien wybierać jednej jako faktu.
To właśnie odróżnia produkcyjne wykorzystanie AI od efektownej demonstracji. Dobra odpowiedź nie zawsze jest najbardziej zdecydowana. Czasem najlepszym wynikiem jest precyzyjne: „Nie mam wystarczających danych, aby to stwierdzić”.
Agent działa w naszej lokalnej infrastrukturze i korzysta z lokalnego modelu językowego. Ogranicza to potrzebę przekazywania pełnego kontekstu operacyjnego do zewnętrznej usługi, ale samo w sobie nie rozwiązuje wszystkich problemów bezpieczeństwa.
Potrzebne są również:
Model nie powinien sam decydować, do których danych użytkownik ma dostęp. Uprawnienia muszą być egzekwowane przez system i narzędzia. Prompt może opisywać zasady, ale nie może być jedynym zabezpieczeniem.
System działa w trzech trybach.
Raporty powstają według harmonogramu. Zespół nie musi pamiętać o ich uruchomieniu, a format i zakres pozostają stałe.
Użytkownik może zadać konkretne pytanie: „Podsumuj tego klienta przed rozmową”, „Pokaż szanse bez aktywności” albo „Porównaj źródła leadów”. Agent wybiera odpowiednią procedurę i przedstawia wynik.
Gdy raport wygląda nietypowo, agent może sprawdzić zakres danych, liczbę pobranych rekordów, brakujące relacje i inne przyczyny rozbieżności. Nie naprawia automatycznie wszystkiego, co znajdzie. Najpierw pokazuje problem i jego możliwy wpływ.
Domyślna praca ma charakter odczytowy. To bardzo istotne: szeroki dostęp do analizy nie oznacza szerokiego prawa do zmieniania CRM.
| Wskaźnik | Obecna skala |
|---|---|
| Połączenia analizowane dziennie | około 150 |
| Szanse widoczne w 30-dniowym pipeline | około 280 |
| Zamknięte sprzedaże w okresie 30 dni | kilkadziesiąt |
| Raporty cykliczne | generowane bez ręcznego uruchamiania |
| Źródła danych | CRM, telefonia i historia obsługi |
| Sposób pracy | cykliczny, na żądanie i diagnostyczny |
Nie chcę dopisywać efektów, których nie mierzyłem. Największa zmiana jest jednak łatwa do zauważenia: raport przestał być osobnym zadaniem dla pracownika. Jest dostępny regularnie, w tym samym formacie i według tych samych definicji.
Menedżer nie zaczyna od budowania filtra. Zaczyna od decyzji. Handlowiec nie przegląda całej historii klienta przed rozmową. Dostaje skrót najważniejszych faktów. Ja nie wracam za każdym razem do tego samego zestawu zapytań. Rozwijam jedną procedurę, z której później korzysta cały system.
Nie dążę do sytuacji, w której model samodzielnie prowadzi sprzedaż i zmienia dane bez kontroli.
Agent nie powinien:
Najlepsze wykorzystanie AI nie polega na usunięciu człowieka z każdej decyzji. Polega na doprowadzeniu człowieka do miejsca, w którym jego osąd ma największą wartość.
Obecnie agent raportuje, analizuje i porządkuje kontekst. Kolejne kierunki obejmują:
Wyraźnie oddzielam te plany od funkcji działających obecnie. Predykcja nie staje się wiarygodna tylko dlatego, że model potrafi wygenerować procent. Potrzebuje danych historycznych, poprawnych etykiet i późniejszej walidacji wyniku.
Ten projekt łączy kilka obszarów, którymi zajmuję się na co dzień: administrację systemami, programowanie, bazy danych, CRM, telefonię, marketing, analizę sprzedaży oraz lokalne modele językowe.
Nie zaczynam od pytania: „Gdzie możemy dodać AI?”. Zaczynam od procesu:
Dopiero później dobieram narzędzia. Czasami wystarczy SQL i cykliczny raport. Czasami potrzebna jest integracja API. Agent AI w CRM ma sens wtedy, gdy trzeba połączyć kilka źródeł, zrozumieć kontekst i przygotować rezultat dopasowany do konkretnej osoby.
Jeżeli w Twojej firmie CRM zawiera wszystkie informacje, ale nadal potrzebujesz jednej konkretnej osoby, aby uzyskać z niego odpowiedź — prawdopodobnie masz problem, który warto uporządkować. Dobrze zbudowany agent AI w CRM potrafi przygotować tę odpowiedź automatycznie.
Możesz napisać po prostu:
Cześć Adrian, mamy podobny problem. Nasz CRM zawiera dane, ale nadal wszystko sprawdzamy ręcznie.
Od takiego zdania można zacząć sensowną rozmowę o procesie, a nie prezentację kolejnego „magicznego AI”.
W poprzednich częściach tej serii opisałem, jak agent AI przejął automatyzację newslettera i flotę bramek SMS.
Nie. Opisany agent nie prowadzi rozmów i nie negocjuje z klientami. Jego głównym zadaniem jest przygotowanie informacji dla ludzi: raportów, podsumowań historii, list spraw wymagających reakcji i analizy jakości procesu.
Technicznie można budować agentów głosowych, ale jest to inne zastosowanie, z innym poziomem ryzyka i odpowiedzialności. W tym wdrożeniu kontakt pozostaje po stronie pracownika, który zna sytuację klienta i może reagować na niuanse rozmowy.
Nie. Sumy, liczniki, wartości prowizji i wskaźniki powinny być wyznaczane przez deterministyczny kod. Model otrzymuje już uporządkowane dane i przygotowuje ich opis.
Dzięki temu zmiana sposobu sformułowania pytania nie zmienia podstawowej wartości raportu. Jeżeli chcemy zmienić definicję konwersji, robimy to świadomie w procedurze, a nie liczymy na to, że LLM za każdym razem zrozumie ją identycznie.
Nie da się zagwarantować, że model językowy nigdy nie popełni błędu, dlatego rozwiązanie nie może opierać się wyłącznie na poprawnym promptcie. Liczby pochodzą z narzędzi, zakres danych jest jawny, a brakujące informacje są oznaczane.
Agent ma rozróżniać fakt, obliczenie i interpretację. Jeżeli nie ma wystarczającej podstawy do wniosku, powinien to powiedzieć. Przy decyzjach o większych konsekwencjach wynik jest materiałem dla człowieka, a nie automatycznym rozstrzygnięciem.
Model nie powinien otrzymywać nieograniczonego dostępu do bazy ani swobodnie generować zapytań modyfikujących. Korzysta z przygotowanych narzędzi udostępniających konkretne możliwości.
To narzędzie, a nie model, egzekwuje zakres danych i rodzaj operacji. Dzięki temu prośba o raport nie może przypadkowo zamienić się w zmianę rekordów.
Raport powinien zostać oznaczony jako częściowy albo zatrzymany — zależnie od tego, czy brakujący zakres pozwala nadal przygotować uczciwy wynik. System kontroluje liczbę pobranych rekordów, stronicowanie oraz rezultat poszczególnych etapów.
Najgorszym rozwiązaniem byłoby przekazanie niepełnego materiału modelowi i wygenerowanie płynnego podsumowania bez informacji o brakach. Wiarygodność raportu zaczyna się od kontroli kompletności danych.
System korzysta z danych identyfikujących kontakt i powiązań dostępnych w CRM. Numery wymagają normalizacji, ponieważ mogą być zapisane z prefiksem kraju, spacjami albo w innym formacie.
Jeżeli ten sam numer występuje przy kilku rekordach albo nie ma jednoznacznego dopasowania, agent nie powinien wybierać kontaktu na podstawie przypuszczenia. Taki przypadek jest oznaczany do dalszej weryfikacji.
Może być bardzo użyteczna, jeżeli kryteria są dobrze opisane, a wynik zawiera uzasadnienie. Nie powinna jednak być jedyną podstawą oceny pracownika ani decyzji kadrowej.
Model może nieprawidłowo zrozumieć kontekst, ironię lub skrót branżowy. Dlatego audyt służy przede wszystkim wykrywaniu wzorców i wskazywaniu rozmów do sprawdzenia. Człowiek zachowuje możliwość powrotu do materiału źródłowego.
Podczas przygotowywania danych agent stosuje zapisane w CRM reguły wykluczające rekordy, których nie należy obejmować danym procesem. Pokazuje również liczebność przed i po filtracji, dzięki czemu wynik można skontrolować.
Nie oznacza to, że agent sam zapewnia zgodność prawną. Organizacja musi prawidłowo zapisywać podstawy kontaktu, sprzeciwy i preferencje oraz regularnie sprawdzać cały proces.
Domyślnie działa w trybie tylko do odczytu. Raportowanie i analiza nie wymagają prawa do zmiany rekordów.
Jeżeli w przyszłości agent ma utworzyć zadanie, uzupełnić pole albo wykonać inną operację, korzysta z osobnej procedury i ograniczonego narzędzia. Operacje o większych konsekwencjach wymagają zatwierdzenia.
Dashboard jest bardzo dobry do stałych wskaźników. Pokazuje to, co wcześniej ktoś zaprojektował. Agent staje się użyteczny, gdy pytanie wymaga zebrania kontekstu, przejścia przez historię i przygotowania odpowiedzi dopasowanej do konkretnej sytuacji.
Nie traktuję tych rozwiązań jako konkurencji. Kod i dashboard odpowiadają za stabilne liczby, a agent może na ich podstawie wyjaśnić, co się zmieniło, wskazać wyjątki i przygotować skrót dla konkretnego użytkownika.
Nie. Wzorzec można zastosować również do innych systemów, jeżeli udostępniają wiarygodne API albo kontrolowany dostęp do danych. Zmieni się warstwa integracyjna i mapa encji, ale zasady pozostaną podobne.
Największa praca nie polega na samym podłączeniu konektora. Trzeba zrozumieć proces firmy, znaczenie pól, wyjątki i definicje raportów. Dlatego wdrożenie nie jest jednym uniwersalnym szablonem.
Pierwszy raport można uruchomić stosunkowo szybko, jeżeli CRM jest uporządkowany, API działa, a definicje wskaźników są jasne. Pełna warstwa analityczna powstaje etapami.
Najpierw wybieram jeden konkretny problem, przygotowuję wersję tylko do odczytu i porównuję wynik z ręcznym raportem. Dopiero później dokładam kolejne źródła, audyt rozmów i ewentualne operacje zapisu.
Kod odpowiedzialny za pobieranie i liczenie danych nie powinien znikać razem z modelem. Można nadal przygotować dane techniczne albo wrócić do procedury ręcznej.
Niedostępność LLM-a oznacza utratę interpretacji i wygodnej warstwy konwersacyjnej, ale nie powinna oznaczać utraty CRM ani wiedzy o sposobie przygotowania raportu. Procedury i narzędzia pozostają niezależnymi elementami.
Jeżeli proces występuje rzadko, dane są bardzo małe, a raport można przygotować w kilka minut raz na kwartał, budowanie agenta może być przerostem formy nad treścią. Podobnie, gdy organizacja nie ma uzgodnionych statusów i definicji — najpierw trzeba uporządkować proces.
Najlepszym kandydatem jest zadanie częste, powtarzalne, oparte na kilku źródłach i zależne od wiedzy konkretnej osoby. Wtedy zwrot wynika nie tylko z oszczędności czasu, ale też z trwałości wiedzy oraz szybszego wykrywania problemów.
Od jednego pytania, na które zespół regularnie potrzebuje odpowiedzi. Nie od wyboru modelu i nie od budowania wielkiego „agenta do wszystkiego”.
Następnie trzeba ustalić źródła danych, definicję poprawnego wyniku, wyjątki, uprawnienia i sposób weryfikacji. Dobrym początkiem jest raport tylko do odczytu. Gdy jego wyniki są zgodne z ręczną kontrolą, można bezpiecznie rozwijać kolejne możliwości.
