Форма сказала «Дякуємо». А заявка куди поділася?

На сайті є форма. Поля акуратні, кнопка помітна, після натискання з’являється «Дякуємо! Ми зв’яжемося з вами».

Клієнт закриває сторінку. Менеджер продовжує свій день. Обоє впевнені, що інша сторона зараз щось зробить.

До вечора ніхто нікому не написав.

Форма може виглядати справною, навіть якщо звернення не потрапило туди, де його чекають. А може чесно передати дані, після чого заявка зникне серед повідомлень або залишиться без відповідального. Зовні ці ситуації дуже схожі: клієнт чекає, бізнес каже, що звернень немає.

Щоб розібратися, перевіряй весь маршрут. Напис «Дякуємо» — лише одна його частина.

Спочатку людина заповнює поля. Далі сайт має передати дані обробнику. Потім звернення може зберігатися в системі й надсилатися на пошту, у месенджер або CRM. І нарешті його має побачити той, хто відповідає клієнтам.

Цей шлях залежить від конкретного сайту. Десь запис спочатку створюється в CRM, а повідомлення на пошту лише сповіщає про нього. Десь форма надсилає тільки лист, і окремого списку звернень узагалі немає.

У документації MDN про надсилання форм пояснено базову схему: браузер передає дані серверу, а подальша обробка залежить від реалізації. Сервер може показати отримане, зберегти дані, надіслати лист або виконати іншу дію. Отже, саме відображення відповіді в браузері ще не підтверджує доставку звернення менеджеру.

Для перевірки розділи чотири питання: чи прийняв сайт звернення, чи зберігся запис, чи надійшло повідомлення в потрібний канал і чи взяла людина заявку в роботу. На кожне потрібне окреме підтвердження.

Уявімо умовну компанію з ремонту техніки. Коли запускали сайт, форму налаштували на пошту власника. Пізніше з’явився адміністратор і робочий чат. Усім здається, що звернення вже йдуть туди. Насправді адресу ніхто не змінював.

Тут проблема не потребує нового дизайну. Потрібно знати чинний маршрут і погодити правильний.

Запитай відповідального за сайт: де зберігаються заявки, кому йдуть повідомлення, яка адреса або чат зараз указаний у налаштуваннях. Потім перевір доступ до цього місця. Колишній працівник може бути єдиним адміністратором, поштова скринька — переповненою, а чат — вимкненим у сповіщеннях.

Не задовольняйся відповіддю «на пошту». Потрібна конкретна робоча адреса, до якої є доступ у бізнесу, і людина, яка її перевіряє.

Якщо для будь-якої перевірки доводиться шукати підрядника, який уже давно не відповідає, спочатку розберися з доступами. Ми писали про це в матеріалі «Підрядник зник. Що залишилося від твого сайту?».

Відкрий форму як звичайний відвідувач, бажано з телефона. Заповни її власними тестовими контактами й додай у повідомлення зрозумілу мітку «ТЕСТ ФОРМИ». Фактичні дату й час надсилання запиши окремо.

Попередь відповідального, щоб він знав про перевірку й не почав оформлювати вигаданий ремонт. Але не підказуй, у якій саме папці зараз має лежати повідомлення, якщо хочеш перевірити звичний робочий порядок.

Запиши час надсилання й те, що показав сайт. Після цього перевір заплановані місця отримання: запис у CRM або іншому сховищі, лист у скриньці, повідомлення в чаті. Для пошти подивись також спам та інші папки.

Попроси відповідального знайти тест за міткою й повторити отримані дані: ім’я, контакт, текст звернення. Так перевіряється і доставка, і вміст. Лист може дійти без номера телефону або з неправильною назвою послуги — а з погляду сервісу надсилання все виглядатиме успішно.

Один вдалий тест підтверджує цей конкретний прохід. Він не доводить, що все працює на кожному пристрої й у будь-який час. Почни з основного маршруту, потім перевір інші важливі форми та сторінки.

Якщо сайт не прийняв звернення, треба перевіряти саму форму й обробку запиту. Користувач має бачити зрозумілий стан, а не повідомлення про успіх після невдалої спроби.

Якщо сайт прийняв дані й запис зберігся, але повідомлення не дійшло, перевіряють наступну частину маршруту: адресата, налаштування пошти чи інтеграції, відповіді сервісу надсилання. Картинка кнопки тут навряд чи допоможе.

