Praca w automatyzacji 2026: zdalnie, biuro, stawki (i czego naprawdę szukają pracodawcy)

Nie zaczynałbym szukania pracy w automatyzacji od pytania "zdalnie czy w biurze". Zaczynałbym od pytania, o jaki rodzaj automatyzacji w ogóle chodzi, bo to decyduje o wszystkim innym: o narzędziach, o widełkach, o formie współpracy. Z naszej strony, czyli firmy, która rekrutowała na takie stanowiska i współpracowała z freelancerami przy wdrożeniach, widzimy, że to rozróżnienie jest w 2026 roku ostrzejsze niż jeszcze dwa, trzy lata temu. I właśnie ono, a nie moda na "AI w procesach", tłumaczy większość nieporozumień między kandydatami a pracodawcami.

Dwa rynki pod jedną nazwą stanowiska

Pierwszy rynek to klasyczne RPA w dużych organizacjach: bankach, firmach ubezpieczeniowych, dużych strukturach korporacyjnych. Tam automatyzacja oznacza UiPath, Power Automate, czasem Blue Prism, integrację z SAP albo wewnętrznymi systemami, które nie mają żadnego publicznego API. Drugi rynek to automatyzacja procesów w małych i średnich firmach oraz agencjach, gdzie narzędziem pierwszego wyboru jest n8n, Make albo Zapier, a projekt polega na połączeniu CRM, poczty, arkusza i systemu księgowego w jeden przepływ.

To nie są warianty tego samego zawodu z inną nazwą stanowiska. To inne umiejętności, inny rytm pracy i inna relacja z klientem czy pracodawcą. Osoba, która świetnie projektuje boty RPA do masowego przetwarzania dokumentów w korporacji, może nie mieć pojęcia, jak rozmawiać z właścicielem dwunastoosobowej firmy handlowej o tym, które pole w fakturze jest "ważne", a które "czasem się zmienia i nikogo to nie obchodzi". I odwrotnie: ktoś biegły w n8n może się zgubić w środowisku, gdzie dostęp do systemu wymaga zgody działu bezpieczeństwa i tygodnia oczekiwania na konto testowe.

RPA korporacyjne: UiPath, Power Automate, procedury

W ogłoszeniach z tej kategorii (typowo Pracuj.pl, czasem No Fluff Jobs) powtarzają się: znajomość UiPath lub Power Automate, podstawy SQL, czasem VBA, umiejętność mapowania procesów (BPMN), a bywa że certyfikat Lean lub Six Sigma. Praca jest zwykle hybrydowa, dwa, trzy dni w tygodniu w biurze, bo dostęp do wewnętrznych systemów często wymaga być na firmowej sieci albo przynajmniej VPN-u nadzorowanego przez IT. Pełna zdalność w tym segmencie istnieje, ale rzadziej niż w innych rolach IT.

Automatyzacja no-code: n8n, Make, Zapier, integracje API

Ten segment żyje głównie na JustJoinIT i wśród ofert freelance, rzadziej jako osobne stanowisko na Pracuj.pl (częściej jest wpleciony w rolę "marketing automation specialist" albo "operations"). Tu dominuje pełna zdalność i kontrakt B2B. Wymagania są bardziej techniczne w sensie integracyjnym: czytanie dokumentacji API, obsługa webhooków, podstawy Pythona albo JavaScriptu do własnych funkcji w n8n, czasem znajomość baz danych. Mniej procedur, więcej samodzielności, ale też mniej stabilności zatrudnienia, bo większość tych ról to projekty, nie stałe stanowiska.

Zdalnie czy w biurze: co naprawdę mówią ogłoszenia w 2026

Deklaracja "praca zdalna" w nagłówku ogłoszenia o automatyzację bywa pół prawdą. W korporacyjnym RPA hybryda jest standardem nie z sentymentu do biura, a z powodów dostępowych: boty często operują na systemach, których nie da się bezpiecznie udostępnić z domowej sieci bez skomplikowanego sprzętu. W projektach no-code bywa odwrotnie: ogłoszenie mówi "zdalnie", ale pierwsze dwa, trzy tygodnie wdrożenia u klienta i tak wymagają wizyty na miejscu, bo trzeba zobaczyć, jak ludzie faktycznie pracują, a nie jak deklarują, że pracują.

