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

Отдел продаж редко теряет время на один большой «лишний» процесс. Обычно время утекает мелкими порциями: 4 минуты на ответ про доставку, 7 минут на уточнение тарифа, 12 минут на объяснение условий возврата, ещё 5 минут на поиск нужного шаблона. Если таких обращений 80–150 в день, повторяемые ответы превращаются в полноценную нагрузку на 1–2 сотрудников.

Я смотрю на ИИ-чат-бота в продажах не как на замену менеджера, а как на фильтр первого касания. Его нормальная зона ответственности, принять вопрос, понять намерение, дать ответ по базе знаний, собрать недостающие данные и вовремя передать диалог человеку. В зрелом сценарии такая настройка может экономить до 70% времени на первичной обработке типовых запросов. Но эта цифра появляется не от самого факта «мы поставили бота», а от правильной границы между автоматикой и живым менеджером.

Какие вопросы можно отдавать боту без риска для продаж

Первым делом я разделяю входящие обращения по цене ошибки. Вопрос «сколько длится пробный период» и вопрос «какой договор подойдёт для сети из 40 филиалов» требуют разного уровня ответственности. Бот хорошо работает там, где ответ опирается на заранее известное правило, а не на переговорную тактику.

Обычно в первичный контур попадают 20–40 повторяющихся тем: наличие товара, сроки доставки, способы оплаты, базовые тарифы, документы для оплаты, статус заявки, состав услуги, ограничения по региону, правила возврата, запись на демонстрацию. Для каждой темы нужен короткий эталонный ответ на 500–900 знаков, список уточняющих вопросов и критерий передачи менеджеру.

Тип обращения Что делает бот Когда передаёт менеджеру Ориентир по времени
Частый вопрос по условиям Даёт ответ из базы знаний Пользователь спорит с условием или просит исключение 10–30 секунд
Подбор решения Задаёт 3–5 уточнений Сумма, объём или требования выходят за типовой сценарий 1–3 минуты
Жалоба или конфликт Фиксирует суть, просит контакт Сразу после классификации намерения до 1 минуты
Запрос на скидку Собирает вводные Всегда передаёт человеку 1–2 минуты
Непонятный вопрос Просит переформулировать один раз После второго неудачного распознавания до 2 минут

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

База знаний: не склад документов, а набор проверяемых ответов

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

Я собираю базу знаний слоями. Первый слой, 30–60 коротких вопросов и ответов. Второй, таблица ограничений: регионы, сроки, минимальные суммы, исключения, стоп-слова. Третий, правила тона: когда отвечать кратко, когда задавать уточнение, когда не обещать результат. Если документов много, лучше сначала сделать выжимку по каждому разделу на 1–2 страницы. Нейросеть хорошо помогает превращать длинные инструкции в черновики FAQ, но финальную версию должен проверить человек, который отвечает за продажи или поддержку.

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

Рабочий шаблон карточки знания выглядит так:

  1. Вопрос пользователя в естественной форме.
  2. Допустимые синонимы и похожие формулировки.
  3. Короткий ответ до 700 знаков.
  4. Что нельзя обещать.
  5. Какие данные запросить, если их не хватает.
  6. Условие передачи менеджеру.
  7. Дата последней проверки ответа.

Дата проверки нужна практично. В продажах меняются цены, регионы, складские остатки, юридические формулировки. Если у карточки нет владельца и даты, через 2–3 месяца она начинает стареть.

Сценарий передачи менеджеру: где автоматика должна остановиться

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

Первая группа, коммерческие триггеры: скидка, индивидуальные условия, крупный объём, партнёрство, тендер, договор с нестандартными правками. Вторая, эмоциональные: жалоба, раздражение, угроза ухода, негативный отзыв. Третья, юридические и финансовые: возврат денег, персональные данные, счёт с особыми реквизитами, спор по оплате. Четвёртая, техническая неопределённость: бот не уверен в ответе, пользователь дважды уточняет одно и то же, в базе знаний есть противоречие.

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

Условный пример: интернет-магазин мебели получает 120 обращений в день, из них 45 вопросов касаются доставки, подъёма и сборки. Если бот закрывает 70% этих 45 диалогов за 30 секунд, менеджеры освобождают около 2–3 часов в день только на одном блоке FAQ. Здесь нет магии. Экономия возникает потому, что человек перестаёт копировать один и тот же текст и переключаться между вкладками.

Как выглядит рабочий контур обработки

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

  1. Пользователь пишет вопрос.
  2. Бот определяет намерение и сверяет его с базой знаний.
  3. Если данных хватает, формирует короткий ответ и предлагает следующий шаг.
  4. Если данных не хватает, задаёт один уточняющий вопрос.
  5. Если вопрос сложный, бот собирает резюме: тема, запрос, контакт, срочность, уже заданные ответы.
  6. Менеджер получает не сырой диалог на 25 сообщений, а сжатую карточку на 5–7 строк.

