Заявка не должна теряться между формой и CRM

Опишите путь одной заявки

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

Это схема процесса, а не готовая интеграция с конкретным API. Имена полей, способ авторизации и ответы системы проверяются по документации выбранного сервиса.

Что делать с повтором

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

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

Запланируйте сбой заранее

• Нет обязательного поля — поместить заявку в очередь ручной проверки.
• Система временно недоступна — ограниченное число повторов с паузой.
• Неверные права доступа — уведомить ответственного, не повторять бесконечно.
• Заявка не обработана в установленный срок — поднять сигнал.

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

Пять проверок перед включением

1. Обычная заявка появляется в нужном месте.
2. Повтор того же события не создаёт вторую запись.
3. Необязательное пустое поле не ломает передачу.
4. Сбой системы обнаруживается и виден ответственному.
5. После восстановления заявка доходит до конечного состояния.