ИИ уже ответил, а работа ещё не закончена

Где заканчивается работа

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

ИИ способен уверенно сообщать ошибочные сведения. Этот риск описан в профиле генеративного ИИ NIST, раздел 2.2. Поэтому гладкость текста и правильность подбора приходится оценивать отдельно. Менеджеру нужен источник, по которому можно проверить предложение.

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

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

Сколько стоит «только проверить»

Самая интересная часть испытания начинается после слов «менеджеру останется только проверить». В это «только» могут поместиться поиск документа, консультация с техническим специалистом и новое письмо с нуля.

Поэтому до проверки с ИИ нужно увидеть, как команда справляется сейчас. На сопоставимых заявках отмечают время чтения, поиска по каталогу, уточнений и подготовки ответа. Если клиент ждёт подтверждения со склада, это отдельная задержка: сотрудник может в это время заниматься другим заказом. Затраты труда и срок ответа клиенту показывают разные стороны процесса.

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

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

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

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

Что обнаружится за ответами ИИ

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

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

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

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

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

Когда есть основания продолжать

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

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

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

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