O projekcie
Automatyzacja stojąca między wpływem zamówień a zespołem handlowym. Każde zamówienie — niezależnie od tego, czy przyszło mailem, PDF-em, ze sklepu czy z formularza — dostaje właściciela w kilka sekund, a każdy przydział potrafi powiedzieć, która reguła go wydała i na jakich danych.
Trudność nie leży tam, gdzie się jej szuka. Reguła nie brzmi „rejon”. W realnej firmie kolejność jest inna: opieka nad klientem bije rejon, bo klient nie zmienia handlowca przez przeprowadzkę magazynu; próg wolumenu bije opiekę, bo duże zamówienie idzie do handlowca od kluczowych klientów; urlop przekierowuje do zastępcy; a zamówienie, które nie pasuje do niczego, musi trafić do nazwanej kolejki, nie donikąd. Spisane, to jest pięć reguł. Przed wdrożeniem żyły w jednej głowie i w arkuszu — więc to samo zamówienie trafiało do dwóch różnych handlowców w zależności od tego, kto pierwszy otworzył skrzynkę.
Zbieranie jest najbrudniejszym odcinkiem, bo zamówienie bywa treścią maila, załącznikiem PDF, arkuszem od klienta albo pozycją ze sklepu. Model pracuje wyłącznie na tej krawędzi: zamienia dokument w pola. O tym, kto dostanie zamówienie, nie decyduje ani w jednym kroku — i to jest granica wpisana w architekturę, nie obietnica w instrukcji.
Klient jest rozpoznawany po NIP-ie, nie po zapisie nazwy. „P.H.U. Kowalski” i „PHU Kowalski sp. z o.o.” to jeden płatnik i dwa różne napisy; dopasowywanie po nazwie po cichu rozcinało historię jednego klienta na dwóch opiekunów. Adresy dostawy w kilku województwach też należą do jednego płatnika, więc rejon czytany jest od płatnika, dopóki reguła nie każe inaczej.
Sam przydział jest deterministyczny i to jest w nim najważniejsze. Łańcuch reguł ma ustaloną kolejność, pierwsza pasująca wydaje decyzję i zostaje zapisana razem z wejściem, na którym zadziałała. To samo zamówienie zawsze kończy się tym samym handlowcem — a handlowiec, zamiast ufać, może sprawdzić. Dopóki nie mógł, trzymał własny arkusz obok systemu, co jest dokładnie tym stanem, do którego automatyzacja miała nie dopuścić.
Zamówienie bez dopasowania nie znika: ląduje w nazwanej kolejce z terminem i eskalacją. Ten sam dziennik, który odpowiada handlowcowi na pytanie „dlaczego ja”, jest przy okazji raportem dla zarządu — pokazuje przeciążone rejony, klientów bez opiekuna i to, ile zamówień wymagało ręcznego rozstrzygnięcia oraz z jakiego powodu.
Problem
Każde zamówienie musi mieć właściciela, a reguła nie brzmi „rejon”: opieka nad klientem bije rejon, próg wolumenu bije opiekę, urlop przekierowuje do zastępcy. Ta wiedza żyła w jednej głowie i w arkuszu, więc to samo zamówienie trafiało do dwóch różnych handlowców zależnie od tego, kto pierwszy otworzył skrzynkę.
Rozwiązanie
Uporządkowany łańcuch reguł zamiast wiedzy plemiennej: pierwsza pasująca reguła wydaje przydział i zostawia w dzienniku ślad, która to była i na czym zadziałała. To samo zamówienie zawsze kończy się tym samym handlowcem, a handlowiec dostaje odpowiedź na pytanie „dlaczego ja”.
Funkcje
- zamówienie z maila, PDF-a, arkusza, sklepu i formularza w jednym kształcie
- klient rozpoznawany po NIP-ie, nie po zapisie nazwy firmy
- opieka nad klientem ma pierwszeństwo przed rejonem — tak jak w praktyce
- próg wolumenu przenosi zamówienie do handlowca od kluczowych klientów
- urlop i zwolnienie przekierowują do zastępcy bez ręcznej podmianki
- zamówienie bez dopasowania ląduje w nazwanej kolejce z terminem, nie w próżni
- handlowiec widzi, która reguła wydała przydział i na jakich danych
- zmiana opiekuna zostawia ślad — żadnego cichego przepisania
Moduły
zam-kolektor
warstwa wejściaSprowadza zamówienia ze wszystkich kanałów do jednego kształtu i rozpoznaje płatnika.
- skrzynka, załączniki PDF i arkusze, zamówienia ze sklepu i formularza w jednym schemacie
- odczyt dokumentu do pól — jedyne miejsce w całym potoku, w którym pracuje model
- dopasowanie płatnika po NIP-ie; nazwa firmy służy wyłącznie podpowiedzi przy ręcznym rozstrzyganiu
- rejon czytany od płatnika, nie od adresu dostawy — jeden klient bywa w kilku województwach
- to samo zamówienie wczytane dwa razy nie tworzy drugiego zgłoszenia
zam-przydzial
silnik regułUporządkowany łańcuch reguł: pierwsza pasująca wydaje przydział i zostaje zapisana.
- kolejność reguł jest danymi, nie kodem — zmiana polityki nie wymaga wdrożenia
- opieka nad klientem, próg wolumenu, rejon, zastępstwo, kolejka wyjątków — w tej kolejności
- kalendarz nieobecności przekierowuje do zastępcy na czas urlopu i zwolnienia
- wynik jest deterministyczny: to samo wejście zawsze daje ten sam przydział
- brak pasującej reguły to nazwana kolejka z terminem i eskalacją, nie najbliższy handlowiec
zam-przekazanie
warstwa wydaniaDowozi przydział do handlowca i do CRM-u, razem z uzasadnieniem decyzji.
- powiadomienie z kompletem danych zamówienia, a nie z samym odnośnikiem do systemu
- zapis do CRM-u pod właściwym opiekunem, z numerem zamówienia jako kluczem
- odpowiedź „dlaczego ja”: wydana reguła, wejście i moment decyzji przy każdym przydziale
- zmiana opiekuna dopisuje wpis do dziennika — poprzedni przydział nie znika
- dziennik jako raport: przeciążone rejony, klienci bez opiekuna, ręczne rozstrzygnięcia
Architektura
- Podstawa
- przepływy w n8n hostowanym u klienta — zamówienia i NIP-y nie wychodzą poza jego infrastrukturę
- Silnik reguł
- uporządkowany łańcuch; pierwsza pasująca reguła wydaje przydział i zostaje zapisana z wejściem
- Polityka jako dane
- progi, rejony i kolejność reguł w bazie, nie w kodzie — zmiana nie wymaga wdrożenia
- Dane
- PostgreSQL: rejestr opieki, progi wolumenu, kalendarz nieobecności i dziennik przydziałów
- Rozpoznanie klienta
- klucz po NIP-ie; nazwa firmy wyłącznie jako podpowiedź przy ręcznym rozstrzyganiu
- Rola modelu
- wyłącznie odczyt dokumentu do pól; o przydziale nie decyduje w żadnym kroku
- Idempotencja
- to samo zamówienie przetworzone dwa razy nie tworzy drugiego przydziału ani drugiego wpisu w CRM
- Integracje
- skrzynka pocztowa, REST API sklepu, CRM handlowców, powiadomienia zespołu
- Audyt
- każdy przydział zapisany z wejściem, wydaną regułą i czasem — decyzję da się odtworzyć po miesiącach
Technologie
- n8n
- PostgreSQL
- TypeScript
- Claude
- REST API
Autor
Mariusz PerzyńskiClient Relations & Operations