- Problem: każde pytanie klienta przechodziło łańcuch Klient → PM → Specjalista → PM → Klient. Odpowiedzi trwały dniami, a zespół patrzył na kanały, nie na biznes klienta. Efekt: spadające NRR i realny churn.
- Rozwiązanie: The Forge, wewnętrzna platforma AI zbudowana na Claude Code. Nie „czat z AI", tylko biblioteka skilli rozwiązujących konkretne problemy, zasilana pełnym, codziennie odświeżanym kontekstem klienta: GA4, Search Console, Google Ads, Meta Ads, CRM projektowy i transkrypty rozmów.
- Efekty: raport miesięczny z 2 godzin do ~15 minut. Keyword research z 2 dni do godziny. PM ewoluujący z pośrednika w stratega. NRR, które odbiło z dołka ~59% do ~80% równolegle ze wzrostem liczby ustrukturyzowanych raportów z ~20 do ~75 miesięcznie.
Uwaga o zrzutach ekranu: są niezmienione poza zasłonięciem adresów e-mail, oznaczonym etykietą e-mail ukryty.
Problem: agencja, która patrzy na kanał, a nie na biznes
Typowa sytuacja w agencji marketingowej. Klient pyta: „Czemu spadła sprzedaż w zeszłym miesiącu?". Pytanie trafia do PM-a. PM nie ma jednocześnie pełnej wiedzy o Google Ads, SEO i analityce, bo nikt nie ma. Szuka więc specjalisty. Specjalista ma kalendarz zapchany na dwa dni do przodu. Odpowiedź wraca do PM-a, PM tłumaczy ją klientowi.
Łańcuch Klient → PM → Specjalista → PM → Klient domykał się w dzień, dwa. PM-owie brali komunikację na klatę i pilnowali, żeby klient był na bieżąco, ale w dzisiejszych czasach nawet dwa dni to za wolno. Do tego PM nie miał przestrzeni na zadawanie pytań wtedy, kiedy ich potrzebował. Zawsze czekał, aż specjalista znajdzie okienko.
A problem był głębszy niż tempo:
„Bardzo zirytowało mnie to, że wielokrotnie specjaliści czy PM-owie patrzą na kanał, a nie na biznes klienta. Stwierdziłem, że trzeba zrobić przestrzeń, która będzie wymagała jakości biznesowej, a nie kanałowej."
Każdy robił dobrze swoją działkę. Kampanie były zoptymalizowane, pozycje rosły. Ale nikt nie składał tego w odpowiedź na pytanie, które klient naprawdę zadaje: co to znaczy dla mojego biznesu i co robimy dalej? Zespół był produktywny, ale nie zawsze efektywny: robił dużo, niekoniecznie to, co miało największy sens.
Wartość, którą agencja realnie wnosiła, nie była odpowiednio prezentowana. A wartość, której klient nie widzi, dla klienta nie istnieje. Widzieliśmy to w twardych danych: NRR dojrzałej kohorty projektów osunęło się z ~78% do dołka ~59%.
Decyzja: budujemy, ale nie „platformę do wszystkiego"
Zanim powstał The Forge, przetestowaliśmy na sobie podejście, które nie zadziałało. W pierwszej iteracji równoległego projektu ludzie dostali otwarte narzędzie, w którym mogli budować, co im się podoba. I właśnie to okazało się barierą: próg wejścia był za wysoki, procedury skomplikowane, a opory naturalne.
„Adopcja AI w organizacji powinna zacząć się od wyrównania progu wejścia od strony ludzi. Inaczej nie przejdzie: projekt uwalą opory społeczne, albo przebijanie ich będzie trwało bardzo długo."
The Forge powstał więc z odwrotnym założeniem: ludzie nie adoptują platform, adoptują rozwiązania swoich problemów. Zamiast otwartego czatu z AI zespół dostał bibliotekę gotowych skilli: wygeneruj raport miesięczny, zrób keyword research, przygotuj listę wykluczeń do Google Ads, zbuduj dashboard strategiczny. Każdy skill rozwiązywał konkretny, znany ból. A przy okazji oswajał ludzi z pracą na zagregowanych danych, budując zaufanie potrzebne do następnego kroku.
Jako fundament wybraliśmy Claude Code. Zdecydowały trzy rzeczy: zarządzanie całym narzędziem przez jedno centralne repozytorium (każdy w firmie pracuje na tej samej, aktualnej wersji), najmocniejsze w benchmarkach modele oraz naturalne wsparcie dla orkiestrowalnych skilli. Model po prostu dobrze rozumie wielokrokowe procedury, więc systemy budowane wokół niego pozostają łatwe w utrzymaniu. Alternatywy, nawet te nieodstające w benchmarkach, nie dawały takiego zestawu narzędzi do zarządzania.
Jak to działa: anatomia jednej odpowiedzi
Żeby nie zostać na poziomie ogólników, prześledźmy krok po kroku, co się dzieje, gdy PM zadaje The Forge to samo pytanie, które kiedyś uruchamiało dwudniowy łańcuszek: „Czemu spadła sprzedaż w zeszłym miesiącu?"
1. Logowanie w 10 sekund. PM otwiera The Forge i podaje e-mail oraz kod jednorazowy z aplikacji uwierzytelniającej. Celowo kod, nie hasło: kod wygasa po chwili, więc nawet zapisany w historii czatu jest bezwartościowy. Bezpieczeństwo danych klientów traktujemy tu bezkompromisowo.
2. Kontekst ładuje się sam. Na starcie sesji platforma pobiera z naszego API pełny kontekst projektu: zadania i postępy prac z CRM-u projektowego, notatki strategiczne PM-a, transkrypty ostatnich rozmów z klientem, dane SEO i analityczne. Automaty aktualizują te dane codziennie, więc kontekst jest zawsze świeży. PM nie musi niczego wklejać ani tłumaczyć narzędziu, „o co chodzi w projekcie".
3. Pytanie jest routowane do właściwych źródeł. W repozytorium platformy żyje mapa decyzyjna: typ pytania → źródło danych. Pytanie o spadek sprzedaży to pytanie złożone, więc The Forge sięga po kombinację źródeł naraz:
- dane e-commerce per produkt (co konkretnie spadło: który produkt, która kategoria, na którym etapie lejka),
- źródła ruchu i kanały (czy spadek przyszedł z organic, z płatnych, z direct),
- dzienne dane kampanii Google Ads (czy reklamy dowoziły: koszty, konwersje, udział w wyświetleniach, utrata widoczności przez budżet albo ranking),
- transkrypty rozmów i notatki PM-a (czy w tle nie było decyzji, która to tłumaczy: zmiana oferty, wstrzymany budżet, sezonowość, o której klient wspominał na spotkaniu).
4. Liczby nagłówkowe pochodzą ze źródła prawdy. Sumy sesji i przychodu całego sklepu zawsze pobierane są z dedykowanego endpointu z totalami miesięcznymi, a nie z sumowania tabel wymiarowych, bo te z natury API analitycznych się nie domykają. To brzmi jak niuans, ale właśnie takie niuanse decydują o tym, czy liczby w odpowiedzi zgadzają się z panelem GA4, który klient ma przed oczami.
5. Analiza dzieje się na surowych wierszach, wnioski po stronie modelu. API celowo nie zwraca gotowych wniosków, tylko surowe, dzienne albo miesięczne wiersze danych w formie zaprojektowanej pod dane pytanie. Do tego, tam gdzie to możliwe, deterministycznie zbudowane konteksty: dane przetworzone algorytmami, nie interpretacją modelu. Model agreguje, porównuje okresy, liczy udziały i skleja to z kontekstem jakościowym z rozmów. Jeśli danych za jakiś okres brak, mówi to wprost. Zmyślanie jest zakazane na poziomie architektury: brak rekordów to komunikat „brak danych", nie zaproszenie do halucynacji.
6. Odpowiedź jest biznesowa, nie kanałowa. PM dostaje nie tabelkę, tylko odpowiedź w rodzaju: sprzedaż spadła o X% głównie w kategorii Y, ruch płatny dowiózł, ale organic stracił widoczność na frazach produktowych, a z transkryptu ostatniego spotkania wynika, że klient ograniczył budżet na Z. Do tego: co warto zrobić dalej. Czyli dokładnie to, czego kiedyś PM szukał dwa dni u trzech osób.
Cała ścieżka zajmuje minuty. I, co równie ważne, PM może dopytywać do woli. Kalendarz specjalisty przestał być wąskim gardłem ciekawości.
Skille: tam, gdzie odpowiedź ma być standardem, nie improwizacją
Swobodna rozmowa załatwia pytania ad hoc. Ale część pracy agencji to procesy powtarzalne, w których liczy się nie tylko trafność, ale i niezmienna, audytowalna jakość. Do tego służą skille: spakowane, wielokrokowe procedury uruchamiane jedną komendą.
Najlepiej pokazuje to nasz flagowy skill raportowy. Pod spodem wygląda tak:
Deterministyczny silnik liczb. Skrypt pobiera równolegle dane z siedmiu źródeł (okno roczne dla trendów, z automatycznym ponawianiem przy błędach), a następnie osobny, deterministyczny silnik liczy wszystko, co policzalne: uzgodnienie totali, rozdział ruchu brandowego od akwizycyjnego, kwantyfikację zmian, priorytety. Obowiązuje żelazna zasada: żadna liczba w raporcie nie powstaje w modelu językowym. Model dostaje gotowe, policzone wartości i odpowiada wyłącznie za narrację oraz framing biznesowy. Dzięki temu raport zawsze zgadza się z panelami, do których klient ma dostęp.
Tone Card: raport pisany głosem PM-a. Przed generowaniem raportu osobny agent analizuje najlepiej ocenione historyczne raporty danego PM-a i destyluje z nich profil stylu: jak ten człowiek zaczyna i kończy komunikację, jakich zwrotów używa, jak równoważy złe wieści, czy stawia rekomendacje wprost, czy proponuje. Klient dostaje raport, który brzmi jak jego PM, nie jak generator treści. Profil przenosi wyłącznie styl; przenoszenie treści czy liczb ze starych raportów jest zakazane.
Continuity Brief: pamięć rozmowy z klientem. Drugi agent wyciąga z poprzedniego raportu zobowiązania i wątki: co obiecaliśmy sprawdzić, co już klientowi wytłumaczyliśmy, jaką historię opowiadamy od miesięcy. Nowy raport jest ciągiem dalszym tej narracji, rozlicza się z obietnic i nie sprzedaje po raz trzeci tej samej ciekawostki jako świeżego odkrycia. Comiesięczny reset, grzech większości raportowania agencyjnego, znika.
Ekspert w pętli, zanim cokolwiek trafi na produkcję. Żaden skill nie wchodzi do użytku bez akceptacji eksperta dziedzinowego. Skill do keyword researchu powstawał w pętli z naszym czołowym SEO-wcem: to on oceniał jakość outputów i bez jego zgody skill nie wszedł produkcyjnie. Kiedy wszedł, pierwszy użytkownik podsumował go tak:
„Z 2 dni roboty zrobiła mi się godzina."
Ta sama filozofia dotyczy skilli analitycznych: skill QBR (kwartalny przegląd biznesowy) ma wpisane trzy bramki walidacyjne (fakty, jakość, design) i zasadę „matematyka tylko w skryptach", a flagi jakości danych i luki trafiają jawnie do stopki dokumentu. Transparentność zamiast lukru.
Od użytkownika do twórcy
Najciekawsze zaczęło się kilka tygodni po starcie. Gdy ktoś w swobodnej rozmowie z The Forge wypracuje coś wartościowego, wystarczy, że napisze: „zrób mi z tego skilla". Jednorazowa akcja staje się reużywalnym standardem: dostępnym na każdym projekcie, wersjonowanym, z możliwością udostępnienia innym i oceniania. Do tego jest też pełnoprawny kreator skilli, który przeprowadza przez proces krok po kroku, od nazwy i źródeł danych po publikację w firmowej bazie.