Для текстовых заготовок полезна отдельная библиотека форматов. Разбор того, как нейросети помогают создавать структурированные черновики и проверять результат, есть в материале про генерацию текста нейросетью. В продажах это особенно заметно на однотипных ответах: приветствие, уточнение, аргумент, ограничение, мягкий переход к менеджеру.

Где использовать SoftChat в такой работе

SoftChat не надо представлять как готовую CRM-систему для маршрутизации лидов. По каталогу продукта это веб-приложение с ИИ-чатом, историей разговоров, переключением моделей в рамках беседы, шаблонами промптов, системными промптами и пользовательскими ассистентами. Поэтому я бы использовал его на этапе подготовки и тестирования сценариев: собрать роль ассистента, проверить ответы на типовые вопросы, сравнить поведение разных моделей в одной задаче, сохранить удачные стартовые промпты.

В SoftChat можно подключить сохранённого ассистента к открытому чату через раздел «Ассистенты», а выбранная модель при этом не меняется. Это удобно для редакционной проверки: один и тот же набор вопросов можно прогнать через роль «первичная квалификация лида» или «оператор FAQ» и посмотреть, где формулировки слишком длинные, где бот рано зовёт менеджера, а где опасно обещает лишнее.

Ещё одна полезная для прототипирования деталь, расширенные настройки чата показываются в зависимости от выбранной модели. Для текста доступны понятные параметры вроде «Креативность» и «Длина ответа». Это помогает тестировать разные режимы: короткий ответ для виджета, более подробное объяснение для письма, строгий тон для юридически чувствительных тем. При этом я не привязываю такие тесты к конкретному каналу внедрения. Боевой бот на сайте, в мессенджере или внутри CRM проектируется отдельно.

Если команда только привыкает к ИИ-инструментам, полезно сначала разобрать бытовые сценарии. В статье про нейросети и чат-боты для повседневных задач хорошо видна базовая логика: повторяемая задача, понятный вход, проверяемый выход. В продажах принцип тот же, просто цена ошибки выше.

Метрики, без которых бот быстро превращается в игрушку

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

Минимальный набор метрик на пилоте:

Метрика Как считать Хороший сигнал
Доля автоматических ответов Ответы бота без участия менеджера / все обращения 30–60% на первом месяце
Точность передачи Переданные диалоги, где менеджер действительно нужен выше 80%
Среднее время первого ответа От сообщения до первого содержательного ответа до 1 минуты для FAQ
Доля исправленных ответов Сколько ответов менеджер поправил после бота ниже 10–15% после обучения базы
Повторные уточнения Пользователь повторяет вопрос после ответа снижение от недели к неделе

Компания из сферы логистики, ~200 сотрудников, может начать с 15 тем: тариф по направлению, сроки доставки, документы, статус груза, претензия. Если вручную первичная сортировка занимает 6 минут на обращение, то 100 обращений в день дают 10 часов работы. Даже автоматизация половины типовых вопросов освобождает рабочий день одного специалиста. Это грубая оценка, но она хорошо показывает порядок величины.

Частые ошибки при настройке

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

Вторая ошибка, не хранить неудачные диалоги. Для улучшения нужны 30–50 примеров плохих ответов: где бот не понял вопрос, где ответил длинно, где не передал диалог. Их надо разбирать раз в неделю и править карточки знаний. Это быстрее, чем спорить абстрактно о качестве модели.

Третья ошибка, запускать бота сразу на всех пользователей. Я предпочитаю пилот на 10–20% трафика или на одном канале, например только форма консультации. За 7–14 дней обычно видно, какие темы закрываются уверенно, а какие надо убирать из автоматического контура.

Отдельная тема, обучение сотрудников. Менеджерам надо объяснить, что бот не забирает у них продажи, а снимает первичный шум. Если человек получает уже собранное резюме и контакт, ему проще перейти к сути. Для внутренних тренировок можно использовать подход из статьи про нейросети в образовании и саморазвитии: модель выступает тренажёром, а не источником истины.

Что бы я сделал на вашем месте

Я бы начал не с выбора платформы, а с выгрузки 200–300 последних обращений и ручной разметки. На это уходит несколько часов, зато сразу видно, где деньги. Если 40% вопросов повторяются, бот имеет смысл. Если каждое обращение нестандартное, лучше настроить генерацию черновиков для менеджера, а не автоматические ответы пользователю.

Дальше я бы собрал 30 карточек знаний, написал правила передачи человеку и прогнал 50 тестовых диалогов. После этого можно считать экономику: время первого ответа, доля автозакрытия, число ошибок, нагрузка на менеджеров. Когда цифры сходятся, расширяем базу до 60–100 тем. Когда не сходятся, режем сценарий до узкой зоны, где бот отвечает уверенно.

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