ИИ в техподдержке: что показал год на нашей первой линии
Про внедрение ИИ в техподдержку пишут в основном вендоры и интеграторы, и чаще о том, как все должно работать. Мы решили проверить это на практике. Рассказываем, что из этого получилось, с какими проблемами столкнулись и что с ними делать.
Автор: Алексей Носков, руководитель линии поддержки SMB, ALP ITSM
Четыре задачи ИИ на первой линии поддержки
Мы запустили ИИ-зацию Service Desk осенью 2025 года. План был такой: сначала внедряем классификатор, потом автоподсказки сотруднику, потом автовопросы клиенту. Четвертым шагом позже планировалось внедрить ИИ-агента для обработки заявок.
- Классификация заявок. От категории, срочности и критичности зависят маршрут и приоритет заявки. Раньше их ставил специалист, по KPI — в течение 3 минут после создания заявки, и мы рассчитывали, что эту ручную работу снимет бот. Начали именно с нее: метрика уже была, значит, эффект было с чем сравнить. Сейчас работает.
- Автоподсказки специалисту. Чтобы решить заявку, специалист ищет инструкцию в базе знаний вручную. Мы хотели, чтобы ИИ сам подбирал знания из базы и сразу показывал подсказку к заявке. Доработки готовы, но в дело пока не пошли.
- Автовопросы клиенту. Если в заявке не хватает деталей, специалист перезванивает клиенту. Мы хотели, чтобы бот сам задавал уточняющие вопросы и специалист получал заявку уже с ответами. Пока в работе.
- ИИ-агент на приеме заявки. Агент сам принимал бы обращение, размечал его и проверял по регламенту. От этого решения в нашем отделе мы отказались, чтобы не расчеловечивать сервис: далеко не все хотят общаться с ИИ, у многих он вызывает только раздражение. Мы сделали упор на качество и оставили пользователям возможность связаться с живым человеком.
- Исторический контекст. Агент находит среди заявок по заявителю и клиенту за последние, например, полгода схожие по услуге и/или контексту, формирует выборку. Выполняет три функции: позволяет идентифицировать дубликаты, выявлять проблемы, а также помогает специалисту с поиском решения на основе опыта выполнения похожих заявок. Пока не реализовано.
Пока еще не все планы выполнены, но прошел год с момента запуска, и пришла пора подвести первые итоги реальной автоматизации работы службы сервиса с помощью ИИ.
На старте ИИ добавляет работу, и это надо заложить в план
Начали с базы — с классификации заявок. Это самый отлаженный процесс первой линии: каждую заявку специалист размечал вручную, ставил категорию, срочность и критичность, при необходимости — эскалировал на нужную команду. На это отводилось 3 минуты. Процесс был понятный и работал как часы. Такие процессы и логично отдавать ИИ первыми: правила известны, результат легко проверить, а эффект сразу видно по метрике.
Но на старте ИИ-классификация шла медленнее, чем это делал сотрудник. Потому что инструмент только подключали, команда его осваивала, дообучала ИИ, при этом поток запросов шел своим чередом. В начале декабря пилот показал точность попадания выше 90%, и мы решили запускать классификатор в автоматическом режиме. Поначалу модель работала нестабильно. В ручном режиме точность долгое время была выше, чем у ИИ. Нам понадобилось полгода на контроль и обучение модели, чтобы переключить на нее процесс целиком.
Отсюда вывод — период, когда ИИ медленнее человека, нужно заложить в план внедрения и заранее согласовать с бизнесом. Тогда вопрос «почему после старта стало хуже» не застанет врасплох ни вас, ни команду.
Обычный поток нашей поддержки — 770–800 заявок в месяц. Но KPI в 3 минуты задает срок: за это время с момента создания заявка должна быть классифицирована, включая время, пока специалист ее увидит. Сами трудозатраты на классификацию, которые списываются автоматически, составляют 2,22 минуты на заявку. По данным за август и сентябрь, ИИ экономит на классификации около 22–24 часов в месяц. Это чуть больше 2% от общего числа трудозатрат, так что экономия вышла незначительной.
ИИ-классификатор снимает рутину, но доверять ему вслепую нельзя
Мы нашли три места, где бота приходится перепроверять.
Бот ошибается там, где мало контекста. На обращение «почта не работает» ИИ ставит срочность и критичность по умолчанию, то есть низкие. Если почта не работает у всего офиса, нужен другой приоритет, а по трем словам модель этого не распознает. Распознать за одной жалобой массовую аварию помогла бы кластеризация инцидентов. Мы ее продумали, но пока не сделали. Так что разметку выборочно проверяем и при высокой доле ИИ.
Команда отвыкает работать без бота. Когда бот почти полностью закрывает разметку, сотрудники перестают делать ее сами. В начале сентября на разборе заявки клиента выяснилось, что, когда она пришла, у бота-классификатора был сбой и заявку разбирали вручную. Незадолго до этого был похожий случай: команда растерялась, и клиент написал резонансное обращение. Таких эпизодов у нас пока два, но вывод уже ясен: навык работы без бота и регламент переключения в ручной режим должны оставаться рабочими.
А бывает, что бот просто не включен. В апреле, разбирая нарушения сроков, мы нашли очередь одного клиента, где бот не был включен. Поэтому проверять, на каких очередях бот реально работает, нужно так же регулярно, как его точность.
Как устроить сам справочник категорий, мы разбирали в статье "Классификация заявок: почему Service Desk есть, а порядка нет".
Подсказки специалисту готовы, но ими не пользуются
Второе направление автоматизации — автоподсказки инженеру. Технически это устроено просто: раз в сутки вся база знаний загружается в ИИ-помощника, и к каждой новой заявке он пишет подсказку, как ее решить.
К сентябрю функция была готова, но специалисты ею пока не пользуются. Пока подсказку не открывают, она не экономит ни минуты. Почему не пользуются, мы точно не знаем. Одна из версий — сама база знаний: если инструкция в базе слабая, то и подсказка по ней выйдет слабой. Поэтому сначала порядок в базе знаний, потом подсказки.
Как считать окупаемость ИИ на первой линии
Один из критериев внедрения ИИ простой: если инструмент экономит 100 рублей в месяц, а полная стоимость владения им — 200, такой инструмент мы не внедряем.
Обе цифры считаем до покупки и по всему циклу заявки. Условный пример — на 800 заявок в месяц. Остальные минуты и доли в нем — допущения, их нужно заменить своими замерами.
Разметка. Трудозатраты на классификацию у нас 2,22 минуты на заявку. По данным за август и сентябрь, ИИ экономит на ней 22–24 часа в месяц.
Поиск решения. Допустим, 10 минут на заявку. Допустим, ИИ сократит время решения примерно на 10% — такого результата ждут опрошенные Forrester ИТ-руководители. Это около 13 часов.
Уточняющие звонки. Допустим, 300 звонков по 5 минут, автовопросы снимают 30% — около 8 часов.
Эскалации. Заявка второй линии в расчет не входит.
Стоимость ИИ. Лицензия и оплата запросов к модели считаются в рублях: подставьте цену своего тарифа.
Всего 43–45 часов, но засчитывать все нельзя: даже в заказанном вендором расчете Forrester засчитывают 80% освобожденного времени. Остается около 35 часов в месяц — четвертая или пятая часть ставки специалиста. На бумаге 35 часов в месяц выглядят значимым бонусом, особенно когда ресурсы ограничены. Но это еще не чистый выигрыш.
Еще одна ловушка — сэкономленное время само по себе не превращается в деньги. Если сотрудник остается и берет другие задачи, компания платит ему столько же, и экономии в рублях нет. В деньги часы превращаются, только если расходы действительно уходят: сокращается ставка или при росте потока не приходится нанимать нового человека. Тогда это около 21 тыс. ₽ в месяц по полной стоимости сотрудника: зарплата начинающего специалиста 65 тыс. ₽ плюс взносы и рабочее место, около 600 ₽ в час.
Вот это, пожалуй, ключевой вывод, и к этому вопросу нужно относиться со всей важностью.
Часть полной стоимости владения тоже в часах: выборочная проверка разметки, допустим, час в день — около 21 часа в месяц, работа над базой знаний, допустим, 10 часов. Чистый выигрыш — около 4 часов, а лицензия, токены и разбор сбоев — реальные деньги. Сам ИИ тоже стоит денег, и это нужно учитывать: подписка и оплата запросов к модели списываются каждый месяц, даже если сэкономленные часы в рубли не превратились. Если ставку не сокращают, ИИ окупается, только когда эти 4 часа на других задачах приносят больше, чем стоит подписка.
Вот и считайте, стоит ли автоматизация экономии.
Хотя мерить проект одними деньгами мы бы не стали: ИИ — это не всегда автоматизация и экономия. Оптимизация полезна, но главной в этом проекте была не она. ALP ITSM — интегратор, ИИ-агентов и автоматизацию мы внедряем клиентам, и правило у нас простое: сначала на себе, потом на клиентах. Своя первая линия стала площадкой, где мы нарабатываем навыки и практику автоматизации с ИИ. На классификаторе команда научилась обучать модель, проверять ее точность и держать наготове ручной режим, и в подсказки и автовопросы мы идем с этим опытом уже не с нуля.
А те самые 22–24 часа в месяц, которые раньше уходили на разметку, специалист теперь тратит в том числе на саму работу над заявками. От верного маршрута и приоритета с первой минуты выигрывают скорость и качество обслуживания: клиент быстрее получает решение.
Что подготовить до запуска ИИ на первой линии
- Оценить экономию по каждому этапу заявки.
- Подсчитать полную стоимость владения до покупки.
- Начать с задачи, у которой есть метрика.
- Привести в порядок базу знаний.
- Заложить в план период, когда ИИ медленнее человека.
- Сохранить навык работы без бота и регламент ручного режима.
Если вы выбираете, с какой задачи начать ИИ на первой линии, или хотите посчитать окупаемость ИИ-агента до покупки, это можно разобрать вместе. ALP ITSM внедряет ИИ-агентов и автоматизацию и развивает ALP GPT, корпоративный ИИ под контролем компании. А о том, почему ИИ-проекты в малом и среднем бизнесе часто не окупаются, мы подробно писали отдельно.
