Automatyzacja procesów rekrutacyjnych

Po co automatyzować: rachunek godzin

Automatyzacja to nie „projekt IT". To decyzja: które z czynności, które robisz co tydzień identycznie, oddać maszynie. Kryterium jest proste — jeśli potrafisz opisać zadanie jako instrukcję dla nowego stażysty („gdy przyjdzie mail z CV, przepisz dane do arkusza i daj znać na Slacku"), to da się je zautomatyzować. Jeśli za każdym razem musisz pomyśleć inaczej — nie da się i nie wartoRachunek dla jednej rekruterki: 30 aplikacji tygodniowo × 6 min ręcznego przepisywania do arkusza = 3 h/tydzień = ok. 144 h rocznie — prawie pełny miesiąc pracy na samo przeklejanie danych. Do tego notatki po rozmowach (8 rozmów × 20 min = 2,7 h/tydz.) i cotygodniowy raport (1 h). Razem ~6,7 h tygodniowo czynności czysto mechanicznych..

W tym module budujemy pięć konkretnych scenariuszy: od wpadającej aplikacji, przez notatkę po rozmowie, po piątkowy raport lejka. Każdy z opisem kroków, listą potrzebnych kont, szacunkiem czasu budowy i kosztem miesięcznym. Wszystkie zbudujesz sam — bez programisty, choć z programistą pójdzie szybciej.

Jedna zasada nadrzędna, zanim klikniesz cokolwiek: automatyzujemy przenoszenie i porządkowanie informacji, nigdy decyzje o ludziach. Scoring z automatu to sugestia kolejności czytania CV, nie werdyktUnijny AI Act klasyfikuje systemy AI używane do selekcji kandydatów jako wysokiego ryzyka. W praktyce: automat może porządkować, streszczać i podpowiadać, ale decyzję o odrzuceniu podejmuje człowiek i musi umieć ją uzasadnić bez powoływania się na „tak wyszło z modelu". Model też halucynuje — potrafi „doczytać" w CV kompetencję, której tam nie ma, i wnosi bias z danych treningowych. Dlatego każdy wynik scoringu traktuj jak podpowiedź stażysty pierwszego dnia pracy..

Cztery narzędzia: Make, Zapier, n8n, Power Automate

Wszystkie cztery robią to samo: łączą aplikacje w łańcuch „zdarzenie → kroki → akcja". Różnią się ceną, progiem wejścia i tym, gdzie fizycznie płyną dane kandydatów. Ceny poniżej są orientacyjne (stan: 2026) — przed zakupem sprawdź aktualny cennikUwaga na jednostki rozliczeń: Make liczy operacje (każdy krok scenariusza = 1 operacja), Zapier liczy taski (kroki poza triggerem). Scenariusz nr 1 z tego modułu ma ~6 kroków, więc 200 aplikacji miesięcznie = ~1200 operacji — to już koniec darmowego planu Make (1000 operacji) i wielokrotność darmowego Zapiera (100 tasków)..

Praktyczna reguła: zacznij od Make na darmowym planie. Jeśli po dwóch miesiącach automatyzacje przetwarzają setki aplikacji albo dział prawny pyta „gdzie dokładnie są te dane" — rozmawiaj z IT o n8n na firmowym serwerzeSelf-hosting n8n rozwiązuje problem „gdzie leżą dane w narzędziu automatyzacji", ale nie problem kroku LLM: jeśli scenariusz wysyła tekst CV do API OpenAI czy Anthropic, dane i tak opuszczają twój serwer. Rozwiązania: anonimizacja przed wysyłką (workflow nr 1 właśnie tak robi), API z gwarancją przetwarzania w UE albo model uruchomiony lokalnie (np. przez Ollama w n8n) — wolniejszy i słabszy, ale w pełni u ciebie..

Elementarz: trigger → kroki → akcja

Każdy scenariusz, w każdym z czterech narzędzi, składa się z tych samych klocków. Trigger to zdarzenie startowe: nowy e-mail z załącznikiem, nowy wiersz w arkuszu, godzina 8:00 w piątek albo webhookWebhook to unikalny adres URL, który twoje narzędzie „nasłuchuje". Gdy inna aplikacja (formularz na stronie, Typeform, narzędzie do transkrypcji) wyśle na ten adres dane — scenariusz startuje natychmiast, bez odpytywania co 15 minut. Adres webhooka traktuj jak hasło: kto go zna, może wstrzykiwać dane do twojego procesu. — czyli „zawołaj mnie, gdy coś się wydarzy". Potem idą kroki: pobierz załącznik, wyciągnij tekst z PDF, przefiltruj, przekształć. Na końcu akcje: dopisz wiersz, wyślij wiadomość, utwórz dokument.

