Первого ИИ-агента для бизнеса стоит проверять на ограниченном процессе: например, подготовке черновика ответа по базе знаний или разборе входящих обращений. Выберите входные данные, разрешённые действия и способ проверки. После пилота станет понятнее, какие операции можно поручить системе, а где сотруднику нужно принимать решение.
Покупка инструмента не определяет результат. Для работы агенту нужны подходящие данные, доступ к нужным системам и правила действий. Если отдел по-разному понимает, что считать подходящей заявкой, сначала согласуйте эти признаки.
Чем агент отличается от чат-бота и сценария
Обычный сценарий выполняет заранее заданную последовательность. Агент может выбирать следующий шаг и инструмент в ходе выполнения задачи. Anthropic использует такое различие между workflows и agents и рекомендует начинать с наиболее простого подходящего решения.
Названия продуктов могут расходиться с этим определением. При выборе смотрите, что система делает: отвечает текстом, ищет сведения, создаёт запись или меняет её. Чат-бот может использовать модель для ответов, а обработку формы можно автоматизировать без участия ИИ.
Для переноса обязательных полей из формы в CRM достаточно заданных правил. Для выделения темы из свободного описания может пригодиться языковая модель. Для самостоятельного выбора нескольких действий потребуется более сложная схема и дополнительные проверки.
Выберите процесс, который можно проверить
Найдите задачу с повторяющимся входом и понятным результатом. Запишите, как сотрудник выполняет её сейчас: какие сведения читает, где принимает решение и кому передаёт результат. Не объединяйте первый пилот со всей работой отдела.
| Задача | Что дать системе | Что проверяет сотрудник |
|---|---|---|
| Черновик ответа по справке | Актуальные документы и вопрос | Соответствие ответу в документах |
| Разбор обращения | Текст и согласованные категории | Категорию и извлечённые сведения |
| Подготовка внутренней сводки | Определённый набор записей | Полноту и связь выводов с записями |
| Заполнение проекта карточки | Поля и источник каждого значения | Данные до записи в рабочую систему |
Это примеры для выбора, а не подтверждённые внедрения студии. Для каждого нужна проверка источников и способа подключения. Не начинайте с операции, ошибку в которой трудно заметить или исправить.
Пример пилота: разбор входящих обращений
Рассмотрим условный процесс. Компания получает обращения о настройке сети, ремонте компьютеров и другой работе. Сотрудник читает текст, выбирает направление и задаёт уточняющий вопрос.
В первом варианте система определяет предполагаемое направление и готовит черновик уточнения. Она не отправляет сообщение клиенту и не обещает стоимость. Сотрудник проверяет результат и выбирает дальнейшее действие.
Подготовьте примеры, на которых вы сможете оценить такой разбор: понятное обращение, сообщение с несколькими задачами, неполный текст, вопрос вне услуг и просьба связаться с человеком. Для каждой ситуации запишите ожидаемое поведение. Если категории допускают несколько разумных ответов, договоритесь, как отмечать такой случай.
Сведения об услугах берите из утверждённого источника. Назначьте человека, который обновляет его при изменении условий. Попросите показывать, на каком документе основан черновик, когда это возможно в выбранной системе. Так проверяющий сможет найти причину ошибки.
Ограничьте действия и доступ к данным
Перечислите операции по отдельности: прочитать справку, подготовить текст, создать карточку, отправить письмо. Для каждой укажите разрешение и необходимость проверки человеком. Доступ ко всей CRM может оказаться избыточным для пилота, которому нужны только тестовые обращения.
Проверка человеком должна останавливать действие до выполнения. Например, n8n описывает подтверждение вызова отдельных инструментов: сотрудник может разрешить действие с указанными параметрами или отклонить его. Наличие похожей настройки в другом продукте нужно проверять по его документации.
В нашем условном пилоте внешнюю отправку оставляем сотруднику. Для отказа и сбоя предусмотрите понятный путь: система передаёт обращение ответственному, сохраняет исходный текст и не выдаёт неподтверждённый результат за завершённую работу.
При подключении внешних документов учитывайте, что их содержание может включать посторонние указания. Разработчик должен разделить рабочие правила системы и данные, которые она читает. Ограничение прав поможет сдержать последствия ошибочного действия, но не заменит проверку конкретной реализации.
Запишите карточку пилота
Для обсуждения достаточно заполнить такие поля:
- Процесс: разбор обращений по трём согласованным направлениям.
- Вход: тестовые тексты обращений и утверждённое описание услуг.
- Результат: категория, извлечённые сведения и черновик уточняющего вопроса.
- Границы: без внешней отправки, цены и изменений рабочих данных.
- Проверяющий: сотрудник, который принимает обращения.
- Ошибка: неверная категория, выдуманный факт, пропущенная задача или действие вне разрешений.
- Решение о продолжении: принять после сравнения с текущей ручной работой и разбором ошибок.
Измерьте время сотрудника на весь процесс: чтение, проверку, исправление и передачу. Учтите расходы на модель, подключение и сопровождение. Быстрый первый ответ может потребовать длинной ручной правки; это видно только при измерении всей задачи.
Что считать результатом
Отдельно оцените корректность, затраты и фактическое действие в системе. Для коммерческого процесса также учитывайте подтверждённые обращения и дальнейшие договорённости. Созданная карточка в CRM не означает продажу.
Если пилот не проходит проверку, установите причину: не хватает сведений, неверно описаны правила или выбран слишком широкий процесс. Сначала исправьте причину на том же наборе проверок, затем добавляйте новые ситуации.
Описание своей задачи можно подготовить по этой карточке для обсуждения автоматизации. Конкретные интеграции, ограничения и состав работ согласуют после изучения систем. Платформа n8n и MCP-сервер относятся к возможным инструментам подключения; выбирать их стоит после определения процесса.