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