Автоматизация заявок: как не терять лиды между сайтом, Telegram и CRM

Почему одного уведомления недостаточно

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

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

Какие данные сохранять вместе с лидом

Кроме имени и контакта важны страница входа, текущая страница, реферер, first-touch и last-touch UTM, yclid, выбранная услуга, источник кнопки и время отправки. Эти поля позволяют восстановить путь пользователя даже после переходов внутри сайта.

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

• request_id для поиска и удаления дублей;
• landing_page и referrer;
• utm_source, utm_medium, utm_campaign;
• yclid и ClientID Метрики, если настроена передача;
• статус доставки и статус качества обращения.

Маршрут от формы до менеджера

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

Менеджеру нужен не сырой набор полей, а короткая карточка: контакт, задача, источник, приоритет и ссылка на полную запись. AI-классификация может предложить тему и срочность, но не должна удалять или отклонять обращение без прозрачного правила.

Статусы качества и обратная связь

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

Яндекс Метрика поддерживает передачу офлайн-конверсий и данных из CRM. Это позволяет связывать последующие статусы с визитами и оценивать не только число форм, но и качество источников. Для привязки используются ClientID, UserID, yclid или PurchaseID.

Контрольный список перед запуском

Отправьте тестовые заявки с разных страниц и устройств. Проверьте дубли, длинные сообщения, невалидный контакт, таймаут Telegram, недоступность CRM и повторный запуск. Сверьте значения источников в записи и в Метрике.

После запуска нужен простой ежедневный сигнал: сколько форм принято, сколько доставлено, сколько осталось с ошибкой и каково среднее время первого ответа. Это полезнее сложного дашборда без контроля потерь.

• запись существует до внешней отправки;
• ошибки не содержат персональные данные в открытом журнале;
• повторная доставка не создаёт дубль;
• конверсия фиксируется после подтверждённого ответа сервера.