Klient: hurtownia materiałów budowlanych, 60 pracowników, około 1400 zamówień miesięcznie od stałych odbiorców. Zamówienia wpływały trzema kanałami: mailem (PDF, Excel, treść wiadomości), przez formularz na stronie i telefonicznie.
Sytuacja wyjściowa
Czteroosobowy zespół obsługi klienta przepisywał zamówienia do systemu ERP. Średni czas jednego zamówienia: 7 minut przy prostym dokumencie, do 20 minut przy zamówieniu z kilkunastoma pozycjami i nietypowymi indeksami.
Miesięcznie dawało to około 210 godzin - ponad 1,2 etatu wyłącznie na przepisywanie. Do tego dochodziły błędy: średnio 15-20 pomyłek w indeksach lub ilościach na miesiąc, z czego część wychodziła dopiero na magazynie.
Pierwsze podejście, które nie zadziałało
Zaczęliśmy klasycznie: OCR na załącznikach plus reguły wyciągające pozycje z tabel. Skuteczność na dokumentach od trzech największych odbiorców przekroczyła 90%, ale na całej reszcie spadła poniżej 50%. Powód: każdy odbiorca miał inny układ tabeli, inne nazewnictwo, a część wysyłała zamówienia w treści wiadomości bez żadnej struktury.
Budowanie osobnego zestawu reguł dla każdego z 80 odbiorców nie miało sensu ekonomicznego.
Rozwiązanie docelowe
Architektura
- Odbiór: dedykowana skrzynka, przepływ w n8n pobierający wiadomości i załączniki.
- Rozpoznanie treści: model językowy z instrukcją zwracającą ustrukturyzowany JSON - niezależnie od tego, czy zamówienie jest w PDF-ie, arkuszu, czy w treści maila.
- Dopasowanie indeksów: wyszukiwanie w katalogu produktów po nazwie i kodzie, z uwzględnieniem historii zamówień danego odbiorcy.
- Walidacja: reguły sprawdzające istnienie indeksu, dostępność, limit kredytu kupieckiego i zgodność jednostek miary.
- Zapis: utworzenie zamówienia w ERP przez API, z identyfikatorem źródłowej wiadomości.
Kluczowa decyzja: próg pewności
Zamówienie trafia do ERP automatycznie tylko wtedy, gdy wszystkie pozycje zostały dopasowane jednoznacznie, a walidacje przeszły bez ostrzeżeń. W przeciwnym razie ląduje w panelu weryfikacji, gdzie pracownik widzi oryginał obok odczytanych danych i poprawia wyłącznie sporne pozycje.
Problemy napotkane po drodze
Najwięcej pracy kosztowały indeksy "własne" odbiorców. Część klientów zamawia po swoich numerach katalogowych, więc powstała tabela mapowań - budowana na podstawie historii i uzupełniana przy każdej ręcznej korekcie. Doszły do tego zamówienia zbiorcze: jedna wiadomość z pozycjami na trzy oddziały, którą przepływ musiał umieć rozdzielić.
Dwa pozostałe problemy rozwiązano decyzją, nie kodem. Odbiorcy wpisywali ceny z nieaktualnych ofert, więc ustalono, że rozbieżność cenowa zawsze wstrzymuje zamówienie do weryfikacji. A kiedy przy porannym szczycie ERP zaczął odrzucać część zapytań, dołożono kolejkę z ponawianiem.
Wyniki po pięciu miesiącach
| Wskaźnik | Przed | Po |
|---|---|---|
| Zamówienia bez udziału człowieka | 0% | 78% |
| Średni czas wprowadzenia | 9 min | 50 s (tylko wyjątki) |
| Czas pracy miesięcznie | 210 h | 46 h |
| Błędy w indeksach/ilościach | 15-20 | 2-4 |
| Czas reakcji na zamówienie | 40 min - 4 h | poniżej 5 min |
Zespół obsługi klienta nie został zredukowany. Dwie osoby przeszły do obsługi zapytań ofertowych, których wcześniej nie nadążano obrabiać - to przełożyło się na wzrost liczby wycen wysyłanych w tym samym dniu.
Najczęstsze pytania
Jedenaście tygodni od pierwszego warsztatu do przełączenia na produkcję, w tym trzy tygodnie pracy równoległej, gdy automat pracował obok zespołu, a wyniki były porównywane.
Pozostały poza zakresem automatyzacji. Stanowiły około 12% wolumenu i zdecydowano, że rozmowa z klientem jest tu wartością, a nie kosztem.
Macie u siebie podobny proces?
Opisz go w dyskusji pod tekstem. Chętnie porównamy liczby i wskażemy miejsca, w których to wdrożenie mogłoby wyglądać inaczej.
Dołącz do dyskusji
