Automatyzacje, których sami używamy w NoCodeWork: za kulisami

Kiedy sprzedajesz automatyzację, pierwsze pytanie, jakie powinieneś usłyszeć od klienta, brzmi: „a wy sami z tego korzystacie?". Padło u nas kilka razy i za każdym razem odpowiadałem tak samo: prawie wszystko, co budujemy firmom, najpierw stoi u nas i musi przeżyć własne wpadki.

Poniżej rozpisuję to na pięć systemów: co każdy z nich rozwiązuje, jak jest zbudowany i czego się przy nim nauczyłem, zwykle w momencie, w którym przestał działać. Nie ma tu wewnętrznych adresów ani identyfikatorów, bo to akurat nikomu nie pomaga. Jest za to schemat, który da się skopiować.

Uprzedzę pytanie o liczby. Nie podam, ile godzin dzięki temu „oszczędzamy", bo takie liczby zwykle powstają w Excelu po fakcie.

TL;DR: U siebie trzymamy pięć rzeczy: pipeline leadowy (formularz → n8n → CRM, zadanie i SMS w kilkadziesiąt sekund), dyspozytor zadań cyklicznych sterowany tabelą zamiast dwudziestoma workflow, cykliczne raporty z GA4, Meta Ads i Search Console streszczane przez AI, mailing self-hosted na Sendy i Amazon SES oraz warstwę utrzymania: healthchecki z autorestartem, error workflows i backupy z testem odtworzenia. Piąty punkt jest najnudniejszy i najważniejszy.

Pipeline leadowy: od formularza do handlowca

Problem. Zgłoszenie z formularza ląduje w skrzynce. Skrzynkę ktoś czyta rano, ktoś inny po lunchu, a w piątek nikt. Potem trzeba przepisać dane do CRM, sprawdzić, czy ta firma już się kiedyś nie odzywała, i doszukać danych rejestrowych. Każdy z tych kroków jest banalny i każdy potrafi kosztować pół dnia opóźnienia.

Jak to działa. Formularz nie wysyła maila, tylko dane do naszego workflow. Dalej dzieje się to:

Antyspam. Cloudflare Turnstile odsiewa boty, zanim cokolwiek dotrze do automatyzacji. Bez tego pierwszy tydzień działania formularza to dziesiątki śmieciowych zgłoszeń w CRM.
Webhook do n8n. Wejście do całego procesu jest jedno. Jeśli nie wiesz, czym dokładnie jest webhook, mamy proste wyjaśnienie.
Deduplikacja po e-mailu. Jeśli taki kontakt już istnieje, workflow dopisuje notatkę do istniejącej szansy zamiast zakładać drugą.
Dane firmy po NIP. Workflow dociąga dane rejestrowe z publicznych źródeł (biała lista podatników, KRS). Handlowiec dostaje pełną nazwę, formę prawną i adres, zamiast pytać o to w pierwszym mailu.
Zapis do CRM i zadanie. Powstaje szansa w Pipedrive i zadanie w ClickUpie z terminem kontaktu.
SMS do handlowca. Jedyny kanał, który realnie przerywa pracę. Mail w tym momencie nie działa, bo ląduje w tej samej skrzynce, którą i tak czyta się raz na kilka godzin.

Całość zamyka się w kilkudziesięciu sekundach od kliknięcia „wyślij". Techniczną stronę spięcia formularza z CRM rozpisaliśmy w artykule o integracji Pipedrive z n8n, a katalog automatyzacji sprzedażowych wokół samego CRM w tekście o automatyzacji Pipedrive.

Czego się nauczyliśmy: cisza nie znaczy, że działa. Przez jakiś czas ten pipeline nie miał obsługi błędów. Gdy CRM odpowiedział błędem albo formularz przysłał pole w innym formacie, workflow kończył się porażką i nic więcej się nie działo. Lead znikał, a my byliśmy przekonani, że po prostu nikt się w tym tygodniu nie odezwał.

