Как найти потерянные заявки между сайтом, мессенджерами и CRM

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

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

Не начинайте с покупки новой CRM. Сначала определите, какие обращения текущий процесс вообще учитывает и какие остаются за его пределами.

2. Проверьте доставку, а не только отправку

Для тестовой заявки сопоставьте подтверждение на сайте, получение в выбранном канале и запись в CRM. Проверьте, сохранились ли контакт, текст сообщения и источник. Для звонка — куда он поступил и что происходит с пропущенным вызовом.

Сообщите команде, что проводите проверку, и пометьте тестовые обращения. Не включайте их в отчёты о реальных лидах.

• Отправка прошла, но получателя нет: проверьте доставку и интеграцию.
• Обращение получено, но в CRM его нет: проверьте правила регистрации.
• Запись появилась дважды: проверьте дубли и способы объединения контактов.

3. Установите, кто отвечает за первый шаг

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

В кейсе HANSA работа включала виджеты распределения заявок и общие процессы в Bitrix24. Сам принцип применим шире конкретной платформы: у обращения должен быть понятный маршрут и ответственный. Публичный кейс не содержит числовой оценки скорости ответа, поэтому её нельзя использовать как ориентир.

4. Посмотрите дальше первого ответа

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

Запись «в работе» без следующего действия мало помогает управлению. При этом количество обязательных полей должно соответствовать тому, что действительно нужно сотруднику и руководителю.

5. Соберите короткий журнал проверки

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

• Источник и время обращения.
• Где и когда оно было получено.
• Назначенный ответственный и время первого ответа.
• Текущий этап, следующее действие и причина остановки.
• Техническая ошибка или пропуск в процессе, если они подтверждены.

Что исправлять по результатам

Сбой передачи требует проверки интеграции. Отсутствие ответственного — правил распределения. Забытое продолжение разговора — задачи и понятного порядка работы. Если источник не сохраняется, нужно исправить учёт, чтобы оценивать результат привлечения.

В Treejar реклама, WhatsApp, звонки и формы связывались с CRM и аналитикой, а распределение и передача данных автоматизировались. Это пример согласованной работы нескольких частей процесса. В вашем случае объём изменений определяется найденными потерями.

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

Опыт в проектах

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