SLA 48% → 99%. Проблема была не в техподдержке
Магазин сообщил о проблеме: кассы перестали работать. Прошел час, потом второй. Никто не позвонил, никто не приехал. Когда я спросил команду поддержки: «Что случилось?» — ответ был честным: «Мы не видели. Были в другом чате». Один менял батарейки в мыши у кого-то в офисе. Другой — картриджи. Третий помогал секретарю с Excel. А магазин в это время просто стоял.
Чатов с заявками было больше двадцати. Отдел вырос — завели отдельный чат. Вышли в новый регион — завели региональный. На старте был один сотрудник и один чат. Потом у пяти человек оказалось двадцать с лишним чатов. Приоритет определял тот, кто первым успел написать, или тот, кто мог физически дойти до нужного инженера. Если проблема была действительно критической, она могла потеряться в общем шуме. По каким-то мелочам при этом эскалировали до CEO.
Внутри команды выработалось рабочее решение: написать в чат и следом добавить CEO. CEO — это сигнал, что надо бросить все и делать то, что скажет CEO. Команда адаптировалась: из потока заявок выбирали что-то простое и делали. По остальным логика была другой: CEO придет, скажет, что важно. Вот и вся система приоритизации.
CEO как ручной маршрутизатор
Участие CEO в ежедневных ИТ-вопросах было запредельным. В начале — до десяти обращений в день. Люди это знали и использовали. Если не добавить CEO — можно ждать бесконечно. Если добавить — получишь реакцию. Это не была слабая команда. Это была команда без управляемой системы.
Единого входа для заявок не было — только чаты. Матрицы приоритетов не было — только громкость голоса и право прямого доступа. Категоризации не было — никто не знал, где чаще всего ломается и почему. Владельца на заявку и срока закрытия — тоже. Аналитики повторов не существовало, и понять, где источник проблем, было невозможно.
Когда случался массовый сбой, все чаты разрывались от сообщений. Координировать действия в этой куче было невозможно. Вытащить информацию тоже.
Бизнес жаловался на ИТ. ИТ просило людей. Получало закономерный ответ: у вас в текущем составе порядка нет — добавим людей, будет больше беспорядка.
Выйти из этого тупика можно было только одним способом — поменять архитектуру, а не залить хаос дополнительными людьми.
Пока обращения жили в чатах, у поддержки не было настоящей экономики. Нельзя было посчитать, сколько стоит один тип проблемы, какие сбои повторяются, где команда тратит время и какой OPEX уходит на ручную маршрутизацию. Бизнес видел только раздражение. Цифр не было.
Первый честно измеренный SLA: 48%. Это не было падением
Начали с покупки системы учета заявок на базе 1С. Инструмент обошелся в 40 000 рублей. Но результат дала не цена системы, а правила вокруг нее. Настройка простая: любая проблема уходит на почту, в ответ приходит номер зарегистрированной заявки. Можно написать в чат, но только с номером. Без номера нет управляемого SLA.
Договорились начать с одного подразделения. Через неделю провели первый разбор — категорий по источнику и способу закрытия оказалось слишком много. Начали упрощать.
Параллельно ввели матрицу приоритетов — не по должности заявителя, а по влиянию на бизнес:
- блокирующий: остановка работы компании;
- критический: остановка группы магазинов или склада;
- высокий: остановка одного магазина или офиса;
- нормальный: остановка одной кассы, одних весов — всего, что снижает уровень сервиса;
- низкий: всё, что может подождать.
Ввели категоризацию: где произошло, что сломалось, кто владелец домена. Ввели способ закрытия: ремонт, вызов подрядчика, ошибка в программе, ошибка пользователя, инструкция, ошибка в данных.
За две недели систему масштабировали на все подразделения: каждый второй день закрывался один чат. Все двадцать с лишним чатов ушли внутрь единой системы. Теперь по каждому типу проблем была картина: сколько их, сколько занимает решение, как они закрываются. Первый честно измеренный SLA оказался 48%.
До запуска учета объективного SLA не существовало — только ощущение вечной перегрузки. Когда начали фиксировать критичные обращения, оказалось, что только 65% из них получали реакцию в тот же день. Остальные тонули в очереди или терялись полностью.
48% — это не было падением. Это была первая правда о состоянии сервиса.
Что изменили: конкретная механика
Рабочее место инженера
Заявки в системе стали сортироваться по приоритету, а не по времени поступления. Старший смены получил отчет: сколько заявок у каждого сотрудника, сколько решено, сколько высоких приоритетов, среднее время на заявку. Тот же отчет — каждому сотруднику о себе и о команде.
Быстро стало видно, кто решает меньше всех или медленнее всех. Разбирался с каждым случаем отдельно. 90% — не нежелание работать. Просто не было опыта. Для них назначил кураторов — более опытных коллег. Условие простое: куратор помогает, подопечный оставляет след — пишет инструкцию, как решить эту проблему в следующий раз. Остальные 10% просто не хотели работать. Теперь это было видно. Кто-то ушел, кого-то перевели туда, где они давали больше пользы.
Роль старшего смены
Поменял режим работы: 2 через 2, по 12 часов, со смещением начала смен. Покрытие выросло до 12+ часов в сутки. В каждой смене — старший с одной задачей: приоритизировать входящий поток и вести все обращения с высоким приоритетом и выше. Прописал порядок эскалации для критичных ситуаций — кого и как уведомлять.
Закрытие обходных каналов
Это было управленческим изменением, а не технической настройкой. Директора магазинов и функции привыкли писать напрямую, подключать CEO и добиваться реакции через личный доступ. Первый чат выбирали осознанно — там было несколько директоров магазинов. Поговорили с каждым: что изменится, почему это лучше, как будет работать дальше. Проблем с негативной реакцией не было. По остальным — подготовка и информирование перед каждым закрытием.
Договорились «на берегу»: нет номера заявки — нет обязательства по сроку. Любое обращение в обход системы означает, что у него нет ни приоритета, ни срока, ни ответственного. Это правило закрепили не приказом, а логикой: система стала единственным местом, где заявка вообще существует.
Те, кому изменение не нравилось, приходили ко мне напрямую. Садились и разбирались, в чем конкретно проблема. Те, кто поднимал вопрос к CEO, получали от него один ответ: «разберитесь», и шли ко мне. За счет подготовки сильного сопротивления не было.
Механизм эскалации поменялся. Ко мне стали приходить с номером заявки — и директора магазинов, и топы других департаментов. Вначале — до 10 раз в день. К концу — один-два раза в неделю. Это тоже был измеримый сигнал: модель работает.
Итерационная настройка SLA
После первой недели SLA составил 63%. Те же люди, та же численность. Но SLA вырос с 48 до 63% только за счет того, что заявки перестали идти к тому, кто первым взял трубку. Дальше настройка шла итерационно: анализировал, почему не укладываемся, корректировал матрицу. Спустя месяц — 76%.
Анализ закрытых заявок: 60% — не ИТ
Параллельно с работой над SLA шел второй анализ — как фактически закрываются заявки. Способ закрытия был обязательным полем: ремонт, замена, ошибка пользователя, инструкция, ошибка в программе, ошибка в данных.
Более 60% закрытых заявок лежали не в ИТ. Они были в знаниях и умениях сотрудников. Люди просто не знали, как работать с системами.
Начал отслеживать это регулярно и нашел закономерность. Каждый новый магазин создавал волну обращений — в первый месяц работы 200+ заявок. Стандартный уровень у работающих магазинов был кратно ниже. Проверили программу обучения новых сотрудников. Стало понятно почему: работе с нужными системами их не учили.
Поправили программу. Волна исчезла. После нескольких итераций новый магазин перестал отличаться по объему обращений от обычного работающего.
Это был разговор с бизнесом — не про ИТ, а про операционный процесс. Результат анализа стал основанием для пересмотра программы обучения, а не только для расширения штата поддержки.
Дальше — регулярная работа с разработкой: процедура допуска релизов, контроль обновлений. Информационный канал: новости о сбое и времени устранения, чтобы магазины не разрывали чаты в поисках ответа. Структура поддержки усложнилась: появились специализированные группы по кассам, сетям, программам и круглосуточный мониторинг 24×7. По оборудованию — регулярные обслуживания на точках, другой механизм закупки, контроль всплесков после глобальных изменений.
Разговор с CEO: как обосновать расширение штата
После первого месяца: SLA 76%, данные по 41 000+ обращениям на 500+ магазинов — я пошел к CEO.
Разговор был коротким.
Я показал: вот объем проблем по доменам. Вот что мы решаем тем же штатом сейчас и как быстро. Вот что накапливается: заявки, которые не успеваем закрыть в SLA. Вот оценка потерь в часах простоя и деньгах по выручке — это было видно, потому что у бизнеса были данные по каждому магазину и каждому часу работы.
Вывод в цифрах был однозначным: стоимость накопленных нерешенных инцидентов перекрывала стоимость дополнительных смен. Не «ИТ просит людей» — разговор с цифрами, у которых есть очевидный вывод.
CEO внес пару правок в матрицу SLA — доработал по паре приоритетов, исходя из своего понимания бизнес-критичности. И дал четыре штатные единицы. Потому что не надо было убеждать — надо было показать.
Результат за 6 месяцев
SLA рос по шагам:
- старт — 48%;
- первая неделя — 63%;
- первый месяц — 76%;
- 6 месяцев — 99%.
Доступность критичных сервисов: с 65 до 99,9%.
Объем обращений: с 41000+ в месяц на 500+ магазинов до 6000+. Каждый магазин — с 2,5+ обращений в день до 2,5+ обращений в неделю.
Кассовые инциденты: с 50 до двух в месяц на магазин. Это отдельная история — про кассу как точку денег, профилактику, подменный фонд и физическое состояние кассового узла. Здесь важно другое: без единой системы, приоритетов и анализа повторов мы бы даже не увидели этот контур как отдельную проблему.
Про доступность отдельно. Рост SLA сам по себе не равен росту доступности критичных сервисов. Доступность поднялась с 65 до 99,9% потому, что из заявок начали системно вытаскивать повторяющиеся причины: оборудование, кассы, сеть, релизы, обучение, подрядчики. Поддержка перестала только тушить обращения и стала источником данных для профилактики. Это разные вещи.
Через полгода я спросил CEO: сколько раз за последний квартал его просили повлиять на ИТ-вопросы? Он задумался. Потом сказал: не помню. Давно не просили.
Для меня это была лучшая оценка результата. Не SLA 99%, а то, что CEO перестал быть ручным маршрутизатором критичных ИТ-проблем.
Вывод
SLA не растет от давления на команду поддержки. От давления растет только выгорание. Пока обращения живут в чатах — у поддержки нет настоящего OPEX. Есть только ощущение вечной перегрузки. Стоимость сервиса становится видна, только когда каждое обращение получает категорию, приоритет, владельца, срок и причину закрытия. Тогда можно обосновать расширение штата не словами, а цифрами. Тогда можно убрать из потока целый класс проблем — как это и получилось с программой обучения.
SLA вырос потому, что хаос получил архитектуру: единый вход, приоритет по влиянию на бизнес, категорию, владельца, срок, понятный способ закрытия. Без этого поддержка — не сервис. Это очередь к тому, кто громче эскалирует. И очень часто этот человек — CEO.
Директор магазина не спрашивает номер заявки. Он спрашивает, когда снова можно продавать.
Опубликовано 28.05.2026