Nowość ostatnich lat to krok LLM w środku łańcucha: moduł OpenAI/Anthropic (albo goły moduł HTTP strzelający do API), któremu wklejasz prompt, a on zwraca ustrukturyzowany wynikTrzy ustawienia kroku LLM, które oszczędzą ci godzin debugowania: (1) temperatura 0 — automat ma być powtarzalny, nie kreatywny; (2) wymuszony format JSON (w API: response_format / structured output) — inaczej model czasem doklei „Oto wynik:" i parser się wysypie; (3) do ekstrakcji i klasyfikacji wystarczy tani, szybki model (klasy Haiku / GPT-mini) — koszt sparsowania jednego CV to 1–4 grosze.. To ten krok zamienia głupi przenośnik danych w asystenta, który czyta CV, pisze notatki i streszcza lejek.

Pięć gotowych workflow

Każdy z pięciu scenariuszy poniżej ma diagram, kroki do odtworzenia w Make (analogicznie w n8n i Power Automate), listę kont, czas budowy i koszt. Buduj w tej kolejności trudności: 4 → 5 → 1 → 3 → 2 (strażnik SLA jest najprostszy, bo nie ma kroku LLM).

Workflow 1 · Nowa aplikacja: z maila do arkusza ze scoringiem

1. Trigger: Gmail/Outlook — obserwuj skrzynkę rekrutacja@… (lub etykietę „Aplikacje"); alternatywnie webhook z formularza na stronie karier.
2. Filtr: tylko wiadomości z załącznikiem PDF/DOCX. Reszta idzie ścieżką z klasyfikatorem (prompt niżej) — pytania kandydatów trafiają do ciebie, spam do kosza.
3. Ekstrakcja tekstu: moduł „Extract text from PDF" (Make ma wbudowany; w n8n — node „Extract From File").
4. Krok LLM: prompt „Ekstraktor CV → JSON" (poniżej), temperatura 0, format JSON.
5. Parsowanie i zapis: moduł „Parse JSON" → „Google Sheets: Add a Row" — jedna kolumna na jedno pole ze schematu.
6. Scoring + powiadomienie: drugi krok LLM z promptem „Klasyfikator dopasowania"; jeśli wynik ≥ 7/10 — wiadomość na Slack/Teams do rekrutera prowadzącego.

Potrzebne konta: Make (darmowy), skrzynka rekrutacyjna, Google Sheets, klucz API Anthropic lub OpenAI, Slack/Teams. Czas budowy: 2–3 h za pierwszym razem, 45 min za drugim. Koszt miesięczny: przy 150 aplikacjach ~900 operacji (mieści się w darmowym Make) + ~3–6 zł za API. Realnie: poniżej 10 złDwustronicowe CV to ~1500–2500 tokenów. Na tanim modelu (klasy Haiku) ekstrakcja + scoring jednego CV kosztuje 1–4 grosze. Nawet 500 aplikacji miesięcznie to koszt jednej kawy — pozycją kosztową jest plan narzędzia automatyzacji, nie API..

Jesteś parserem dokumentów rekrutacyjnych działającym wewnątrz automatycznego scenariusza. Twoja odpowiedź jest przetwarzana maszynowo — nie pisze jej człowiek i nie czyta jej człowiek.

Zadanie: z poniższego tekstu CV wyodrębnij dane do formatu JSON.

Zwróć WYŁĄCZNIE poprawny obiekt JSON. Bez tekstu przed i po, bez bloków kodu, bez komentarzy.

Schemat pól (typ i definicja):
{
  "stanowisko_docelowe": "string|null — stanowisko, na które kandydat aplikuje; jeśli nie wynika z dokumentu, null",
  "lata_doswiadczenia": "number — łączne lata doświadczenia zawodowego, z dokładnością do 0.5",
  "ostatni_pracodawca": "string|null",
  "ostatnie_stanowisko": "string|null",
  "kluczowe_umiejetnosci": ["string — maks. 8 pozycji, krótkie hasła, np. 'Java', 'kadry i płace', 'zarządzanie zespołem sprzedaży'"],
  "jezyki": [{"jezyk": "string", "poziom": "string — skala A1–C2; jeśli CV nie podaje poziomu, wpisz 'deklarowany'"}],
  "wyksztalcenie": "string|null — najwyższy stopień + kierunek, np. 'mgr, finanse i rachunkowość'",
  "lokalizacja": "string|null — miasto zamieszkania lub preferowane",
  "tryb_pracy": "string|null — zdalnie / hybrydowo / stacjonarnie, jeśli podano",
  "dostepnosc": "string|null — okres wypowiedzenia lub data dostępności, jeśli podano",
  "oczekiwania_finansowe": "string|null — dosłownie tak, jak w CV; niczego nie przeliczaj",
  "braki_w_cv": ["string — nazwy pól, których nie dało się ustalić z tekstu"]
}

