Files
Test-task/docs/implementation_plan.md
T

6.7 KiB

AI Lead Processor · план пилотного запуска

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

Предлагаемое решение. Локальная форма готовит категорию, объяснение и черновик на русском языке. Менеджер отвечает за итоговую категорию, обещания клиенту и отправку сообщения.

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

Предполагаемый экономический эффект. Иллюстративные допущения составляют 120 заявок в неделю, 4 минуты вручную и 1,5 минуты с проверкой черновика. Занятость снижается с 8 до 3 часов в неделю. При 500 ₽/ч высвобождается ресурс стоимостью 2 500 ₽ в неделю, или 10 825 ₽ за 4,33 недели.

Расходы на эксплуатацию. При 600 входных и 250 выходных токенах на заявку API обойдётся примерно в 0,078 в неделю. При условных 90 ₽/ это 7,02 ₽ в неделю и 30,40 ₽ в месяц. За вычетом API оценка ресурса составит около 10 795 ₽ в месяц. Настройку, обучение и сопровождение владелец оценивает отдельно. Допущения и тарифы

План пилота. Предлагаем три этапа.

  1. Подготовка, день 1. Владелец и менеджер согласуют признаки срочности и спама, допустимые обещания в ответах, перечень передаваемых данных и круг лиц с доступом к журналу.
  2. Пробный запуск, дни 2–3. Ответственный за внедрение подключает API. Менеджер сверяет результат с эталоном на синтетических примерах, включая протечки, короткие обращения и попытку изменить инструкцию.
  3. Контроль, одна рабочая неделя. После согласования правил обработки данных отбирают 50 обезличенных обращений. Для сопоставимых заявок фиксируют полное время обычной работы и время с ИИ. Менеджер заранее размечает категории, сверяет их с первоначальными предложениями модели и считает пропуски срочных случаев. Владелец изучает ошибки и расходы.

Три ключевых риска. Вероятность и влияние ниже — предварительные оценки команды для обсуждения до пилота.

Риск Вероятность / влияние Последствия и защита Остаточное ограничение
Ошибка категории Средняя / высокое Пропуск протечки задержит помощь. Менеджер проверяет каждую заявку, видит цвет приоритета, исправляет категорию. Неоднозначные примеры включают в контроль. Описание может скрывать срочность. Иногда потребуется уточнение клиента.
Утечка данных Средняя / высокое Контакты могут попасть во внешний сервис или репозиторий. Удаляют лишние детали до отправки, на отладке используют синтетику, ключ хранят в исключённом из Git .env. Excel исключён из Git, доступ к папке ограничивает владелец. Обезличивание требует внимания. У скачанной копии Excel отдельные права доступа.
Сбой API или ошибочный ответ Средняя / среднее Работа задержится, клиенту могут пообещать лишнее. Система ограничивает время и повторы, проверяет структуру ответа и сообщает об ошибке. Инструкции клиента считаются недоверенным текстом. Менеджер проверяет смысл и при сбое работает вручную. Даже корректный формат допускает выдуманные факты и влияние вредоносной инструкции.

Критерии успешности пилота. Предлагаемые пороги — не менее 90% совпадений с эталоном, ноль пропусков критически срочных случаев, снижение среднего полного времени обработки не менее чем на 40%. Для проверки срочности в контрольном наборе нужны хотя бы 10 критических случаев. Если их мало, набор дополняют отдельной размеченной серией и отмечают её происхождение.

Рекомендация. Расширять использование после достижения всех трёх порогов и оценки полных затрат. При пропуске критического случая пересмотреть правила и повторить проверку на новых примерах.