Почему поддержка перестаёт справляться, даже когда людей становится больше

Есть момент, который я видел уже не один раз.

Количество обращений растёт. Очереди увеличиваются. Руководители начинают срочно искать новых сотрудников. Через несколько месяцев команда становится больше, а ощущение аврала никуда не исчезает.

Обычно в этот момент становится понятно, что проблема глубже.

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

В результате людей становится больше, а лишних действий — ещё больше.

Одна из самых недооценённых вещей в поддержке — хороший классификатор обращений.

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

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

То же самое происходит с разделением линий поддержки.

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

Поэтому любые изменения я обычно начинаю не с поиска новых сотрудников и не с обсуждения KPI.

Сначала нужно посмотреть, как на самом деле проходит обращение от клиента до решения. Где оно задерживается. Где его передают между командами. Где сотрудники принимают разные решения в одинаковых ситуациях.

Только после этого появляется смысл пересматривать классификатор, разграничивать зоны ответственности между линиями, настраивать правила эскалации и SLA.

На практике именно такие изменения дают самый заметный эффект.

Не потому, что операторы начинают работать быстрее. А потому, что обращение перестаёт блуждать между людьми и с первого раза попадает туда, где его действительно могут решить.