Якщо повідомлення є, але його не побачили, з’ясовують, хто перевіряє канал і як нова заявка відрізняється від решти повідомлень. Якщо заявку побачили, але ніхто не відповів, потрібні правила розподілу роботи.

Для розмови з розробником зручно зібрати таку таблицю:

Етап Що шукаємо як підтвердження Хто допоможе перевірити Надсилання з форми Фактичний результат запиту й коректний стан для клієнта Відповідальний за сайт Збереження Запис тестового звернення, якщо він передбачений системою Адміністратор сайту або CRM Сповіщення Тестовий лист чи повідомлення в потрібному місці Відповідальний за канал і розробник Опрацювання Людина підтвердила отримані дані й взяла звернення в роботу Менеджер або власник

Якщо система не зберігає звернення, так і запиши. Не вигадуй наявність журналу, щоб таблиця виглядала завершеною. Окремо обговоріть, чи потрібне сховище і як ним користуватися.

Навіть якщо код форми відпрацював, лист може бути відхилений або потрапити не туди, де менеджер його чекає. Налаштування відправника мають значення.

Наприклад, у вимогах Gmail до відправників серед базових умов є автентифікація домену через SPF або DKIM. Для великих обсягів надсилання вимоги відрізняються. Ці правила стосуються доставки до особистих Gmail-акаунтів, а не автоматично всіх поштових систем.

Не потрібно самостійно міняти записи домену за випадковою інструкцією. Передай відповідальному за пошту конкретний тест, час, адресу одержувача й те, що знайшли в результатах надсилання. Нехай перевірить вимоги саме вашого відправника та одержувача.

Також домовтеся, яку адресу використовує повідомлення від форми й куди надходить відповідь на нього. Інакше менеджер може натиснути «Відповісти» й написати технічному відправнику замість клієнта.

Продовжимо тест у нашій умовній ремонтній компанії. Маршрут налаштували, і повідомлення вже приходять у спільний чат. Власник бачить нове звернення й думає, що його взяв адміністратор. Адміністратор бачить, що власник онлайн, і думає те саме про нього.

Технологія виконала свою частину. Клієнту від цього не легше.

Визнач, хто перевіряє нові заявки, як позначає взяту в роботу й хто підхоплює звернення за відсутності цієї людини. Для невеликої команди достатньо простого запису з відповідальним і наступною дією. Важливо, щоб він був видимий усім, хто бере участь у роботі.

Звір і обіцянку на сайті. «Зателефонуємо за п’ять хвилин» погано працює, якщо форму можна заповнити вночі, а команда відповідає тільки в робочий час. Напиши те, що бізнес реально може виконати, й організуй роботу під цю обіцянку.

Повідомлення для клієнта має відповідати фактичному стану. Якщо система лише прийняла звернення на сайті, не варто стверджувати, що менеджер уже його читає. Конкретні строки відповіді додавай тільки після того, як команда погодила й може підтримувати такий порядок.

Форма могла працювати на запуску й перестати після зміни пошти, оновлення сайту, заміни сервісу або переходу до іншого чату. Тому тест варто повторювати після змін, які зачіпають маршрут звернення.

Для регулярної перевірки вибери посильний порядок і відповідального. Якщо сайт — важливий канал продажів, одне заплановане тестове звернення може дати більше користі, ніж чергове споглядання графіка відвідувань. Частоту визначайте за обсягом звернень і наслідками пропуску, а не за універсальною порадою з інтернету.

Попроси розробника пояснити, як команда дізнається про невдале надсилання й чи зберігаються звернення, коли сповіщення не доходить. Резервний канал теж треба перевірити: друга кнопка, яка веде на ту саму поламану адресу, не створює запасного маршруту.

Готове повідомлення для першої перевірки:

Якщо реклама приводить людей, а звернень мало, цю перевірку корисно зробити до збільшення бюджету. Інші можливі причини розібрані в статті «Реклама крутиться, а заявок немає».

Почни сьогодні з одного тесту. Простеж його до конкретної людини й перевір отримані дані. Після цього «Дякуємо» матиме за собою трохи більше, ніж гарну анімацію.

Умовний бізнес, таблиця перевірки й тексти повідомлень — редакційні приклади. Фактичний маршрут залежить від реалізації твого сайту.