Когда бизнес говорит, что «ИТ работает медленно», проблема обычно не в нехватке людей. Проблема в «налоге на хаос»: нет единого входа, размыта ответственность, а дорогие эксперты заняты не тем, за что бизнес действительно готов платить.
Чтобы поддержка не превращалась в тупик, ее нужно делить по уровню сложности. Проще всего понять это через аналогию с медициной.
L1 - регистратура. Принимает обращение, фиксирует симптомы, решает типовые задачи по инструкции: сброс пароля, настройка почты, базовые консультации.
L2 - дежурный врач. Проводит диагностику, ищет причину сбоя, дает временное решение и восстанавливает работу.
L3 - профильный хирург. Это разработчики, архитекторы, системные и сетевые администраторы. Они должны заниматься сложными проблемами, а не рутиной первой линии.
Главная управленческая ошибка - отправлять «хирурга» лечить каждую простуду. Когда архитектор чинит принтер или ищет, почему у бухгалтера не открывается Excel, компания платит за эту работу в разы дороже рынка. Это один из самых дорогих способов тратить ФОТ.
Для пользователя внутренняя архитектура L1–L3 должна быть невидима. Ему нужно одно окно: сообщил проблему один раз - получил номер заявки, статус, срок и понятный ответ.
Но для бизнеса важна не только скорость, а предсказуемость результата. Если 85% инцидентов закрываются в согласованный срок, этим можно управлять. Можно планировать смены, работу склада, касс и логистики. А поддержка по модели «либо быстро, либо никогда» - это уже не сервис, а источник операционного риска.
Даже если в решении участвуют несколько команд, у обращения всегда должен быть один владелец. Именно он отвечает перед пользователем за статус, сроки и результат. Иначе исполнителей много, а по факту не отвечает никто.
Нужен и старший смены или диспетчер потока. Он управляет входящими обращениями: ставит приоритеты, следит за сроками и видит, где разовая проблема, а где уже массовый сбой. Приоритет должен определяться не громкостью крика, а влиянием на бизнес: одна неработающая касса и сбой оплаты во всей сети - это разный уровень риска.
Обязательно нужен и прозрачный путь эскалации. Если магазин или офис не согласны со сроком или приоритетом, должно быть понятно, кто пересматривает решение и в какой срок.
Из практики. В одной розничной сети на одного сотрудника поддержки приходилось 25 магазинов, и жалобы на скорость были постоянными. Анализ показал: проблема не в людях, а в отсутствии структуры. Мы закрыли обращения через личные сообщения и звонки, оставили одно окно, разделили роли L1–L3, ввели диспетчера потока и закрепили владельца за каждой заявкой. В результате один сотрудник стал устойчиво обслуживать уже 40 магазинов - без найма новых людей и без переработок.
Зрелая поддержка - это когда у каждого сбоя есть владелец, срок и понятный путь эскалации. Бизнесу не нужны герои. Бизнесу нужен предсказуемый результат в согласованный срок.