Руководитель просит помощника создать задачу после разговора с клиентом. Тот отвечает: «Готово, передал мастеру». Мастер ничего не видит. В чате поручение завершено, в работе компании ничего не изменилось.
Результат ИИ-агента для бизнеса нужно проверять там, где он должен появиться. Для задачи это существующая запись с правильными условиями и ответственным. Для отправленного документа потребуется отдельное подтверждение предусмотренного действия. Уверенность финальной фразы эту проверку не заменяет.
Сначала разберём, какие задачи можно отдать такому помощнику, затем пройдём один учебный сценарий от поручения до приёмки. Все примеры, имена, номера и записи ниже условные.
Что делает ИИ-агент
ИИ-агент получает цель и выбирает шаги с помощью языковой модели. Если ему подключили нужные инструменты и дали доступ, он может найти сведения, сопоставить их и выполнить разрешённое действие: например, подготовить карточку обращения или создать задачу сотруднику.
Для читателя важно различать ответ и действие. Помощник, который написал текст задачи в чате, ещё не создал её в CRM. Чтобы изменить запись, ему нужны подключение к системе, разрешённая операция и проверка сохранения.
В разборе Anthropic об устройстве агентов выбор шагов моделью отделён от заранее заданной последовательности действий. Это помогает решить, нужен ли агент в конкретной работе. Способ подключения инструментов зависит от выбранной системы.
Какие задачи можно поручить агенту в сервисной компании
Выбирать первую задачу удобнее по результату, который сотрудник сможет открыть и проверить. Ниже возможные сценарии для разработки, а не обещание функций любого готового чат-бота.
Разобрать обращение свободным текстом. Клиент в одном сообщении описал поломку, удобное время и ограничение по выезду. Помощник может выделить сведения и подготовить черновик карточки. Неизвестная модель оборудования останется открытым вопросом. Перед записью на выезд сотрудник проверит исходное сообщение и заполненные поля.
Собрать историю заказа перед звонком. Менеджеру нужна короткая сводка из разрешённых записей: что обещали, что уже сделали и какой вопрос ждёт ответа. В результате полезны ссылки на записи и даты сведений. Если доступна только часть истории, это должно быть видно в сводке.
Подготовить передачу работы сотруднику. По итогам разговора помощник предлагает конкретное действие, ответственного и срок. После предусмотренного подтверждения создаёт задачу и проверяет её. Именно этот сценарий разберём дальше.
Найти дела, требующие решения руководителя. По статусам и комментариям помощник собирает список остановившихся работ с причиной и следующим шагом. Руководитель сверяет выводы с исходными записями. Право составить сводку само по себе не разрешает менять исполнителя или условия заказа.
Когда хватит обычной автоматизации
Если правило полностью известно, начать проще с него. Передать все заявки формы в CRM, назначить дежурного по расписанию или отправить напоминание по сохранённой дате можно по заранее заданному порядку. В таких действиях свободный выбор модели может оказаться лишним.
Агента стоит рассматривать там, где входные сообщения различаются и следующие шаги зависят от их содержания. При этом должны быть доступны нужные данные, разрешённые инструменты и сотрудник, который примет спорный результат.
До разработки выберите одно поручение и опишите его обычное выполнение. Затем сравните с пробой помощника весь путь, включая уточнения и исправления. В расчёт входят настройка, оплата сервисов и работа проверяющего. Сам факт появления агента не устанавливает экономию или окупаемость.
Заранее договоритесь, что означает «сделано»
В нашем примере руководитель говорит: «Создай в тестовой CRM задачу по обращению 417. Мастер Илья должен связаться с клиентом завтра до 12:00 и уточнить модель оборудования. Самому клиенту пока не пиши».
Чтобы принять результат, нужны конкретные признаки:
- В тестовой CRM существует одна задача, связанная с обращением 417.
- Назначен нужный сотрудник, срок записан конкретной датой и временем с согласованным часовым поясом.
- Сохранено действие: связаться с клиентом и уточнить модель оборудования.
- Внешнее сообщение клиенту не отправлялось, поскольку этого не разрешали.
До запуска также нужно понять, какую календарную дату означает «завтра». Если текущая дата или часовой пояс неизвестны, помощник должен уточнить их. Красивое описание задачи с неправильным сроком не подходит.
Этот список задаёт приёмку одного поручения. Большая инструкция «помогай отделу продаж» оставляет слишком много вариантов того, что агент посчитает выполненной работой.
Посмотрите на действие в рабочем инструменте
В простейшей проверке сотрудник открывает CRM и находит созданную задачу. Полезно, если помощник возвращает ссылку на запись и коротко перечисляет, что в ней сохранено.
Проверьте, что ссылка открывает существующую задачу, а поля совпадают с поручением. Номер, придуманный в тексте ответа, нельзя считать подтверждением. То же относится к скриншоту, который не позволяет проверить актуальное состояние записи.
Для регулярной работы разработчик может добавить автоматическое чтение созданной записи из самой системы. Оно должно проверять нужные поля. Успех операции «создать» и совпадение результата с поручением остаются отдельными проверками.
Если задача появилась в CRM, следующий вопрос: видит ли её назначенный сотрудник в обычной работе? Открытие от имени администратора не доказывает, что мастер получил нужный доступ или заметил поручение. Дальнейшее уведомление и начало работы проверяются отдельно.
Разделите понимание и выполнение
Вернёмся к примеру. Агент может правильно пересказать просьбу и ошибиться при выборе сотрудника из двух людей с одинаковым именем. Может выбрать верного сотрудника, но потерять номер обращения. Может заполнить всё правильно, а затем не сохранить запись.
Эти ошибки требуют разной доработки. Поэтому полезно видеть хотя бы короткую историю: что агент понял, какой инструмент вызвал и какой ответ получил. Чувствительные сведения в такой истории должны быть ограничены действующими правилами доступа и хранения.
В материале Yandex Cloud о наблюдении за агентами разбирается прослеживание шагов модели и инструментов. Для небольшого сценария смысл простой: по неудаче должно быть понятно, на каком шаге результат разошёлся с поручением. Полная переписка на десятки экранов сама по себе этого не обеспечивает.
В отчёте помощника можно оставить короткую запись: «Создана задача [ссылка]. Обращение 417, ответственный [сотрудник], срок [дата, время, часовой пояс]. Сохранённые поля проверены. Клиенту не писали». Каждое утверждение должно опираться на выполненное действие или проверку.
Если ответ системы потерялся, сначала найдите результат
Самый неудобный случай: CRM успела создать задачу, но помощник не получил ответ. На экране ошибка. Повторная команда может создать ещё одну задачу.
В таком состоянии результат неизвестен. Сначала проверьте, существует ли запись по этому поручению. Для автоматического повтора разработчику нужен устойчивый способ распознать ту же операцию и избежать дубля; конкретный механизм зависит от CRM и её интерфейса.
Если однозначно установить результат не удалось, помощник должен передать проверку сотруднику. Самовольная серия повторов добавит неопределённости.
Для пользователя понятен такой ответ: «Подтверждение создания не получено. Проверяю, появилась ли задача. Повтор пока не выполняю». После проверки он должен смениться фактическим результатом или ясной передачей человеку.
Подготовьте маленькую проверочную площадку
Первую приёмку проводите с вымышленными обращениями и тестовым получателем. Действия должны быть ограничены тестовой средой. Реальное уведомление сотруднику или клиенту не является безопасным способом проверить сценарий по умолчанию.
Пройдите несколько разных ситуаций:
- Все сведения есть. Одна задача появляется с правильными полями.
- Ответственный неоднозначен. Агент уточняет сотрудника до создания.
- Не хватает срока. Он запрашивает недостающее, а не выбирает дату самостоятельно.
- Нет доступа к записи. Сообщает о конкретном ограничении, не объявляет успех.
- Потеряно подтверждение. Сначала ищет результат, повтор не создаёт дубль.
- Сохранена только часть поручения. Например, задача появилась без связи с обращением. Агент сообщает о незавершённости и следует заранее согласованному порядку исправления.
Ожидаемое поведение запишите до прогона. Иначе убедительное объяснение помощника может незаметно заменить исходное требование.
Такая подборка выявляет конкретные сбои и даёт основание для следующей проверки. Она не доказывает безошибочность всех будущих действий агента.
Считайте и работу человека после ответа
Запишите, сколько поручений принято с правильным результатом, сколько потребовало уточнения, исправления или ручной проверки. Ошибки разбирайте по последствиям. Лишняя задача и сообщение не тому клиенту требуют разного решения.
Сравнивайте весь путь с обычной работой на одинаковых учебных случаях: постановку, выполнение, проверку и исправления. Если руководитель каждый раз заново выполняет поручение после агента, быстрый ответ в чате ещё не даёт основания говорить об экономии времени.
Оставьте сотруднику простой способ остановить дальнейшие действия и передать спорный случай человеку. Права агента должны соответствовать разрешённой части работы. Поручение создать внутреннюю задачу не разрешает менять условия заказа или писать клиенту.
Что принести на первый разбор
Возьмите одно повторяющееся поручение и покажите правильный результат в системе. Добавьте случай, в котором выполнять действие нельзя без уточнения, и объясните, кто принимает незавершённую работу.
Если пока непонятно, нужен ли для этой операции агент, можно начать с выбора между ИИ и обычной автоматизацией. Если подход уже выбран, в разработке ИИ-помощника первым этапом может стать конкретное действие с проверкой результата. На таком участке проще увидеть, что действительно работает и что ещё нужно исправить.
