Форми на сайті ламаються на умовній логіці та оплаті
Форма з умовною логікою — це не «показати поле, якщо вибрано опцію». Це дерево залежностей, де кожне правило спирається на попереднє: вибрав юрособу — з'явилися реквізити та поле для номера, вибрав самовивіз — зникла адреса доставки.
Варто одній умові послатися на поле, яке саме приховане, і логіка розсипається: клієнт бачить порожній блок або надсилає форму з незаповненими обов'язковими даними. На тестовому сценарії це не спливає — спливає на живому трафіку, коли заявок десятки на день.
Найдорожче обходиться не косметика, а розрив ланцюжка після надсилання. Заявка йде на пошту, але не доходить до CRM: не збіглося поле, відвалився вебхук, спрацював фільтр за обов'язковістю.
Менеджер дізнається про клієнта через добу або не дізнається взагалі — а клієнт у цей час уже написав конкуренту. Помилки обробки заявок майже ніколи не видно в інтерфейсі: форма показує «дякую», лист іде, а запису в системі немає.
Окрема історія — приймання платежів на сайті. Форма збирає дані, передає їх платіжному шлюзу і має повернути людину на сторінку з підтвердженням, а статус — у CRM та на пошту.
Якщо повернення за посиланням губиться або сума не сходиться з кошиком, платіж проходить, а замовлення в системі не створюється. Розбиратися доводиться вручну, за випискою, і кожен такий випадок — втрачений час і репутація.
Інтеграція форм з CRM ламається тихо: змінили назву поля на боці форми, додали обов'язковий атрибут у CRM, оновили плагін — і частина заявок перестала створюватися. Ніхто не помічає, поки не почне падати конверсія.
Тому ми першим ділом будуємо карту полів і правил, перевіряємо кожну гілку умовної логіки і ставимо контроль на наскрізний шлях «надсилання → CRM → оплата», щоб збій було видно одразу, а не за скаргою клієнта.
Що дає налаштована форма: ефект у цифрах
Налаштована форма — це не «гарні поля», а різниця між кількістю відправлень і кількістю заявок, що дійшли до менеджера.
У Gravity Forms цей розрив закривається на рівні логіки: умовні гілки показують лише релевантні поля, обов'язковість виставляється за сценарієм, а не за замовчуванням, тому відвідувач не кидає заповнення на п'ятому кроці.
За нашою практикою частка відправлень, що дійшли до кінця, зростає в 1,5–2 рази — завдяки тому, що форма перестає запитувати зайве.
Втрати заявок майже завжди криються не у верстці, а в доставці. Лист потрапляє у спам, лист губиться при недоступності поштового сервісу, лист іде «в нікуди», бо отримувач один і він у відпустці.
Ми закриваємо це так: запис зберігається в базі до відправлення повідомлення, доставка йде через зовнішній сервіс із підтвердженням, при збої спрацьовує повтор, а копія йде в CRM і на резервну адресу.
Клас відмов «заявка була, але її ніхто не побачив» перестає існувати — кожне відправлення має статус, який можна перевірити.
Швидкість обробки заявки — другий вимірюваний ефект. Коли дані з форми потрапляють у CRM з готовою структурою, а не пересилаються листом, менеджер не витрачає час на перенесення та уточнення.
Відповідь за типовою заявкою прискорюється з годин до хвилин, а частка заявок, оброблених того ж дня, зростає передбачувано — це видно у звіті, а не на словах.
Надійність відправлення тримається на трьох речах: захист від повторних відправлень, перевірка вхідних даних до запису та журнал подій форми. Ми налаштовуємо їх разом з інтеграціями — платежі, CRM, розсилки, — щоб форма працювала як частина процесу, а не як окрема сторінка. Далі розбираємо, з чого складається таке налаштування.
Способи реалізації: вбудовані засоби та зовнішні сервіси
Розвилку зручно вирішувати за тим, де живе логіка: всередині форми, у розширенні на боці сайту або у зовнішньому сервісі.
Штатні засоби Gravity Forms закривають умовне відображення полів, розрахунки, повідомлення та базовий запис у базу — цього достатньо, поки правила не залежать від даних поза формою.
Як тільки з'являється погодження за ролями, обмін із CRM або складна валідація за зовнішніми довідниками, починається зона розширень і зовнішніх обробників.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Штатні можливості | Умовна логіка, розрахунки, повідомлення, приймання платежів, простий запис заявок | Логіка обмежена полями форми; немає погоджень і обміну із зовнішніми системами «з коробки» |
| Розширення для форм | Повторювані сценарії: покрокові форми, завантаження файлів, інтеграції з розсилками та складами | Залежність від стороннього коду: оновлення ядра можуть ламати сумісність, частина розширень конфліктує між собою |
| Зовнішні обробники | Погодження за ролями, обмін із CRM та обліковими системами, нестандартна валідація, аудит дій | Потребують підтримки на своєму боці: обробка помилок, повторні відправлення, розмежування доступів |
Як вибирати підхід
Вважаємо не кількість полів, а число розгалужень і зовнішніх залежностей. Якщо правило читається одним рядком умови і не тягне дані ззовні — залишаємо у штатних засобах: менше коду, менше точок відмови при оновленні.
Якщо сценарій повторюється на кількох формах, розширення дешевше в підтримці, ніж копія логіки в кожній.
Зовнішній обробник виправданий, коли форма стає частиною процесу: заявка йде в CRM, проходить погодження, повертає статус. Тоді важливі ідемпотентність відправлення, журнал змін і зрозуміла поведінка при недоступності зовнішньої системи — інакше дублі заявок і втрачені звернення.
Ми фіксуємо вибір у схемі: які правила залишаються у формі, що виносимо в розширення, які виклики йдуть назовні. Це знімає головний ризик — логіку, розмазану між плагіном і зовнішнім сервісом, яку потім ніхто не може прочитати цілком.
Як ми впроваджуємо: від аудиту до передачі
Роботу починаємо з інвентаризації: збираємо всі форми на сайті, фіксуємо, куди надходять дані, які поля обов'язкові, де зараз втрачаються заявки. На цьому етапі видно, які форми дублюють одна одну, а які ламаються на мобільних — це і є карта для проєктування.
- Аудит форм. Проходимо по кожній формі як користувач: заповнюємо, надсилаємо, перевіряємо листи та записи. Відзначаємо биті повідомлення, поля без валідації, конфлікти плагінів і форми, які не надсилаються при вимкненому скрипті.
- Проєктування логіки. Розкладаємо сценарії за умовами: які поля показуються залежно від відповіді, де потрібні розрахунки, кроки, файли, згоди. Узгоджуємо схему розгалужень до початку налаштування — правки на папері дешевші за правки в проді.
- Налаштування інтеграцій. Підключаємо приймачі даних: CRM, поштові сервіси, таблиці, платіжні шлюзи. Перевіряємо, що заявка не втрачається при збої зовнішнього сервісу і що повідомлення надходять потрібним адресатам.
- Тестування сценаріїв. Проганяємо кожну гілку логіки, включаючи крайні випадки: порожні поля, невірний формат, повторне надсилання, відмова платежу. Дивимося, що бачить користувач і що отримує менеджер.
- Передача рішення. Віддаємо налаштовані форми, схему логіки, список інтеграцій та інструкцію з правок. Показуємо, як додати поле або змінити умову без розробника.
Кожен етап закінчується перевірюваним результатом, а не звітом. Якщо на аудиті з'ясовується, що частину форм простіше переписати, ніж лагодити, — говоримо про це одразу, до початку робіт.
Що залишається у вас після роботи
Після здачі проєкту у вас залишається не «набір форм», а робоча система з прозорою структурою. Ми передаємо все, що потрібно для самостійної експлуатації та розвитку: конфігурацію, схеми, правила доступу й документацію. Нижче — що саме ви отримуєте.
- Конфігурація форм — експортовані конфігурації Gravity Forms з усіма полями, умовною логікою, валідацією та зв'язками між формами. Кожне правило підписано: що перевіряє, за якої умови спрацьовує, куди передає дані.
- Схеми потоків даних — карта руху заявки від надсилання до отримувача: які інтеграції задіяні, які поля куди надходять, де спрацьовують повідомлення та вебхуки, де дані зберігаються.
- Правила доступу та ролі — матриця прав: хто зі співробітників бачить заявки, хто може змінювати конфігурацію, хто вивантажує дані. Окремо — правила обробки персональних даних і строки їх зберігання.
- Документація щодо форм — опис кожного поля, логіки розгалуження та інтеграцій людською мовою. Новий співробітник розбереться без звернення до нас.
- Регламенти підтримки — що робити при збої надсилання, як перевірити доставку повідомлень, як відкотити конфігурацію до попередньої версії, до кого звертатися при інциденті.
- Інструкції щодо платежів — якщо підключено оплати: як налаштовані сценарії, як звіряти статуси транзакцій, як обробляти повернення та незавершені платежі.
- Чек-лист приймання — список перевірок, за якими ви приймаєте роботу: тестові надсилання, граничні випадки, поведінка при недоступності зовнішніх сервісів.
Усе це в одному місці, у форматі, який читається без нас. Ви не прив'язані до підрядника: система задокументована настільки, що її можна передати іншій команді або розвивати власними силами.
Кейс: як ми усунули втрати заявок на формі
Що було до
Клієнт — сервісна компанія з потоком заявок з кількох лендінгів. Форми збиралися на Gravity Forms, але логіка була «плоскою»: одне довге полотно полів, обов'язкові поля без умов, відправлення в одну спільну скриньку. На практиці це давало три класи відмов.
Перший — валідація: користувач заповнював усе, спотикався на необов'язковому за змістом полі й ішов. Другий — платежі: оплата йшла окремим кроком, і при поверненні з платіжної сторінки дані форми губилися, заявка не дозаписувалася. Третій — маршрутизація: заявки падали в загальну чергу, частина губилася при розборі.
Що змінили
Ми перебудували форму на умовну логіку: поля з'являються в міру відповідей, обов'язковість вмикається лише для релевантної гілки, а необов'язкові приховані до потрібного вибору.
Платіж вбудували в саму форму — статус транзакції фіксується в записі, а не в окремому процесі, тому повернення користувача більше не обнуляє дані.
Додали серверну валідацію та захист від повторних відправлень, а маршрутизацію заявок розвели за відповідальними через правила за значеннями полів.
Що стало
Частка успішних відправлень зросла з 61% до 89% — основну частину дав відхід від «хибної обов'язковості» та поява полів за умовою. Відмови при оплаті, коли заявка губилася на поверненні, зникли повністю: статус тепер прив'язаний до запису форми.
Час обробки однієї заявки скоротився майже вдвічі — оператор отримує вже розмічену заявку з потрібними полями, без ручного уточнення. Окремо зняли ризик дублів: повторне відправлення при оновленні сторінки більше не створює другий запис.
Чому це відтворювано
Метрики тут — наслідок не «гарної форми», а розбору, де саме губляться заявки. Ми дивимося воронку за кроками, знаходимо точки відвалу й закриваємо їх логікою, а не умовляннями «заповніть, будь ласка, усе».
Такий розбір переноситься на будь-який потік заявок: змінюються поля та правила, підхід залишається тим самим.
Чим відрізняється умовна логіка від динамічного заповнення?
Умовна логіка керує тим, що показувати і коли: вона оцінює відповіді користувача і за заданими правилами приховує, показує або позначає поля, секції та цілі кроки форми.
Динамічне заповнення вирішує інше завдання — воно підставляє значення у вже видимі поля: підтягує дані з профілю, з попередньої відповіді, із зовнішнього джерела або з вибраного варіанта. Перше змінює структуру форми на льоту, друге — її вміст.
Різниця проявляється в момент спрацювання. Умовна логіка перебудовує форму в міру заповнення: вибрав «юридична особа» — з'явилися поля з реквізитами та ІПН, вибрав «фізична» — вони зникли, а разом з ними й обов'язковість їх заповнення.
Динамічне заповнення спрацьовує інакше: поле залишається на місці, але в нього вже підставлено значення — наприклад, місто з адреси доставки переноситься в платіжний блок, а назва компанії підставляється в поле рахунку. Користувач бачить готові дані і або підтверджує їх, або виправляє.
Звідси й різні сценарії використання. Умовну логіку ставлять там, де розгалуження анкети залежить від вибору: калькулятори, заявки на послуги з різними наборами полів, багатокрокові опитування, форми з різною обов'язковістю для різних категорій клієнтів.
Динамічне заповнення потрібне там, де важливо не ганяти людину по одних і тих самих питаннях: повторне замовлення, оформлення з уже відомими контактами, розрахунок, де частина параметрів береться з вибраного тарифу.
На практиці обидва підходи майже завжди працюють разом. Умовна логіка визначає, яка гілка форми активна, а динамічне заповнення наповнює цю гілку даними без повторного введення.
Якщо побудувати лише логіку, користувач буде вводити те, що система вже знає; якщо лише заповнення — форма не зможе адаптуватися під різні категорії заявників.
Інженерно це два незалежні шари: правила видимості та обов'язковості з одного боку, джерела й пріоритети підстановки значень — з іншого. Їх розділення спрощує підтримку: змінюючи сценарій розгалуження, ви не чіпаєте логіку підстановки, і навпаки.
Часті технічні сумніви
Форма на Gravity Forms — це запис у тих самих таблицях, що й решта контенту, тому сумісність із темами, кешувальними плагінами та конструкторами сторінок вирішується на рівні розмітки й порядку завантаження скриптів, а не переписуванням форми.
Якщо сайт уже збирає заявки через інший плагін, переносимо структуру полів і повідомлення, зберігаючи попередні адреси обробників — старі посилання та закладки продовжують працювати.
Безпеку закриваємо на боці сервера: перевірка одноразового токена сесії, обмеження частоти надсилань за адресою та відбитком браузера, honeypot-поле й капча підключаються вибірково — там, де форма реально збирає спам.
Умовна логіка та розрахунок платежу виконуються повторно під час обробки, тому підміна прихованих полів у браузері не дає змоги надіслати заявку з неправильною сумою або пропущеною обов'язковою відповіддю.
Форма перестане працювати після оновлення теми чи плагіна?
Ми фіксуємо конфігурацію форм і логіку обробки в окремому модулі, а не у файлах теми, — оновлення оформлення їх не зачіпає. Перед оновленнями проганяємо надсилання тестових заявок за кожним сценарієм: умовні гілки, платежі, повідомлення. Якщо щось розходиться, відкочуємо зміну точково.
Чи витримає форма пікове навантаження, наприклад рекламну кампанію?
Обробка заявки — коротка операція, вузьке місце зазвичай не в ній, а в поштових повідомленнях і зовнішніх сервісах. Ставимо надсилання листів у чергу, щоб сплеск заявок не блокував сторінку, і розводимо приймання даних та їх передачу в CRM.
У разі зростання трафіку форма залишається чутливою, а заявки не губляться за тимчасової недоступності зовнішньої системи.
Що з доступом до заявок і персональними даними?
Дані зберігаються в базі сайту, доступ розмежовуємо за ролями: оператор бачить лише потрібні форми, вивантаження та видалення — окреме право. Налаштовуємо термін зберігання й автоматичне очищення застарілих записів, а передачу в CRM і месенджери ведемо захищеним каналом.
Хто підтримує форми після запуску?
Ми супроводжуємо конфігурацію: додаємо поля й гілки логіки, змінюємо умови платежів, стежимо за доставкою повідомлень і розбираємо збої надсилання. Правки вносимо через тестовий контур, тому робоча форма не залишається без нагляду ні на час змін, ні після них.
Обговоримо ваше завдання і повернемося з планом
Щоб оцінка була точною, а не «на око», нам потрібен від вас мінімум контексту: де зараз живуть форми (поточний сайт, CMS, окремий сервіс), які поля та сценарії вже працюють, куди мають надходити заявки та платежі.
Якщо форми ще немає — достатньо опису процесу: хто заповнює, які гілки питань виникають, що відбувається після надсилання. Цього достатньо, щоб запропонувати архітектуру умовної логіки та інтеграцій, а не гадати.
Далі ми розбираємо завдання крок за кроком і повертаємося з планом робіт: які форми та гілки логіки проєктуємо, які інтеграції підключаємо (CRM, поштові сервіси, платежі, антиспам), як налаштовуємо сповіщення та зберігання заявок.
Окремо проговорюємо, що робимо на наявній базі, а що потребує доопрацювання — щоб ви бачили межі робіт і не платили за зайве.
Що корисно підготувати до обговорення:
- список форм і сценаріїв, які мають працювати;
- опис гілок умовної логіки: які відповіді змінюють наступні поля;
- перелік інтеграцій і куди мають потрапляти дані заявок;
- вимоги до оплат: разові, підписки, валюта, повернення;
- доступи до сайту, CMS і панелей сервісів, якщо форми вже є;
- приклади листів і сповіщень, які мають надходити заявнику та вам;
- обмеження за термінами та пріоритети: що критично в першу чергу.
За підсумком обговорення ви отримуєте оцінку, план робіт за етапами та зрозумілі наступні кроки: що робимо ми, що залишається на вашому боці, у якому порядку запускаємо.
Якщо по ходу виявляться ризики — наприклад, конфлікт із поточними плагінами або обмеження хостингу — скажемо одразу, до старту, а не в процесі. Опишіть завдання у зручному форматі — повернемося з оцінкою та планом і обговоримо формат співпраці.
