Zautomatyzowaliśmy własną obsługę zapytań. Zwrot po sześciu tygodniach
Zanim zaproponowaliśmy tę usługę komukolwiek, zbudowaliśmy ją u siebie. Pięć godzin pracy, dwa dni testów, dwanaście zgłoszeń w pierwsze dwa tygodnie. Poniżej: co dokładnie powstało, ile to zajęło, co poszło nie tak i uczciwy rachunek zwrotu.
Krótka odpowiedź
Zautomatyzowaliśmy własny proces obsługi zapytań, zanim zaproponowaliśmy taką usługę komukolwiek. Pięć godzin pracy plus dwa dni testów. Ręczna obsługa jednego zgłoszenia zabierała 6–10 minut.
W pierwsze dwa tygodnie przez system przeszło dwanaście zgłoszeń. W tym tempie nakład zwraca się po około sześciu tygodniach, a przez pierwsze dwa tygodnie odzyskaliśmy już mniej więcej jedną trzecią włożonego czasu.
W skali roku, przy tym samym ruchu, to ponad czterdzieści godzin — pełny tydzień pracy, odzyskany z czynności, które nikogo nie rozwijają.
Jak było wcześniej
Formularz na stronie wysyłał wiadomość na skrzynkę. Wszystko dalej robił człowiek:
- Odsianie spamu. Boty znajdują formularz szybciej niż klienci. Znaczna część wiadomości nie była zgłoszeniami.
- Przepisanie kontaktu do arkusza. Imię, mail, firma, treść — ręcznie, z maila do arkusza.
- Odpowiedź do klienta. Za każdym razem pisana od nowa.
- Wpisanie zadania. Przypomnienie o kontakcie, żeby zgłoszenie nie utknęło.
Sześć do dziesięciu minut na zgłoszenie, nie licząc czasu na usuwanie spamu.
Żaden z tych kroków nie jest trudny. Problem nie polega na trudności, tylko na tym, że każdy z nich zależy od tego, czy ktoś akurat zajrzy do skrzynki. To jest dokładnie ten typ procesu, o którym piszemy klientom: powtarzalny, o jasnych regułach, na danych cyfrowych, z odwracalnym błędem.
Co zbudowaliśmy
Cały proces łączy narzędzia, których już używaliśmy. Nic nie zostało kupione.
Formularz wysyła zgłoszenie do webhooka. Nie na skrzynkę — do scenariusza, który decyduje, co dalej.
Filtr antyspamowy odrzuca boty. Trzy warunki naraz: ukryte pole formularza musi być puste, adres e-mail musi mieć poprawną budowę, a treść musi zawierać cokolwiek poza znakami przypadkowymi. Ukryte pole to tak zwany honeypot — człowiek go nie widzi, bot wypełnia wszystko, co znajdzie.
Zgłoszenie trafia do arkusza. Automatycznie, w tych samych kolumnach co zawsze, bez ręcznego przepisywania.
Powiadomienie idzie na skrzynkę. Z pełną treścią, żeby dało się ocenić zgłoszenie bez otwierania arkusza.
Router rozpoznaje wersję językową. Formularz przekazuje informację o tym, z której wersji strony przyszło zgłoszenie, a scenariusz kieruje je do odpowiedniej gałęzi. Strona ma trzy wersje językowe, więc gałęzie są trzy.
Klient dostaje potwierdzenie w swoim języku. Nie „dziękujemy za wiadomość", tylko informacja o tym, kiedy odpowiemy i co się wydarzy dalej.
Zadanie ląduje na liście. Automatycznie, z terminem.
Do tego osobna ścieżka: kto woli od razu wybrać termin rozmowy, klika w kalendarz i rezerwuje trzydzieści minut bez wymiany maili.
Ile to zajęło
| Etap | Czas |
|---|---|
| Projekt, w tym dobór narzędzi | ok. 2 godziny |
| Budowa scenariusza | 2–3 godziny |
| Testy i poprawki | 2 dni |
Testy zajęły kilkukrotnie więcej niż budowa. To nie jest anomalia i nie oznacza, że coś poszło źle. Tak wygląda każde uczciwe wdrożenie.
Budowa scenariusza to układanie klocków, które robią to, co mają robić w warunkach idealnych. Testy to sprawdzanie, co się stanie, gdy ktoś wpisze adres bez małpy, wyśle pusty formularz, kliknie dwa razy albo wypełni go w innej wersji językowej.
Kiedy wykonawca automatyzacji podaje termin, warto zapytać, ile z tego to testy. Jeśli odpowiedź brzmi „testy zrobimy na żywo", to znaczy, że testować będzie klient.
Rachunek: zwrot po sześciu tygodniach
Konkretne liczby, bez zaokrąglania w swoją stronę.
| Pozycja | Wartość |
|---|---|
| Nakład pracy | ok. 5 godzin |
| Zgłoszeń w pierwsze 2 tygodnie | 12 |
| W przeliczeniu na miesiąc | ok. 26 |
| Czas ręcznej obsługi | 6–10 min na zgłoszenie |
| Oszczędność miesięcznie | ok. 3,5 godziny |
| Zwrot nakładu | ok. 6 tygodni |
| W skali roku | ponad 40 godzin |
Po dwóch tygodniach mamy odzyskane około jednej trzeciej włożonego czasu. Przy dolnej granicy szacunku, gdyby ręczna obsługa zajmowała tylko sześć minut, zwrot wypadałby po ośmiu tygodniach. Przy górnej — po pięciu. W każdym wariancie mieści się to poniżej dwóch miesięcy.
Do tego dochodzą dwie rzeczy trudniejsze do policzenia, a realne.
Spam przestał istnieć jako problem. Nie zajmuje czasu, bo nie dociera do skrzynki. Tego nie ma w tabeli, a przed automatyzacją była to zauważalna część pracy.
Odpowiedź wychodzi natychmiast, o każdej porze. Zgłoszenie wysłane w sobotę wieczorem dostaje potwierdzenie w sobotę wieczorem, nie w poniedziałek rano. Przy wyborze wykonawcy czas pierwszej odpowiedzi bywa rozstrzygający — a to jest różnica, której ręczna obsługa nie nadrobi żadnym wysiłkiem.
Pięć godzin włożyliśmy raz. Proces działa co miesiąc tak samo, niezależnie od urlopów, natłoku pracy i tego, czy ktoś akurat zajrzał do skrzynki. Po roku bilans to ponad czterdzieści godzin, po dwóch — dwa razy tyle, przy tym samym jednorazowym nakładzie.
Kiedy to się nie opłaca
Nie każdy proces zwraca się w sześć tygodni. Warunek jest prosty i wart sprawdzenia przed wdrożeniem, a nie po nim.
Poniżej kilkunastu powtórzeń miesięcznie zwrot się rozjeżdża. Ten sam proces przy trzech zgłoszeniach miesięcznie zwracałby się ponad rok. Wtedy mówimy klientowi wprost, że jeszcze nie warto.
Proces bez ustalonych reguł najpierw trzeba opisać. Jeśli trzy osoby obsługują zgłoszenia na trzy sposoby, automatyzacja utrwali jeden z nich — niekoniecznie najlepszy.
Nasz przypadek spełniał oba warunki od początku i dlatego wynik jest taki, jaki jest. To nie przypadek, tylko kryterium doboru.
Co poszło nie tak
Trzy rzeczy. Wszystkie wyszły w testach, żadna nie dotarła do klienta, wszystkie naprawiliśmy w kilkanaście minut.
Filtr honeypota porównywał tekst zamiast długości
Ukryte pole miało być puste. Warunek sprawdzał, czy jego wartość równa się pustemu tekstowi — i nie działał, bo puste pole formularza nie zawsze przychodzi jako pusty tekst. Poprawne rozwiązanie to sprawdzenie długości wartości i porównanie liczbowe do zera. Różnica wygląda na kosmetyczną, a decyduje o tym, czy filtr w ogóle działa.
Reguła zakładała checkbox, którego już nie było
Formularz miał obowiązkowy checkbox zgody na kontakt. Zamieniliśmy go na klauzulę informacyjną, bo przy odpowiadaniu na zapytanie zgoda nie jest podstawą prawną przetwarzania — jest nią podjęcie działań na żądanie osoby przed zawarciem umowy.
Zmiana była słuszna, ale scenariusz nadal sprawdzał, czy pole zgody ma wartość „on". Po usunięciu checkboxa ten warunek nie mógł już być spełniony i odrzuciłby wszystkie zgłoszenia.
To najciekawszy z tych trzech błędów, bo pokazuje coś, o czym łatwo zapomnieć: zmiana na stronie potrafi zepsuć automatyzację, która stronę tylko czyta. Jeśli ktoś zmienia formularz, ktoś musi sprawdzić scenariusz. Dlatego przy wdrożeniach zostawiamy dokumentację procesu — żeby wiadomo było, co od czego zależy.
Format wysyłki blokował zapytanie
Formularz wysyłał dane w formacie, przy którym przeglądarka wykonuje najpierw dodatkowe zapytanie sprawdzające, czy serwer zgadza się przyjąć dane z innej domeny — i na tym etapie potrafi się zatrzymać. Zmiana formatu na prostszy usunęła ten krok w całości.
Wszystkie trzy wyszły podczas testów. Gdyby wyszły na produkcji, każdy oznaczałby zgłoszenia, o których nigdy byśmy się nie dowiedzieli. To jest dokładnie ten powód, dla którego testy zajęły dwa dni.
Czego świadomie nie zautomatyzowaliśmy
Odpowiedzi merytorycznej. Klient dostaje automatyczne potwierdzenie, ale właściwą odpowiedź pisze człowiek. Automat nie udaje handlowca.
Kwalifikacji zgłoszenia. To, czy proces opisany w formularzu nadaje się do automatyzacji, wymaga oceny. Wysyłamy pytania, nie werdykt.
Personalizacji treści przez model językowy. To kolejny krok i jest odłożony celowo: najpierw wersja na regułach musi przetworzyć realne zgłoszenia, żeby było wiadomo, co model miałby poprawić. Automatyzowanie czegoś, czego się jeszcze nie zmierzyło, to zgadywanie.
Gdy ten krok wejdzie, dojdzie do niego obowiązek, o którym warto wiedzieć zawczasu: odbiorca musi zostać poinformowany, że treść przygotowała sztuczna inteligencja. Wynika to z art. 50 unijnego AI Act i obowiązuje od 2 sierpnia 2026. Opisaliśmy to osobno w tekście o nowym obowiązku informowania klientów o AI.
Najczęstsze pytania
Nie. My zaczęliśmy od arkusza. CRM ułatwia pracę przy większej liczbie zgłoszeń, ale nie jest warunkiem. Można zacząć bez niego i dołożyć później.
Automatyzacja jednego kroku procesu to 3 600 zł i pięć dni roboczych. Cały proces obsługi zapytań, z integracjami i dokumentacją — 6 900 zł i dziesięć dni. Pełny cennik jest na stronie z cenami.
Bo u siebie nie musieliśmy nikogo pytać, jak proces ma wyglądać. U klienta największą częścią pracy jest ustalenie reguł i przetestowanie ich na prawdziwych danych, a nie samo budowanie.
Zależy od liczby powtórzeń. Przy dwudziestu kilku zgłoszeniach miesięcznie i ośmiu minutach na każde — kilka tygodni. Przy kilku zgłoszeniach miesięcznie — kilkanaście miesięcy, i wtedy odradzamy. Rachunek robimy na konsultacji, zanim cokolwiek zbudujemy.
Może, dlatego filtr sprawdza warunki, których człowiek normalnie nie narusza: ukryte pole zostaje puste, adres e-mail ma poprawną budowę. Przy wątpliwości lepiej przepuścić spam niż odrzucić klienta i tak ustawiamy progi.
Zgłoszenia nie przepadają — scenariusz można wznowić, a dane z formularza trafiają do arkusza. Przy wdrożeniach dla klientów projektujemy dodatkowo ścieżkę awaryjną, żeby zgłoszenie zawsze miało gdzie wylądować.
Da się. Trudność nie leży w narzędziach, tylko w wyjątkach: co zrobić z pustym polem, ze zgłoszeniem z innej wersji językowej, z klientem, który wysłał formularz trzy razy. Na to schodzi większość czasu i o tym są dwa dni testów.
Przez pięć lat budował operacje w WebWave: od stworzenia działu wsparcia od zera po stanowisko Head of Operations i integrację po przejęciu firmy. Przy porządkowaniu procesów zauważył, ile czasu zabierają czynności, które nikogo nie rozwijają — i że narzędzia zdolne je przejąć już istnieją. Absolwent finansów przedsiębiorstw w SGH.
Profil na LinkedIn →