Как настроить ИИ-бота для заявок и отчётов
Разбираю рабочую схему: что отдавать боту, где ставить проверку и как не превратить автоматизацию в источник ошибок.
ИИ-бот для частых вопросов, отчётов и заявок не начинается с выбора модели. Я начинаю с карты процесса: какие входящие сообщения повторяются, какие данные нужны на выходе, где ошибка стоит денег, а где достаточно черновика. Если пропустить этот шаг, бот будет красиво отвечать на тестах и ломаться на реальных формулировках клиентов: «акт потерялся», «поменяйте реквизиты», «где статус по заказу», «срочно на завтра».
В этой статье я разбираю настройку как пайплайн: вход, классификация, промпт, база знаний, проверка, выгрузка. Такой подход подходит для поддержки, отдела продаж, бэк-офиса, обучения сотрудников и внутренних сервисных заявок. Если вы только начинаете применять нейросети в работе, сначала полезно посмотреть на общую схему внедрения ИИ в процессы, а здесь мы пойдём глубже, до полей отчёта и правил эскалации.
Что можно автоматизировать без участия менеджера
Я делю задачи на три группы по риску. Первая группа, ответы на повторяющиеся вопросы: график работы, правила возврата, список документов, статус типовой заявки, инструкция по оплате. Здесь бот может закрывать большую долю обращений, если у него есть свежая база знаний и запрет на фантазии.
Вторая группа, заполнение отчётов. Нейросеть хорошо вытаскивает из текста дату, сумму, тему обращения, категорию, ответственного, срочность, следующий шаг. Дальше эти данные можно передать в таблицу, CRM или внутреннюю систему, если в компании уже есть технический слой для интеграции. Само подключение к конкретным внешним сервисам зависит от вашей инфраструктуры, поэтому я не привязываю этот блок к одному продукту.
Третья группа, обработка заявок. Здесь бот принимает текст, уточняет недостающие поля, классифицирует запрос и решает, что делать дальше: ответить по инструкции, отправить на ручную проверку, попросить документ, пометить как срочное. В сценариях с деньгами, договорами, персональными данными и юридическими формулировками я оставляю человека в контуре. Не постоянно, а на точках риска.
| Задача | Что делает бот | Что проверяет человек | Типовой порог автоматизации |
|---|---|---|---|
| Частые вопросы | Находит ответ в базе знаний и формулирует короткий ответ | Новые или спорные вопросы | 70–90% типовых обращений после настройки базы |
| Отчёты | Извлекает поля из сообщений и собирает строку отчёта | Аномалии, пустые поля, суммы | Черновик за минуты вместо ручного переноса |
| Заявки | Классифицирует, уточняет данные, ставит статус | Высокий риск, жалобы, нестандартные условия | Автообработка простых заявок, ручная эскалация сложных |
| Внутренние инструкции | Даёт сотруднику шаги по регламенту | Изменения регламента | Хорошо работает при базе из 20–100 документов |
Схема пайплайна: от сообщения до действия
Автоматизация держится на последовательности. Если бот сразу «отвечает клиенту», без промежуточных проверок, вы теряете контроль. Я использую более скучную, зато управляемую схему.
- Входящее сообщение попадает в очередь.
- Бот определяет тип запроса: вопрос, жалоба, заявка, отчёт, мусор, дубль.
- Система подставляет нужный промпт и нужный фрагмент базы знаний.
- Нейросеть формирует ответ или структурированный черновик.
- Правила проверяют уверенность, полноту полей и запретные темы.
- Результат уходит в канал ответа, таблицу, карточку заявки или на ручную проверку.
Для примера: если входящее сообщение содержит фразу «верните деньги» и сумму 18 400 рублей, я бы не отдавал такой запрос на полный автопилот, даже если бот нашёл пункт регламента. Лучше присвоить категорию «возврат», заполнить поля, подготовить черновик ответа и отправить менеджеру.
При проектировании удобно держать рядом материал про нейросети в повседневных задачах: там хорошо видна разница между разовым вопросом и процессом, который повторяется десятки раз в неделю.
База знаний: меньше текстов, больше правил применения
База знаний для ИИ-бота, это не папка со всеми документами компании. Я бы начал с 30–50 реальных обращений за последний месяц и выделил из них повторяющиеся намерения. Обычно быстро появляются группы: оплата, доставка, документы, доступ, возврат, перенос сроков, техническая ошибка, консультация перед покупкой.
После этого для каждой группы нужен короткий рабочий блок:
- что бот имеет право отвечать сам;
- какие факты он должен запросить, если данных не хватает;
- какие слова или условия отправляют обращение человеку;
- какой тон использовать;
- какую ссылку или инструкцию дать в финале.
Плохая база знаний выглядит так: «Отвечай клиентам вежливо, опирайся на регламент». Хорошая база звучит иначе: «Если клиент спрашивает про закрывающие документы, уточни ИНН или номер заказа. Если номер есть, сформируй ответ со списком документов. Если клиент пишет о расхождении суммы, передай обращение бухгалтерии».
Для текстовых заготовок полезна логика из статьи про генерацию текста нейросетью и проверку результата: сначала черновик, затем критика, затем финальная версия. В ботах это превращается в цепочку «извлеки данные», «проверь пробелы», «сформулируй ответ».
Промпты для трёх рабочих сценариев
Я не люблю универсальные промпты на полстраницы. Они быстро разрастаются, конфликтуют сами с собой и плохо поддерживаются. Лучше сделать несколько коротких шаблонов под разные шаги.
Промпт для классификации обращения
Определи тип входящего сообщения. Верни только JSON с полями: категория, срочность, недостающие_данные, нужна_проверка_человеком, причина. Категории: вопрос, заявка, жалоба, отчёт, дубль, другое. Если есть риск по деньгам, договору, персональным данным или конфликту, поставь нужна_проверка_человеком: да.
Промпт для ответа на частый вопрос
Ответь пользователю коротко и по делу. Используй только факты из базы знаний ниже. Если ответа нет, не придумывай. Задай один уточняющий вопрос или передай обращение человеку. Тон: спокойный, деловой, без обещаний, которых нет в базе.
Промпт для отчёта
Извлеки из сообщения поля: дата, клиент, тема, сумма, статус, следующий шаг, ответственный, риск. Если поля нет, поставь null. Не меняй суммы и даты. В конце добавь краткое резюме до 20 слов.
Условный пример: при 120 входящих обращениях в день и 8 повторяющихся категориях команда может начать с автоклассификации, а ответы включать позже, когда накопится статистика ошибок за 1–2 недели. Это снижает риск: сначала бот раскладывает поток, затем получает право отвечать на безопасные классы.
Отчёты: как превратить переписку в строки данных
Отчётность ломается не из-за сложности таблицы, а из-за неодинаковых формулировок. Один сотрудник пишет «не оплатили», другой пишет «долг», третий пишет «счёт висит». Для человека это очевидно, для таблицы это три разных текста. Нейросеть помогает привести их к одной категории.
Я обычно задаю отчёт как схему, где каждое поле имеет тип и правило заполнения. Например:
| Поле | Тип | Правило |
|---|---|---|
| Дата обращения | дата | Брать из сообщения, если даты нет, ставить дату получения |
| Категория | список | Выбрать из заранее заданных категорий |
| Сумма | число | Не округлять, не пересчитывать валюты без отдельного правила |
| Срочность | список | Низкая, обычная, высокая, критичная |
| Следующий шаг | текст | Одно действие, без длинного пересказа |
| Проверка человеком | да/нет | Да, если есть спор, деньги, персональные данные или жалоба |
Гипотетический пример: интернет-магазин с 35 сотрудниками получает 300 сообщений в будний день, из них 90 связаны с доставкой и документами. В такой ситуации бот может сначала заполнять отчётные строки по этим двум категориям, а ответы клиентам оставить менеджеру до проверки точности на выборке за неделю.
Для обучения команды я бы добавил внутреннюю инструкцию в формате «что считать ошибкой». В ней должны быть 10–15 примеров: неверная категория, потерянная сумма, слишком уверенный ответ, отсутствие эскалации, лишнее обещание. Похожий подход используется в самообучении: статья про нейросети в образовании и самопроверку хорошо показывает, почему проверка результата важнее красивого ответа.
Обработка заявок: правила эскалации важнее красоты ответа
В заявках я ставлю несколько стоп-сигналов. Бот не должен самостоятельно решать спорные деньги, менять условия договора, обещать компенсацию, трактовать юридический текст, обрабатывать чувствительные данные без правил компании. Он может собрать факты, задать уточняющий вопрос, присвоить категорию, подготовить черновик и передать человеку.
Минимальный набор полей для заявки:
- источник обращения;
- имя или идентификатор клиента, если он уже есть в системе;
- тема;
- категория;
- описание проблемы в 1–2 предложениях;
- срочность;
- недостающие данные;
- рекомендуемое действие;
- причина эскалации.
Для примера: если клиент пишет «доступ пропал», бот может уточнить почту аккаунта и время ошибки, затем создать черновик заявки с категорией «доступ». Если клиент пишет «удалите все мои данные», бот должен передать запрос по регламенту, потому что здесь нужен контролируемый процесс.
Небольшие нестандартные сценарии тоже бывают полезны. В статье о необычных способах использовать ИИ-чатбота есть идеи для тренировки мышления, но в операционном контуре я оставляю только те сценарии, где понятны вход, выход и проверка.
Где здесь помогает SoftChat
SoftChat я бы использовал как рабочую среду для проектирования роли бота, тестирования промптов и сравнения поведения моделей в диалоге. В веб-чате можно вести разговоры с историей, переключать модель для конкретной беседы и настраивать параметры ответа через понятные настройки вроде «Креативность» и «Длина ответа». Это удобно на этапе, когда команда ещё не пишет интеграции, а проверяет, какие формулировки дают стабильный результат.
Для повторяемых сценариев полезны шаблоны промптов: один шаблон для классификации, второй для отчётной строки, третий для черновика ответа. Если у команды есть сохранённые ассистенты, их можно подключать к открытому чату через меню «Инструменты». Активный ассистент задаёт роль текущему разговору, а выбранная модель при этом не меняется. Так проще сравнивать: меняется инструкция, модель или входные данные.
В SoftChat есть память о пользователе для авторизованных пользователей. Её можно применять осторожно в личных рабочих сценариях: например, сохранить предпочтение по стилю ответа или формат резюме. Для клиентских заявок я бы не переносил в память сырые обращения. Там нужны отдельные правила хранения, согласования и удаления данных в вашей инфраструктуре.
Как измерять качество до запуска на автопилоте
Я не запускаю бота сразу на весь поток. Сначала беру выборку обращений и считаю ошибки вручную. Размер выборки зависит от риска, но для первого теста обычно хватает 100–200 сообщений, чтобы увидеть повторяющиеся сбои: неверная категория, лишнее обещание, потерянная сумма, отсутствие уточняющего вопроса.
Метрики должны быть простыми:
| Метрика | Как считать | Зачем нужна |
|---|---|---|
| Точность классификации | Верная категория / все проверенные обращения | Показывает, можно ли доверять маршрутизации |
| Полнота полей | Заполненные нужные поля / все нужные поля | Нужна для отчётов и заявок |
| Доля эскалаций | Передано человеку / все обращения | Помогает не перегрузить менеджеров |
| Ошибочные автоответы | Неверные ответы / все автоответы | Главный риск для клиентского опыта |
| Среднее время обработки | Время до готового ответа или черновика | Показывает реальную экономию времени |
Модельный кейс: компания из сферы онлайн-услуг, ~50 сотрудников, тестирует бота на 200 обращениях за неделю и разрешает автоответ только для категорий, где нет ошибок в 30 подряд проверенных примерах. Это жёсткое правило, зато оно защищает от раннего запуска на слабой базе.
После первого теста я правлю не модель, а инструкцию. В 7 случаях из 10 проблема сидит в расплывчатом промпте, устаревшем регламенте или неописанном исключении. Смена модели помогает, но не заменяет нормальную схему данных и правила эскалации.
Что бы я сделал на вашем месте
Я бы не начинал с большого бота «для всего отдела». Сначала выбрал бы один поток: например, вопросы по документам или внутренние заявки на доступ. Затем собрал бы 100 реальных сообщений без лишних персональных данных, разметил категории, написал 3 промпта и прогнал тест. Если бот стабильно классифицирует поток и аккуратно заполняет поля, можно дать ему право готовить черновики ответов. Полный автоответ, только после проверки на безопасных категориях.
Хороший ИИ-бот не заменяет процесс. Он делает процесс видимым: какие вопросы повторяются, где не хватает регламента, какие заявки всегда уходят на ручное решение. Когда это видно в цифрах, автоматизация перестаёт быть экспериментом и становится обычной инженерной работой.