Заявка принята сайтом или уже появилась в CRM?
Посетитель нажал «Отправить», увидел благодарность и закрыл вкладку. Для него работа закончена. Для системы она только начинается: проверить поля, сохранить обращение, передать его в CRM, назначить ответственного и проконтролировать результат. Надёжность определяется всей этой цепочкой, а не зелёным уведомлением в браузере. Ниже разберём проектную схему, а не результаты вымышленного внедрения.
Сначала договоритесь о значении статусов. «Принята» означает, что заявка надёжно сохранена на стороне сайта. «Доставлена» означает, что интеграция получила подтверждение CRM и идентификатор карточки. «Требует внимания» сообщает о проблеме оператору. HTTP 202 сам по себе не подтверждает завершение обработки: это прямо определено в RFC 9110, раздел 15.3.3.
Сначала сохранение, потом доставка
Практический вариант для небольшого сервиса: записывать заявку и задание на отправку в одной транзакции базы данных. Отдельный обработчик забирает задания и обращается к CRM. Такой подход называется transactional outbox; проблему несогласованных записей в две системы объясняет документация AWS по transactional outbox. Использовать именно облако AWS для этого не требуется.
В записи доставки полезно хранить идентификатор заявки, состояние, число попыток, время следующей попытки, категорию последней ошибки и внешний идентификатор. Тело обращения хранится отдельно с ограниченным доступом. Обработчик должен переживать перезапуск: задание, взятое в работу, но не завершённое за установленный срок, возвращается на разбор. Простая очередь в памяти процесса этого свойства не обеспечивает.
Успешное сохранение не равно вечной сохранности. У базы должны быть резервные копии, мониторинг доступности и понятный срок хранения. Когда запись не удалась, сайт не показывает благодарность и не очищает заполненные поля. Пользователю нужен честный результат и возможность повторить действие, а не техническая трассировка ошибки.
Два вида дублей требуют разных решений
Технический дубль появляется при повторе одной отправки: двойном клике, повторном запросе или потере ответа. Для одной логической отправки используйте стабильный ключ идемпотентности. На сервере сохраняйте его вместе с отпечатком нормализованных полей; повтор с тем же ключом и другим содержимым отклоняйте как конфликт. Проверку уникальности выполняйте в базе, а не только предварительным поиском: PostgreSQL документирует ограничения UNIQUE, включая составные ключи.
Бизнес-дубль выглядит иначе: один человек сегодня спрашивает о сайте, а завтра о сопровождении. Склеивать такие обращения по телефону автоматически опасно. Контакт может быть общим, но интересы и сделки различаются. Правила объединения согласуют с продажами: какие поля сравнивать, за какой период и кто принимает окончательное решение.
Отдельный случай: CRM создала карточку, но ответ потерялся. Локальная защита от дублей не устраняет эту неопределённость. Проверьте, поддерживает ли конкретный API идемпотентность или уникальный внешний ключ. Если нет, потребуется сверка по идентификатору обращения, последовательная обработка и иногда ручное решение. Нельзя обещать создание строго одной карточки только на основании наличия очереди.
Чек-лист интеграции
- Перечислите все точки входа: контакты, калькулятор, модальные формы, мобильные версии и отдельные посадочные страницы. Для каждой укажите владельца и назначение полей.
- Проверяйте данные на сервере. Ограничьте длину текста, размер вложений и частоту обращений; секрет CRM не должен попадать в браузер.
- Разделите временные ошибки и ошибки данных. Повторы планируйте с увеличением интервала и случайным смещением, учитывая ограничения конкретного API.
- Не повторяйте бесконечно запрос с неверным полем или недействительным доступом. После установленного лимита переводите заявку в отдельный список с уведомлением ответственного.
- Сохраняйте источник страницы и допустимые маркетинговые метки, но не записывайте в журналы полные телефоны, сообщения и токены авторизации.
- Предусмотрите ручную повторную отправку с прежним ключом и журналом действий. Оператор должен видеть причину сбоя, а не создавать новое обращение наугад.
Типичные ошибки
Отключённая кнопка уменьшает случайные клики, но не защищает сервер от повторного запроса. Письмо менеджеру не заменяет сохранённую заявку: уведомление тоже может не доставиться. Ещё одна ошибка состоит в общем статусе «успех» для приёма формы, отправки письма и создания карточки. У каждого этапа должна быть собственная проверяемая отметка.
Критерии приёмки и наблюдение
Перед приёмкой отправьте тестовые обращения из каждой формы. Повторите один запрос одновременно, отключите тестовый доступ к CRM, перезапустите обработчик после сохранения и смоделируйте потерю ответа после создания карточки. Для каждого опыта заранее запишите ожидаемый результат. После восстановления связи заявки должны либо доставиться, либо оказаться в видимой очереди разбора, но не исчезнуть.
Проверяйте количество принятых и доставленных заявок, возраст самой старой ожидающей записи и число неоднозначных результатов. Согласуйте допустимую задержку с владельцем процесса. Проверка заканчивается открытием карточки менеджером: поля, источник, ответственный и содержание должны соответствовать форме. Эти сценарии полезно включить в проверки окружений и релизов, а требования к интеграции зафиксировать ещё на этапе разработки сайта.
Короткий FAQ
Нужен ли отдельный брокер для нескольких заявок в день?
Не обязательно. Таблица заданий и контролируемый обработчик могут быть достаточны. Важнее сохранность, повторяемость обработки и наблюдаемость, чем количество инфраструктурных компонентов.
Можно ли считать одинаковый телефон дублем?
Только сигналом для проверки. Один контакт может представлять несколько запросов, а корпоративным номером могут пользоваться разные люди.
Как проверить, что схема работает после запуска?
Проводить помеченную тестовую отправку, сверять её путь до CRM и регулярно разбирать очередь ошибок. Реальные персональные данные для такой проверки не нужны.