Workflow automation: Make, Zapier czy n8n — i kiedy potrzebujesz czegoś innego
Słowo „workflow automation” brzmi jak coś, co wymaga działu IT i pół roku wdrożenia. W praktyce pierwszy działający przepływ pracy potrafię postawić w popołudnie – na gotowym narzędziu, bez jednej linijki kodu. Problem zaczyna się później: gdy ten sam przepływ obsługuje nie 50, a 5000 zdarzeń miesięcznie, gdy ktoś z zespołu pyta „a gdzie to podejrzeć?”, albo gdy rachunek za narzędzie nagle przebija pensję juniora. W tym tekście rozkładam na części trzy najpopularniejsze narzędzia – Make, Zapier i n8n – pokazuję, gdzie każde się sprawdza, a gdzie pęka, i kiedy ma sens przejście na rozwiązanie szyte na miarę.
Czym właściwie jest workflow automation
Automatyzacja przepływów pracy to łączenie wielu kroków w jeden ciąg, który uruchamia się sam – bez tego, żeby ktoś klikał „dalej”. Klasyczny przykład: klient wypełnia formularz → dane lądują w CRM → leci powiadomienie na Slacka → tworzy się zadanie w systemie → klient dostaje maila z potwierdzeniem. Pięć kroków, które ktoś wcześniej robił ręcznie, dzieje się w kilka sekund.
To nie to samo co pojedyncza integracja („przepisz dane z A do B”). Workflow ma logikę: warunki, rozgałęzienia, pętle, obsługę sytuacji, gdy coś pójdzie nie tak. Jeśli chcesz spojrzeć na temat szerzej, zanim zejdziemy do narzędzi, zacznij od mojego przewodnika po automatyzacji procesów – ten artykuł jest jego praktycznym rozwinięciem.
Trzy narzędzia, których używam najczęściej
Nie ma jednego „najlepszego” narzędzia – jest narzędzie dopasowane do skali, budżetu i tego, kto będzie to utrzymywał. Poniżej szybkie porównanie, a niżej rozwijam każde.
| Kryterium | Zapier | Make | n8n |
|---|---|---|---|
| Próg wejścia | Najniższy | Średni | Wyższy (techniczny) |
| Model cenowy | Per zadanie | Per operacja | Self-hosted / per execution |
| Liczba integracji | Największa (8000+) | Duża (2000+) | Średnia, ale rozszerzalna |
| Złożona logika | Ograniczona | Dobra | Bardzo dobra (kod inline) |
| Koszt przy skali | Rośnie szybko | Rośnie wolniej | Najniższy (own hosting) |
| Własny hosting | Nie | Nie | Tak |
Zapier – najszybszy start, najszybciej drożeje
Zapier wygrywa prostotą. Jeśli chcesz połączyć dwie–trzy popularne aplikacje (Gmail, Sheets, Slack), zrobisz to w 10 minut, bez czytania dokumentacji. Ma najwięcej gotowych integracji na rynku. Słaba strona: model rozliczeń per zadanie i ograniczona logika. Przy bardziej rozgałęzionych przepływach szybko trafiasz na ścianę – albo funkcjonalności, albo ceny. Trzymam go do prostych, niskowolumenowych automatyzacji.
Make – więcej logiki za rozsądniejsze pieniądze
Make (dawniej Integromat) to mój domyślny wybór dla średnio złożonych przepływów. Wizualny edytor pokazuje przepływ danych krok po kroku, łatwiej tu o rozgałęzienia, filtry i agregacje. Liczy operacje, nie zadania, więc przy tej samej automatyzacji zwykle wychodzi taniej niż Zapier. Słaba strona: przy naprawdę dużej liczbie operacji pułapka cenowa wraca – tylko później. I dalej nie masz własnego interfejsu dla zespołu.
n8n – kontrola i niski koszt przy skali, ale wymaga techniki
n8n jest open-source i można go hostować u siebie. To zmienia ekonomię: przy dużych wolumenach płacisz za serwer, a nie za każde wykonanie. Pozwala wstawiać kod inline, więc logikę robisz praktycznie dowolną. Słaba strona: próg wejścia. Ktoś musi to postawić, utrzymać i ogarnąć aktualizacje. Dla firmy bez zaplecza technicznego „darmowy” n8n potrafi okazać się droższy w godzinach niż płatny Make.
Pułapka cenowa: dlaczego „tanie” no-code drożeje przy skali
To najczęstsze zaskoczenie u moich klientów. Model per-operacja wygląda świetnie na starcie: kilkadziesiąt złotych miesięcznie. Ale jeden przepływ z 6 krokami to 6 operacji na jedno zdarzenie. Przy 5000 zdarzeń miesięcznie to już 30 000 operacji – i nagle jesteś w wyższym, droższym planie.
- Policz operacje, nie zdarzenia. Pomnóż liczbę kroków przez przewidywany wolumen, zanim wybierzesz plan.
- Sprawdź próg, przy którym custom się zwraca. Z mojego doświadczenia, gdy rachunek za no-code przekracza ~500–800 zł/mies. i rośnie, warto policzyć alternatywę — pomoże w tym kalkulator ROI.
- Dolicz ukryte koszty. Czas na obchodzenie ograniczeń narzędzia też kosztuje.
Druga pułapka: brak własnego UI
Low-code świetnie łączy systemy w tle, ale nie daje twojemu zespołowi własnego interfejsu. Jeśli pracownik ma codziennie zatwierdzać wnioski, przeglądać zgłoszenia albo wprowadzać dane – w Make czy Zapier nie ma gdzie tego zrobić wygodnie. Skutek: ludzie i tak siedzą w arkuszu albo w skrzynce, a automatyzacja obsługuje tylko fragment procesu.
To wyraźnie widać przy automatyzacji obiegu dokumentów: samo przerzucanie plików między folderami to za mało – ktoś musi je zaakceptować, opisać, odrzucić z komentarzem. Tu zaczyna się przewaga rozwiązania szytego na miarę, które dokłada ekran dopasowany do realnej pracy zespołu.
Jak zaprojektować dobry workflow – niezależnie od narzędzia
Narzędzie jest wtórne. Najpierw projekt. Trzymam się prostego szkieletu:
- Wyzwalacz (trigger). Co dokładnie uruchamia przepływ? Jedno, konkretne zdarzenie – nie „jak coś się zmieni”.
- Kroki. Rozpisz je liniowo, najprościej jak się da. Każdy krok robi jedną rzecz.
- Warunki i rozgałęzienia. Dodawaj je dopiero, gdy są naprawdę potrzebne – każde rozgałęzienie to dług do utrzymania.
- Obsługa wyjątków. Najważniejsze i najczęściej pomijane. Co się dzieje, gdy API nie odpowie? Gdy dane są niekompletne? Bez tego „działający” przepływ cicho gubi zdarzenia.
- Logowanie. Musisz wiedzieć, co się wydarzyło. Inaczej debugowanie to zgadywanie.
Ta sama dyscyplina dotyczy zarówno no-code, jak i custom. Różnica jest taka, że w custom obsługę wyjątków i logowanie kontrolujesz w pełni.
Kiedy dołożyć AI
AI w workflow ma sens tam, gdzie wcześniej potrzebny był człowiek do oceny lub interpretacji, a nie do prostego przeklejania danych. Dobre przypadki: klasyfikacja zgłoszeń (do którego działu trafia mail), wyciąganie danych z nieustrukturyzowanych dokumentów, wstępna odpowiedź na powtarzalne pytania, streszczanie długich treści.
Przestroga: nie wkładaj AI tam, gdzie wystarczy zwykły warunek. To droższe i mniej przewidywalne. AI dokładam świadomie, w jednym–dwóch punktach przepływu, gdzie realnie zastępuje decyzję człowieka. Dokładnie tak działa SupportFlow AI – AI klasyfikuje i wstępnie odpowiada na zgłoszenia, ale całość ma własny panel, w którym zespół zachowuje kontrolę.
Moje podejście: najpierw gotowiec, custom gdy konieczne
Nie zaczynam od pisania kodu. Jeśli Make albo Zapier rozwiązują problem w rozsądnej cenie – rekomenduję je i koniec. Custom proponuję dopiero, gdy widać konkretny powód: pułapkę cenową przy skali, potrzebę własnego interfejsu dla zespołu, złożoną logikę, której no-code nie udźwignie, albo wymagania wokół danych i bezpieczeństwa.
Gdy ten próg zostaje przekroczony, buduję end-to-end – od wyzwalacza, przez logikę i integracje, po własny ekran, na którym zespół realnie pracuje. Jedno rozwiązanie, jeden właściciel, przewidywalny koszt utrzymania.
Nie wiesz, po której stronie tej granicy jesteś? Napisz do mnie – przejdziemy przez twój proces i powiem wprost, czy wystarczy gotowiec, czy warto policzyć custom.