Представьте: ночью у клиента случается критический сбой сервера. Инженер уже занимается инцидентом, но клиент об этом не знает. Он видит только молчание системы и пустой экран портала. Через час начинаются тревожные звонки, еще через час - письма руководству. К утру проблема решена, но доверие к сервисному партнёру уже под вопросом. Это не история про плохих инженеров. Это история про «чёрный ящик»: пока всё работает, поддержка почти незаметна. Но если процессы непрозрачны, даже качественная работа может выглядеть как провал.
Привет! Я Наташа Сляднева, руководитель центра экспертизы по комплексному сервису К2Тех. В этой статье-обзоре покажу, как мы сделали сопровождение понятным для клиентов: от двухуровневого управления и работы с обратной связью до портала, Telegram-ботов и Problem Management. Статья будет полезна тем, кто отвечает за сервис, поддержку и клиентский опыт и хочет повысить прозрачность и доверие.
По данным Центра исследований сервисных компаний (ЦИСК), лишь 42,3% компаний фиксируют все активности по заявкам. Многие компании до сих пор полагаются на ручной ввод или разрозненные инструменты коммуникации. Диагностика, внутренняя переписка, повторные выезды — всё это часто остается «за бортом» единого контура управления. В итоге клиент просто не понимает, что происходит с его задачей прямо сейчас.
Мы сопровождаем более 550 заказчиков (с некоторыми из них работаем больше 10 лет) и на своем опыте поняли: в долгосроке удерживает клиента положительный клиентский опыт и прозрачность процессов, а техническая экспертиза — воспринимается как база. В этой статье расскажем, как мы боролись с эффектом «черного ящика» в поддержке и какие инструменты внедрили, чтобы заказчик не гадал, живы ли мы там вообще.
Оглавление:
Два эшелона поддержки: зачем нам два менеджера для одного клиента
Problem Management: Как мы перестали чинить VPN каждый понедельник
Два эшелона поддержки: зачем нам два менеджера для одного клиента
Обычно у нас на поддержке находятся крупные компании со сложным ИТ-ландшафтом и высокими требованиями, и в какой-то момент мы поняли, что одного менеджера для сложных клиентов недостаточно. Поэтому за качество работы с заказчиками у нас отвечают две команды с разными фокусами,и именно их совместная работа обеспечивает стабильный уровень клиентского опыта.
Менеджер сервисных проектов (МСП) Закрепляется за клиентом и отвечает за выстраивание прозрачного и бесшовного процесса работы с ним. Он всегда на связи, готов саппортить по всем вопросам, глубоко погружается в задачи бизнеса и проактивно предлагает способы их решения. Такой подход позволяет выстраивать личные отношения с заказчиком, превращаться из подрядчика в ИТ-партнера.
К сложным проектам и крупным заказчикам подключаются эксперты из второй команды — сервис-менеджеры (СМ). У МСП параллельно несколько десятков контрактов, и он не может физически контролировать каждую заявку. Это уже задача СМ. Они отслеживают соблюдение SLA, скорость реакции, эскалации, вручную контролируют ход решения сложных заявок (иногда по нескольку раз в день), хорошо знают инфраструктуру клиента, помогают инженерам в административных и коммуникационных вопросах.
Например, инженер запланировал замену платы в крупном банке в Красноярске и назначил доставку запчасти курьерской службой на короткую праздничную неделю. Он не учёл, что курьерская служба не возит в выходные, а площадка банка закрыта. СМ сработал как предохранитель: вмешался, перестроил план — запчасть поехала с инженером, сроки сократились на несколько рабочих дней. Без СМ заказчик получил бы просроченную заявку и формальное «ожидаем доставку», а инженер — гневный звонок.
Получение и отработка обратной связи
Работа с обратной связью легко превращается в формальность: собрали оценки, показали отчет руководству, на этом всё остановилось. Чтобы не скатиться в это, мы сформулировали несколько правил:
Разбираем каждый отзыв: и негативный, и позитивный. После закрытия тикета клиенту предлагается оценить работу и оставить комментарий. Он может это сделать в любом формате: комментарий на портале, письмо, звонок. Каждый отзыв разбирается: позитивный подсвечивается команде, негативный прорабатывается индивидуально. Если клиент жалуется на долгое ожидание, мы не ограничиваемся извинениями. Наша задача — найти корневую причину: не дошло уведомление до инженера, сломался процесс эскалации, требуется дополнительная автоматизация. Мы чиним не единичный инцидент, а место в процессе, где он возник.
По каждой жалобе мы возвращаемся к конкретному человеку с результатом: что нашли, что починили, почему так произошло, подсвечиваем изменения. Про этот шаг часто можно забыть, но именно он больше всего влияет на доверие клиента к компании. Для одного крупного банка подготовили видеоотчет с инфографикой, где показали, как их замечания повлияли на развитие сервиса. Но так запариваемся мы, конечно, не всегда, ответа в почте обычно достаточно. Раньше мы отвечали только на критичные замечания, но теперь около 95% обращений получают ответ. При этом работаем не только с негативом: тем, кто ставит высокие оценки, отправляем личные благодарственные письма.
Регулярные встречи МСП с заказчиками. Их цель собрать контекст: какие задачи сейчас решает бизнес клиента, где болит. Все фиксируется в follow-up-письме, включая негатив. Например, на одной из встреч заказчик пожаловался, что коллеги из другого нашего подразделения долго не присылают коммерческое предложение. Сервис-менеджер зафиксировал, пошел к коллегам, подсветил недовольство, и в итоге все оперативно закрыли вопрос. Мелочь, но именно из таких мелочей складывается ощущение, что тебя слышат.
Ежегодный NPS. Он как регулярный замер «температуры по палате»: показывает, насколько заказчики готовы рекомендовать сервис и как в целом оценивают взаимодействие. Мы проводим его силами телемаркетологов — людей, с которыми заказчик не работает напрямую. Потому что клиенту иногда легче сказать правду незнакомцу, чем своему менеджеру. В таких беседах часто всплывают скрытые боли. Результаты NPS мы сводим в единый документ с ответственными по каждому блоку и формируем задачи для каждой группы. Клиентский портал когда-то появился после того, как заказчики в опросе сказали: хотим видеть все в одном месте. Telegram-бот для работы с обращениями — тоже результат NPS.
Унификация информации: от трех тикетов на одну задачу к единому клиентскому порталу
Клиентский портал — одна из ключевых точек контакта с заказчиком. Если им удобно пользоваться, разгружает от рутиных задач менеджеров и инженерные команды.
Когда мы только создали портал, он предоставлял базовый функционал: простую форму создания заявки и раздел с тикетами. Затем мы добавили фильтры и другие инструменты, а со временем он вырос до концепции единого окна. Сейчас заказчик видит все свои заявки по всем направлениям в одном месте.
Раньше разные команды поддержки работали в разных проектах Jira. В случае комплексного инцидента, например при замене сервера, приходилось подключать инженеров по железу, специалистов по телеком-решениям и сотрудников ИБ. Внутри Jira это означало три разных тикета. Клиенту приходилось следить за всеми тремя, хотя у него была одна проблема.
Чтобы убрать этот «зоопарк», мы внедрили сквозную нумерацию и объединили задачи в один проект для заказчика. Теперь он открывает один тикет с единым номером — например, SD‑150 — а внутри него, при необходимости, задача разделяется на внутренние подзадачи. Каждая команда ведёт работу под собственным номером с профильным суффиксом (SD‑150‑INFRA или SD‑150‑DB), но все связанные записи видны на одной вкладке и привязаны к главному тикету. Для клиента это снимает ощущение, что он работает сразу с несколькими разными командами
Нормализация данных: избавились от 10 названий одного сервера
В 2025 году мы собрали со всех подразделений и вывели на портал детальную информацию по контрактам: перечень оборудования на поддержке с серийными номерами, статусы договоров, контакты ответственных менеджеров.
Внутри компании сначала это вызвало сопротивление: менеджерам пришлось вручную приводить данные из договоров к единым шаблонам, чтобы десять моделей оборудования не назывались десятью разными способами. Реакция была предсказуемой: «Вроде и так все работает, зачем?» Но для клиентов фича оказалась ценной. Они теперь сами могут проверить, находится ли конкретный сервер на активном контракте, и увидеть оборудование, которое уже не на поддержке. И фидбэк от заказчиков стал лучшей мотивацией для тех самых менеджеров, которые поначалу сопротивлялись.
Портал продолжает развиваться. Сейчас он в первую очередь удобен инженерам заказчика, но мы хотим, чтобы им было полезно пользоваться и техническим директорам. Для руководителей мы готовим дашборды с аналитикой по отказам оборудования, стабильности инфраструктуры и загрузке ресурсов.
Ускорение реакции с помощью Telegram-ботов
Одна из метрик нашего SLA — скорость реакции на инцидент. Для критических ситуаций счёт идёт на минуты. Мы сделали внутреннего Telegram-бота: он шлёт уведомление о новой заявке, инженер может взять её в работу прямо из мессенджера, и информация о назначении ответственного сразу появляется на портале. Похожий подход — для курьеров по Москве и области: экспедитор фиксирует передачу запчасти нажатием одной кнопки, и статус обновляется на портале в реальном времени. Раньше данные о доставке попадали в систему только на следующий день, после обработки бумажных путевых листов.
Как мы боремся с зависшими заявками
За год мы закрываем более 100 000 заявок. Когда одновременно обрабатываются сотни тикетов, контролировать каждый вручную невозможно. Чтобы находить рискованные кейсы до того, как клиент обратит на них внимание, мы создали внутренний инструмент контроля — «температура заявки».
Механика простая: заявка живет спокойно, пока по ней идет работа. Но если она зависает без движения, ее “температура” начинает расти. Достигает порога, и автоматически попадает в поле зрения техлида и группы клиентского сервиса . Каждая заявка оценивается по нескольким критериям: сколько времени она открыта, есть ли эскалация, какой приоритет, как давно менялся статус. Это решает частую проблему «тишины в тикете», когда инженер что-то делает, но клиенту кажется, что о нём забыли.
Внутри инженерных команд мы используем внутренний скоринг заявок («пенальти»). Он учитывает ошибки в ведении кейса и коммуникации: чем выше значение, тем больше вопросов к работе инженера. Показатель обсуждается на индивидуальных встречах между руководителем, техлидом и специалистом. Если ошибки повторяются, вопрос выносится в отдельную работу по улучшению.
Problem Management: Как мы перестали чинить VPN каждый понедельник
Мы все знаем теорию ITIL, но на практике иногда кажется, что проще бесконечно перезагружать сервер по понедельникам, чем один раз сесть и разобраться, почему он падает. Мы начали внедрять Problem Management около двух лет назад. Суть простая: выявлять и устранять корневые причины повторяющихся инцидентов. Если у заказчика несколько раз ломается одно и то же оборудование, инженеры помимо ремонта ищут системную проблему. Возможно, дело в некорректных настройках, ошибках в конфигурации или внешних факторах. Problem-тикеты выводятся на клиентский портал: заказчик видит связь между инцидентами и корневой причиной.
Пример: у одного из заказчиков каждый понедельник массово отваливался VPN. Инженеры перезагружали шлюз, закрывали инциденты, все расходились до следующего понедельника. Когда сервис-менеджер увидел паттерн, он инициировал Problem-тикет. Провели анализ корневых причин (RCA), и оказалось, что проблема в лимите одновременных сессий на VPN-шлюзе. Оформили Known Error с инструкцией по временному перезапуску, тут же завели Change Request на расширение лицензии. После этого инциденты прекратились.
Есть два режима реагирования на проблемы: во-первых, реактивный — по повторяющимся инцидентам, а во-вторых — проактивный. Он возможен, если мы поддерживаем систему мониторинга инфраструктуры заказчика и подключены к получению алертов, тогда мы часто видим тренд раньше, чем клиент заметит сбой.
Большое значение имеет синхронизация команд и обмен опытом. Все нестандартные случаи и новые решения сразу попадают во внутреннюю базу знаний. Чтобы мотивировать сотрудников пополнять ее мы разработали систему внутреннего бонус-банка: помощь коллеге, статья для базы знаний, полезный скрипт — за всё это можно получить внутреннюю валюту (ака коины) и обменять на курсы или мерч. Одним из ярких результатов стал интерактивный онбординг-симулятор: вместо чтения регламентов новый инженер проходит 40-минутную игру, где ИИ дает фидбек по каждому шагу. Подробнее об этом рассказали в отдельной статье на Хабре.
Вместо заключения
Сейчас уже недостаточно сформировать сильную инженерную команду и обеспечить её запчастями. Техническая часть даёт только половину результата. Для зрелых клиентов «хороший сервис» превращается в базовый уровень. Разово превзойти ожидания не сложно, но эффект «вау» быстро становится новой нормой. Гораздо эффективнее — предсказуемость и прозрачность: клиент хочет точно понимать, что произойдёт, в какие сроки и в какой последовательности. Важно, чтобы даже в 3 часа ночи он мог увидеть, что кто-то за него сейчас воюет с сервером.
