AiHummer 
Тендеры и лиды
Информация
На демонстрации агент находит нужный документ, отвечает по делу и создаёт заявку. Всё сходится. Но приёмка начинается там, где в документе нет ответа, заявка уже существует, а человек, который должен согласовать действие, недоступен. Я предлагаю проверять такие ситуации до запуска — пока заказчик и интегратор ещё могут спокойно договориться, какое поведение считать правильным.
Формулировка «агент обрабатывает обращения» слишком просторна для приёмки. В неё помещаются поиск инструкции, подготовка ответа, изменение карточки и отправка письма. Если оставить их одним пунктом, хорошая переписка легко заслонит ошибку в самой операции.
Я бы начал с одного сценария. Что агент вправе прочитать? Какой черновик подготовить? Какую запись изменить? При каких условиях отправить сообщение? Для каждого шага нужен признак завершения вне разговора с агентом: идентификатор созданной заявки, новое значение поля, подтверждённый статус в сервисе отправки.
Фраза «готово» доказательством не служит. Между предложением модели вызвать инструмент и фактическим исполнением могут быть проверка прав, согласование и ошибка интеграции. Поэтому я включаю в критерии приёмки точность статусов: «подготовлено», «ожидает решения», «выполнено», «не выполнено», «результат пока не подтверждён». Последний особенно нужен, когда запрос ушёл во внешнюю систему, а ответ от неё потерялся.
Проверьте и обратную границу: попросите объяснить порядок изменения заявки. Агент должен рассказать о порядке, сохранив саму заявку без изменений. Право на разговор не означает поручения выполнить всё, что в разговоре упомянуто.
Для следующего прогона я предлагаю убрать из базы нужный фрагмент. Агенту придётся сообщить о пробеле, задать уточнение или передать вопрос человеку. Выбор нужно согласовать заранее. Иначе заказчик посчитает отказ дефектом, а интегратор назовёт тот же отказ защитой от выдуманного ответа.
Пустой результат поиска и устаревший документ требуют разных реакций. В первом случае основание не найдено. Во втором оно есть, но пользоваться им уже нельзя или можно с оговоркой. Дата обновления файла тоже не обязательно совпадает с датой вступления правила в силу. Владелец процесса должен обозначить действующую версию, область применения и срок актуальности материала.
Для отдельного теста оставьте в базе два регламента с разными сроками обработки обращения. Если приоритет документов задан, ожидается ответ по действующему регламенту со ссылкой. Если приоритета нет — обозначение противоречия и передача владельцу знаний. Самостоятельно выбирать более удобный срок агенту разрешать не стоит.
Сохраните версию источника или найденный фрагмент вместе с результатом прогона. Одной ссылки на живой документ недостаточно: завтра его поправят, и спор о вчерашнем ответе станет спором по памяти. Избыточные сведения из клиентского обращения в тестовую копию переносить незачем.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13731 тендер
проведено за восемь лет работы нашего сайта.
Здесь нужно различать полномочия пользователя, доступы интеграции и разрешённые операции агента. Сотрудник может видеть карточку, но не иметь права менять её владельца. Техническая учётная запись иногда умеет гораздо больше. Приёмка должна выявлять такие разрывы: действие проверяют от лица будущего пользователя.
Запрет в инструкции — лишь один слой. Для существенного ограничения нужен контроль перед исполнением. Попытку обойти запрет стоит поместить и во вложение: добавить в тестовый файл указание изменить чужую запись. Содержимое источника не должно получать права служебной команды.
В документации AiHummer v1.2 описан конкретный механизм: для заданного списка инструментов выполнение приостанавливается до решения человека. Проверяющий видит инструмент, аргументы и контекст. Одобрение относится к рассмотренным аргументам, отклонённый вызов не исполняется. Возможность зависит от тарифа и настройки. На приёмке нужно показать, что нужная операция действительно попала под такой контроль.
Проверьте согласование в обе стороны: одобрите действие и сверьте результат, затем отклоните новый вызов и проверьте отсутствие изменения. Ещё один прогон — молчание согласующего. Для него задают срок ожидания, состояние задачи после его истечения и следующего ответственного. Молчание не должно превращаться в согласие.
Эскалация нуждается в доказательстве: созданном обращении, назначенной очереди или подтверждении доставки. Человек должен получить вопрос, причину остановки, найденные материалы и уже выполненные шаги. Если передача не удалась, агенту следует сообщить об этом и предложить предусмотренный процессом следующий шаг. Иначе задача исчезнет между двумя участниками.
Ниже — заготовка протокола для агента, который отвечает по базе знаний и работает с заявками. Подставьте тестовые условия в свой процесс. До прогона стороны фиксируют ожидаемое поведение, допустимое время ожидания и способ проверки. Проверки выполняют на тестовых записях и адресатах.
Добавьте обычный успешный сценарий с полными данными и корректными правами. Иначе система, которая отказывает всем, пройдёт проверки на остановку. Повторите ключевые входы с другой формулировкой и в новом диалоге: условие должно работать по смыслу, без зависимости от заученной фразы.
Сможет ли сотрудник сопровождения восстановить спорный эпизод без устного рассказа разработчика? Для этого нужно связать входящий запрос, источник, вызов инструмента, решение согласующего и результат внешней системы. Общий идентификатор эпизода позволит искать его без просмотра всей переписки.
Здесь легко перепутать журналы. В документации AiHummer v1.2 об аудите описана регистрация административных изменений с управляемым сроком хранения. Это помогает выяснить, кто поменял настройки. Полноту истории исполнения бизнес-операции надо проверять отдельно. Пункт «аудит» в описании платформы её не доказывает.
При сдаче нужно показать, где искать историю операции, какие сведения сохраняются, кто их видит и когда они удаляются. Заодно проверить остановку проблемного действия без потери принятых задач. Порядок возобновления тоже нужен: что останется в ожидании, что разрешено повторить, а что сначала придётся сверить с внешней системой.
Границы гарантий я бы записал через условия: типы проверенных запросов, действующие источники, разрешённые действия, обязательное участие человека. Обещание отвечать правильно на любой вход сопровождению не помогает. Проверяемое обязательство — при отсутствии подтверждённого основания не менять заявку и запускать определённую процедуру передачи.
Заранее определите повод для повторной приёмки. Замена модели, инструкций, прав инструмента или правил выбора источника может затронуть проверенное поведение. Для таких изменений нужен набор повторных прогонов и человек, который принимает результат. Сохранённая таблица с входами и доказательствами становится первым рабочим инструментом сопровождения.
Я считаю проект готовым к передаче, когда обе стороны одинаково понимают результат каждого такого прогона. Агент может ответить, выполнить поручение или остановиться. Во всех трёх случаях должно быть понятно, что произошло с задачей, на каком основании и кто отвечает за следующий шаг.
