Кейс-подход: CRM подключена, но заявки всё равно теряются

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

Разбирать нужно не факт наличия CRM, а качество маршрута заявки.

Шаг 1. Проверить создание сущности

После тестовой отправки нужно найти конкретный лид, сделку или контакт в CRM. Не “вроде должно быть”, а реальный ID.

Заявка с сайта: 1250
CRM lead ID: 88431
Статус передачи: success

Если ID не фиксируется на сайте, диагностика становится сложнее. Лучше сохранять внешний ID рядом с локальной заявкой.

Шаг 2. Проверить поля

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

Проверять нужно:

• имя;
• телефон;
• email;
• комментарий;
• услугу или товар;
• страницу заявки;
• UTM-метки;
• город или регион, если важно.

Шаг 3. Проверить ответственного

Заявка может попасть в CRM, но остаться без ответственного или уйти не тому отделу. Тогда формально она есть, но фактически не обработана.

Ответственный: не назначен
Воронка: общая
Стадия: новая заявка

Нужно проверить правила распределения, отделы, воронки и уведомления.

Шаг 4. Проверить уведомления

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

Шаг 5. Проверить ошибки API

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

[
    'crm_method' => 'lead.add',
    'http_code' => 400,
    'error' => 'PHONE is invalid',
]

Такие ошибки должны попадать в лог и статус заявки.

Шаг 6. Проверить дубли

CRM может объединять заявки с существующим контактом, создавать повторные лиды или отклонять дубль. Все варианты должны быть понятны бизнесу.

Если дубль просто пропускается без уведомления, менеджер может не узнать о новом обращении старого клиента.

Шаг 7. Проверить обратную аналитику

Заявка должна не только попасть в CRM, но и вернуться в отчёты: источник, качество, статус обработки, продажа или отказ. Иначе бизнес видит только количество форм, но не результат.

Чек-лист

1. После тестовой заявки найти конкретный ID в CRM.
2. Проверить заполнение всех важных полей.
3. Проверить воронку и стадию.
4. Проверить ответственного.
5. Проверить уведомление менеджера.
6. Проверить ошибки API и статус передачи.
7. Проверить обработку дублей.
8. Проверить передачу источников и UTM.
9. Связать CRM-статусы с аналитикой.

CRM не гарантирует порядок сама по себе. Порядок появляется, когда заявка проходит проверяемый маршрут: сайт, CRM, ответственный, статус, уведомление, обработка и отчёт.