Про ботов для приёма заявок написано на удивление мало: ни одной разобранной статьи, только ссылка на чужого бота и два видеоролика. Тему обсуждают, но по существу никто не разбирал.
А разбирать есть что. Потому что бот, который «принимает заявки», и бот, после которого заявки перестают теряться, — это два разных бота, и разница не в форме, а в том, что происходит после нажатия кнопки «отправить».
Заявки теряются не там, где их ищут
Когда владелец бизнеса говорит «у нас теряются заявки», он обычно представляет одну картину: человек написал, а ему не ответили. На практике это только один из пяти сценариев, и далеко не самый частый.
Вот полный путь заявки. Обратите внимание, сколько в нём стыков — каждый стык это место, где что-то может не доехать.
Дальше — пять конкретных мест, где лиды исчезают. Все пять я встречал в работе, и все пять чинятся, если знать о них заранее.
Место первое: человек бросил форму на середине
Самая обидная потеря, потому что клиент уже пришёл и уже начал отвечать.
Бот задаёт вопрос за вопросом: имя, телефон, город, бюджет, откуда узнали, удобное время звонка. К четвёртому вопросу человек понимает, что это анкета, а не разговор, и закрывает чат. Для системы такой диалог не существует: заявка не создана, данных нет, менеджер ничего не увидел.
Лечится это двумя решениями сразу.
Спрашивать только то, без чего нельзя перезвонить. Обычно это два-три вопроса. Всё остальное менеджер выяснит голосом за минуту, и выяснит лучше бота. Каждый лишний вопрос — это шанс потерять человека, который уже был готов оставить контакт.
Сохранять недозаполненные диалоги. Если человек назвал имя и телефон, а на третьем вопросе ушёл, — у вас уже есть лид. Технически это значит, что бот пишет данные по мере поступления, а не одним пакетом в конце. Разница в архитектуре небольшая, разница в результате заметная: половина «брошенных» диалогов превращается в звонок.
Место второе: заявка принята, но её никто не увидел
Классика: бот работает, база растёт, а менеджеры говорят, что заявок нет.
Причин обычно три:
- уведомление ушло в общий чат, где за день проходит две сотни сообщений, и заявка утонула между обсуждением поставки и мемом;
- уведомление ушло одному человеку, который в отпуске;
- уведомление пришло, но по нему непонятно, взял ли кто-то заявку — все видят, каждый думает, что возьмёт другой.
Третья причина самая коварная, потому что выглядит как работающая система. Лечится она одной деталью: у уведомления должна быть кнопка «беру». Нажатие превращает сообщение из объявления в закреплённую ответственность — видно, кто взял и когда. В Telegram это обычная кнопка под сообщением, технически она описана в документации Bot API и делается за час.
Если людей больше двух, кнопки уже мало и нужна CRM. Но начинать стоит с кнопки: она стоит час работы и закрывает большую часть проблемы.
Место третье: дубли
Человек нажал кнопку, ничего не произошло за секунду, он нажал ещё дважды. В системе три заявки от одного человека.
Менеджер видит три карточки, звонит по первой, потом выясняет, что вторая и третья — та же, тратит время и портит статистику. Если заявок много, дубли ещё и ломают отчётность: непонятно, сколько обращений было на самом деле.
Правильное решение — склейка по устойчивому признаку: телефону, идентификатору пользователя в мессенджере или паре «человек плюс окно времени в несколько минут». Второе обращение от того же человека присоединяется к первому, а не создаёт новое.
Это ровно тот класс задач, где бот из конструктора обычно упирается в потолок: логика «проверить, есть ли уже такая заявка, и если есть — дополнить» выходит за рамки дерева кнопок. Подробнее о том, где именно проходит эта граница, — в статье конструктор чат-ботов или разработка.
Место четвёртое: CRM была недоступна
Самая тихая потеря из всех, потому что о ней никто не узнаёт.
Бот принял заявку, отправил её в CRM, CRM в этот момент обновлялась или отвечала ошибкой. Бот получил отказ — и всё. Клиенту он уже сказал «спасибо, приняли», менеджеру не пришло ничего, в системе пусто. Заявка исчезла бесследно, и вы никогда не узнаете, что она была.
Лечится очередью и повторами. Схема простая по смыслу и обязательная по важности:
- 1Сначала сохранить у себяЗаявка пишется в собственное хранилище до всякой отправки во внешние системы
- 2Потом отправить в CRMУспех — отмечаем доставленной. Ошибка — оставляем в очереди
- 3Повторить с задержкойНесколько попыток с нарастающим интервалом: сервисы чаще недоступны минуты, а не часы
- 4Не смогли — сказать вслухУведомление ответственному, а не молчание. Тихая потеря хуже видимой ошибки
Тот же принцип действует и с уведомлениями: если мессенджер вернул ошибку, сообщение должно уйти повторно, а не потеряться. Про другие способы, которыми боты ломаются уже после запуска, писал отдельно — почему чат-бот не работает.
Место пятое: заявка пришла ночью
Формально она не потеряна: лежит и ждёт утра. Фактически — потеряна примерно наполовину, потому что человек за ночь успевает написать ещё двоим.
Здесь бот даёт самый простой и самый заметный выигрыш, и для этого не нужен ни ИИ, ни интеграции. Достаточно двух вещей:
Мгновенное подтверждение с честным сроком. Не «спасибо за обращение», а «получили, ответим до 11 утра». Человек перестаёт гадать, дошло ли, и с большой вероятностью дожидается вас.
Сбор данных ночью, чтобы утром сразу работать. Пока менеджер спит, бот выясняет, что нужно, в каком объёме и когда удобно созвониться. Утром менеджер открывает не строчку «Иван, +7…», а заполненную карточку и начинает с решения, а не с расспросов.
Отдельно стоит выделять срочные обращения — по ключевым словам или по прямому вопросу «это срочно?». Тогда ночная заявка от человека, у которого прорвало трубу, не окажется в одной куче с вопросом про прайс.
Если ночью нужно не просто принять заявку, а ещё и квалифицировать её по вашим критериям и завести сделку в CRM, это уже работа для агента, а не для бота. Разница разобрана в статье про ИИ-агентов для продаж — там же расчёт, во сколько обходится такой ночной приём.
Что должно быть в боте приёма заявок
Сведём разбор в проверочный список. По нему удобно сверять и своего бота, и предложение подрядчика.
| Что | Зачем | Что будет без этого |
|---|---|---|
| Два-три вопроса, не больше | Человек не бросает диалог | Половина уходит на середине анкеты |
| Сохранение по ходу | Недозаполненная заявка тоже лид | Брошенный диалог исчезает бесследно |
| Мгновенное подтверждение | Человек знает, что дошло | Пишет конкуренту, пока ждёт |
| Кнопка «беру» в уведомлении | Видно, кто взял заявку | Все видят, никто не берёт |
| Склейка дублей | Одна заявка вместо трёх | Менеджер звонит по одному лиду трижды |
| Своё хранилище до CRM | Заявка переживёт сбой | Тихая потеря, о которой не узнают |
| Повторы при ошибке | Доставка после сбоя | Заявка теряется на минутной недоступности |
| Отметка срочности | Срочное не лежит в общей куче | Пожар обнаруживают утром |
Список выглядит длинным, но половина пунктов — это часы работы, а не недели. Дорогими становятся только связи с внешними системами, и то не всегда.
Когда бот для заявок не нужен
Честный раздел, потому что бот окупается не всегда.
- Две-три заявки в неделю
- Все приходят в рабочее время
- Вы отвечаете сами и сразу
- Каждое обращение нестандартное
- Клиенту важно живое общение с первой минуты
- Поток от нескольких заявок в день
- Заметная часть приходит ночью и в выходные
- Обращения однотипные по первым вопросам
- Заявки приходят из нескольких каналов сразу
- Есть кому передавать готовую заявку
Ещё один случай, когда бот не решает задачу: если заявки теряются не при приёме, а при обработке. Бот доставит их идеально, а дальше они всё равно будут неделю висеть без звонка. Это уже не про автоматизацию, а про процесс — и бот тут не поможет, только сделает проблему заметнее.
Как оценить, нужен ли бот в принципе и когда он окупается, разбирал подробно в статье нужен ли бизнесу чат-бот. А если решение уже принято и вопрос в том, где такой бот делать, — на странице разработка чат-ботов описано, как проходит работа и что входит в неё.
Что делаю я
Начинаю не с бота, а с того, как заявки приходят сейчас: из каких каналов, в какое время, куда попадают и на каком шаге останавливаются. Обычно уже на этом разговоре видно, где именно течёт, — и иногда выясняется, что дырка чинится настройкой уведомлений, а не разработкой.
Если бот нужен, делаю его с той обвязкой, о которой была вся статья: сохранение до отправки во внешние системы, повторы при сбоях, склейка дублей и внятное уведомление с ответственным. Код и доступы остаются у вас.
