Проекты с AI-агентами чаще проваливаются не на пилоте, а сразу после него — в момент, когда удачный участок решают масштабировать на весь поток, и деньги, сэкономленные на первой линии, возвращаются очередью неразобранных обращений. Масштабировать агента после пилота — значит расширять его охват по времени, каналам, темам и подразделениям так, чтобы качество ответов и нагрузка на людей оставались под контролем. Пилот доказывает, что подход работает на выбранном участке. Готовность к полному потоку он не доказывает, и путать одно с другим дорого.
Пилот проверяет идею, полный поток — разнообразие
Пилот идёт на выбранном участке: один канал, одни часы, понятный тип обращений. Полная нагрузка приносит то, чего в этой выборке не было, — редкие сценарии, нетипичные формулировки, пики, обращения на границе компетенции агента.
Отсюда типичная ошибка: успех пилота воспринимают как доказательство готовности к масштабу. На деле он доказывает только то, что подход работает на проверенном участке. Похоже на ресторан, который отлично отработал банкет на двадцать гостей и решил открыть зал на двести: рецепты те же, кухня — нет.
Пилот отвечает на вопрос «работает ли это в принципе». Масштабирование отвечает на вопрос «выдержит ли это разнообразие реального потока». Второе не следует из первого.
Вердикт: решение «расширяем» после пилота — это начало второго проекта, а не конец первого.
При росте потока первыми ломаются редкие темы и люди на передачах
| Что | Почему на пилоте не проявилось |
|---|---|
| Редкие сценарии | На узкой выборке просто не встретились |
| Полнота базы знаний | Пилотный участок покрывался несколькими документами |
| Нагрузка на людей | Передач было мало, их успевали разбирать |
| Интеграции | Объём запросов к системам вырос на порядок |
| Единообразие ответов | Противоречия в документах не встретились |
Что это значит: три строки из пяти — работа с содержанием, ещё одна — техническая проверка интеграций, и всё это можно сделать заранее. Третья строка — про людей, и её недооценивают чаще всего. Если агент передаёт человеку десятую часть обращений, то при росте потока в десять раз поток передач тоже вырастет — и упрётся в тех же сотрудников, ради разгрузки которых всё затевалось.
Вердикт: агент, который масштабируется быстрее, чем люди за ним, переносит очередь из одного места в другое.
Расширять по одной оси за раз: время, канал, темы, процесс
- Сначала время. Расширить часы работы на том же типе обращений безопаснее, чем добавить новые темы в прежних часах.
- Потом смежный канал. Тот же процесс в другом канале — переиспользуется база знаний, меняется только способ доставки.
- Затем новые темы. Каждая требует своих материалов и своей проверки.
- И только потом второй процесс. Это фактически новое внедрение, а не расширение, со своей целью и своей метрикой.
Порядок не догма, но логика в нём есть: каждый следующий шаг добавляет ровно один источник неопределённости. Расширение сразу по нескольким осям лишает возможности понять, что именно пошло не так, — а понять это нужно быстро, пока клиенты не заметили.
Вердикт: медленное расширение по одной оси почти всегда быстрее, чем быстрое по трём с последующим разбором завалов.
Пока сплошное чтение находит ошибки, расширяться рано
Четыре признака говорят, что пилот ещё не закончен, даже если метрика уже понравилась.
Находки ещё идут. Если сплошное чтение ответов за день даёт хотя бы один неверный ответ, поток увеличит их пропорционально.
Передачи не разбираются. Если список тем для дописывания копится и не закрывается, при росте он станет неуправляемым.
Метрика не устоялась. Если результат прыгает от недели к неделе, непонятно, что именно масштабируется.
Владелец процесса перегружен. На пилоте роль требовала пары разговоров в неделю; при расширении нагрузка вырастет, и это надо предусмотреть заранее.
Вердикт: торопиться с расширением стоит только тогда, когда эти четыре признака ушли, а не когда закончился бюджет пилота.
Материалы, люди и интеграции готовятся до расширения, а не в режиме тушения
Материалы по темам, которых не было в пилоте, проще собрать заранее, чем в режиме тушения. Нужна договорённость о том, кто разбирает возросший поток передач. Интеграции проверяются на увеличенном объёме запросов. И набор тестовых сценариев обновляется: пилотные вопросы уже не покрывают новый охват — как собрать такой набор, разобрано в статье про тестирование AI-агента перед запуском.
За день сплошного чтения не нашлось ни одного выдуманного или неверного ответа, список тем для дописывания закрывается быстрее, чем пополняется, а метрика держится ровно две-три недели подряд.
Вердикт: каждый пункт этого списка дешевле сделать за неделю до расширения, чем за день после.
Сотрудники вне пилота встречают агента со скепсисом
В пилоте участвуют те, кто согласился, а часто и те, кто сам вызвался. При расширении в контур попадают все, включая тех, кто был против или просто не в курсе, и эту работу обычно не планируют.
Разница между группами существенная. Участники пилота знают, что система умеет и чего не умеет, у них есть опыт обхода слабых мест и понимание, зачем это. Остальные получают инструмент, о котором слышали в коридоре, и первый же неудачный ответ подтверждает их скепсис.
Работает не общая рассылка, а короткое введение от тех, кто участвовал: что реально изменилось в их работе, что раздражало и как это решили. Пятнадцать минут от коллеги убеждают лучше часа презентации и заодно снимают подозрение, что показывают витрину.
Вердикт: внедрение масштабируется со скоростью доверия людей, а не со скоростью настройки.
Часы на разбор передач считаются заранее одной формулой
Расширение увеличивает не только поток обращений к агенту, но и поток того, что он передаёт человеку. Пропорция сохраняется, а способность людей это разбирать — нет: она упирается в конкретные часы конкретных сотрудников.
Считается это просто: доля обращений, уходящих человеку, умножается на среднее время разбора одного и на планируемый объём. Получаются часы в неделю, которые сравниваются с реальным временем назначенных людей.
Условный пример для проверки арифметики: 3 000 обращений в неделю, человеку уходит 10%, разбор одного занимает 6 минут. Это 300 передач и 30 часов в неделю — почти ставка одного сотрудника. После расширения потока в десять раз при той же доле передач нужно уже 300 часов в неделю, то есть при 40-часовой неделе семь-восемь человек на полный день. Если их нет, план расширения нереален, как бы хорошо ни работал агент.
Если расчёт даёт больше, чем есть, результатом расширения будет очередь неразобранных передач — худшее состояние из возможных: клиент не получил ответа ни от агента, ни от человека. Лечится это снижением доли передач или увеличением ресурса, но не надеждой, что справятся.
Вердикт: эта формула за пять минут отвечает на вопрос, который иначе всплывёт через месяц жалобами.
После расширения метрики пилота перестают ловить проблемы
Показатели, которые подтвердили успех пилота, в новом режиме менее чувствительны к проблемам, поэтому на время набор метрик стоит сменить.
Три показателя стоит смотреть ежедневно первые две недели. Доля обращений, завершившихся без ответа или с отказом агента, — она первой реагирует на темы, к которым не готовились. Время до разбора переданных человеку обращений — оно показывает, справляются ли люди. Доля повторных обращений по тому же вопросу — она ловит ситуацию, когда ответ формально дан, а вопрос не решён.
Сравнивать эти числа нужно не с пилотом, а с их собственной динамикой: важно не абсолютное значение, а растёт оно или стабилизируется. Рост на третьей неделе чаще всего означает, что накопился хвост неразобранного. Что отслеживать дальше, в постоянном режиме, — в разборе мониторинга после запуска.
Вердикт: первые две недели после расширения — это не отчётный период, а период наблюдения.
Каждый новый отдел — отдельный маленький пилот
Пилот шёл в одном отделе, а расширение затрагивает соседние, у которых свои процессы и своя терминология. Одна и та же тема в разных подразделениях может означать разное: запрос на «согласование» в продажах и в закупках проходит по разным маршрутам, к разным людям и с разными сроками. Навык, настроенный на первое, во втором отделе будет уверенно давать неверные ответы.
Отсюда правило: каждое новое подразделение — отдельный небольшой пилот, а не добавление пользователей. Неделя наблюдения на малом потоке перед полным включением экономит месяц разбирательств и сохраняет доверие людей, которые видят систему впервые.
Вердикт: «подключим ещё один отдел» звучит как настройка доступа, а на деле это новое внедрение в миниатюре.
Откат к прежним границам проверяется до расширения
Расширение должно быть обратимым. Если после увеличения охвата качество просело, нужна возможность вернуться к прежним границам за минуты, а не пересобирать конфигурацию. Это условие проверяется до расширения, а не в момент, когда оно понадобилось. Я бы записывал условие отката рядом с условием остановки пилота: оба отвечают на вопрос «что делаем, если пошло не так».
Когда масштабировать агента не стоит
Не каждый удачный пилот нужно расширять. Если пилот закрыл самый массовый и простой тип обращений, следующий по объёму участок может оказаться в разы меньше и сложнее: затраты на материалы, проверку и людей на передачах там растут, а экономия падает. Честный расчёт иногда показывает, что агенту лучше остаться на своём участке, а остальное пусть делают люди.
Масштабирование не окупится и там, где поток и так невелик: при паре десятков обращений в день агент на всех темах легко сэкономит меньше, чем стоит поддержка базы знаний по этим темам. И оно рискованно, если в компании нет человека, который отвечает за процесс целиком, — без него расширение упирается в согласования. Это же условие мы проверяем перед любым проектом, оно описано в нашем подходе.
Экономика масштаба у агента, который тарифицируется за диалог, линейная: у Дирижёра это 2 ₽ за диалог, и стоимость растёт вместе с потоком. Поэтому окупаемость расширения считается не по цене агента, а по тому, сколько человеческих часов на новом участке реально освобождается.
Расширение планируется как второй проект со своей метрикой
Что это меняет в решении: после удачного пилота вопрос «расширяем или нет» стоит заменить тремя — на какую ось расширяемся первой, сколько часов людей понадобится на передачи при новом объёме и как вернуться к прежним границам, если качество просядет. Если на какой-то из трёх ответа нет, расширяться рано, даже если пилот был блестящим.
Проверить на своих данных можно за день. Возьмите данные пилота: долю передач человеку, среднее время разбора одной, число неверных ответов за день сплошного чтения. Умножьте первые два числа на планируемый объём и сравните с часами людей; умножьте третье на рост потока и спросите себя, готовы ли вы к такому числу ошибок в день. Если оба ответа устраивают — расширяйтесь по одной оси. Если нет — сначала доводите пилот.
Как выбрать первый процесс — в статье с чего начать внедрение. Как считать эффект — в разборе замера.
