HTTP 200 ещё не означает доставленный лид: проектируем контракт приёмки

Форма может вернуть HTTP 200, очистить все поля и показать зелёное подтверждение, хотя заявка уже потеряна. Код ответа говорит только о завершении одного HTTP-обмена. Он не доказывает, что данные сохранены, менеджер получил уведомление, а CRM создала рабочую запись.

Определите приёмку как бизнес-состояние

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

{
  "accepted": true,
  "server_recorded": true,
  "manager_notified": true,
  "crm_synced": false,
  "submission_id": "stable-id"
}

Сохраняйте до обращения к внешним системам

Telegram, почта, CRM и webhook автоматизации — внешние зависимости. Они не отвечают вовремя, меняют токены, отклоняют payload и иногда возвращают промежуточный успех. Серверная запись даёт точку восстановления. В ней нужны исходный запрос, версия политики и согласие, landing page, UTM, referrer, время и попытки доставки — но не больше персональных данных, чем действительно требует процесс.

Делайте повторные запросы идемпотентными

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

Не скрывайте pending

Очищайте форму только после accepted. При pending или failed сохраняйте введённый текст, простыми словами объясняйте состояние и предлагайте безопасный повтор. Это не косметика: интерфейс не должен обещать то, чего backend ещё не выполнил.

Измеряйте приёмку, а не клик

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

Выпускайте с доказательством

1. Отправьте через production-страницу явно помеченную тестовую заявку.
2. Проверьте серверную запись и её стабильный идентификатор.
3. Проверьте фактическое уведомление менеджеру или запись CRM, а не mock-ответ.
4. Убедитесь, что атрибуция и согласие прошли весь маршрут.
5. Повторите тот же идентификатор и убедитесь, что уведомление не задублировалось.
6. Зафиксируйте релиз, тестовый ID, канал доставки и решение об очистке.

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