«Дякуємо» на сайті, тікета в CRM немає: знайдіть заявку

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

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

Повідомлення на сайті й тікет у CRM — це різні результати

Сайт може показати «Дякуємо» як власну відповідь на натискання кнопки. Тікет у CRM — це окремий результат: рядок, який менеджер може відкрити, призначити, взяти в роботу й зафіксувати підсумок дзвінка. Ці дві події не зобов’язані відбутися разом.

Код, який показує підтвердження на сторінці, може спрацювати навіть тоді, коли крок створення тікета не запустився, зламався пізніше або отримав відмову від CRM. Тому скриншот із «Дякуємо» доводить лише те, що людина побачила повідомлення. Він не доводить, що номер телефону вже є в робочому списку.

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

Для цієї перевірки заявка — це саме рядок у CRM. «Дякуємо» — це лише повідомлення. Якщо людина взагалі не побачила підтвердження й просто чекала, поки крутиться індикатор, це вже інший тип збою. Якщо підтвердження не з’явилося, але тікет у списку є, це теж інша ситуація. Тут ми розбираємо лише незручний середній випадок: підтвердження було, а тікета з цим ім’ям і телефоном у робочому списку немає.

Спочатку назвіть робочий список, а вже потім шукайте збій

Спочатку треба назвати той вигляд списку, який менеджер відкриває вранці в понеділок. Яка це воронка? Який статус вважається новим? Який фільтр за відповідальним увімкнений за замовчуванням? Через скільки хвилин після реальної заявки менеджер очікує побачити новий рядок?

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

Запишіть, хто саме перевіряє список і що саме він відкриває. Рядок може бути призначений на колишнього співробітника. Фільтр може приховувати закриті або спам-записи. Конектор може відправляти нові заявки в іншу воронку. Для людини, яка дивиться лише свій звичний список, усе це виглядає як «нічого не прийшло», хоча запис у CRM вже є.

Лист на пошті — це не робочий список. Повідомлення в месенджері — це не робочий список. Цифра на дашборді — це не робочий список. Відкрийте саме той список, де менеджер мав би поставити результат дзвінка. Якщо рядка там немає і пошук по телефону теж нічого не дає, тоді справді є розрив між сайтом і CRM. Якщо рядок існує, але команда його не побачила, проблема у вигляді списку, а не у формі.

Чому «Дякуємо» є, а тікет не з’явився

Перша причина — розрив у часі між відповіддю сайту та записом у CRM. Сайт може одразу показати успіх, а передача в CRM піде окремим фоновим завданням. Людина вже закрила вкладку, а завдання ще навіть не відпрацювало. Якщо воно впаде, сайт не забере назад повідомлення «Дякуємо». Менеджер відкриє список і не знайде нічого, доки хтось не перевірить журнал або чергу завдань за цю хвилину.

Друга причина — CRM відхилила дані після того, як сайт уже відповів успіхом. У формі може не бути обов’язкового поля. Телефон може бути в форматі, який CRM не приймає. Значення списку може не збігатися з дозволеним значенням у полі CRM. У такій ситуації треба шукати текст помилки саме для цієї спроби, а не одразу міняти форму. Якщо причина в конкретному полі або значенні, новий дизайн із тим самим набором даних отримає ту саму відмову.

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

Четверта причина — неправильне місце призначення. Конектор міг успішно створити рядок, але не там, де команда його чекає: в іншій воронці, під іншим відповідальним, у записах іншого напряму в межах тієї самої CRM. Для журналу це буде успішна передача. Для менеджера це буде порожній список. Саме тому під час тесту варто одразу записати очікувану воронку та очікуваного відповідального.

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

Одна перевірка: відправили форму й одразу перевірили список

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

• Точний вигляд списку: воронка, фільтр за статусом, фільтр за відповідальним.
• Чи існує рядок із цим номером телефону будь-де, включно із закритими та спам-записами.
• Чи є помилка в журналі завдання або конектора за ту саму хвилину, якщо рядка немає.
• Яке саме поле або значення відхилила CRM, якщо журнал називає причину.
• Хто мав би телефонувати за цим тікетом і чи дивиться ця людина саме на цей вигляд списку.

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

Якщо команда після листа на пошту все одно вручну переносить дані в CRM, це треба прямо зафіксувати. У такому процесі автоматичний тікет і ручне копіювання — це два різні продукти. Сайт може чесно показувати успіх після відправлення листа, а робочий список залишатиметься порожнім, доки хтось не вставить дані руками. Тоді треба або прибрати ручний етап, або перестати говорити, що зв’язка форма—CRM працює автоматично. Для такої перевірки корисна карта шляху: про форму і картку.

Що зафіксувати до того, як хтось оцінюватиме переробку

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

Не використовуйте реальні дані клієнтів. Для такої перевірки вистачає власного номера та тестового імені. Це безпечніше й дає можливість повторити пошук без ризику змішати тест із живими зверненнями.

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

Коли вже варто підключати допомогу

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

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

Суть роботи тут не в тому, щоб намалювати нову форму. Суть роботи — змусити збігатися два результати: підтвердження на сайті й тікет у тому списку, з якого команда реально телефонує. Послуги охоплюють увесь шлях від відправлення форми до робочого списку. Обрані роботи показують, як ми тримаємо технічний результат поруч із реальною операційною дією. Людина побачила «дякуємо», а в робочому списку немає заявки, і з цим дає раду послуга автоматизації заявок у CRM. Якщо звертатиметеся, надішліть назву вигляду списку, що саме людина побачила після одного тесту і що показав пошук за цим номером. І не надсилайте реальні імена клієнтів.