Dziś w katalogu obok skilli „fabrycznych" żyją skille zbudowane przez specjalistów z zespołu: raport placementów Google Ads autorstwa naszego specjalisty PPC, kreatory ofert od zespołu sprzedaży i kolejne. Każdy z tagiem autora, wersją i oceną. Pętla się domknęła: narzędzie, które miało oswoić ludzi z AI, jest teraz przez nich rozbudowywane.
Efekty: liczby i zmiana ról
Skala po ~4 miesiącach od decyzji o budowie:
- 43 skille w katalogu: 13 wbudowanych w platformę i 30 zbudowanych w zespole, w tym skille autorstwa samych użytkowników
- 28 z nich miało odnotowane użycie w oknie maj–sierpień 2026
- 25 aktywnych użytkowników miesięcznie — 33,8% adopcji, czyli 25 z 74 kont (stan na koniec sierpnia 2026)
- raport miesięczny: z 2 godzin do ~15 minut
- keyword research: z 2 dni do ~1 godziny

Ale najważniejszy wykres wisi gdzie indziej: zestawienie NRR dojrzałej kohorty z liczbą generowanych raportów.

NRR osuwało się z ~78% do dołka w okolicach ~59-60%. Dokładnie w okresie, w którym liczba ustrukturyzowanych raportów wzrosła z ~20 do ~75 miesięcznie, trend się odwrócił i NRR wróciło do ~80%. Uczciwie: to korelacja na dowodzie anegdotycznym, nie kontrolowany eksperyment (porównujemy kohortę do punktowych okresów). Sprawdziliśmy jednak, że na starcie kohorty nie było anomalii, które tłumaczyłyby odbicie. I trudno zignorować mechanizm, który za tym stoi: klienci zaczęli zostawać, gdy zaczęli regularnie widzieć wartość, którą dostają, oraz plan, dokąd zmierzamy.
Zmiana, której nie widać w liczbach: PM przestał być forward managerem. Może zadawać pytania kiedy chce, bez czekania na okienko w kalendarzu specjalisty, i ewoluuje w stratega marketingowego, który potrafi merytorycznie podważyć zdanie specjalisty w drodze do najlepszego rozwiązania dla klienta. Specjaliści nie zostali zastąpieni: zostali odciążeni z odtwórczej roboty i włączeni w pętlę jakości jako recenzenci skilli ze swoich dziedzin. Zarówno tempo, jak i jakość dawnego łańcuszka uległy niebotycznej poprawie.
Adopcja jako KPI, nie pobożne życzenie
Jesteśmy w trakcie rozpychania narzędzia w organizacji i traktujemy adopcję jak metrykę produktową: mierzoną co miesiąc (odsetek kont z co najmniej jednym użyciem skilla), z jawnie postawionym celem: 85% organizacji w ciągu 6 miesięcy, z kamieniami milowymi po drodze.