Zasady twarde:
1. NIE zgaduj i NIE uzupełniaj z wiedzy ogólnej. Brak informacji = null + wpis w "braki_w_cv".
2. POMIŃ celowo: imię, nazwisko, adres, telefon, e-mail, datę urodzenia, linki do profili, zdjęcie, stan cywilny. Te dane nie mogą znaleźć się w odpowiedzi.
3. Zatrudnienie „obecnie" / „do dziś" licz do: lipiec 2026.
4. Jeżeli tekst nie wygląda na CV (np. to zapytanie ofertowe albo spam), zwróć: {"blad": "to_nie_jest_cv"}.

Tekst CV:
{{tu narzędzie automatyzacji wkleja tekst z kroku ekstrakcji PDF}}

Jesteś klasyfikatorem wiadomości w skrzynce rekrutacyjnej firmy NAZWA FIRMY, branża. Działasz w automatycznym scenariuszu — odpowiadasz wyłącznie w formacie JSON, bez żadnego innego tekstu.

Przypisz poniższą wiadomość do dokładnie jednej kategorii:
- "aplikacja" — kandydat przesyła CV lub zgłasza się na konkretne stanowisko,
- "pytanie_kandydata" — pytanie o status, ofertę, proces, dostępność stanowisk,
- "wycofanie" — kandydat rezygnuje z procesu lub prosi o usunięcie danych,
- "spam_lub_oferta_handlowa" — mailing, oferta usług, cold mail sprzedażowy,
- "inne" — nic z powyższych (np. mail wewnętrzny, pomyłka).

Format odpowiedzi:
{
  "kategoria": "jedna z pięciu wartości powyżej",
  "pewnosc": "liczba 0–100",
  "stanowisko": "string|null — nazwa stanowiska, jeśli da się ustalić",
  "wymaga_czlowieka": "boolean — true, jeśli wiadomość zawiera skargę, sprawę prawną, prośbę o usunięcie danych lub silne emocje",
  "uzasadnienie": "jedno zdanie po polsku"
}

Zasady:
- Przy pewności poniżej 70 ustaw "wymaga_czlowieka": true — lepiej, żeby człowiek zerknął, niż żeby automat źle skierował kandydata.
- "wycofanie" i prośby o usunięcie danych ZAWSZE mają "wymaga_czlowieka": true — to obowiązek z RODO, nie zadanie dla automatu.

Wiadomość (temat + treść):
{{temat}} — {{treść wiadomości z triggera}}

Jesteś asystentem rekrutera. Porównujesz zanonimizowane dane kandydata z wymaganiami stanowiska i proponujesz WSTĘPNĄ kolejność czytania aplikacji. Nie podejmujesz decyzji o kandydacie — to robi człowiek.

Stanowisko: Senior Java Developer (Kraków, hybrydowo)

Wymagania twarde (brak któregokolwiek = wynik maks. 4/10):
- min. 5 lat komercyjnego doświadczenia w Javie
- Spring Boot, mikroserwisy
- angielski min. B2

Mile widziane (każde podnosi wynik, ale nie jest warunkiem):
- Kafka, Kubernetes
- doświadczenie w fintechu
- prowadzenie code review / mentoring

