Со стороны задача звучит просто: убрать ручную вставку и сделать так, чтобы форма сама создавала карточку. На практике это цепочка из нескольких действий с разными точками отказа.

Сайт принимает отправку. Потом значения нужно разложить по полям. CRM должна создать карточку. После этого сотрудник обязан увидеть её именно в том списке, который он открывает в начале дня, а не где-то в глубине системы.

Поэтому надпись «спасибо» на сайте и карточка в воронке — не одно и то же событие. Из-за этого разрыва заявка может пропасть после «спасибо». Здесь речь уже о следующем шаге: команда знает, что данные пока переносит человек, и хочет убрать именно этот ручной этап. Значит, он и есть настоящая спецификация, а не страница плагина с красивым описанием.

1. Сначала посмотрите один реальный перенос

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

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

Если во время переноса человек ещё выбирает статус, ответственного или воронку, это тоже поля, даже если форма их не показывает. Форма собрала имя и телефон, а сотрудник добавил решение вроде «новая заявка», «утренняя смена» или «источник — сайт». Если эти решения не попадут в карту, карточка уедет в место по умолчанию, а такое место нередко никто не открывает.

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

2. Что обычно ломается первым

До редких случаев дело доходит не сразу. Сначала появляются несколько очень обычных сбоев, и именно они объясняют, почему ручной перенос переживает первый месяц после слов «мы уже всё автоматизировали».

Первый сбой — в CRM есть обязательное поле, которого форма не спрашивает. Тогда CRM либо отклоняет карточку, либо создаёт её с пометкой, что она непригодна для работы. На сайте человек уже видит «спасибо», потому что сайт свой шаг завершил, а отказ лежит в журнале, который команда продаж или маркетинга не читает.

Второй сбой — карточка создаётся не там. Не та воронка, не тот статус, не тот ответственный, не та очередь. Интеграция жива, но утренний список пуст, поэтому подозрение падает на форму, хотя карточка просто осела в другом месте.

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

Рядом с дублями почти всегда стоит формат телефона. Один и тот же номер может прийти локально, а в CRM уже храниться с кодом страны. Если сравнивать строки буквально, один человек легко превращается в две карточки.

Поэтому правило нормализации нужно записать отдельно. Недостаточно сказать, что вы убираете пробелы. Нужно явно договориться, какой код страны хранится, что делать с добавочным номером и по какому виду телефона выполняется сравнение.

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

Отправьте одну заявку с телефоном, который вы контролируете. Затем откройте не только поиск в CRM, а именно тот список, с которого менеджер реально начинает день. Если карточки там нет, ищите номер по всей системе и фиксируйте, куда именно она попала.

Отдельно запишите, появилось ли «спасибо» на сайте, создалась ли карточка, какие у неё воронка, статус, ответственный и источник. После этого отправьте тот же номер ещё раз и проверьте, появилась ли вторая карточка. Если CRM отклонила данные, сразу отметьте, где эту ошибку читают и кто вообще может её увидеть.

Если в CRM есть тестовая воронка, используйте её. Если отдельной воронки нет, берите имя, которое нельзя принять за клиента, после проверки удаляйте карточку и указывайте это в заметке.

Доказывать нужно не абстрактное «интеграция работает», а очень конкретный факт: карточка появляется в том месте, где команда действительно берёт её в работу. Личный ящик коллеги или случайный список для этого не подходят.

Когда создание карточки вынесено в фоновую задачу, дождитесь завершения этой задачи и только потом делайте вывод. Быстрое «спасибо» и неудачное фоновое выполнение — обычная комбинация. Если кнопка после клика долго висит, потому что сайт ждёт ответ CRM, замерьте этот запрос и только потом решайте, проблема ли это формы или способа вызова. Более широкий разбор времени ответа есть в материале что проверить до редизайна.

4. Исправляйте конкретный промах

Если CRM отклонила заявку из-за пустого обязательного поля, либо начинайте собирать это поле в форме, либо ставьте значение по умолчанию, с которым команда действительно согласна. Источник «сайт» работает только тогда, когда все одинаково понимают, какой именно сайт имеется в виду.

Если карточка создаётся не в той воронке, меняйте место назначения, а не перестраивайте форму. Если появляются дубли, зафиксируйте правило совпадения: телефон, email или оба поля после нормализации. Потом отдельно решите, что делает повтор: обновляет открытую карточку, добавляет заметку или игнорируется.

Если человек всё равно добавляет оценку, которой форма знать не может, не стоит делать вид, что интеграция полностью убрала человека из процесса. «Горячий лид», «это спам» или «передать в другую очередь» — это уже решения, а не механическое копирование.

Либо оставляйте такой шаг явным, либо добавляйте отдельное поле, которое это решение фиксирует. Новая кнопка не принимает решение вместо человека, если само решение нигде не описано.

Спам и согласие тоже должны быть в этой же схеме. Если форму всю ночь может отправлять скрипт, CRM быстро заполнится мусором, а команда перестанет доверять списку. Проверка на спам, обязательная строка согласия и место, где видны отклонённые заявки, — это часть рабочей карты, а не дополнительная задача на потом.

5. Короткая заметка, которая прекращает спор

После одной проверки, которую вы увидели от начала до конца, достаточно короткой заметки. В ней должны быть адрес формы и кнопка, карта полей вместе со статусом, ответственным, воронкой и источником, правило повторной отправки и место, где читают ошибки.

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

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

Такой аккаунт должен уметь создавать только те карточки, которые разрешены этой форме, и только в названной воронке. В заметке можно указать имя учётной записи, но не пароль.

Когда короче позвать специалиста

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