- ФормаБраузер отправляет поля и идентификатор запроса.
- ПриёмСервер проверяет запрос и фиксирует приём или ошибку.
- CRMИнтеграция создаёт или обновляет нужную запись.
- ОтветственныйНазначение и уведомление проверяются отдельно.
Начните с одного обращения, которое можно проследить
Выберите реальное обращение, которое можно проверить без копирования лишних персональных данных. Зафиксируйте источник, время с часовым поясом и внутренний идентификатор. Найдите соответствующие события в обработчике формы, интеграции и CRM. Запись в одной системе ещё не доказывает, что произошло в следующей.
Разница между общими счётчиками — только подсказка. Фильтрация спама, повторные отправки, поиск дублей и разные периоды отчётности могут объяснять её без потери обращения. Сравнивайте одно событие за один период. Если на каком-то этапе нет журнала, отметьте этот пробел вместо вывода, что ничего не поступало.
- Сохраняйте исходный идентификатор на всех этапах.
- Проверяйте и принятые, и отклонённые запросы.
- Не копируйте имена, контакты и полное содержимое формы в общий журнал ошибок.
Отделите приём от завершения
Сообщение об успехе в браузере само по себе не подтверждает наличие записи в CRM. Выясните, что подтверждает сервер формы: получение, надёжное сохранение, постановку в очередь или завершённую запись в CRM. Последующее уведомление — ещё один отдельный шаг.
Нарисуйте маршрут и определите признак успеха на каждом переходе. Проверьте валидацию полей, права интеграции, состояние очереди и ответ CRM. Форма может принять запрос, а следующий этап — отклонить его из-за отсутствующего обязательного поля или утраченного доступа.
- Используйте стабильные идентификаторы, статусы и временные отметки.
- Показывайте посетителю подтверждение, соответствующее реально завершённому действию.
- Сделайте ошибки следующих этапов видимыми для ответственного.
Восстановите обращение без создания дубля
Перед повторной отправкой проверьте, не сохранила ли CRM запись. Соединение может оборваться после сохранения, но до получения ответа интеграцией. Повторное создание без проверки может создать дубль.
Используйте ключ идемпотентности, если система его поддерживает, или явное правило поиска дубля по запросу. Определите, какие ошибки допускают повтор, когда попытки прекращаются и кто разбирает окончательный отказ. Отсутствующее обязательное поле нужно исправить: повторная доставка сама его не добавит.
- Храните исходные данные защищённо и только необходимый срок.
- Перед повтором проверяйте частичное выполнение.
- Фиксируйте идентификатор восстановленной записи CRM и результат восстановления.
Закройте пробел в ежедневной работе
Сохранённую заявку тоже можно пропустить, если у неё нет ответственного или уведомление не дошло. Проверяйте назначение отдельно от создания и определите место разбора неудачных запросов. Ответственному нужен контекст для исправления, а не неограниченный доступ ко всем данным клиентов.
После исправления проверьте обычный запрос, дубль, отклонённое поле и недоступный внешний сервис в изолированной тестовой среде. Сверьте результат в CRM и сообщение посетителю. Затем наблюдайте за рабочим маршрутом с назначенным ответственным и правилами хранения записей.
Практический следующий шаг
Начните с маршрута, на котором сейчас теряется видимость. Мы можем проверить переходы, обработку ошибок и ответственность до предложения масштабной перестройки CRM.
Читайте также
Различайте принято, записано и уведомлено
Форма может успешно передать данные, а CRM отклонить их из-за обязательного поля или изменившегося доступа. CRM может создать запись, но уведомление команде не дойдет. У этих событий разные последствия: в первом случае нужно восстановить запись, во втором — повторить только уведомление.
Детали для внедрения
Определите обязательные поля на входе. Email проверяют на формат, но это не доказывает, что адрес существует. Телефон нормализуют, только когда известен код страны. Не придумывайте значения для пустого поля «компания». Оставьте его пустым или направьте обращение на уточнение с видимой причиной.
У одного контакта может быть несколько задач
Повторный клик по кнопке не должен создавать новую сделку. Но новая задача от того же клиента может быть отдельной возможностью. Поэтому сущности человека, компании, обращения и сделки — разные вещи. Правило «один email — одна сделка навсегда» приведет к потере повторных продаж.
Детали для внедрения
Для повторной доставки используйте стабильный идентификатор события из источника. Если источник его не предоставляет, согласуйте ограниченный способ распознавания повторов. Похожие имена или названия компаний — повод для ручной проверки, а не автоматического объединения. Сохраняйте ссылку на исходный источник, чтобы решение можно было пересмотреть.
У ошибки должен быть ответственный
Временный сбой можно повторить. Неверное поле или отозванный доступ повтором не исправляются. Установите лимит повторов и очередь обращений, требующих внимания. Для каждого сбоя показывайте этап, последнюю попытку и следующее действие без вывода секретов или полного текста обращения клиента в общий журнал.
Детали для внедрения
Уведомление должно ссылаться на запись, а не создавать вторую базу данных в чате. Согласуйте, кто проверяет очередь и за какой рабочий интервал. Это операционная договоренность с командой, а не гарантия, которую можно добавить одной программной настройкой.
Как принять первый небольшой запуск
Начните с одного источника, одного типа обращений и существующей CRM. Перед запуском проверьте стандартное обращение, пустое обязательное поле, повтор того же события, временную недоступность CRM и сбой уведомления после успешной записи. Тестовые контакты должны быть четко отделены от настоящих.
Детали для внедрения
Критерий приемки: обращение можно проследить от источника до ответственного, повтор не создает дубль, а у ошибки есть видимый следующий шаг. Отдельно измерьте количество принятых и завершенных событий за сопоставимый период. До таких замеров не стоит обещать процент роста продаж.