ИИ-агент или чат-бот и как выбрать решение под задачу бизнеса
Что компании имеют в виду под словами «умный бот»
Разговор о внедрении ИИ в компании обычно начинается с фразы «нам нужен умный бот» . Дальше каждый понимает её по-своему. Владелец представляет сотрудника, который сам отвечает клиентам, заводит сделки и помнит все прайсы. Маркетолог думает о виджете на сайте с приветствием и тремя кнопками. Программист мысленно уже прикидывает, к каким системам придётся подключаться.
Путаница понятная. Словом «бот» сейчас называют очень разные вещи: от меню в мессенджере до программы, которая сама ходитяё в CRM и склад. Разница между ними огромная и по сложности, и по сроку запуска, и по объёму будущей поддержки. Ошибиться можно в обе стороны. Компания либо переплачивает за агента там, где справилось бы простое меню, либо годами мучает клиентов кнопками, хотя их вопросы давно в кнопки не помещаются.
Показательно, что сами разработчики нередко отговаривают клиентов от лишней сложности. Денис Лузиков , который занимается внедрением ИИ-агентов и чат-ботов для бизнеса, прямо пишет на странице своих услуг: если задачу закрывает сценарий из нескольких кнопок, агент не нужен. Такая позиция встречается реже, чем хотелось бы, и она хорошо задаёт правильный вопрос. Выбирать инструмент стоит под задачу, мода тут плохой советчик.
Три разных уровня под одним словом «бот»
Первый уровень — сценарный бот. Он работает по заранее нарисованной схеме: клиент нажимает «Узнать статус заказа», бот просит номер и показывает ответ из базы. Шаг влево или вправо он не понимает. Зато ведёт себя предсказуемо и почти не требует присмотра.
Второй уровень — чат-бот на языковой модели с базой знаний. Он понимает вопросы, заданные своими словами, и отвечает по документам компании. Технически это чаще всего RAG: перед ответом система ищет подходящие фрагменты в регламентах, прайсах и инструкциях и строит ответ на их основе. Хорошо настроенный бот честно говорит «не знаю» и зовёт человека, если нужной информации в базе нет.
Третий уровень и есть ИИ-агент. Кроме понимания речи у него есть инструменты. Через API, то есть программный интерфейс других систем, он может проверить остаток товара на складе, создать сделку в CRM, записать клиента на встречу или собрать заявку с бюджетом и сроками в готовую карточку для менеджера. Модель сама решает, какой инструмент вызвать и в каком порядке. Отсюда и сила агента, и главный риск.
Когда хватит кнопок
Простой сценарий выигрывает, если вопросов у клиентов немного и они повторяются почти дословно. Статус заказа, адрес пункта выдачи, график работы, запись на один тип услуги. Если за месяц переписки набирается десяток типовых обращений, их проще разложить по меню. Агент в такой ситуации будет тратить ресурсы языковой модели на то, что решается одной кнопкой, и добавит поводов для ошибок.
Ещё один признак: когда цена ошибки высокая, а ответ должен быть всегда одинаковым. Юридические формулировки, условия возврата, медицинские ограничения. Здесь жёсткий текст из базы надёжнее живой генерации.
Признаки того, что задача переросла сценарий
Клиенты пишут длинно и каждый по-своему. Один присылает фото, другой спрашивает сразу про три позиции и доставку в область. Нарисовать дерево на все такие случаи нельзя, а модель с базой знаний справляется.
Для ответа нужны данные из нескольких мест. Наличие лежит в складской программе, цена в таблице, свободные окна в календаре. Сотрудник поддержки сейчас открывает три вкладки, агент может сделать то же самое сам.
После разговора нужно действие. Ответить клиенту мало, надо ещё завести сделку, поставить задачу менеджеру или забронировать время. Вот здесь агент и начинает экономить часы сотрудников.
Менеджеры тонут в сырых заявках. Если половина обращений отсеивается после первого же уточняющего вопроса, эту первичную квалификацию разумно отдать агенту.
Что компании стоит подготовить заранее
Самое недооценённое — порядок в документах. Агент отвечает по базе знаний, и если в ней лежат прошлогодний прайс и два противоречащих регламента, он будет уверенно повторять устаревшее. Разработчик тут бессилен: мусор на входе даёт мусор на выходе.
Второй вопрос касается систем. Есть ли у CRM, склада и сайта API, кто в компании знает, как им пользоваться. Без доступа к данным агент превращается обратно в чат-бота.
Третий вопрос про людей. Кто получает диалоги, которые агент передал дальше, и как быстро на них отвечает. Клиент, которого вежливо переключили на человека и забыли, запомнит это надолго.
И последнее: реальные переписки для проверки. Прототип стоит гонять на выгрузке настоящих обращений, со всеми опечатками и странными вопросами. Красивые тестовые фразы из головы проверяют только то, что и так работает.
Права агента выдаются постепенно
Возможность действовать в системах компании делает агента полезным и одновременно опасным. Ошибка сценарного бота заканчивается неудачным ответом. Ошибка агента может закончиться отменённой сделкой или двойной бронью. Поэтому разумная схема запуска выглядит скромно: сначала агент только читает данные и отвечает, потом получает право создавать черновики, которые подтверждает человек, и лишь после недель спокойной работы начинает менять записи сам. Такой путь кажется медленным, но именно он показывает, где проходит граница между задачей для кнопок и задачей для интеллекта в конкретной компании.
