Krótka odpowiedź. Europejska firma B2B prowadziła operacje ręcznie. Każde zamówienie, każde pytanie sprzedażowe i każdy nowy partner wymagały człowieka. Nie wymieniliśmy jej systemów. Nałożyliśmy na nie warstwę operacyjną w n8n, a Slack został jedynym interfejsem. Dziesięć procesów działa dziś produkcyjnie. Ukształtowały je cztery zasady: pracuj tam, gdzie ludzie już są, przy pieniądzach przycisk klika człowiek, sprawdzaj każdą akcję po wykonaniu i spraw, by każda awaria była widoczna.
To prawdziwy projekt dla klienta. Klient pozostaje anonimowy, więc liczby zostały zmienione ze względu na poufność. Proporcje są prawdziwe.
Jaki był problem?
Firma sprzedaje klientom biznesowym w całej Europie. Jej klienci wybierają dostawcę, który dowozi na czas i w komplecie. Klient zbiera zamówienia przez cały dzień i oczekuje jednej dostawy o stałej godzinie, więc każde opóźnienie po stronie naszego klienta łamie obietnicę, jaką ten klient złożył własnym odbiorcom.
Za tą obietnicą stała praca ręczna:
- Ktoś informował magazyn o każdym zamówieniu i wyliczał dzień wysyłki.
- Ktoś zmieniał statusy zamówień ręcznie.
- Przed każdą ustaloną godziną kompletacji ktoś sprawdzał każde otwarte zamówienie linia po linii.
- Pytania sprzedażowe trafiały wciąż do tych samych członków zespołu deweloperskiego. Każda odpowiedź wymagała ręcznego sprawdzenia kilku systemów: powtarzalna praca, która odrywała ich od rozwijania produktu.
Wzrost ograniczała liczba rzeczy, które mogło zrobić kilka osób. Gdy jednej z nich brakowało, praca czekała.
Dlaczego budować na istniejących systemach?
Główne systemy działały. Ich wymiana trwałaby długo, a w międzyczasie nic nie przestałoby się psuć. Cykle wydawnicze tych systemów były też wolne, więc czekanie na nowe funkcje w nich nie wchodziło w grę.
Połączyliśmy więc to, co już było: systemy zamówień i magazynu, dane klientów, narzędzia finansów i compliance oraz system do śledzenia projektów. n8n uruchamia workflow. W Slacku ludzie widzą wyniki i naciskają przyciski.
Które procesy zautomatyzowaliśmy?
Dziesięć procesów dzieli się na trzy grupy.
Zamówienia: od zamówienia do magazynu
- Natychmiastowa wiadomość do magazynu. Nowe zamówienie trafia do magazynu na Slacku w chwili utworzenia, z ustawionym już priorytetem i dniem wysyłki. Każde zamówienie ma ustaloną godzinę kompletacji, a ta godzina razem z wielkością zamówienia decyduje o dniu wysyłki.
- Obsługa ekspresowa. Zamówienia ekspresowe powiadamiają zespoły, które muszą zadziałać. Zwykłe zamówienia idą standardową ścieżką bez dodatkowych wiadomości.
- Zaufani klienci. Co godzinę zamówienia zatwierdzonych klientów z odroczonym terminem płatności trafiają do realizacji bez czekania na człowieka.
- Sprzątanie zamówień testowych. Co wieczór zamówienia z kont testowych są anulowane, dzięki czemu znikają z kolejki magazynu i z raportów sprzedaży.
- Brakujące linie zamówienia. Co godzinę przed kompletacją otwarte zamówienia są porównywane z tym, co klient faktycznie wysłał (patrz niżej).
Pytania sprzedażowe i sprawdzanie statusów
- Bot sprzedażowy na Slacku. Czyta pytanie zapisane zwykłymi słowami i sam sprawdza status w różnych działach: compliance, finanse (na przykład weryfikację VAT), zamówienia i stan magazynowy. Akcje z konsekwencjami uruchamia przycisk, a wynik jest sprawdzany po fakcie.
- Cotygodniowa lista statusów. Co tydzień sprzedaż dostaje klientów, którzy wciąż czekają na decyzję innego działu, żeby nikt nie czekał w ciszy.
Partnerzy i raportowanie
- Wdrożenie partnera w jednym wątku. Menedżer wpisuje identyfikator klienta i wybiera typ połączenia. System zakłada partnera we wszystkich potrzebnych systemach, prosi o wymagane dostępy i odpowiada w wątku.
- Codzienne kontrole partnerów. Otwarte kroki konfiguracji są monitorowane, aż partner zostanie w pełni podłączony.
- Raportowanie. Cotygodniowe liczby zamówień partnerów, przypomnienia o raportach oraz statusy roadmapy zbierane automatycznie z pracy wykonanej w innych projektach i systemach.
Jak jeden proces działa od początku do końca?
Najlepiej pokazuje to kontrola brakujących linii zamówienia.
Kluczowi klienci przez cały dzień dodają linie do jednego otwartego zamówienia przez API. W ustalonej godzinie kompletacji zamówienie jest zamykane i trafia do kompletowania. Czasem jakaś linia nie dotarła do zamówienia, a klient dowiadywał się o tym z reklamacji.
Teraz wygląda to tak:
- Kontrola co godzinę. W godzinach przed kompletacją każda linia dodana przez klienta przez API jest porównywana z liniami faktycznie obecnymi w zamówieniu.
- Ponowny odczyt przed alertem. Rozbieżność jest czytana ponownie z pierwotnego źródła po krótkim oczekiwaniu. Jedno ze źródeł danych raz się spóźniło i zbyt wczesny alert podwoiłby linie.
- Alert do menedżera. Slack pokazuje „Brakuje 4 linii w tym zamówieniu” z dwoma przyciskami: „Dodaj 4 linie” i „Poprawione ręcznie”.
- Jedno kliknięcie. Menedżer klika „Dodaj 4 linie”. System dodaje je, odczytuje zamówienie ponownie i potwierdza. Przycisk zamienia się w „Wszystkie linie dodane”.
- Zablokowana pozycja, jeśli jest. Jeśli pozycja jest zablokowana i nie można jej dodać, osoby, które mogą ją odblokować, są od razu wołane do wątku.
Reguła z kroku 2 wzięła się z prawdziwego fałszywego alarmu. Dziś to stała zasada w każdym workflow, który budujemy: sprawdź jeszcze raz, zanim wyślesz alert.
Jak testowaliśmy bota sprzedażowego?
Nie uruchomiliśmy bota na wyczucie. Wzięliśmy tysiące prawdziwych zapytań z historii kanału sprzedaży i ręcznie oznaczyliśmy je poprawną odpowiedzią. Każda zmiana reguł bota jest odtwarzana na całym zbiorze, zanim trafi na produkcję.
Odsetek pytań, które bot ignorował, spadł z 36% do 5%. Przy pierwszym uruchomieniu zestawienie roadmapy przeniosło 12 pozycji bez błędów i z 4 ostrzeżeniami.
Czego to nie robi?
- Wszystko, co dotyczy pieniędzy, wymaga kliknięcia człowieka: dodawanie linii zamówienia, etykiety ekspresowe, prośby o dostęp.
- Bot kieruje pytania według reguł słów kluczowych i wciąż pomija niektóre tematy. Każde pominięcie trafia do kolejnej rundy reguł.
- Przypomnienia o płatnościach i miesięczne zbieranie faktur są zbudowane i czekają na ponowne włączenie.
Co zmieniło się dla zespołu?
Menedżerowie sprzedaży pytają bota i dostają odpowiedź w kilka sekund. Deweloperzy, którzy wcześniej odpowiadali na te pytania, dostają już tylko nietypowe przypadki i zostają przy swojej pracy. To, co wiedzieli, żyje w systemie, więc zmiana osoby odpowiedzialnej nie zaczyna wszystkiego od zera.
Opiekunowie klientów działają na podstawie wiadomości w Slacku z przyciskiem, zamiast sprawdzać każde zamówienie przed kompletacją. Magazyn kompletuje z zadań, które przychodzą z ustawionym priorytetem i dniem wysyłki. Menedżerowie partnerów łączą nowego partnera w jednym wątku na Slacku, a statusów roadmapy nikt już nie przesuwa ręcznie.
Co możesz z tego wziąć dla własnych operacji?
- Wypisz przekazania, nie systemy. Marnotrawstwo siedziało między sprzedażą, magazynem i partnerami, a nie wewnątrz żadnego narzędzia.
- Postaw interfejs tam, gdzie ludzie już pracują. Dla tego zespołu był to Slack.
- Zostaw człowieka przy każdej decyzji o pieniądzach. Przycisk kosztuje kilka sekund i utrzymuje zaufanie.
- Sprawdzaj wyniki, nie tylko błędy. Najgroźniejszą awarią jest krok, który po cichu w ogóle się nie wykonał.
- Daj każdemu alertowi jednego wskazanego właściciela.
Jeśli chcesz zastosować to do własnych procesów, plan automatyzacji zadaje te same pytania i zwraca plan. Nasze projekty automatyzacji procesów biznesowych zwykle zaczynają się od jednego procesu, takiego jak kontrola zamówień powyżej.
FAQ
Dlaczego Slack, a nie nowy dashboard?
Zespół i tak cały dzień pracował w Slacku. Nowy dashboard to kolejna karta, której nikt nie otwiera. Wiadomość w Slacku z przyciskiem trafia do właściwej osoby tam, gdzie już jest, a wątek zachowuje historię tego, co się wydarzyło.
Dlaczego n8n, a nie własny kod?
n8n pozwolił szybko połączyć istniejące systemy klienta i pokazać każdy workflow osobom, które za niego odpowiadają. Ważniejsze od narzędzia są reguły. Każda jest spisana, przetestowana i ma wskazanego właściciela, więc ta sama logika może później trafić do własnego kodu, jeśli proces przerośnie narzędzie do workflow.
Jak zapobiegacie szkodom wyrządzonym przez automatyzację?
Cztery nawyki. Wszystko, co dotyczy pieniędzy, czeka na kliknięcie człowieka. Każda akcja jest sprawdzana po wykonaniu. Podejrzany wynik jest czytany ponownie z pierwotnego źródła, zanim ktokolwiek dostanie alert. Każda awaria trafia do wskazanego właściciela, nigdy na kanał, na którym wszyscy zakładają, że zajmie się nią ktoś inny.
Prawdziwy projekt klienta, klient zanonimizowany. Liczby zmienione ze względu na poufność, proporcje zachowane.