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