Начинать внедрение AI с выбора модели неудобно. Сначала нужно найти процесс, в котором повторяются похожие действия и можно проверить правильность результата. Иначе команда получает эффектную демонстрацию без понятного рабочего применения.

Найдите узкую задачу

Хороший кандидат для пилота имеет понятный вход и выход, а сотрудник может объяснить, какой результат верный. Выберите одну повторяющуюся операцию, а не весь рабочий день отдела.

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

Пример пилота: подготовка карточки обращения

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

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

Сначала пилот работает на сохранённых примерах. Менеджер видит исходное сообщение рядом с предложенной категорией и описанием, исправляет результат и подтверждает его. AI не отправляет ответы клиентам и не меняет сделки самостоятельно. Если модель недоступна или сообщение не подходит под согласованный сценарий, обращение остаётся доступно для обычной ручной обработки.

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

Зафиксируйте исходное состояние

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

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

Сравните AI с обычными правилами

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

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

Опишите границы и отказ

  • Какие источники можно использовать.
  • Какие сведения нельзя передавать внешнему сервису.
  • Когда результат должен уйти сотруднику на проверку.
  • Что происходит при недоступности API.
  • Как ограничиваются расходы и доступы.

Фраза «не знаю» или передача человеку может быть правильным поведением. Принудительный уверенный ответ не повышает качество.

Считайте полный эффект

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

Решение о расширении принимают по наблюдаемым результатам, а не по обещанию заменить отдел. Наш подход описан на странице AI и автоматизации. Для первого разговора достаточно процесса и нескольких обезличенных примеров в брифе.