Z naszego doświadczenia przy wdrożeniach to właśnie ten etap, czyli obserwacja realnego procesu, najczęściej odróżnia automatyzację, która się przyjmuje, od tej, która po miesiącu wraca do ręcznej obsługi. Jeżeli ktoś codziennie traci 90 minut na przepisywanie danych z faktury do systemu księgowego, trzeba zobaczyć, co robi w tych 90 minutach poza samym przepisywaniem, zanim się ten proces zautomatyzuje. Dlatego w ofertach dla freelancerów coraz częściej pojawia się zastrzeżenie "zdalnie, z możliwością wizyty na starcie projektu" i to jest szczere ustawienie oczekiwań, nie wymówka.

Widełki płacowe: junior, mid, senior

Widełki w automatyzacji są mniej liniowe niż w klasycznym developmencie, bo mocno zależą od segmentu. Poniższe liczby traktujemy jako orientacyjne pasmo, które widzimy powtarzające się w ogłoszeniach, nie jako sztywną normę.

W RPA korporacyjnym, na umowie o pracę, junior zwykle startuje w okolicach 6000-8000 zł brutto, mid to raczej 9000-13000 zł, a senior, zwłaszcza z doświadczeniem w zarządzaniu portfolio botów i integracją z kilkoma systemami jednocześnie, może trafić w przedział 14000-19000 zł brutto. Na kontrakcie B2B te liczby rosną proporcjonalnie, ale nie dramatycznie, bo w korporacjach stawki RPA i tak są negocjowane w odniesieniu do etatowych benchmarków.

W segmencie no-code i freelance rozpiętość jest większa, bo dużo zależy od tego, czy ktoś pracuje dla jednej agencji na stałym zleceniu, czy łączy kilku klientów. Początkujący freelancer, dopiero budujący portfolio, bierze projekty często poniżej realnej wartości swojej pracy, żeby mieć co pokazać, czasem w przedziale 4000-7000 zł miesięcznie ekwiwalentu. Doświadczony specjalista, który ma ustabilizowaną bazę klientów i potrafi samodzielnie prowadzić wdrożenie od rozmowy do utrzymania, osiąga stawki porównywalne albo wyższe niż senior RPA na etacie, bo nie ma pośredniej warstwy korporacyjnej negocjującej jego cenę.

B2B czy umowa o pracę: co dominuje i dlaczego to ma sens

Nie polecałbym wchodzenia na umowę o pracę do roli, która w praktyce jest projektowa, czyli ma początek i koniec, a potem najwyżej lekkie utrzymanie. Widzieliśmy sytuacje, w których firma zatrudniała specjalistę automatyzacji na etat, zrobił on swoje trzy, cztery wdrożenia w pierwszym półroczu, a potem zabrakło mu realnej pracy, bo kolejne procesy do zautomatyzowania pojawiają się partiami, nie ciągłym strumieniem. W takim układzie B2B z jasno określonym zakresem projektu jest po prostu uczciwsze dla obu stron, niż trzymanie kogoś na etacie "w razie czego".

Jakie portfolio faktycznie otwiera drzwi

Tu wchodzimy na teren, który znamy najlepiej, bo sami przeglądaliśmy dziesiątki CV i portfolio kandydatów. I regularnie widzimy ten sam wzorzec: CV deklaruje znajomość n8n, Make, Zapier, Pythona, podstaw RPA i integracji API, ale w rozmowie trudno wskazać jeden kompletny, zamknięty projekt, który kandydat przeprowadził od rozmowy z klientem po działające, utrzymywane rozwiązanie. Deklaracja narzędzia w CV i umiejętność wdrożenia go w realnym, bałaganiarskim środowisku klienta to dwie różne rzeczy.