Dziś ten sam pipeline ma osobną ścieżkę na wypadek awarii: jeśli zgłoszenie nie trafi do CRM, dostajemy alert z jego surową treścią i lead da się obsłużyć ręcznie. Zasada jest prosta: każda automatyzacja dotykająca pieniędzy musi umieć zgłosić własną awarię. Bez tego mierzysz skuteczność liczbą rzeczy, które przeszły, i nie wiesz nic o tych, które przepadły.

Dyspozytor zadań cyklicznych: jedna tabela zamiast dwudziestu workflow

Problem. Cyklicznych przypomnień w firmie jest zaskakująco dużo: sprawdzenie briefów, przegląd kampanii, kontrola płatności, cotygodniowy rzut oka na backlog. Odruch podpowiada zbudować dla każdego osobny workflow z własnym harmonogramem. Po pół roku masz ich dwadzieścia, połowa robi to samo, a nikt nie pamięta, który wysyła którą wiadomość.

Jak to działa. Odwróciliśmy to. Zamiast dwudziestu automatyzacji mamy jedną i tabelę z konfiguracją.

W naszej firmowej bazie (NocoDB na własnym serwerze) stoi tabela zadań cyklicznych. Jeden wiersz to jedno zadanie: nazwa, wyrażenie cron, typ akcji, treść, znacznik „aktywne" i data ostatniego uruchomienia.
Jeden workflow w n8n budzi się co minutę, czyta tabelę i sprawdza, dla których wierszy właśnie wypada termin.
Przy typie „powiadomienie" wysyła treść na kanał zespołowy, skąd idzie pushem na telefon. Przy typie „uruchom workflow" odpala wskazany podprzepływ.
Po wykonaniu dopisuje datę uruchomienia, więc od razu widać, co się zacięło.

Dodanie nowego przypomnienia to dopisanie wiersza. Zero kodu, zero nowego workflow, zero wdrożenia. Ten sam wzorzec wdrażamy klientom i to jedna z niewielu rzeczy, które sprawdzają się praktycznie zawsze. O samej bazie pod spodem piszemy w artykule o NocoDB jako Airtable na własnym serwerze.

Czego się nauczyliśmy: powiadomienie to nie zadanie. Pierwsza wersja tego mechanizmu zakładała zadania w menedżerze projektów. W tydzień lista zamieniła się w rejestr rzeczy, których nikt nie zamyka, bo „sprawdź, czy poszedł nocny import" nie jest zadaniem do odhaczenia, tylko wiadomością do przeczytania. Prawdziwe projekty zaczęły tonąć między przypomnieniami.

Od tego czasu trzymamy twardy podział: rzeczy z właścicielem i terminem idą na listę zadań, wszystko pozostałe na czat. Rozwinięcie tej granicy opisaliśmy przy okazji automatyzacji w ClickUp, a samą higienę powiadomień w tekście o powiadomieniach z n8n na Slacka i Teams.

Raporty AI: trzy źródła danych, jeden dokument z wnioskami

Problem. Dane o tym, jak radzi sobie firma marketingowo, leżą w trzech miejscach: GA4 (ruch), Meta Ads (kampanie) i Google Search Console (widoczność w wyszukiwarce). Każde ma inny interfejs, inną definicję konwersji i inną zakładkę do klikania. Zagląda się tam w przypływie sumienia, zwykle wtedy, gdy coś już poszło nie tak.

Jak to działa. Backend zbiera dane z tych trzech źródeł do jednej bazy Postgres. Na tym siedzi warstwa generująca analizę na żądanie albo cyklicznie: model Claude dostaje ustrukturyzowane dane z dwóch porównywanych okresów i pisze dokument w markdownie z wnioskami i rekomendacjami. Raport przychodzi mailem albo na kanał zespołowy.

Najwięcej pracy poszło w prompt, a dokładniej w to, czego modelowi zabraniamy. Raport ma nie streszczać tabeli. Ma odpowiedzieć, co się zmieniło względem poprzedniego okresu, co jest prawdopodobną przyczyną i co z tym zrobić w tym tygodniu. Architekturę i konstrukcję samego promptu rozpisaliśmy w osobnym artykule o automatycznych raportach dla zarządu.

