Первый ИИ-пилот: как выбрать задачу, которую можно проверить за неделю

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

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

Ниже — порядок подготовки такого теста на одну рабочую неделю. За это время можно получить первые наблюдения; редкие ошибки и долгосрочную пользу придётся проверять дольше.

Начните с трёх кандидатов

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

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

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

Если для задачи пока нет примеров или ответственного, это отдельная подготовительная работа. Сначала соберите её основу, затем назначайте дату теста.

Запишите результат одним предложением

Для учебного примера возьмём входящие запросы на поставку. Формулировка пилота может быть такой:

«Из сообщения клиента получить черновик карточки: товар, количество, единицу измерения, желаемую дату и вопросы для уточнения. Отсутствующие сведения оставить незаполненными. Карточку проверяет менеджер».

Теперь понятно, что сравнивать. В карточке не должно появляться выдуманной даты. Если клиент написал «две коробки», нельзя без проверки превращать это в определённое число штук. Неясность должна оставаться видимой.

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

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

Попросите сотрудника выполнить выбранный шаг вручную на небольшом наборе примеров. Запишите время и места, где пришлось уточнять исходные данные. Сохраните этот набор для сравнения с вариантом, где помогает ИИ.

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

Мы ведём проект «Кай · ИИ для бизнеса» и разбираем применение инструментов в рабочих задачах: https://t.me/kaiforbiz

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

Считайте время до готового результата

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

Для каждой попытки достаточно пяти записей:

— пример и его сложность;
— время выполнения всего шага;
— что сотрудник исправил;
— можно ли использовать результат после проверки;
— нужно ли было полностью вернуться к ручному способу.

Покажем на условных числах. Ручная подготовка карточки заняла 6 минут. С ИИ подготовка и ожидание заняли минуту, проверка — две, исправления — ещё одну. Для этой попытки разница составляет две минуты. По одной карточке нельзя заключить, что так будет всегда: нужны повторения на обычных и сложных примерах.

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

Договоритесь о решении до начала теста

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

Не назначайте универсальную норму вроде «достаточно 90% точности». Для черновика внутренней заметки и документа, по которому отгружают товар, последствия ошибки различаются. Критерии нужно привязать к конкретному действию и возможности проверки.

В конце недели выберите один из трёх следующих шагов:

1. Продолжить ограниченный тест: польза заметна, но примеров пока мало или не проверены сложные случаи.
2. Изменить задачу: например, оставить ИИ извлечение данных, а расчёт количества выполнять по справочнику.
3. Остановить пилот: проверка и переделки съедают выигрыш либо результат слишком трудно контролировать.

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

Перед расширением

Вернитесь к первоначальной формулировке. Ускорился ли именно выбранный шаг? Сохранилось ли качество после проверки? Появились ли новые действия, которые никто не учёл? Может ли другой сотрудник повторить процесс по короткой инструкции?

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