Używamy plików cookie aby zapewnić działanie platformy oraz (opcjonalnie) analizować ruch. Wybierz swoje preferencje:
Automatyzacje stają przez zmiany w innych systemach: API, tokeny, formularze, limity planów. Jak wykryć awarię i jak rozliczać opiekę z wykonawcą.
Działająca automatyzacja przestaje działać najczęściej przez zmianę po stronie innego systemu: nowe API, wygasły token, przebudowany formularz albo przekroczony limit planu. Twój scenariusz się nie zmienił, zmieniło się otoczenie. Dlatego po wdrożeniu potrzebujesz osoby w firmie, która odpowiada za automatyzację, i czasu reakcji umówionego z wykonawcą.
Scenariusz w Make albo workflow w n8n łączy kilka systemów, a każdy z nich żyje własnym życiem. Pięć przyczyn odpowiada za większość przerw:
| Przyczyna | Przykład | Jak się objawia |
|---|---|---|
| Zmiana API | system wycofuje starą wersję API, zmienia nazwę pola | błąd przy każdym przebiegu od konkretnego dnia |
| Wygasły token lub hasło | odejście pracownika, na którego koncie było połączenie, zmiana hasła, wygaśnięcie autoryzacji | błąd autoryzacji, scenariusz staje w całości |
| Zmiana formularza lub arkusza | ktoś dodał kolumnę w arkuszu albo zmienił nazwę pola w formularzu | dane trafiają w złe miejsce albo puste pola |
| Limit planu | koniec operacji w planie Make, limit zapytań API | scenariusz zatrzymuje się w połowie miesiąca |
| Nowy przypadek | pierwsze zamówienie z zagranicy, korekta, zwrot częściowy | błąd albo, gorzej, ciche złe dane |
Przykład z dokumentacji Allegro (stan na październik 2026): token dostępu jest ważny 12 godzin, a token odświeżania 3 miesiące. Scenariusz, który nie odświeża tokenu poprawnie, zadziała przy wdrożeniu i przestanie działać po kilku miesiącach, długo po odbiorze projektu.
Najgroźniejszy jest ostatni wiersz tabeli. Błąd, który zatrzymuje scenariusz, widać od razu. Błąd, który przepuszcza złe dane, wychodzi na jaw przy zamknięciu miesiąca albo przy reklamacji klienta.
Osobną kategorią są zmiany w samej firmie. Nowy kurier, nowa stawka VAT dla części asortymentu, drugi magazyn albo nowy kanał sprzedaży to nie awaria, tylko rozwój procesu. Scenariusz trzeba wtedy przebudować, a ta praca zwykle nie mieści się w opiece rozumianej jako usuwanie błędów. Warto to rozróżnienie zapisać od początku, żeby nie spierać się o nie przy pierwszej fakturze za opiekę.
Limity planów i to, jak liczą operacje Make, n8n i Zapier, opisujemy we wpisie o miesięcznych kosztach tych narzędzi.
Trzy rzeczy warto mieć od pierwszego dnia po wdrożeniu.
Pierwsza to powiadomienia o błędach. Make wysyła mailowe powiadomienia o błędach i ostrzeżeniach scenariusza oraz o jego wyłączeniu, a po włączeniu opcji przechowywania niekompletnych przebiegów zapisuje nieudane przebiegi do ponownego uruchomienia. W n8n można wskazać osobny workflow błędów, który uruchamia się przy każdym nieudanym przebiegu i wysyła wiadomość, na przykład na Slacka albo mailem. Powiadomienia muszą trafiać do osoby, która je czyta, a nie na skrzynkę wykonawcy, który zakończył projekt pół roku temu.
Druga to dziennik przebiegów. Raz w tygodniu ktoś po Twojej stronie przegląda historię wykonań: ile było przebiegów, ile błędów, czy liczba przetworzonych rekordów zgadza się z liczbą zamówień albo faktur. Spadek liczby przebiegów do zera jest równie niepokojący jak seria błędów, bo oznacza, że scenariusz w ogóle przestał się uruchamiać.
Trzecia to jedna osoba odpowiedzialna. Nie musi umieć budować scenariuszy. Musi wiedzieć, co robi każda automatyzacja, gdzie jest dokumentacja, jak wyłączyć scenariusz i do kogo dzwonić. Bez takiej osoby powiadomienie o błędzie trafia do wszystkich i nikt nie reaguje. Wyznacz też zastępcę na czas urlopu, bo awarie nie czekają na powrót odpowiedzialnej osoby.
Do kontroli złych danych przydaje się prosta reguła: scenariusz, który nie wie, co zrobić z rekordem, odkłada go do kolejki do ręcznego przejrzenia zamiast zgadywać. Wtedy nowy przypadek z tabeli wyżej kończy się jednym rekordem do sprawdzenia, a nie serią błędnych faktur.
Część awarii da się przewidzieć. Dostawcy API zapowiadają wycofanie starych wersji z wyprzedzeniem, w komunikatach dla deweloperów albo w dzienniku zmian. Jeśli opiekę prowadzi wykonawca, ustal, że śledzi te zapowiedzi dla systemów używanych w Twoich scenariuszach i informuje Cię o planowanych zmianach, zanim scenariusz przestanie działać.
Oba modele mają sens, zależnie od tego, ile automatyzacji masz i jak drogi jest przestój.
| Model | Kiedy się sprawdza | Na co uważać |
|---|---|---|
| Godziny na żądanie | jedna lub dwie automatyzacje, przestój nie zatrzymuje firmy | brak gwarancji czasu reakcji, wykonawca może być zajęty |
| Abonament z pulą godzin | kilka automatyzacji, regularne drobne zmiany | niewykorzystane godziny zwykle przepadają |
| Abonament z czasem reakcji | automatyzacje, od których zależy sprzedaż lub wysyłka | wyższa cena za gotowość, nie za pracę |
Punktem odniesienia są stawki specjalistów no-code w Polsce: według benchmarków Qerify 80-300 zł za godzinę. Przykład rachunku, nie rekomendacja: jeśli przy trzech scenariuszach spodziewasz się 3 godzin poprawek miesięcznie, przy stawce 150 zł to 450 zł. Abonament z gwarantowanym czasem reakcji będzie droższy niż sama suma godzin, bo wykonawca rezerwuje dla Ciebie czas.
Godziny na żądanie wystarczą, dopóki pierwsza poważna awaria nie wypadnie w tygodniu, w którym wykonawca jest na urlopie. Jeśli automatyzacja obsługuje zamówienia albo faktury, policz, ile kosztuje Cię dzień przestoju, i porównaj to z różnicą w cenie modeli.
Lista do przeniesienia do umowy albo do opisu etapu:
Punkt 8 łączy się z pytaniem, do kogo należą scenariusze i konta. Jeśli działają na Twoim koncie, zmiana wykonawcy opieki to kwestia przekazania dokumentacji. Więcej o tym we wpisie kto jest właścicielem automatyzacji.
Nie ma jednej liczby. Ilość opieki rośnie z liczbą scenariuszy i, przede wszystkim, z liczbą zewnętrznych systemów, z którymi się łączą. Scenariusz przenoszący dane między dwoma arkuszami w jednej firmie może działać latami bez zmian. Scenariusz łączący Allegro, BaseLinkera, program księgowy i CRM ma cztery miejsca, w których coś może się zmienić niezależnie od Ciebie.
Najlepsze źródło danych ma Twój wykonawca. Zapytaj go o historię zgłoszeń z podobnego projektu: ile było awarii w pierwszym roku, z jakich przyczyn i ile godzin zajęła każda poprawka. Wykonawca, który prowadzi opiekę od dawna, odpowie konkretnie. Sam też możesz zrobić wstępną ocenę. Policz, z iloma zewnętrznymi systemami łączą się Twoje scenariusze, ile z tych połączeń korzysta z tokenów, które wygasają, i ile osób w firmie może zmienić arkusz albo formularz, z którego scenariusz czyta dane. Im wyższe te liczby, tym bardziej opłaca się abonament z czasem reakcji zamiast godzin na żądanie. Przy wyborze wykonawcy to dobre pytanie uzupełniające do listy z wpisu o tym, jak sprawdzić eksperta automatyzacji.
Pierwsze tygodnie po wdrożeniu są zwykle najbardziej pracowite, bo wtedy wychodzą przypadki, których nie było w danych testowych. Dlatego okno na poprawki po odbiorze warto rozliczyć w ramach wdrożenia, a opiekę liczyć od jego końca.
Opisując problem Concierge'owi, dopisz od razu oczekiwania co do opieki: czas reakcji, kto po Twojej stronie będzie odpowiadał za automatyzację, czy wolisz abonament, czy godziny. Te informacje trafią do briefu, a wykonawca wyceni opiekę razem z wdrożeniem.