Наймите хоть сто человек в поддержку — заявки всё равно не будут решаться на первой линии

Бороться с низким FLR можно по-разному. Иногда, если поддержка не может решать проблемы сама, без второй линии, бизнес делает вывод, что на первой не хватает рук. Нанимаем ещё десяток человек, потом ещё, потом ещё. Полгода спустя штат первой линии вырос на треть, а FLR остался там же, где был до найма. Иногда даже чуть просел, потому что новички чаще передают обращения дальше: знаний и прав у них меньше, чем у опытных коллег.

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

В чём тогда причина проблемы? В том, что заметная доля обращений на первой линии — это вопросы с уже готовым ответом. Новые сотрудники берут на себя в первую очередь такие вопросы: они и так закрываются на первой линии, поэтому общий FLR не растёт, а содержательные обращения решаются так же, как раньше. «Когда заработает почта?» — ответ есть в объявлении наверху портала, просто пользователь его не увидел, потому что до портала нужно ещё дойти. «Где моя заявка?» — ответ есть в статусе, который открывается за два клика, если знать, куда кликать. «Как сбросить пароль от VPN?» — есть в базе знаний, статья написана, актуализирована, найти её можно за десять секунд, если искать, а не писать в чат.

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

Посчитаем реальную эффективность поддержки

Возьмём условный пример: 1000 заявок в месяц. Формальный FLR по всем 1000 — 55%.

Теперь вычтем из этой тысячи однотипные, заведомо автоматизируемые обращения — статусные запросы, вопросы по уже объявленным инцидентам, типовые «как сделать X» с готовой пошаговой инструкцией. Таких в реальности набирается немало, по разным оценкам от трети до половины входящего потока в зависимости от зрелости самообслуживания в компании. Возьмём консервативно 450 из 1000. 

Типовые вопросы закрываются с первого раза почти всегда: допустим, 440 из 450. Значит, из 550 решённых на первой линии на содержательные обращения приходится всего 110. Реальный FLR по 550 содержательным обращениям, где нужно разбираться, а не искать ссылку, — около 20%, а не 55%.

Если типовых обращений треть, FLR составит около 34%, если половина — около 12%. Вывод тот же.

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

Почему стандартные методы не помогают

Если пользователь путается в каталоге, самое очевидное решение — научить его каталогом пользоваться: записать видеоинструкцию, провести вебинар, разослать памятку «как найти нужную форму». Только этот способ не масштабируется. Каждый новый сотрудник проходит этот путь с нуля, у всех разный уровень цифровой грамотности, а память об инструкции держится только пока человек не забудет, куда нужно было кликать, обычно недели две. Дальше он снова пишет в чат, потому что вспомнить путь через три раздела каталога дольше, чем написать пару слов в поддержку.

Пользователь не обязан учиться.

Можно пойти дальше и переделать сам каталог услуг — переименовать заявки, сгруппировать их не по структуре ИТ-отдела, а по жизненным ситуациям пользователя. Это, конечно, помогает, но лишь отчасти. Формулировки в каталоге обычно пишут его формальные владельцы, администраторы и разработчики, которые смотрят на мир языком своей специальности. У них уже есть готовый словарь для описания услуги, словарь ИТ-отдела, а не сотрудника из продаж, который открывает портал раз в квартал. Можно нанять контент-дизайнера, чтобы перевести это на человеческий, но в компании на тысячу человек и больше всегда найдётся тот, для кого даже переведённый каталог — тёмный лес.

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

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

Что действительно снимает нагрузку

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

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

При этом просто чат-бот с деревом сценариев — это уже устаревший подход, он маскирует проблему тем же способом, что и лишний найм, а именно добавляет посредника между пользователем и ответом, только более дешёвого. Пользователь всё равно тратит время, просто теперь на диалог с ботом, а не с человеком. А агентный ИИ, у которого есть доступ к CMDB, истории обращений пользователя и базе знаний — через MCP или аналогичный адаптер, — закрывает вопрос. Потому что ищет не «похожую статью по ключевым словам», а конкретный ответ по конкретной заявке конкретного пользователя: смотрит статус его тикета, проверяет, не висит ли по его сервису уже открытый инцидент, и только если готового ответа нет — передаёт заявку человеку, причём с уже собранным контекстом.

На содержательных обращениях FLR растёт именно из-за этого. Оператор получает заявку, в которой уже указаны система, текст ошибки и то, что пользователь успел попробовать, поэтому ему не нужно переспрашивать, а заявке не нужно уходить на вторую линию только из-за нехватки данных.

Чтобы убрать типовые вопросы с первой линии, портал не придётся переделывать заново. Мы в SimpleOne ITSM делаем ИИ-помощника, которой работает поверх уже существующей структуры и данных — каталога услуг, объявлений и базы знаний, поэтому процессы перестраивать не нужно. Простые вопросы он закрывает до создания заявки, а обращения, которые всё же доходят до оператора, приходят предзаполненными.

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

Что в итоге

Когда типовые вопросы уйдут в самообслуживание, FLR первой линии упадёт до тех самых 20% из нашего примера, а среднее время обработки вырастет, потому что останутся одни сложные обращения. По старым метрикам проект покажется провалом. После запуска смотреть стоит на другое: сколько обращений закрылось без человека, какой FLR по содержательным обращениям и во сколько обходится поддержка в целом.

Живые люди в поддержке сейчас стоят дорого, и они должны заниматься только дорогими вопросами, не справкой. А как вы считаете FLR — по всем обращениям или без типовых?