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