Техзадание на ИИ-агента: что записать до разговора с разработчиком

Начните с одной ситуации, которую все узнают

Плохая формулировка: «Нужен умный агент для отдела продаж». Неясно, где он работает, что получает и по каким признакам считать работу законченной. Лучше: «После входящего сообщения с сайта агент создаёт черновик заявки в CRM, определяет тему и назначает очередь. Ответ клиенту отправляет менеджер». В такой постановке виден вход, выход и граница ответственности.

В руководстве OpenAI по созданию агентов подчёркиваются инструменты, инструкции, ограничения и передача человеку. Переведите эти технические категории на язык вашего процесса, а не копируйте общие фразы в договор.

Запишите вход и источники правды

Перечислите каналы: форма, почта, мессенджер, звонок после расшифровки. Для каждого укажите обязательные поля, возможность дубля и правила согласия на обработку данных. Затем назовите источники, на которые агенту можно опираться: действующий прайс, справочник услуг, CRM. У каждого источника должен быть владелец и дата актуальности.

Если в прайсе есть две версии, задание должно говорить, какую выбирать и что делать при конфликте. Ответ «пусть модель разберётся» перекладывает решение о цене на систему, которая не несёт за него ответственности.

Опишите разрешённые и запрещённые действия

Эти границы зависят от бизнеса. Для низкорискового сценария можно расширять автоматизацию по результатам проверок. Для медицинского, финансового или юридически значимого ответа ограничений понадобится больше.

Пять случаев, которые обязательно положить в тест

• Клиент пишет неполно: есть вопрос, но нет контакта или номера заказа.
• Сообщение содержит два разных запроса; один из них срочный.
• В CRM уже есть похожая заявка от того же человека.
• Документ противоречит текущей политике или не имеет даты.
• Клиент просит действие, которое агенту запрещено выполнять.

Для каждого случая запишите ожидаемое поведение. Агенту может быть правильно сказать «не знаю», задать уточняющий вопрос или передать задачу менеджеру. Гладкий ответ в этих ситуациях может быть хуже честной остановки.

Назначьте метрики и владельцев

В задании нужны базовая скорость обработки сегодня, допустимая доля неправильных назначений, время ручной проверки и правило возврата к старому маршруту. Метрики считайте на реальном потоке, а не на демонстрационных примерах. Назначьте владельца бизнес-результата и человека, который обновляет документы.

Критерий приёмки: на согласованной выборке агент делает разрешённые действия, корректно передаёт исключения и оставляет проверяемый след. Доля красивых формулировок не является критерием.

Что передать подрядчику в конце встречи

Передайте схему текущего процесса, обезличенные примеры, список доступов, таблицу разрешённых действий, тестовые случаи и критерий успеха. Попросите в ответ архитектуру, план пилота, смету, журнал решений и способ выключить автоматизацию без потери заявок. Это уже предметный разговор о внедрении, а не покупка абстрактного «ИИ-бота».

Как выглядит короткий готовый бриф

«Агент получает заявки с сайта и из рабочего мессенджера. На основании текста создаёт черновик карточки в CRM и предлагает категорию. Не отправляет клиенту цену, не объединяет сомнительные дубли и не удаляет записи. Если не найден контакт или сообщение касается жалобы, передаёт менеджеру вместе с исходным текстом. На пилоте проверяем 50 обезличенных исторических примеров и поток за две недели; фиксируем ошибочную маршрутизацию, потерю заявок и время ручного исправления».

Такой бриф ещё не заменяет договор или техническую схему, зато не даёт команде строить «универсального помощника» без границ. После первой проверки его можно уточнить на основании ошибок, а не по впечатлению от демонстрации.

Что часто забывают при приёмке

Проверьте сценарий недоступной CRM, отмены согласия на обработку данных и изменения категории уже созданной карточки. Уточните, куда идут сообщения, если очередь менеджеров пуста. Эти мелочи редко показывают в демо, хотя именно они решают, будет ли система сохранять обращения в обычный рабочий день.

Опишите один цикл работы от начала до конца

Входящее сообщение поступает в очередь. Система проверяет, есть ли согласие и обязательные поля. Затем ищет совпадение с существующей карточкой, выбирает категорию и предлагает ответственную команду. Если правила однозначны, записывает черновик и сохраняет ссылку на исходное сообщение. Если возник конфликт, оставляет сообщение в очереди и сообщает сотруднику причину. После подтверждения менеджером карточка переходит в рабочий статус.

Для каждого перехода запишите событие, которое его подтверждает. Например, отправка запроса к CRM ещё не означает успешное создание карточки; нужна квитанция системы. Если запрос повторился после сбоя, нельзя создать дубль. Такое описание помогает разработчику увидеть технические требования, а бизнесу — потерянные шаги.

Разведите качество ответа и права действия

Агент может отлично понимать запрос клиента, но не иметь права изменить цену. И наоборот, формально разрешённое действие может быть ошибочным из-за плохого распознавания текста. В брифе сделайте отдельные столбцы: «что система знает», «что может предложить», «что может выполнить без человека» и «что фиксирует в журнале».

Не соединяйте права в одну настройку «доступ к CRM». Чтение карточки, создание черновика, редактирование уже подтверждённой сделки и удаление записи — разные действия. Самый узкий необходимый доступ упрощает проверку и снижает последствия ошибки.

Какие вопросы задать на приёмке

Покажите один успешный путь, один случай с отсутствующим полем, один дубль и один отказ интеграции. Где виден исходный запрос? Как сотрудник узнаёт, что агент не уверен? Можно ли исправить карточку и повторить операцию без потери истории? Кто увидит ошибку, если уведомление клиенту не ушло?

Эти вопросы должны получить ответ на работающем пилоте. Документ с описанием не заменяет фактической проверки, но делает её предметной: команда заранее знает, какое поведение требуется, и не спорит о смысле слова «готово» после разработки.

Какие файлы приложить к заданию

Полезно передать не весь архив компании, а минимальный комплект: схему текущего процесса, действующие инструкции, перечень систем и ролей доступа, десять типичных и несколько проблемных обезличенных примеров. Добавьте список известных исключений, которые сотрудники сегодня решают вручную. Если часть правил устная, запишите, кто и когда её подтвердит.

Отдельным файлом сделайте журнал вопросов, на которые пока нет ответа. Он не должен исчезнуть из проекта после первой встречи. Именно такие вопросы часто определяют объём разработки и срок запуска. Если подрядчик сам заполняет пробелы догадками, приёмка превратится в спор о том, чего «все имели в виду».