Co realnie przekonuje: dwa, trzy opisane studium przypadku, nawet drobne, z konkretnym "przed" i "po". Nie trzeba nazywać klienta po nazwie, wystarczy opis typu "firma handlowa, która codziennie ręcznie przepisywała dane z faktur PDF do systemu księgowego, po automatyzacji ten etap zniknął z pracy jednej osoby, a wyjątki (faktury w nieznanym formacie) trafiają do niej do ręcznej weryfikacji". To ostatnie zdanie jest ważniejsze niż się wydaje: pokazuje, że kandydat rozumie, że automat robi większość przypadków, a decyzję przy wyjątku zostawia człowiekowi. Firmy, które same wdrażają takie procesy, wiedzą, że to rozróżnienie jest sedno dobrego projektu, nie szczegół. Tego typu podejście opisujemy też szerzej przy automatyzacji faktur, bo to jeden z najczęstszych punktów startowych dla kandydatów budujących portfolio.

Drugi obszar, który realnie działa w rozmowach rekrutacyjnych, to automatyzacja obsługi klienta: routing zgłoszeń, automatyczne odpowiedzi na powtarzalne pytania, eskalacja do człowieka przy nietypowych przypadkach. Kandydaci, którzy pokazują taki projekt z opisem, które zgłoszenia automat obsłużył samodzielnie, a które przekazał dalej, od razu wyglądają inaczej niż ci, którzy mówią ogólnie "automatyzowałem komunikację z klientami". Więcej o tym, jak to wygląda w praktyce, piszemy przy automatyzacji obsługi klienta.

Czego nie szukamy w CV, nawet jeśli dobrze brzmi

Są trzy sformułowania, które raczej zapalają nam lampkę ostrzegawczą, niż budują zaufanie. Pierwsze to "wykorzystuję AI do automatyzacji procesów" bez ani jednego konkretnego przykładu, co to znaczy technicznie. Drugie to sam certyfikat UiPath czy n8n bez żadnego działającego flow do pokazania, bo certyfikat mówi, że ktoś przeszedł kurs, nie że umie poradzić sobie z realnym, brudnym eksportem danych z systemu, który nikogo nie obchodził od pięciu lat. Trzecie to lista dziesięciu narzędzi integracyjnych naraz, bo w praktyce wdrożeniowej rzadko kiedy jedna osoba naprawdę biegle operuje więcej niż dwoma, trzema głównymi platformami.

To, co faktycznie się liczy w codziennej pracy wdrożeniowej, to umiejętność poradzenia sobie z eksportem CSV z Comarchu, Subiekta albo wFirmy, który ma inne kodowanie znaków niż się spodziewano, albo z API, które w dokumentacji wygląda inaczej niż działa naprawdę. Ta umiejętność nie jest fotogeniczna w CV, ale to ona odróżnia osobę, którą warto zatrudnić, od osoby, która zna nazwy narzędzi.

Jak się przygotować, jeśli szukasz pracy albo zleceń w automatyzacji

Wybierz jedną wąską niszę, zamiast deklarować, że ogarniasz wszystko. Automatyzacja w e-commerce (synchronizacja stanów, zamówień, zwrotów między platformami) ma inną logikę niż automatyzacja w biurze rachunkowym, a ta inną niż automatyzacja działań marketingowych. Jeżeli celujesz w konkretny segment, warto to zobaczyć w praktyce, zanim zadeklarujesz go w CV, na przykład przy automatyzacji e-commerce albo przy procesach, które opisujemy przy automatyzacji biura rachunkowego.

Zrób jedno, dwa prawdziwe, nawet drobne wdrożenia, zamiast dziesięciu demówek na własnych danych testowych. Lokalna firma, znajomy przedsiębiorca, nawet projekt pro bono w zamian za możliwość opisania go w portfolio, to więcej wart niż kolejny tutorial powtórzony z YouTube'a. I zapisuj liczby: ile czasu zajmowało coś przed automatyzacją, ile po, ile przypadków automat obsługuje samodzielnie, a ile trafia do człowieka. To właśnie te liczby, nie lista narzędzi, przekonują rekrutera albo klienta, że masz realne doświadczenie, nie tylko teoretyczną znajomość platformy.