Dołożyliśmy do tego jedną rzecz, której nie ma w domyślnych widokach: rozdzielenie fraz brandowych od non-brand. Zapytania z nazwą firmy rosną, gdy zwiększamy budżet reklamowy, i mówią wyłącznie o tym, że reklamy działają. O skuteczności bloga mówi ruch non-brand. Zmusiła nas do tego obserwacja, która przy pierwszym spotkaniu wygląda na błąd w danych: zdarzają się frazy z pierwszą pozycją w wynikach i zerową liczbą kliknięć, bo odpowiedź generuje się nad wynikami i nikt nie ma powodu wchodzić dalej.

Czego się nauczyliśmy: raport, po którym nikt nic nie zmienia, jest kosztem. Pierwsze wersje były ładne i długie, z każdą metryką, jaką dało się wyciągnąć. Czytałem je przez dwa tygodnie, potem przestałem, bo nie wynikało z nich żadne działanie.

Dziś obowiązuje jedna reguła: jeśli z raportu nie da się wyprowadzić decyzji, raport jest za długi albo nie na temat. W praktyce oznacza to porównanie okres do okresu zamiast wartości bezwzględnych, wskazanie wprost tego, co zmieniło się najmocniej, i rekomendację, którą da się odrzucić. Rekomendacja, z którą nie sposób się nie zgodzić, jest bezużyteczna.

Mailing na własnym serwerze

Problem. Klasyczne platformy mailingowe rozliczają się od liczby kontaktów na liście, a lista rośnie niezależnie od tego, czy wysyłasz raz w tygodniu, czy raz na kwartał. Przy newsletterze wysyłanym nieregularnie płacisz głównie za przechowywanie adresów.

Jak to działa. Używamy Sendy postawionego na naszym serwerze, a wysyłkę realizuje Amazon SES. Sendy to jednorazowa licencja i aplikacja PHP, którą sam hostujesz. SES rozlicza się za wysłane wiadomości, więc płacisz za ruch, a nie za rozmiar bazy. Policzony rachunek i wymagania techniczne rozpisaliśmy w artykule o mailingu self-hosted na Sendy.

Lekcja wyszła z tego nieoczywista: self-hosting nie jest tańszy, tylko inaczej płatny. Rachunek miesięczny spada wyraźnie, ale dochodzą pozycje, których wcześniej nie było: rekordy SPF, DKIM i DMARC, rozgrzewanie domeny wysyłkowej, pilnowanie odbić i skarg, aktualizacje aplikacji, backup bazy subskrybentów. Przy platformie SaaS to problem dostawcy. Tutaj jest twój i płacisz za niego uwagą, a nie fakturą.

Nam ten rachunek się spina, bo własną infrastrukturę mamy i tak. Firmie bez nikogo od serwerów odradzam ten ruch bez wahania: oszczędność na abonamencie znika w pierwszym tygodniu problemów z dostarczalnością.

Utrzymanie: healthchecki, error workflows, backupy

Problem. To najnudniejsza część i jedyna, bez której cztery poprzednie są tymczasowe. Automatyzacja psuje się cicho. Kontener z aplikacją potrafi się zawiesić i odpowiadać stroną błędu, mając status „działa". Workflow potrafi wywalić się na jednym kroku i skończyć bez śladu. Kopia zapasowa potrafi robić się latami i nie dać się odtworzyć.

Jak to działa. Trzy warstwy:

