Rozmowa z potencjalnym klientem właśnie się skończyła i zaczyna się ta część pracy, którą większość ludzi odkłada na wieczór: notatka, podsumowanie, a potem oferta w slajdach, którą trzeba złożyć z tego, co padło na spotkaniu. Wszystko to da się dziś zautomatyzować prawie do końca. Prawie, bo ostatni krok, czyli decyzję, co naprawdę trafia do klienta, zostawiam człowiekowi i pokażę ci, dlaczego to nie jest ostrożność na wyrost.
Przejdę przez cały układ: jak zapisać spotkanie, jak doczekać się danych, jak zapytać człowieka o zgodę, jak napisać polecenie dla modelu, jak wysłać tekst do generatora slajdów i co sprawdzić w szkicu, zanim ktokolwiek go zobaczy. Narzędzia podaję jako przykłady: notatnik spotkań w rodzaju Fireflies, platforma automatyzacji n8n, arkusz Google, Slack do zatwierdzeń i generator prezentacji w rodzaju Gamma. Wzorce zadziałają tak samo na innym zestawie.
Dwa przepływy zamiast jednego
Przepływ (ang. workflow) to ciąg kroków, które automat wykonuje po kolei. Każdy krok to węzeł: pojedynczy klocek, który robi jedną rzecz, na przykład pobiera dane, zapisuje wiersz w arkuszu albo wysyła wiadomość.
Pierwsza decyzja projektowa jest najmniej efektowna i najbardziej się opłaca: rozdzielasz całość na dwa osobne przepływy. Pierwszy tylko zapisuje, że spotkanie się odbyło. Drugi robi coś z tym zapisem, w tym przypadku składa ofertę.
Powód jest prosty. Po zakończonym spotkaniu nie zawsze chcesz robić to samo. Po rozmowie sprzedażowej potrzebujesz oferty, po spotkaniu wewnętrznym wystarczy notatka, po rozmowie z obecnym klientem może lista zadań. Jeśli zapis spotkania zaszyjesz w środku przepływu od ofert, każda nowa ścieżka oznacza przebudowę całości. Jeśli zapis jest osobny, dokładasz kolejne gałęzie po obu stronach i nic się nie rozjeżdża. Łatwiej też śledzić, co się dzieje, bo każdy przepływ ma jedno zadanie.
Webhook niesie tylko numer, a podsumowanie dojrzewa później
Pierwszy przepływ startuje od webhooka. Webhook to adres, pod który inny program sam wysyła powiadomienie, gdy coś się wydarzy. W ustawieniach dla deweloperów notatnika spotkań wklejasz adres produkcyjny webhooka z n8n i zaznaczasz zdarzenie „transkrypcja gotowa”. Od tej chwili każde zakończone i przetworzone spotkanie wywołuje twój przepływ.
Tu czeka pierwsza niespodzianka. W samym powiadomieniu prawie nic nie ma: identyfikator spotkania i typ zdarzenia. Nie ma transkrypcji, tytułu ani uczestników. Dlatego kolejny węzeł robi osobne zapytanie: „podaj mi wszystko o spotkaniu o tym identyfikatorze”. Dopiero ta odpowiedź niesie transkrypcję w postaci listy zdań, tytuł, adres gospodarza, słowa kluczowe i podsumowania, które notatnik wygenerował sam: punkty, zadania do wykonania, skrót rozmowy.
Druga niespodzianka wychodzi dopiero w praktyce. Kiedy pytasz zaraz po zakończeniu transkrypcji, części generowanej przez AI często jeszcze nie ma. Transkrypcja jest, podsumowania nie. Rozwiązaniem jest polling, czyli cykliczne dopytywanie: przepływ czeka chwilę, pyta o dane, a węzeł warunkowy sprawdza, czy skrót rozmowy już istnieje. Jeśli tak, idzie dalej. Jeśli nie, wraca do czekania i pyta ponownie. Pętla kręci się tak długo, aż dane są kompletne.
Potem porządkujesz dane. Odpowiedź przychodzi w formacie JSON, czyli w uporządkowanym tekście z polami i wartościami, i trzeba z niej wyciągnąć to, czego potrzebujesz: najpierw listę osób, które mówiły, a w drugim przepływie także czytelną transkrypcję. Czytelną, czyli taką, w której imię mówiącego pojawia się raz na początku jego wypowiedzi, a nie przed każdym zdaniem.
Tego kodu nie musisz pisać sam. Kopiujesz cały JSON, który wchodzi do węzła z kodem, wklejasz go do czatu z AI, takiego jak Claude czy ChatGPT, i piszesz wprost: potrzebuję kodu do węzła w n8n, oto dane wejściowe, na wyjściu chcę listę mówiących. Model widzi strukturę danych i pisze kod pod nią. Za pierwszym razem rzadko jest idealnie, więc wklejasz kod, uruchamiasz, a jeśli wynik jest zły, wracasz do czatu z trzema rzeczami: jaki kod dostajesz, co z niego wychodzi i dlaczego to nie to. Kilka takich rund zwykle wystarcza.
Arkusz jako pamięć i pytanie do człowieka
Ostatni krok pierwszego przepływu dopisuje wiersz do arkusza: datę i godzinę, tytuł spotkania, uczestników, skrót rozmowy, status i identyfikator spotkania. Ten identyfikator jest tu najważniejszą kolumną, bo to jedyna wartość, która na pewno jest unikalna. Tytuły się powtarzają, daty się pokrywają, a identyfikator nie. Każdy późniejszy krok, który ma wrócić do tego spotkania, szuka go właśnie po nim.
Kolumna statusu na starcie ma wartość neutralną, a potem zmienia się w miarę postępu: odrzucone, gdy nikt nie chce oferty, wygenerowane, gdy szkic powstał. Dzięki temu arkusz jest jednocześnie dziennikiem i tablicą stanu. Jednym spojrzeniem widzisz, po których rozmowach coś poszło dalej, a po których nie.
Drugi przepływ startuje, gdy w arkuszu pojawia się nowy wiersz. Pobiera dane spotkania jeszcze raz i od razu zostawia tylko ostatnią pozycję. To drobny bezpiecznik: jeśli dwa spotkania skończą się w tej samej chwili, przepływ przetworzy jedno i się nie pogubi.
Potem przychodzi miejsce, którego nie wolno pominąć: pytanie do człowieka. Human-in-the-loop, czyli człowiek w pętli, oznacza, że automat zatrzymuje się i czeka na decyzję osoby. Tutaj wygląda to tak: na Slacku przychodzi wiadomość „spotkanie się zakończyło, czy wygenerować ofertę?” z dwoma przyciskami. Tak uruchamia generowanie. Nie zmienia status w arkuszu na odrzucone i kończy przebieg. Nie każda rozmowa kończy się ofertą, a generowanie jej po każdej zaśmieca skrzynkę i kosztuje.
Polecenie dla modelu, które ma szkielet
Sercem drugiego przepływu jest agent piszący ofertę, czyli model językowy z poleceniem systemowym, które ustala, jak ma pracować. Model wygeneruje za każdym razem coś trochę innego. Im więcej struktury mu dasz, tym mniej ta losowość boli. Polecenie składam z pięciu warstw.
Rola. Model wciela się w doświadczonego konsultanta rozwiązań AI i inżyniera sprzedaży, który z surowej transkrypcji rozmowy rozpoznawczej albo handlowej składa dopracowaną ofertę dla klienta.
Cel. Ma wykorzystać transkrypcję i nic poza nią jako materiał wyjściowy.
Ograniczenia. Dokument jest w całości przeznaczony dla klienta. Nie zawiera pytań uzupełniających, notatek wewnętrznych ani żadnego tekstu o tym, jak powstał. Tam, gdzie brakuje konkretnych danych, model wstawia wyraźny symbol zastępczy, na przykład [kwota do uzupełnienia], zamiast wymyślać szczegóły. Ta jedna reguła oszczędza najwięcej pracy przy przeglądzie.
Ton i styl. Rzeczowy, pewny, zrozumiały dla osoby decyzyjnej, a nie dla inżyniera.
Stała struktura sekcji. Strona tytułowa, podsumowanie dla zarządu, problem i wyzwanie, proponowane rozwiązanie, zwrot z inwestycji, korzyści trudno mierzalne, plan wdrożenia, mierniki sukcesu i na końcu „dlaczego my”. Ta lista robi więcej niż reszta polecenia razem wzięta, bo każda oferta ma ten sam kręgosłup i łatwo ją przejrzeć.
Na wyjściu dostajesz jeden blok tekstu. Do klienta jeszcze się nie nadaje, ale jest gotowym materiałem na slajdy.
Wywołanie generatora slajdów i druga droga wejścia
API to serwisowe wejście do programu, przez które inny program rozmawia z nim wprost, bez klikania w interfejs. Generator prezentacji ma takie wejście: wysyłasz mu tekst, a on składa z niego slajdy z nagłówkami, ikonami i grafikami.
Treść zapytania wygląda na początku groźnie, bo ma kilkanaście pól. Sposób na nią jest nudny i skuteczny. Kopiujesz przykładowe zapytanie z dokumentacji, a potem idziesz pole po polu i przy każdym odpowiadasz na trzy pytania: czy jest wymagane, co robi i czego chcesz. Tekst wejściowy to wynik agenta. Tryb tekstu ustawiasz na zachowanie treści, bo nie chcesz, żeby generator skracał albo przepisywał to, co agent starannie złożył. Motyw to identyfikator twojego własnego szablonu, skopiowany z ustawień generatora. Do tego ilość tekstu na slajd, ton, odbiorca i źródło obrazów. Na końcu udostępnianie: dostęp do komentowania i automatyczna wysyłka linku na twój wewnętrzny adres, żeby nie szukać gotowej prezentacji ręcznie. Jeśli dokumentacja jest niejasna, wklej link do niej do czatu z AI i opisz, jaką prezentację chcesz dostać.
Jeden szczegół łatwo przeoczyć. Zanim wstawisz tekst agenta do zapytania, oczyść go z łamań wierszy i cudzysłowów. Jeden niezamaskowany cudzysłów potrafi rozbić całą treść zapytania i wywołanie się wyłoży. Prosta funkcja zamiany przed wysyłką załatwia sprawę raz na zawsze.
Po wywołaniu przepływ wysyła na Slacka informację, że prezentacja się generuje, i aktualizuje wiersz w arkuszu. Tym razem nie dopisuje nowego, tylko szuka istniejącego po identyfikatorze spotkania i zmienia status na wygenerowane.
Zostaje druga droga wejścia. Zdarza się, że klikniesz „nie”, a później zmienisz zdanie. Dlatego obok automatycznego wyzwalacza stoi prosty formularz z jednym polem: identyfikator spotkania, skopiowany z arkusza. Formularz uruchamia te same kroki: pobranie danych, porządkowanie, agent, generator, powiadomienie i zmiana statusu.
Tu pojawia się problem, który wychodzi dopiero przy drugiej ścieżce. Każde uruchomienie idzie jedną drogą, nigdy obiema naraz. Jeśli agent i dalsze węzły odwołują się wprost do węzła z drogi automatycznej, to przy uruchomieniu z formularza tego węzła po prostu nie ma i przepływ się wywraca. Rozwiązaniem jest węzeł standaryzujący, w n8n węzeł typu Set. Obie drogi wpadają do niego i wystawiają pod tymi samymi nazwami dwa pola: transkrypcję dla agenta i identyfikator spotkania dla aktualizacji arkusza. Wszystko dalej czyta już tylko z tego jednego miejsca, bez względu na to, którędy przyszło uruchomienie.
Szkic, nie oferta: co sprawdzasz przed wysyłką
Gotowa prezentacja wygląda profesjonalnie i właśnie to jest w niej najbardziej zdradliwe. Pokonuje większość drogi, ale nie całą. Po obu stronach pracuje AI, przy pisaniu tekstu i przy składaniu slajdów, więc dwa przebiegi dla tej samej rozmowy dadzą dwie trochę różne prezentacje. Dlatego wynik traktujesz jak szkic, który przegląda człowiek.
Najpierw liczby. Model z dużą pewnością wyliczy z rozmowy zaoszczędzone godziny, oszczędności w pieniądzach i spadek liczby błędów, nawet jeśli klient podał tylko luźne szacunki. Takie liczby wyglądają wiarygodnie, bo stoją w zielonych ramkach na slajdzie o zwrocie z inwestycji. Każdą z nich weryfikujesz na prawdziwych danych klienta albo usuwasz. Oferta z wymyśloną liczbą jest gorsza od oferty bez liczby.
Potem wykresy. Generator lubi dorysować porównanie „z automatyzacją i bez”, w którym nie wiadomo, co pokazują osie, a kolory nie pasują do legendy. Jeśli sam nie umiesz w jednym zdaniu powiedzieć, co wykres pokazuje, wyrzuć go.
Dalej plan wdrożenia. Agent chętnie rozpisze harmonogram na tygodnie. Może się zgadzać, może nie, a model nie ma skąd tego wiedzieć. Terminy ustalasz sam, na podstawie tego, co wiesz o zespole i zakresie.
Na końcu sprawdzasz symbole zastępcze, które trzeba uzupełnić, i szukasz resztek tekstu systemowego, który nie powinien trafić do klienta.
Jedno ulepszenie warte jest rozważenia: slajd „dlaczego my” jest najsłabszy, kiedy model pisze go z niczego. Jeśli dasz agentowi dostęp do bazy wcześniejszych projektów twojej firmy, wyszuka ten najbliższy tematowi rozmowy i oprze slajd na prawdziwym przypadku. Oferta przestaje wtedy brzmieć jak szablon.
Zasada, którą z tego wynoszę: automat ma odebrać ci pracę, nie podpis. Wszystko, co prowadzi do szkicu, można oddać maszynie. Wszystko, co klient przeczyta jako zobowiązanie, czyli liczby, terminy i obietnice, przechodzi przez człowieka. Jeśli chcesz zacząć, zbuduj najpierw sam pierwszy przepływ: zapis spotkania w arkuszu z identyfikatorem i statusem. Kiedy przez tydzień będzie się wypełniał bez twojej pomocy, dołożenie oferty to już tylko kolejna gałąź.