Martwe formularze: dlaczego zgłoszenia nie docierają i jak to wyłapać

Siedem miejsc, w których pęka wysyłka formularza, checklista kontroli i co wpisywać w zgłoszeniach testowych.

Formularze · Opublikowano: 9 lipca 2026 · 3 min czytania · Ольга Мирошник

Formularz to najdroższa część serwisu: przez niego przychodzą zgłoszenia, rejestracje i zamówienia. I najbardziej krucha: zależy jednocześnie od frontendu, backendu, poczty, antyspamu i CRM. Pęka dowolne ogniwo — użytkownik widzi „Dziękujemy!", a wy nie widzicie nic.

Gdzie rwie się łańcuch

1. Walidacja. Regex e-maila nie przepuszcza adresu z plusem albo domeny .digital. Użytkownik nie wie, co jest nie tak, i wychodzi.
2. Przycisk. Handler się nie podpiął przez błąd JS wyżej na stronie — formularz w ogóle nie wysyła.
3. Żądanie. CORS, wygasły token CSRF, 500 na backendzie. Frontend pokazuje sukces, bo nie sprawdza kodu odpowiedzi.
4. Antyspam. Captcha nie ładuje się w części regionów, honeypot łapie prawdziwych użytkowników z autouzupełnianiem.
5. Poczta. Brak SPF/DKIM — wiadomość ląduje w spamie albo wraca.
6. CRM. Webhook padł miesiąc temu, brak ponowień, zgłoszenia giną po cichu.
7. Analityka. Zdarzenie konwersji nie strzela i nie widzicie spadku.

Checklista kontroli

• Wysyłka z pustymi polami: pojawia się zrozumiały komunikat, fokus wędruje do pierwszego błędnego pola.
• Wysyłka z poprawnymi danymi: przychodzi i mail, i wpis w CRM. Sprawdzajcie oba kanały, nie jeden.
• Wartości brzegowe: adres z plusem, domena cyrylicą, telefon ze spacjami i nawiasami, imię z jednej litery.
• Podwójne kliknięcie: nie powstają dwa zgłoszenia.
• Wysyłka bez JavaScriptu albo przy błędzie skryptu: czy jest degradacja.
• Mobile: czy klawiatura nie zasłania przycisku, czy inputmode i autocomplete są poprawne.
• Dostępność: każde pole ma <label>, błędy powiązane przez aria-describedby, stan błędu nie jest przekazany samym kolorem.

Zgłoszenia testowe, które nie przeszkadzają

Oznaczajcie sztuczne wysyłki tak, by dało się je odfiltrować w CRM i wykluczyć z analityki: osobna pula adresów typu qa+2026-08@, pole techniczne source: monitoring, stały ciąg w komentarzu. Inaczej za pół roku dział sprzedaży będzie obdzwaniał roboty.

Monitoring zamiast jednorazowej kontroli

Ręczna kontrola łapie problem w chwili kontroli. Prawdziwe awarie zdarzają się pomiędzy — po aktualizacji wtyczki, rotacji tokenu albo zmianie dostawcy poczty. Sensowny układ: raz na dobę automatycznie wypełniać kluczowe formularze, sprawdzać kod odpowiedzi, dostarczenie maila i pojawienie się wpisu w CRM, a przy rozjeździe wysyłać alert.

Osobno pilnujcie liczby zgłoszeń dziennie: nagły spadek do zera to najpewniejszy znak, że formularz umarł, nawet jeśli technicznie odpowiada 200.