Healthchecki z automatycznym restartem. Każda ważna aplikacja ma healthcheck i etykietę, po której proces nadzorujący wie, że w razie awarii ma ją podnieść. Nauczka: sonda pod adresem strony głównej to za mało, bo aplikacja potrafi zwrócić ekran błędu z kodem 200. Sonda ma trafiać w endpoint potwierdzający, że aplikacja naprawdę żyje, na przykład że ma połączenie z bazą.
Error workflows w n8n. Każdy istotny workflow ma podpięty przepływ błędu, który po nieudanym wykonaniu wysyła alert z nazwą workflow i treścią błędu. Ta sama mechanika pilnuje leadów z pierwszego punktu.
Backupy z testem odtworzenia. Kopie robią się automatycznie i trafiają na zewnętrzny magazyn, a raz na jakiś czas odtwarzamy je na czysto i sprawdzamy, czy dane faktycznie są. Przy bazach SQLite doszła nam po drodze konkretna lekcja: nie kopiuje się pliku bazy zwykłym cp, bo część danych siedzi w dzienniku zapisu i kopia bywa niespójna. Trzeba użyć wbudowanego mechanizmu kopii. Co backupować w samym n8n, w tym pułapkę z kluczem szyfrowania, opisaliśmy w tekście o backupach i aktualizacjach n8n.

Czego się nauczyliśmy: alert, na który nie da się zareagować, to szum. Na początku alertowaliśmy wszystko: każde nieudane wykonanie, każdy restart, każde przekroczenie progu. Po dwóch tygodniach był to kanał, którego nikt nie czyta, a wtedy przestaje mieć znaczenie, czy alerty w ogóle przychodzą.

Teraz przed dodaniem alertu odpowiadam sobie na dwa pytania: kto go przeczyta i co konkretnie po nim zrobi. Jeśli odpowiedź brzmi „nic, ale dobrze wiedzieć", to nie jest alert, tylko wpis do logu. Rzeczy, które trzeba wiedzieć, idą do logu. Alert dostaje tylko to, co wymaga reakcji człowieka w ciągu godziny.

Pięć systemów w jednej tabeli

System	Co rozwiązuje	Z czego zbudowany	Lekcja
Pipeline leadowy	Zgłoszenie czekające w skrzynce, ręczne przepisywanie do CRM	Formularz + Turnstile → webhook → n8n → CRM, zadanie, SMS	Automatyzacja musi umieć zgłosić własną awarię
Dyspozytor zadań cyklicznych	Dwadzieścia workflow z harmonogramem wpisanym na sztywno	Tabela w NocoDB + jeden workflow n8n czytający ją co minutę	Powiadomienie to nie zadanie
Raporty AI	Dane w trzech panelach, do których nikt nie zagląda	GA4 + Meta Ads + Search Console → Postgres → model → mail	Raport ma prowadzić do decyzji
Mailing self-hosted	Abonament rosnący z liczbą kontaktów	Sendy na własnym serwerze + Amazon SES	Self-hosting nie jest tańszy, tylko inaczej płatny
Utrzymanie	Awarie, o których dowiadujesz się od klienta	Healthchecki z autorestartem, error workflows, backupy z testem	Alert bez możliwej akcji to szum

Czego u siebie nie zbudowaliśmy

Uczciwość wymaga wymienienia też pustych miejsc, bo lista automatyzacji bez nich brzmi jak folder reklamowy.

Pierwszego kontaktu z klientem nie automatyzujemy. Żadnych sekwencji „cieszę się, że się odezwałeś" wysyłanych w naszym imieniu. Workflow doprowadza zgłoszenie do handlowca i tam się kończy. Z każdej takiej sekwencji, jaką sam dostałem, wynikało głównie to, że nadawca ma system.

Ofertowania też nie domykamy do końca. Zebranie danych i szkic to jedno, ale każda oferta przechodzi przez człowieka, zanim wyjdzie. Człowiek w pętli przy decyzjach kosztujących pieniądze to u nas standard, nie kompromis.

I nie tykamy procesów, których nie umiemy narysować. Kilka razy próbowałem ten krok obejść i za każdym razem kończyło się przepisywaniem workflow dwa tygodnie później. Metodę mapowania rozpisaliśmy w przewodniku po mapowaniu procesów, a listę rzeczy, po które w ogóle nie warto sięgać, w tekście o tym, czego nie automatyzować.

