Шаг 1. Найдите процесс, а не «идею для нейросети»
Запишите задачи, на которые сотрудники жалуются из месяца в месяц. Не ограничивайтесь словами «много писем». Разберите одно обращение: где появляется, кто его берёт, сколько раз ищет информацию, кому передаёт, когда считает закрытым. Иногда узкое место находится совсем не в написании ответа, а в поиске ответственного или ожидании согласования.
Для первого проекта удобен процесс с регулярным потоком и понятной проверкой результата. Важна цена ошибки. Автоматизировать черновик внутренней заметки проще, чем обещание клиенту о поставке. Не начинайте с задачи, где ошибка необратима, а данных для оценки мало.
После обсуждения должно остаться короткое описание: вход, выход, объём в месяц, участники, исключения. Если его трудно составить, рано писать техническое задание для агента.
Шаг 2. Зафиксируйте нулевую отметку
До появления нового инструмента измерьте, как отдел работает сейчас. Возьмите репрезентативную выборку задач: простые и трудные, обычные и спорные. Запишите время от получения до завершения, время чистой работы, число возвратов, ошибки и расходы на операцию.
Договоритесь, что считаете успехом. Например, сократить время подготовки черновика без роста числа ошибок и без увеличения времени проверки. «Сотрудникам понравилось» полезно услышать, но этого недостаточно для решения о масштабировании.
Проверьте, не измеряете ли вы удобную подмену: скорость ответа модели вместо времени закрытия обращения. Клиенту нужна закрытая задача, а не быстрый текст.
Шаг 3. Подготовьте знания и данные
Соберите документы, которыми сотрудник пользуется сегодня, и выясните, кто отвечает за их актуальность. Условия в CRM, таблице и PDF могут расходиться. Сначала определите источник истины и порядок обновления. Иначе система будет раз за разом выдавать старое правило новым языком.
Отделите данные, разрешённые для теста, от конфиденциальных. Назначьте доступы. Не загружайте клиентские документы в личный аккаунт сотрудника ради быстрой проверки гипотезы. Вместе с IT и ответственными за данные определите допустимый способ обработки и хранения.
Когда ответ нужно строить по документам, помогает поиск подходящих фрагментов и передача их модели. Но источник должен быть виден человеку: без него убедительный ответ сложно перепроверить.
Шаг 4. Проведите пилот так, чтобы ему можно было не поверить
Хороший пилот заранее допускает отрицательный результат. Возьмите реальные примеры с согласованным доступом, отложите часть для итоговой проверки, не подгоняйте тест под удачные ответы. Специалисты оценивают полноту, правильность, тон и действия после ответа. Отдельно отмечают ошибки, которые нельзя отправить клиенту.
Проверьте и неблагоприятные случаи: устаревший документ, противоречивый запрос, попытку заставить ассистента игнорировать инструкцию, отсутствие ответа в базе. По рекомендациям OWASP, работа с языковыми моделями требует внимания к инъекциям в запросы и раскрытию данных. Надёжность выясняется на тестах, не в рекламном ролике.
В конце посчитайте весь путь: генерация, проверка, исправления, расход на модель. Если человек тратит столько же времени, как раньше, измените задачу или остановитесь. Продолжать только ради уже вложенных денег — плохой критерий.
Шаг 5. Встройте результат туда, где уже работают люди
Отдельная вкладка часто проигрывает привычному окну CRM, почты или базы знаний. Продумайте, как задача поступит в инструмент, кто увидит рекомендацию, как её исправит, где сохранится окончательное решение. Это и есть большая часть внедрения.
Для действий с последствиями используйте подтверждение, ограничения прав и журнал событий. У агента, который может создавать карточки и отправлять сообщения, полномочия должны быть уже, чем у сотрудника. Откат и разбор ошибки нужно предусмотреть заранее.
После запуска назначьте владельца процесса и владельца технической части. Первый следит за правилами и качеством, второй — за доступностью, обновлениями и стоимостью. Без обоих решение постепенно теряет актуальность.
Шаг 6. Пересматривайте результат после запуска
Каждый новый тариф, продукт или регламент меняет содержание ответов. Проверяйте выборку завершённых задач, собирайте жалобы сотрудников, обновляйте документы и тесты. Если модель или поставщик меняются, повторите ключевые проверки: «раньше работало» не гарантирует того же завтра.
Оценка должна соединять качество и экономику. Учитывайте лицензии, запросы, поддержку, работу проверяющих и исправление ошибок. Только после этого сравнивайте стоимость операции с исходной.
Мы начинаем с диагностики одной задачи и плана пилота. Такой этап в «Горячо!» стоит от 90 000 ₽; разработку и интеграции считаем отдельно. Опишите свой процесс, и первый разговор получится предметным.
Частые вопросы
Сколько времени занимает внедрение ИИ?
Срок зависит от данных, интеграций и уровня риска. Диагностика и пилот для одной задачи короче, чем развёртывание нескольких процессов. Календарный план составляют после изучения системы и примеров.
С чего начать, если в компании нет технической команды?
С описания одного процесса и владельца со стороны бизнеса. Для простого теста можно рассмотреть готовые сервисы, но ответственный за данные, проверку и решение о запуске всё равно нужен.
Какие метрики нужны для пилота?
Время завершения задачи, доля результатов без переделки, частота критических ошибок, время контроля человеком и полная стоимость операции. Сравнивайте их с тем же процессом до пилота.
Что делать после неудачного пилота?
Разобрать причины: процесс, данные, модель, интеграция или экономика. Отрицательный результат экономит бюджет, если на его основе не масштабируют слабое решение.
Владимир Перекатнов
Генеральный директор Креативной группы «Горячо!». Пишет о практике — без маркетингового тумана и слайдов ради слайдов.
Познакомиться с командой