Когда IT-команде нужен руководитель технической поддержки

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

Он отвечает за всё, что связано с обработкой обращений пользователей и качеством сервиса. Это структура линий поддержки (L1–L2–L3) и правила маршрутизации, SLA по времени реакции и решения, процессы эскалации сложных инцидентов, метрики — поток обращений, время решения, доля повторных тикетов, CSAT. На нём дежурства и нагрузка команды, база знаний, чтобы типовые запросы закрывались быстрее, и связка с разработкой и инфраструктурой по повторяющимся проблемам. Его задача не «отвечать на тикеты», а выстроить поддержку как управляемый процесс с предсказуемым качеством, который держит нагрузку при росте.

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

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

Это зависит от того, есть ли у вас постоянный поток обращений. Если поддержка — это регулярная функция с командой инженеров, дежурствами и пользователями, которым каждый день нужно решение, то это штатная роль: ею нельзя управлять наездами. Разовое привлечение оправдано в другом сценарии — когда нужно один раз выстроить процесс с нуля: спроектировать линии поддержки, ввести SLA, настроить эскалации, метрики и базу знаний, обучить команду, — а дальше уже поддерживать систему силами тимлида. Главное — не путать задачи: построить процесс поддержки и ежедневно им управлять под потоком обращений — это разные роли и разный режим работы.

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