Dane kandydata (JSON z poprzedniego kroku):
{{JSON z kroku „Ekstraktor CV"}}

Zwróć WYŁĄCZNIE JSON:
{
  "wynik": "liczba całkowita 1–10",
  "spelnione_twarde": ["lista wymagań twardych potwierdzonych w danych"],
  "niespelnione_lub_nieznane": ["lista wymagań, których dane NIE potwierdzają — rozróżnij: 'brak' vs 'brak informacji'"],
  "atuty": ["maks. 3 rzeczy z listy mile widzianych, które kandydat ma"],
  "do_weryfikacji_na_rozmowie": ["maks. 3 konkretne pytania weryfikujące niepewne obszary"],
  "uzasadnienie": "2 zdania po polsku"
}

Zasady:
- Oceniaj TYLKO na podstawie przekazanych danych. Niczego nie zakładaj po nazwie pracodawcy ani kierunku studiów.
- „Brak informacji" to nie „brak kompetencji" — obniża pewność, nie wynik do zera.
- Ignoruj i nie komentuj: płeć, wiek, narodowość, przerwy w zatrudnieniu. Jeśli takie dane przeciekły do wejścia, nie używaj ich w ocenie.

Workflow 2 · Po rozmowie: transkrypt → notatka → ATS i hiring manager

1. Trigger: webhook z narzędzia transkrypcji (Fireflies, tl;dv — patrz moduł 05) albo obserwacja folderu Google Drive/SharePoint, do którego spadają transkrypty z MS Teams.
2. Pobranie treści: moduł „Download a File" + ekstrakcja tekstu.
3. Krok LLM: prompt „Notatka z rozmowy" (poniżej). Tu warto użyć mocniejszego modelu — notatkę czyta człowiek i podejmuje na jej podstawie decyzje.
4. Zapis: nowy dokument w folderze kandydata lub wpis w ATS — Traffit i eRecruiter mają API/integracje; jeśli twój ATS nie ma, wyślij notatkę mailem na adres-skrzynkę ATS-a.
5. Dystrybucja: e-mail do hiring managera z notatką w treści i linkiem do pełnego transkryptu.

Potrzebne konta: narzędzie transkrypcji z webhookiem lub Drive/SharePoint, Make, API LLM, ATS lub Docs. Czas budowy: 1,5–2 h. Koszt miesięczny: transkrypcja wg własnego planu (moduł 05); sam scenariusz — przy 30 rozmowach ~150 operacji + ~5–10 zł API (transkrypt godzinnej rozmowy to ~8–12 tys. tokenów).

Jesteś asystentem rekrutera. Na podstawie transkryptu rozmowy rekrutacyjnej przygotuj notatkę dla hiring managera, który NIE był na rozmowie i ma 3 minuty na jej przeczytanie.

Kontekst:
- Stanowisko: Kierownik regionalny sprzedaży, region południowy
- Etap: pierwsza rozmowa z rekruterem, 45 min
- Kluczowe kryteria do pokrycia: zarządzanie zespołem 5+ osób, wyniki sprzedażowe B2B, gotowość do delegacji 2 dni/tydz.

Struktura notatki (dokładnie te nagłówki):
**TL;DR** — 3 zdania: kim jest kandydat, najmocniejsza strona, największa wątpliwość.
**Fakty ustalone** — wypunktowane, tylko to, co kandydat POWIEDZIAŁ (liczby, daty, nazwy), bez interpretacji.
**Kryteria vs rozmowa** — dla każdego kryterium z kontekstu: pokryte / częściowo / niepokryte + cytat z transkryptu jako dowód.
**Do weryfikacji** — maks. 4 punkty: co wymaga sprawdzenia na kolejnym etapie lub w referencjach (niejasności, sprzeczności, tematy ominięte).
**Pytania kandydata** — o co pytał kandydat (to informacja o jego motywacji).
**Następny krok** — co ustalono na koniec rozmowy.

Zasady twarde:
- Każde twierdzenie o kompetencji podpieraj cytatem lub parafrazą z transkryptu. Zero informacji spoza transkryptu.
- NIE oceniaj kandydata słowami „dobry/słaby", nie wystawiaj not — opisuj dowody, ocenę zostaw ludziom.
- Pomijaj small talk i dygresje. Nie komentuj sposobu mówienia, akcentu ani cech osobistych.
- Jeśli transkrypt jest ucięty lub niskiej jakości, zaznacz to na początku notatki.

Transkrypt:
{{treść transkryptu z poprzedniego kroku}}

Workflow 3 · Publikacja ogłoszenia: jeden opis, wszystkie kanały

1. Trigger: nowy wiersz w arkuszu „Ogłoszenia do przygotowania" (kolumny: stanowisko, lokalizacja, widełki, wymagania, o zespole, link do pełnego JD).
2. Krok LLM: prompt „Warianty ogłoszenia" (poniżej) — jeden strzał generuje wszystkie wersje.
3. Zapis: „Google Docs: Create a Document" — jeden dokument z wszystkimi wariantami, nazwany datą i stanowiskiem.
4. Powiadomienie: e-mail lub wiadomość na Slacku do ciebie z linkiem: „szkice gotowe do redakcji".

Potrzebne konta: Make, Sheets, Docs, API LLM. Czas budowy: 1–1,5 h. Koszt miesięczny: pomijalny — nawet 20 ogłoszeń to ~80 operacji i grosze za API.

Jesteś copywriterem rekrutacyjnym znającym polski rynek pracy. Na podstawie opisu stanowiska przygotuj komplet tekstów publikacyjnych. Piszesz po polsku, konkretnie, bez frazesów typu „młody dynamiczny zespół" i „konkurencyjne wynagrodzenie".

Dane stanowiska:
- Stanowisko: Specjalista ds. kadr i płac
- Firma i branża: firma produkcyjna, 400 osób, Wielkopolska
- Lokalizacja i tryb: Poznań, hybrydowo 3/2
- Widełki brutto: 7 500 – 9 500 zł
- Pełny opis wymagań i zadań: {{kolumna „wymagania" + „zadania" z arkusza}}

Wygeneruj DOKŁADNIE pięć sekcji, każdą zaczynając nagłówkiem w linii: === NAZWA ===

=== PRACUJ.PL ===
Klasyczna struktura: krótki lead o firmie (2 zdania), zakres obowiązków (maks. 7 punktów), wymagania (maks. 6, rozdziel twarde od mile widzianych), oferujemy (konkrety, nie „owocowe czwartki"). Do 300 słów.

=== LINKEDIN (ogłoszenie) ===
Wersja skrócona, do 150 słów, pierwsza linijka musi zatrzymać scroll — bez „poszukujemy kandydata na stanowisko". Widełki jawnie.

=== NO FLUFF JOBS ===
Styl NFJ: zero lania wody, sekcje „Musisz mieć" / „Mile widziane" / „Zadania na tym stanowisku" jako krótkie listy, widełki OBOWIĄZKOWO na początku. Jeśli stanowisko nie jest z IT, zachowaj ten sam bezpośredni styl.

=== POST — PROFIL REKRUTERA ===
Post na mój prywatny LinkedIn, 1. osoba, maks. 120 słów: dlaczego ta rola jest ciekawa, dla kogo, widełki, zaproszenie do wiadomości prywatnej. Ton: człowiek, nie dział HR. Bez hashtagów-spamu (maks. 3).

=== POST — PROFIL FIRMOWY ===
Krótszy, 80 słów, w tonie marki pracodawcy, z widełkami i CTA do aplikowania.

Zasady wspólne:
- Zero sformułowań dyskryminujących (wiek, płeć, „native speaker").
- Widełki zawsze jawne — to standard rynku w 2026 i wymóg dyrektywy o jawności wynagrodzeń.
- Nie wymyślaj benefitów ani faktów o firmie, których nie ma w danych wejściowych.

Workflow 4 · Strażnik SLA: żaden kandydat nie czeka bez odpowiedzi

1. Trigger: harmonogram — codziennie o 8:00 w dni robocze.
2. Odczyt: „Google Sheets: Search Rows" w rejestrze kandydatów (ten sam arkusz, który zasila workflow 1; kluczowa kolumna: data_ostatniego_kontaktu).
3. Filtr: status ≠ „zakończony" ORAZ dziś − data_ostatniego_kontaktu > 5 dniBadania candidate experience pokazują od lat to samo: głównym powodem porzucania procesu jest cisza. Po ~10 dniach bez kontaktu duża część kandydatów uznaje proces za zakończony i przyjmuje inne oferty. Próg 5 dni daje ci margines, żeby zareagować, zanim to się stanie. Uwaga: alert dostajesz TY, nie kandydat — wiadomość do człowieka piszesz sam, z empatią, której automat nie udźwignie..
4. Agregacja: moduł „Aggregator" skleja wszystkich czekających w jedną listę (jeden alert dziennie, nie dziesięć).
5. Alert: wiadomość na Slack/Teams do zespołu; opcjonalny krok LLM formatujący listę (prompt niżej).

Potrzebne konta: Make, Sheets (lub ATS z API), Slack/Teams. Czas budowy: ~1 h. Koszt miesięczny: 0 zł — ~22 uruchomienia × 3–4 operacje mieszczą się w każdym darmowym planie.

Jesteś asystentem zespołu rekrutacji. Z poniższej listy kandydatów czekających na odpowiedź przygotuj jedną zwięzłą wiadomość na kanał zespołu na Slack.

Format wiadomości:
1. Pierwsza linia: „⏰ SLA: X kandydatów czeka dłużej niż 5 dni" (X policz z danych).
2. Potem grupuj po rekruterze prowadzącym. Dla każdego rekrutera lista: identyfikator kandydata — stanowisko — liczba dni ciszy — ostatni etap.
3. Sortuj wewnątrz grup malejąco po liczbie dni.
4. Kandydatów czekających powyżej 10 dni oznacz na początku linii: „🔴".
5. Ostatnia linia: „Odpisz dziś albo zmień status w rejestrze."

Zasady:
- Używaj identyfikatorów z danych (np. numer wiersza lub ID), NIE imion i nazwisk — wiadomość idzie na wspólny kanał.
- Żadnych ocen ani komentarzy o kandydatach. Tylko fakty z danych.
- Jeśli lista jest pusta, zwróć dokładnie: „✅ SLA czyste — nikt nie czeka dłużej niż 5 dni."

Dane (wiersze z rejestru):
{{zagregowane wiersze z kroku filtrowania}}

Workflow 5 · Piątkowy raport lejka bez otwierania arkusza

1. Trigger: harmonogram — piątek 15:00.
2. Dane: odczyt zakładki „Lejek" (per rekrutacja: aplikacje, po selekcji, po 1. rozmowie, oferty, przyjęte oferty, dni od otwarcia). Liczby agreguj formułami w arkuszu — LLM ma je dostać policzonePułapka: modele językowe słabo i niepowtarzalnie liczą. Nie każ LLM sumować kolumn — od tego są formuły i tabele przestawne. LLM dostaje gotowe liczby i robi to, w czym jest dobry: zamienia tabelę w trzy akapity, które chce się przeczytać, i wskazuje anomalie..
3. Krok LLM: prompt „Piątkowy raport lejka" (poniżej).
4. Wysyłka: wiadomość na kanał zespołu + kopia mailem do szefa HR.

Potrzebne konta: Make, Sheets, API LLM, Slack/Teams. Czas budowy: 1–1,5 h (najwięcej zajmie uporządkowanie arkusza). Koszt miesięczny: ~4 uruchomienia — poniżej 1 zł.

Jesteś analitykiem rekrutacji. Co piątek podsumowujesz stan lejka rekrutacyjnego dla zespołu HR firmy X (5 rekruterów, ~12 otwartych rekrutacji). Odbiorcy znają procesy — nie tłumacz pojęć.

Dane wejściowe: tabela per rekrutacja z kolumnami: stanowisko, rekruter, dni od otwarcia, nowe aplikacje (7 dni), w selekcji, po 1. rozmowie, finał, oferty, oferty przyjęte, uwagi.

Napisz raport w formacie:
**Lejek — tydzień {{numer tygodnia / zakres dat}}**
1. „W skrócie" — 3 zdania: ogólny puls tygodnia (ruch w lejku, co domknięte, co utknęło).
2. „Wymaga uwagi" — maks. 4 punkty: rekrutacje bez ruchu, wąskie gardła (np. dużo aplikacji, zero rozmów), procesy powyżej 45 dni. Przy każdym: co konkretnie zrobić w przyszłym tygodniu.
3. „Dobre wieści" — maks. 3 punkty: przyjęte oferty, domknięte etapy, wyraźne przyspieszenia.
4. „Liczby tygodnia" — tabela: stanowisko | nowe aplikacje | rozmowy | oferty | dni od otwarcia.

Zasady:
- Używaj WYŁĄCZNIE liczb z danych wejściowych. Niczego nie dolicz, nie szacuj, nie uśredniaj samodzielnie.
- Jeśli w danych czegoś brakuje, napisz „brak danych", zamiast zgadywać.
- Ton: rzeczowy, kolegialny, zero korpomowy. Całość do 250 słów + tabela.
- Nie wymieniaj nazwisk kandydatów — tylko stanowiska i etapy.

Dane:
{{wiersze z arkusza „Lejek"}}

Prompty do budowania scenariuszy

Dwa prompty-narzędzia, które nie żyją w środku workflow, tylko pomagają ci go zaprojektować i zbudować. Pierwszy zamienia opis twojego procesu w blueprint gotowy do klikania. Drugi generuje opisy kroków do wklejenia wprost w Make lub n8n, gdy utkniesz przy konfiguracji.

Jesteś architektem automatyzacji specjalizującym się w procesach HR i rekrutacji. Pomagasz rekruterowi bez doświadczenia technicznego zamienić ręczny proces w scenariusz w narzędziu Make.

Mój proces (opisuję własnymi słowami):
Gdy kandydat wypełni formularz na naszej stronie, dostaję maila. Otwieram CV, przepisuję dane do Excela, oceniam czy pasuje, i jak pasuje, to piszę na Teams do rekrutera prowadzącego.

Narzędzia, które mamy w firmie: Microsoft 365 (Outlook, Teams, Excel), formularz na WordPressie, budżet do 100 zł/mies.

Zanim zaprojektujesz scenariusz, zadaj mi maksymalnie 5 pytań doprecyzowujących (wolumen miesięczny, wyjątki, kto jest właścicielem procesu, jakie dane osobowe płyną, co ma się dziać przy błędzie). Poczekaj na odpowiedzi.

Dopiero potem zwróć blueprint w formacie:
1. **Trigger** — konkretny moduł i jego konfiguracja.
2. **Kroki** — ponumerowana lista: nazwa modułu w Make, co robi, jakie pola mapuje z kroków poprzednich.
3. **Krok LLM** (jeśli potrzebny) — model, temperatura, szkic promptu, format wyjścia.
4. **Obsługa błędów** — co się dzieje, gdy krok padnie (powtórka? mail do mnie?).
5. **Dane osobowe** — które kroki przetwarzają dane kandydata, co zanonimizować przed krokiem LLM, gdzie ograniczyć retencję logów.
6. **Szacunek** — liczba operacji miesięcznie, koszt, czas budowy.
7. **Test** — 3 przypadki testowe, w tym jeden brzegowy (np. mail bez załącznika).

Zasady: proponuj najprostszą wersję, która działa (bez rozgałęzień „na przyszłość"); jeśli proces słabo nadaje się do automatyzacji (niski wolumen, dużo wyjątków, komunikacja wymagająca empatii) — powiedz to wprost i zaproponuj, którą CZĘŚĆ zautomatyzować.

Jesteś ekspertem od narzędzia Make (make.com). Prowadzisz mnie za rękę przez konfigurację JEDNEGO kroku scenariusza. Zakładaj, że nie znam żargonu narzędzia.

Buduję scenariusz: nowa aplikacja z maila → parsowanie CV przez LLM → wiersz w Google Sheets → powiadomienie na Slacku.

Utknąłem na kroku: wywołanie API Anthropic przez moduł HTTP i przekazanie tekstu CV z poprzedniego kroku.

Komunikat błędu lub objaw (jeśli jest): dostaję 401 unauthorized / wynik kroku jest pusty.

Odpowiedz w formacie:
1. **Diagnoza** — co najpewniej jest nie tak (1–2 zdania).
2. **Konfiguracja pole po polu** — dokładna lista: nazwa pola w interfejsie → co wpisać. Przy module HTTP podaj: metodę, URL, nagłówki (z zaznaczeniem, gdzie wkleić klucz API), body z przykładowym JSON-em i miejscem na zmienną z poprzedniego kroku.
3. **Jak to przetestować** — jak uruchomić pojedynczy krok na danych testowych i po czym poznać sukces.
4. **Typowe pułapki** — maks. 3, specyficzne dla tego kroku.

Zasady: podawaj nazwy modułów i pól dokładnie tak, jak brzmią w interfejsie Make; jeśli czegoś nie wiesz na pewno (np. zmieniony interfejs), zaznacz to zamiast zgadywać; nigdy nie proś mnie o wklejenie prawdziwego klucza API do czatu.

Trzeci szablon do zabrania: karta automatyzacji. Wypełniasz ją PRZED budowaniem — na warsztacie zrobimy to w ćwiczeniu. Karta jest też twoim dokumentem dla działu prawnego i IT: jedna strona, z której widać, co płynie, dokąd i po co.

Kiedy NIE automatyzować

Automatyzacja ma koszt stały: budowa, doglądanie, naprawianie po zmianach w API. Ten koszt musi się zwrócić — a zwraca się tylko na wolumenie i powtarzalności. Nie automatyzuj, gdy:

• Wolumen jest niski. Proces, który dzieje się kilka razy w miesiącu (np. rekrutacja na stanowisko Head of Finance raz na kwartał), robisz ręcznie — 2 h budowy scenariusza nigdy się nie zwróci, a scenariusz zdąży „zgnić", zanim odpali się trzeci razProsty próg opłacalności: (minuty na jedno wykonanie × wykonania miesięcznie) powinno być większe niż ~120, żeby automatyzacja zwróciła się w kwartał. 10 CV miesięcznie × 6 min = 60 — za mało. 60 CV × 6 min = 360 — buduj natychmiast..
• Przypadki brzegowe rządzą procesem. CV w formie grafiki, portfolio na Behance, kandydat z polecenia zarządu, aplikacja w trzech mailach — jeśli wyjątki to 30% ruchu, automat będzie częściej psuł, niż pomagał. Zautomatyzuj szczęśliwą ścieżkę, wyjątki kieruj filtrem do człowieka.
• Komunikacja wymaga empatii. Odmowa po finałowym etapie, negocjacje oferty, odpowiedź kandydatowi, który napisał o trudnej sytuacji życiowej — to wiadomości, które MUSI napisać człowiek. Automat może ci je co najwyżej podsunąć do napisania (jak strażnik SLA), nigdy wysłać za ciebie.
• Proces zmienia się co miesiąc. Najpierw ustabilizuj proces na ludziach, potem go zamrażaj w automacie. Automatyzacja chaosu daje szybszy chaos.
• Nikt nie jest właścicielem. Scenariusz bez właściciela po pół roku wysyła alerty, których nikt nie czyta, do kanału, którego nikt nie otwiera. Jedna osoba odpowiada za każdy workflow — z imienia i nazwiska.

RODO w przepływach danych

W momencie, gdy scenariusz rusza, dane kandydata zaczynają płynąć przez kilka systemów naraz — i za każdy z nich odpowiadasz ty jako administratorPrześledź jeden przebieg workflow 1: CV leży (1) na serwerze pocztowym, (2) w logach Make — domyślnie z pełną treścią przetwarzanych danych!, (3) w API dostawcy LLM, (4) w Google Sheets, (5) we fragmencie na Slacku. Pięć miejsc, pięć polityk retencji. Minimum: skróć retencję logów w ustawieniach scenariusza, wybierz region UE, podpisz DPA z każdym dostawcą i dopisz przepływ do rejestru czynności przetwarzania.. Zanim uruchomisz scenariusz na prawdziwych kandydatach, przejdź te cztery punkty z osobą odpowiedzialną za ochronę danych:

• Umowy powierzenia (DPA). Make, Zapier, dostawca LLM, Google — każdy z nich przetwarza dane w twoim imieniu. Wszyscy duzi dostawcy mają standardowe DPA do zaakceptowania w panelu; zrób to świadomie, nie „domyślnie".
• Region i retencja. Wybieraj centra danych w UE tam, gdzie się da (Make i Power Automate dają wybór). W ustawieniach scenariusza skróć przechowywanie logów do minimum — logi Make domyślnie zawierają pełną treść przetwarzanych danych.
• Minimalizacja przed krokiem LLM. Do API modelu wysyłaj tylko to, co potrzebne do zadania. Prompt „Ekstraktor CV → JSON" celowo pomija dane kontaktowe — imię i nazwisko nie poprawia scoringu, a tworzy ryzyko. Najlepiej: krok anonimizacji PRZED krokiem LLM.
• Prawa kandydata dalej działają. Prośba o usunięcie danych musi objąć też wiersze w arkuszu, dokumenty z notatkami i logi scenariuszy. Dlatego klasyfikator z workflow 1 oznacza takie prośby flagą „wymaga_czlowieka" — i dlatego rejestr kandydatów trzymasz w jednym miejscu, nie w siedmiu.

Ćwiczenie: blueprint twojej pierwszej automatyzacji

Wdrożenie w poniedziałek

Osiem kroków na pierwszy tydzień po warsztacie. Kolejność jest celowa: najpierw fundament i zgody, potem najprostszy scenariusz, na końcu ten z LLM. Twój postęp:

• Poniedziałek: załóż darmowe konto Make (lub potwierdź z IT, że stawiacie n8n / używacie Power Automate) i przeklikaj jeden gotowy szablon, żeby oswoić interfejs.
• Poniedziałek: załóż klucz API (Anthropic lub OpenAI) na firmowy e-mail i ustaw miesięczny limit wydatków, np. 50 zł.
• Wtorek: uporządkuj rejestr kandydatów w arkuszu — kolumny ze schematu JSON z tego modułu plus „status", „rekruter", „data_ostatniego_kontaktu".
• Wtorek: zbuduj workflow 4 (strażnik SLA) — godzina pracy, zero LLM, natychmiastowy efekt.
• Środa: wyślij osobie odpowiedzialnej za ochronę danych kartę automatyzacji workflow 1 z wypełnionym wierszem „Dane osobowe" i poproś o zielone światło.
• Czwartek: zbuduj workflow 1 i przetestuj na 5 CV testowych (własne stare CV, CV znajomych za zgodą) — sprawdź każdy wiersz w arkuszu ręcznie.
• Piątek: uruchom workflow 5 (raport lejka) i porównaj jego pierwszy raport z tym, co sam wiesz o lejku — rozjazdy to błędy w danych arkusza, napraw je u źródła.
• Cały tydzień: prowadź licznik minut zaoszczędzonych przez automaty; po miesiącu pokaż wynik szefowi — to twój argument o budżet na płatny plan.