Тендеры и лиды
Информация
На демонстрации ИИ-агент отвечает на знакомый вопрос и аккуратно заполняет карточку. Но в рабочем процессе ему встретятся неполные документы, недоступные сервисы и противоречивые указания. Именно эти ситуации полезно проверить до запуска.
Ниже схема приёмки для заказчика. Она помогает обсуждать конкретные результаты вместо общего требования «сделайте, чтобы всё работало». Это рекомендации для проверки, а не отчёт о результатах конкретного клиента.
Иллюстрация Bogdanov Lab: прежде чем автоматизировать работу, нужно разобраться с актуальными документами.
«Помогает менеджеру» слишком широко для приёмки. Описать сценарий можно так: агент читает обращение, извлекает контакт и тему, предлагает ответ по базе знаний и готовит запись для CRM. Отправку ответа подтверждает менеджер.
Для каждого шага нужны понятные вход и выход. Откуда приходит обращение? Какие поля обязательны? Где хранится черновик? Что происходит, если контакта нет или клиент просит нестандартные условия?
Отдельно перечислите запрещённые действия. Например, агент не меняет цену, не обещает срок поставки и не отправляет сообщение клиенту без подтверждения. Эти ограничения должны проверяться в сценариях, а не оставаться фразой в описании проекта.
Соберите небольшую подборку типичных обращений и ожидаемых результатов. Если используете реальные записи, удалите сведения, которые не нужны для проверки, и убедитесь, что данные разрешено передавать в выбранную систему.
Кроме обычного вопроса включите случаи, которые легко пропустить:
В документе нет нужного ответа.
Два источника содержат разные условия.
Обращение пришло без обязательного поля.
Клиент изменил запрос после подготовки черновика.
CRM вернула ошибку или не ответила вовремя.
Ожидаемый результат не всегда представляет собой готовый ответ. Иногда правильное поведение: показать, каких данных не хватает, задать уточнение или передать задачу сотруднику.
Сохраните эти примеры и повторяйте проверку после изменения базы знаний, модели или интеграции. Так легче заметить, что новая настройка исправила один сценарий, но сломала другой.
Если агент отвечает по документам, заказчику нужен способ сопоставить ответ с источником. Это может быть ссылка на раздел базы знаний, название документа или фрагмент, из которого взято условие.
Проверьте не только наличие ссылки, но и соответствие: действительно ли источник подтверждает ответ, актуальна ли версия, есть ли у сотрудника право открыть документ.
Отсутствующее значение нельзя незаметно подменять нулём, а неподтверждённое условие выдавать за факт. Для отчёта важно различать «расходов нет» и «данные о расходах не получены». Иначе внешне аккуратная сводка приведёт к неверному решению.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13799 тендеров
проведено за восемь лет работы нашего сайта.
Если человек согласует отправку письма или изменение записи, перед ним должны быть получатель, содержимое и существенные параметры операции. Кнопки «Разрешить агенту работать» недостаточно для понимания того, что будет сделано.
Проверьте ситуацию, когда после согласования изменились данные. Если ответ отредактировали или выбрали другого адресата, прежнее подтверждение не должно автоматически разрешать новую отправку.
Нужен и сценарий отказа. При отмене действие не выполняется, а сотрудник видит, что именно осталось в черновике. Для необратимых операций отдельно обсуждаются порядок согласования и возможность восстановления.
Повторное обращение, обновление страницы и сетевой сбой встречаются в обычной работе. Для действий, меняющих внешнюю систему, заранее определите, как распознаётся повтор и в каких случаях создаётся новая запись.
Например, повторная попытка отправить ту же заявку после таймаута не должна безусловно создавать второго клиента в CRM. Система должна проверить, не выполнилась ли первая операция, либо передать спорный случай человеку.
На приёмке полезно намеренно отключить доступ к тестовой интеграции. Посмотрите, где видна ошибка, как сохраняется задача и кто узнаёт о проблеме. Сообщение «готово» допустимо только после подтверждённого результата, а не после начала запроса.
Испытания, которые могут отправить письмо, изменить заказ или списать деньги, проводите в тестовой среде либо по отдельно согласованному безопасному сценарию.
Передача человеку должна сохранять контекст: исходный вопрос, использованные данные, подготовленный ответ и причину остановки. Если сотруднику приходится разбирать всё заново, часть пользы автоматизации теряется.
Определите, кто отвечает за такие задачи и где находится очередь. Уточните, какие сведения попадают в уведомление: ответственному нужны данные для работы, а не полный архив документов на всякий случай.
Проверьте и границы доступа. Агент одного отдела не должен раскрывать документы другого только потому, что пользователь попросил об этом в сообщении. Доступ определяется правами системы и источников, а не убедительностью запроса.
Зафиксируйте проверяемые критерии: какие сценарии пройдены, какие ошибки допустимы и как они обрабатываются, какие действия требуют подтверждения. Порог для рекомендации товара и порог для финансовой операции будут разными.
Отдельно договоритесь о том, что произойдёт после запуска: кто обновляет документы, разбирает ошибки и подтверждает изменения. Сам факт подключения модели не означает, что этот процесс уже организован.
Удобный итог приёмки: список сценариев, результаты проверки, известные ограничения, ответственные и инструкции по остановке системы. Рост выручки или экономию времени оценивают позднее по согласованной методике и реальным данным, а не по красивой демонстрации.
Если задача ещё не выбрана, сначала определите один повторяющийся процесс и ожидаемый результат. У Bogdanov Lab есть отдельное руководство об этом: https://bogdanovlab.ru/materialy/ii-agenty-pervaya-zadacha/
Автор: Александр Богданов, главный разработчик AI-студии Bogdanov Lab.