FAQ

Czy da się zbudować taki zestaw automatyzacji bez programisty?

Pipeline leadowy, dyspozytor zadań cyklicznych i powiadomienia zbudujesz w n8n na gotowych węzłach, bez pisania kodu. Trudność leży nie w budowaniu, tylko w utrzymaniu: aktualizacje, backupy, reakcja na awarie i decyzja, co zrobić, gdy zewnętrzne API zmieni format odpowiedzi. To wymaga kogoś, kto czuje się swobodnie z serwerem, albo zewnętrznego utrzymania.

Od którego systemu zacząć we własnej firmie?

Od tego, który zdejmuje ręczną robotę osobie zarabiającej pieniądze, czyli zwykle od pipeline'u leadowego. Zgłoszenie u handlowca w kilkadziesiąt sekund zamiast po kilku godzinach widać w sprzedaży od razu, a sam workflow jest prosty na tyle, że da się go złożyć w jeden dzień. Raporty i utrzymanie dokładaj później, gdy jest już co utrzymywać.

Ile kosztuje utrzymanie takiej infrastruktury?

Warstwa techniczna jest tania: VPS pod n8n i bazę zaczyna się od kilkudziesięciu złotych miesięcznie, wysyłka przez Amazon SES rozlicza się od wiadomości, a n8n w modelu fair-code używasz do własnych automatyzacji bez opłat licencyjnych. Prawdziwy koszt to czas: aktualizacje, reakcja na alerty i okresowe testy odtworzenia backupu.

Czy powiadomienia lepiej wysyłać mailem, czy na czat?

Na czat, jeśli mają być przeczytane tego samego dnia, bo idą pushem na telefon i nie konkurują z resztą skrzynki. Mail zostaje dla rzeczy, które mają przeżyć dłużej niż jeden dzień: raportów cyklicznych i podsumowań. To, co ma przerwać pracę natychmiast, jak nowy lead, wysyłamy SMS-em, bo tego kanału nikt nie wycisza.

Po co rozdzielać frazy brandowe od non-brand w raporcie?

Bo zapytania z nazwą firmy rosną razem z budżetem reklamowym i mówią o skuteczności reklam, a nie treści. Patrząc na sumę, każdą kampanię odczytasz jako sukces contentu. Ruch non-brand to jedyna liczba pokazująca, czy blog i widoczność w wyszukiwarce przyciągają nowych ludzi. Sprawdzaj też frazy z wysoką pozycją i zerową liczbą kliknięć, bo tam odpowiedź często generuje się nad wynikami wyszukiwania.

Podsumowanie

Wspólny mianownik tych pięciu systemów nie jest technologiczny. W każdym najważniejszą decyzją było ograniczenie: co dzieje się automatycznie, a co zostaje przy człowieku, co jest alertem, a co wpisem do logu, co jest zadaniem, a co wiadomością. Narzędzia są wymienne, ta granica nie jest.

Drugi wniosek dotyczy kolejności. Cztery pierwsze systemy budowaliśmy z entuzjazmem, piąty pod przymusem, po pierwszych awariach. Gdybym zaczynał jeszcze raz, healthchecki, obsługę błędów i test odtworzenia backupu wprowadzałbym razem z pierwszym workflow dotykającym czegokolwiek ważnego.

Te same wzorce wdrażamy u klientów i to właściwie cała pointa tego tekstu. Dyspozytor zadań cyklicznych, alert na wypadek zgubionego leada, podział na kanał alertów i listę zadań, raport prowadzący do decyzji: żaden z nich nie jest teorią z bloga. To rzeczy, które musiały u nas najpierw się zepsuć, żebyśmy wiedzieli, jak zbudować je drugi raz.

Chcesz ustalić, który z tych systemów miałby u Was największy sens jako pierwszy? Umów bezpłatną konsultację — przejdziemy przez Wasze procesy i powiemy wprost, jeśli sensowniejsze będzie poprawienie tego, co już macie, zamiast budowania czegokolwiek nowego.