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

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

1. Спочатку подивіться на одне реальне перенесення

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

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

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

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

2. Що зазвичай ламається першим

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

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

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

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

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

3. Перевіряйте не пошук, а робочий список

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

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

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

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

4. Виправляйте конкретний промах, а не все підряд

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

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

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

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

5. Коротка нотатка, яка зупиняє суперечку

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

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

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

Коли коротше залучити спеціаліста

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