Plan rozwoju samego narzędzia jest równie konkretny: The Forge ma być nie tylko koniecznym, ale przede wszystkim wymaganym przez ludzi assetem. Partnerem, który pomaga dostarczać klientom wartość, a specjalistom i PM-om rozwijać się i pracować komfortowo, usuwając blokery, których bez niego nie da się przeskoczyć albo które kosztują zbyt wiele czasu.
Czego nauczyło nas to wdrożenie
- Zacznij od problemów, nie od platformy. Ludzie adoptują rozwiązania swoich bólów. Tryb twórczy przychodzi sam, po zaufaniu.
- Wymuszaj jakość biznesową, nie kanałową. Narzędzie ma składać kanały w odpowiedź na pytanie klienta o jego biznes. Inaczej budujesz szybszą wersję starego problemu.
- Karm model kontekstem, nie surowymi zrzutami. Codziennie odświeżana agregacja danych ze wszystkich systemów plus transkrypty realnych rozmów z klientem to różnica między odpowiedzią a zgadywanką.
- Liczby licz deterministycznie, poza modelem. Model językowy odpowiada za narrację i framing; każda liczba pochodzi ze skryptu albo z danych. To warunek zaufania, i zespołu, i klienta.
- Ekspert w pętli. Żaden skill nie wchodzi na produkcję bez akceptacji eksperta dziedzinowego. To odróżnia standard od generatora treści.
- Mierz adopcję i postaw jej cele. Adopcja to KPI produktu, z celem, kamieniami milowymi i dashboardem. Nie „zobaczymy, jak się przyjmie".