Как проверить путь заявки с сайта до CRM

• Интеграции

К вопросам по статье

На сайте появилось «Заявка отправлена», а менеджер ничего не получил. Чтобы найти причину, нужно пройти путь одного обращения: от формы до записи в CRM. Эта инструкция поможет руководителю или маркетологу поставить проверку, а разработчику — показать результат на стороне получателя.

Какие формы включить в проверку

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

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

Пройдите цепочку по шагам

1. Откройте форму в нужном сценарии и заполните контрольные данные.
2. Проверьте поведение кнопки: нет ли зависания, повторной отправки и непонятной ошибки.
3. Посмотрите итоговый экран или страницу благодарности.
4. Найдите результат в CRM и проверьте поля, источник и ответственного.
5. Убедитесь, что следующий сотрудник видит запись и понимает действие.
6. Если предусмотрено письмо или сообщение, отдельно проверьте его получение.

Сохраните понятный результат

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

В проекте «Маткласс» я проверял обращения с основного сайта, блогов и лендингов. В amoCRM подтвердил появление 12 контрольных сделок. Это результат проверки доставки; количество продаж и влияние на выручку я по нему не оценивал.

Рабочая процедура аудита: от реестра форм к подтверждённой записи

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

Владелец процесса объясняет, что должна создавать каждая форма. Редактор или маркетолог показывает фактические места размещения, включая квизы и всплывающие окна. Разработчик определяет обработчики и интеграции. Представитель CRM проверяет принимающую сторону и доступ менеджера. Эти участники могут быть одним человеком, но разные вопросы не должны исчезать из приёмки из-за совмещения ролей.

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

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

Как определить ожидаемую запись до теста

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

Сверяйте способ добавления с документацией вашей CRM. На странице crm.lead.add Битрикс24 сообщает об остановке развития метода и рекомендует crm.item.add. Это повод проверить выбор для новой интеграции, а не переписывать работающую без обследования. В руководстве amoCRM контроль дублей через API отдельно связан с методом /api/v4/leads/complex и настройками поиска. Обещать одинаковое объединение контактов при любом подключении нельзя.

Далее согласуют поля. У каждого есть источник, формат и получатель. Необязательный комментарий не должен подменять структурированное значение, если оно нужно для распределения или отчёта. Но превращать всё в обязательные поля тоже не стоит. Если бизнес не использует параметр, его сбор увеличит нагрузку на клиента без доказанной пользы. Требования должны соответствовать следующему действию менеджера.

Результат ожидания можно записать одной короткой карточкой: какой объект, какие сведения, где он находится и кто выполняет следующий шаг. Эта карточка становится критерием теста. Тогда спор «форма работает» разрешается фактами: интерфейс, передача, сохранение и работа сотрудника проверяются отдельно, а не объединяются в один удобный для исполнителя статус.

Пошаговое выполнение одной контрольной отправки

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

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

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

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

Диагностический пример: сообщение об успехе есть, объекта нет

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

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

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

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

Диагностический пример: повтор создал две сделки

Первый запрос мог успешно записать данные, а ответ потеряться. Посетитель повторил отправку и получил второй объект. Для технической устойчивости полезно различать одну операцию и новую самостоятельную потребность. Совпадение телефона — слишком грубое правило: тот же человек способен заказать другую услугу через несколько минут.

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

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

Как проверять сбой CRM без вреда рабочему потоку

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

Если есть очередь, смотрят сохранённую операцию, время следующей попытки и предел повторов. При ответе 429 учитывают правила сервиса и Retry-After, если он передан. Если ошибка относится к данным или авторизации, ожидание само её не исправит. Такие случаи должны выходить на разбор с понятной причиной, а не бесконечно считаться временной задержкой.

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

Сценарии приёмки для группы форм

Составьте матрицу, в которой каждое испытание различает отдельное условие. Одна обычная отправка проверяет основной путь. Ошибочное поле проверяет валидацию и сохранение ввода. Повтор — устойчивость операции. Всплывающее окно — динамическое подключение. Мобильный вариант — реальные условия управления. Недоступный получатель — поведение незавершённой передачи.

Не нужно считать каждое испытание доказательством всех остальных. Если проверены только серверные ответы, так и укажите. Если подтверждены записи, но не работа сотрудника, это следующий слой. В проекте «Маткласс» важным подтверждением было появление тестовых сделок в amoCRM на согласованных маршрутах. Этот опыт показывает ценность принимающей проверки, но не обещает одинаковое покрытие любому сайту без его собственного реестра.

После исправлений выделяют затронутые формы и проверяют их по общему правилу. Если менялся один самостоятельный endpoint, не обязательно повторять все остальные сайты. Если обновлялась общая библиотека защиты, охват должен включать характерные варианты её использования. Так приёмка остаётся соразмерной риску и не превращается в набор случайных повторений.

Итоговый артефакт и дальнейшее наблюдение

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

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

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