Как автоматизировать обработку входящих заявок из WhatsApp/Telegram

Когда руководитель говорит «у нас стоит бот в WhatsApp и Telegram, всё работает», он обычно видит только факт приёма сообщений. Но между «сообщение получено» и «сделка закрыта» — разрыв, который съедает до 30–35% лидов. Цифра не гипотетическая: агентство «Интериум» зафиксировало именно такой объём потерь до пересборки процесса. После того как выстроили сквозную логику от первого контакта до CRM, потери упали до 8–10%, а конверсия в сделку поднялась с 9–10% до 20–22%. Секрет не в выборе платформы, а в пяти полях, трёх ветках маршрутизации и четырёх метриках.

Пять полей, без которых воронка слепая

Когда заявка падает в CRM бесформенным «новый чат», вы не можете ответить на вопросы: какой канал приносит лучших клиентов, в какое время суток лиды уходят без ответа и сколько из них вообще достойны внимания менеджера. Ваша карточка лида из мессенджера обязана содержать минимум пять полей.

Без поля «канал» вы не узнаете, что Telegram даёт конверсию в сделку вдвое выше при вдвое меньшей стоимости лида. Без времени входа не увидите, что 15% заявок приходят после 21:00 и висят без ответа до утра. Без первого вопроса ваш «бот» просто пересылает текст менеджеру, а не принимает решение. Пять полей — это минимальный каркас для аналитики воронки, а не излишество.

Маршрутизация без менеджера: дерево решений

Почти в каждом чате менеджер сначала читает сообщение и только потом решает, что с ним делать. Это ручная сортировка, которая крадёт время и создаёт неравномерную загрузку. Схема ниже снимает эту работу с людей.

Горячий лид — сообщение содержит прямой запрос: «сколько стоит?», «в наличии?», «пришлите счёт». Алгоритм (простое правило или бот) немедленно создаёт сделку в CRM с высоким приоритетом и уведомляет конкретного менеджера. Время от входа до первого ответа сокращается до десятков секунд. Поле «квалификационный статус: горячий» уже проставлено.

Тёплый лид — человек интересуется, но без конкретики: «расскажите про условия», «как работает?». Бот задаёт два-три квалификационных вопроса: тип бизнеса, бюджет, сроки. Ответы записываются в карточку лида, статус становится «тёплый», и только после этого заявка назначается менеджеру. Вы получаете готовый контекст для разговора, а не просто «здравствуйте».

Нецелевой — спам, ошибка, повторное обращение по закрытой сделке. Система либо отправляет автоответ с контактом поддержки, либо закрывает диалог с пометкой «нецелевой», без создания сделки. Менеджер не отвлекается.

Эта развилка работает на практике: в кейсе ChatApp бот квалифицирует заявки с закрытого B2B-портала каждые 10 минут, распределяет по типам и без участия человека наполняет Bitrix24. Ручной мониторинг упал до нуля, а нужные менеджеры получили готовые карточки без потери времени.

Три архитектуры: что выбрать под масштаб

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

Агрегатор выигрывает по скорости: вы можете за день подключить оба канала и получить первые карточки лидов. Но когда поток перевалит за несколько сотен заявок в день, вы упрётесь в квоты и захотите глубже управлять данными. Нативная интеграция требует больше времени на старте, зато вы не зависите от вендора и строите любые отчёты на своей стороне. No-code — компромисс для тех, кто уже использует Make или n8n и готов поддерживать сценарии самостоятельно.

Заявка в 23:00: сценарий «мёртвой зоны»

Ночной лид — самый дорогой для потери. Клиент оставляет вопрос в 22:47, а менеджер видит его в 9:15 на фоне утренней очереди. К этому моменту человек уже написал конкурентам. Ваш процесс должен предусматривать fallback-логику без участия дежурного оператора.

Что происходит при корректном сценарии: бот принимает сообщение в нерабочее время, фиксирует время входа (поле обязательно), задаёт уточняющие вопросы, если лид тёплый, и создаёт карточку с квалификационным статусом. Менеджер получает уведомление с утра, но уже видит структурированный контекст, а не «прочитайте всю переписку». Время первого ответа в таком случае считается от утреннего входа менеджера, а не от ночного сообщения, но главное — лид не потерян, его данные уже в CRM.

Агентства, внедрившие подобную логику, сокращали долю лидов без ответа более часа с 25–35% до единичных процентов, причём именно за счёт обработки внеурочных сообщений. Инструментарий вторичен: это может быть условие в Make, скрипт в агрегаторе или штатный сценарий CRM — принцип один.

Четыре метрики для еженедельного дашборда

Вы не управляете тем, чего не измеряете. Четыре показателя дают руководителю полную картину здоровья канала и подсвечивают узкие места за минуту.

1. Время первого ответа (цель: <5 минут в рабочее время, <60 минут в нерабочее). Если медиана превышает 10–15 минут в часы пик, страдает конверсия. Именно этот показатель «Интериум» сжал с 2–3 часов до 15–20 минут и тем самым удвоил результат.
2. Доля лидов без ответа >1 часа (% от потока). Сигналит о перегрузке менеджеров или об отсутствии fallback-логики. Значение выше 5% требует немедленного разбора.
3. Конверсия канал→сделка по каждому мессенджеру отдельно. Без этого показателя вы не знаете, какой канал выгоднее масштабировать. Возможно, Telegram даёт клиентов с вдвое большей вероятностью закрытия — тогда именно туда стоит направить рекламный бюджет.
4. Доля квалифицированных лидов. Если бот пропускает много спама или, наоборот, отсекает интересантов, вы увидите это по резкому падению доли горячих и тёплых заявок. Норма — выше 70% от общего потока после фильтрации.

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

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

Хотите понять, где в вашем процессе теряются заявки из мессенджеров? Покажем на разборе — смотрим схему от первого сообщения до сделки.