Что такое Hypercare?
 
Hypercare — это период усиленной поддержки сразу после запуска нового продукта. 
Клиенты только начинают осваивать интерфейс, разбираться с функциями, адаптировать процессы.
 
Усиленная поддержка работает до тех пор, пока всё не станет стабильно.
 
Представь: компания — как скорая помощь. 
Быстро реагируем, помогаем разобраться с проблемами и показываем, что заботимся о пользователе.

🚀 Почему Hypercare особенно важен при выходе нового продукта?
 
Запуск — всегда стресс. Не только для команды, но и для клиентов.
 
Они боятся:
▪️Сложностей освоения
▪️Ошибок и простоев
▪️Потери привычного функционала
 
Hypercare позволяет:
▪️Успокоить клиентов 
▪️Быстро решать проблемы 
▪️Обеспечить плавный переход 
▪️Превратить стресс в доверие 
▪️Контролировать качество сервиса 
▪️Убедиться, что решение работает как задумывалось 
▪️Проверить, что команда готова к своим обязанностям
 
⚠️ Что будет, если пропустить Hypercare?
 
Как сесть в лодку без весел:
▪️Критические баги могут остаться незамеченными 
▪️Пользователи не поймут, как работать с решением 
▪️Репутация продукта пострадает 
▪️Мелкие проблемы станут большими 
 
🛠 Как организовать Hypercare при запуске нового продукта
 
Шаг 1. Сформируйте команду
Создайте специальную группу для поддержки продукта:
▪️L1, L2, L3
▪️Менеджеры БЗ
▪️Аналитики
 
Шаг 2. Обучите команду
Подготовьте персонал к работе:
▪️Изучение интерфейса и функций
▪️Отработка типовых вопросов
▪️Администрирование
▪️Эскалационная схема
▪️Настройка алертов
 
Шаг 3. Коммуницируйте заранее
До запуска объясните пользователям:
▪️Что меняется
▪️Зачем это нужно
▪️Как получить помощь
▪️Где найти инструкции и обучающие материалы
 
Шаг 4. Мониторьте показатели
Фокусируйтесь на метриках:
▪️Скорость ответа и закрытия обращений
▪️Темы обращений
▪️Отклонения от нормальных значений
 
Шаг 5. Собирайте обратную связь
Используйте:
▪️ Опросы
▪️ Формы
▪️ Прямую коммуникацию 
Чтобы улучшить следующий запуск и сам продукт.
 
❌ Частые ошибки при запуске без Hypercare
 
1. Выгорание команды 
Резкий рост обращений истощает сотрудников.
 
2. Неподготовленность команды 
Без чёткого плана действия хаотичны.

 3. Неправильная приоритизация запросов 
Мелкие вопросы затмевают настоящие проблемы.
 
4. Разнобой в ответах 
Если каждый говорит по-своему — клиент теряет доверие.
 
✅ Преимущества Hypercare при запуске нового продукта
 
1. Увеличение удовлетворённости (CSAT) 
Клиенты получают быструю и качественную поддержку через удобные каналы. Это создаёт ощущение, что их услышали и ценят.
 
2. Снижение оттока (churn) 
Когда видишь, что тебя поддерживают — остаёшься. Особенно в момент неопределённости.
 
3. Рост adoption 
Пользователи активно используют продукт, когда чувствуют уверенность. 
А она даётся грамотной поддержкой и обучением в первые недели.
 
> Когда ваша команда объясняет, как работают новые фичи — клиенты не просто используют продукт. Они полюбят его.
 
❓Часто задаваемые вопросы
 
Сколько длится Hypercare? 
Обычно — 2–4 недели. Время зависит от сложности продукта и реакции пользователей.
 
Что дальше? 
Начинается этап пост-гоу-лайв поддержки. 
Нет повышенной нагрузки, но важно сохранять высокий уровень обслуживания и продолжать собирать обратную связь для будущих улучшений.
 
🎯 Итог
 
Hypercare — не прихоть, а необходимость. 
Это время, когда формируется первое впечатление о продукте, закладывается его репутация и создаётся база для успешного будущего.
 
Пренебрегать Hypercare — всё равно что запустить ракету, но не проверить систему посадки. 
Взлёт прошёл успешно, а вот с приземлением могут возникнуть проблемы.
 
Хочешь надёжный запуск? 
Делай Hypercare. И делай его правильно.
 
#Hypercare #TechSupport #IT #ProductLaunch #CustomerSuccess #SupportTeam

Прочитал книгу Real ITSM: Проверено временем от Cleverics. Все главы также также доступны у них на сайте.
Какие мысли понравились:
Мысль 1: Люди важнее процессов. Или почему ITIL не работает без культуры
Есть одна старая мудрость:

Хорошие люди могут работать с плохими процессами.
Хорошие процессы могут компенсировать плохое ПО.
Но лучшее ПО не спасёт плохие процессы.
А лучшие процессы — не создадут хороших людей.

Это сказал Роб Ингланд. Один из самых уважаемых голосов в ITSM.
И вот что важно: большинство ITSM-проектов заканчиваются внедрением инструментов или документации. Но настоящий успех приходит только тогда, когда меняется поведение людей.
Ты можешь написать идеальные SLA, внедрить AI и автоматизировать Incident Management.
Но если никто не понимает, зачем это делается — процессы останутся бумагой. А команда будет работать так, как привыкла.
В этом фундаментальная проблема многих проектов: мы меняем систему, но забываем про культуру.
Если ты руководишь — твоя задача не запустить процесс. Твоя задача — создать условия, где он будет жить, развиваться и помогать людям делать лучше.
Потому что технологии работают только тогда, когда за ними работают люди.

Мысль 2: Управление проблемами — ключ к скорости
Вы замечали: одни и те же инциденты возникают снова и снова?
Типичный ответ техподдержки:

«Я закрыл обращение. SLA соблюдено. Все довольны».

Но если проблема остаётся — она будет стоить вам больше времени, больше нервов и больше денег .
🔍 Управление проблемами — это не про реакцию. Это про профилактику.
Когда инженер второй линии решает один и тот же инцидент по 20 раз в месяц, он тратит часы на то, что можно было бы решить один раз, но глубоко .
⚙️ Как это работает:
1️⃣ Фиксируется повторяющийся инцидент
2️⃣ Создаётся проблема
3️⃣ Диагностируется корень
4️⃣ Разрабатывается обходное решение или исправление
5️⃣Информация передаётся в Change Management
Это не просто работа с ошибками. Это работа над тем, чтобы этих ошибок становилось меньше.

Мысль 3: 🎯 Метрики без целей — это шум
Метрики нужны, чтобы видеть картину.
Но они должны отвечать на вопросы:
1️⃣ Как мы улучшаем опыт клиента?
2️⃣Что работает хорошо, а что требует корректировки?
3️⃣Какие точки в процессе тормозят команду?
Если метрика не помогает ответить на эти вопросы — она бесполезна.
Даже если она красиво оформлена в дашборде.
#ITIL #Метрики

Что такое Incident Management? Часть 1/2
 
Incident Management - это управление жизненным циклом инцидента, от первого сигнала до полного восстановления сервиса. 
Цель - не просто закрыть заявку. 
Цель - восстановить нормальную работу как можно быстрее, с минимальным влиянием на клиентов и бизнес.
 
Что такое инцидент?
 
Инцидент - это любое событие, которое нарушает нормальную работу сервиса.
Это не обязательно «всё упало». 
Это может быть:
▪️ пользователь не может войти в систему,
▪️ сервис работает медленно,
▪️ кто-то увидел ошибку в логах и напугался,
▪️ или просто: «Я не понимаю, что происходит».
 
Главное - влияние на пользователя.
 
 Основные цели Incident Management
 
1️⃣ Восстановить сервис как можно быстрее
   Не обязательно найти корневую причину. 
   Достаточно вернуть работоспособность - даже временным решением.
 
2️⃣ Минимизировать влияние на бизнес
   Чем дольше сервис недоступен - тем больше ущерб.
 
3️⃣ Соблюдать стандарты и SLA
   Это не бюрократия. 
   Это обещание, которое вы даёте клиенту.
 
5️⃣ Передать проблему дальше, если нужно
   Инцидент - это симптом. 
   А значит, за ним может быть проблема, которую нужно изучить.
 
Кто участвует?
 
1️⃣ L1(1-ая линия) 
Это фронт.
Их задача - не решить всё, а:
▪️ зарегистрировать инцидент,
▪️ определить приоритет,
▪️ передать в нужную группу,
▪️ держать клиента в курсе.
 
 2️⃣ IT Support Team (вторая и третья линия)
Это эксперты. 
У них глубокие знания по конкретным сервисам. 
Они:
▪️ диагностируют,
▪️ ищут корень,
▪️ создают обходные решения,
▪️ инициируют изменения.
 
Те, кто делает сервис снова рабочим.
 
3️⃣ Incident Manager (менеджер процесса) 
Не каждый инцидент требует менеджера. 
Но если инцидент критичный - он появляется.
 
Его задача:
▪️ координировать,
▪️ следить за SLA,
▪️ информировать бизнес,
▪️ и не давать процессу выйти из-под контроля.
Он - дирижёр, а не музыкант
 
Как начинается инцидент?
Инцидент может начаться:
▪️ от пользователя («не работает»),
▪️ от мониторинга («сервер не отвечает»),
▪️ от внутренней команды («заметили аномалию»).
 
🔄 Жизненный цикл инцидента: от «сломалось» до «всё снова работает»
 
Каждый инцидент проходит через четыре ключевые фазы:
1️⃣ Регистрация
   Инцидент поступает - через портал, чат, телефон. 
   Его нужно: зарегистрировать, присвоить ID, указать категорию и приоритет.
 
2️⃣ Диагностика и расследование
   Что не работает? 
   Где? 
   Кто ответственный/может помочь? 
   Нужна ли эскалация?
 
3️⃣ Решение и восстановление
   Найден обходной путь? 
   Устранена ошибка? 
   Сервис восстановлен?
 
5️⃣ Закрытие и анализ 
   Клиент подтвердил? 
   Есть ли риск повтора? 
   Нужно ли передать в Problem Management?
 
🔥 Срочность и влияние: как определить, что срочно, а что — критично
Не все инциденты одинаковы. 
Именно поэтому в Incident Management есть два ключевых параметра:
 
Влияние (Impact)
Кто и что пострадало?
Насколько широко проблема затрагивает бизнес?
Высокое - сервис недоступен для большого числа пользователей или критичных подразделений. 
Среднее -  несколько пользователей или одно подразделение. 
Низкое - один пользователь, не критичная функция.  
 
⏱Срочность (Urgency)
Насколько быстро нужно решить?
Высокая - требует немедленного вмешательства, например, остановка бизнес-процесса 
Средняя - важно, но можно подождать несколько часов 
Низкая - стандартный запрос, срок решения - дни
 
Из этих двух параметров формируется приоритет инцидента.
Приоритет = Влияние × Срочность
Зачем это нужно?
 
Чтобы:
▪️ не терять время на низкоприоритетные задачи, пока горит критичный сервис,
▪️ правильно распределять нагрузку,
▪️ соблюдать SLA,
▪️ и главное - говорить с бизнесом на одном языке.
 
«срочно» и «важно» - это не одно и то же.
 
Во второй части поговорим о Major Incident, метриках и связи с другими процессами.

#ITIL #IncidentManagement #TechSupport #ТехническаяПоддержка

Problem Management.
Что? Зачем? И почему?
 
Incident Management - восстанавливает сервис. 
Problem Management - убирает причину, по которой он сломался.
 
Если инцидент - это симптом, то проблема - это источник боли. 
 
Что такое проблема?
Проблема - это неизвестная корневая причина одного или нескольких инцидентов.
 
Примеры:
▪️ У 15 клиентов за день упал один и тот же сервис.
▪️ Сервер каждый понедельник в 9:00 замедляется на 30 минут.
▪️ После каждого обновления падает интеграция с биллингом.
 
Инцидент - это «не могу войти». 
Проблема - это «почему у 200 пользователей каждый четверг в 14:00 падает авторизация».
 
Что такое Problem Management?
Это процесс поиска и устранения корневых причин инцидентов.
 
Не чтобы закрыть тикет.  А чтобы больше не открывать такие тикеты.
Цель - не реагировать. Цель - предотвратить.
 
Основные цели Problem Management
 
1️⃣ Найти корневую причину 
   Не «починили» - а поняли, почему сломалось.
 
2️⃣ Предотвратить повторение
   Устранить не симптом, а источник. 
   Чтобы инцидент больше не возникал.
 
3️⃣ Создать долгосрочное решение
   Не временный обходной путь, а постоянное исправление - в коде, в архитектуре, в процессе.
 
5️⃣ Связать инциденты в паттерны*
   Увидеть, что 10 разных инцидентов — на самом деле одна проблема.
 
5️⃣ Передать знания команде
   Зафиксировать решение в базе знаний. 
   Чтобы следующий инженер не изобретал велосипед.
 
Когда запускается Problem Management?
Проблема может начаться:
▪️ после серии повторяющихся инцидентов,
▪️ после Major Incident (там всегда есть корень),
▪️ по инициативе инженера: «Я вижу закономерность»,
▪️ из аналитики: «Сервис падает каждый раз после бэкапа».
 
Главное - не ждать. Если инцидент повторяется - пора искать проблему.
 
Как работает процесс?
 
1️⃣ Выявление проблемы
  ▪️ Анализ инцидентов. 
  ▪️ Выявление паттернов. 
  ▪️ Сигнал: «Никогда такого не было. И вот опять».
 
2️⃣ Корневой анализ (RCA)
   ▪️ Не «что упало», а «почему упало». 
   ▪️ Методы: 5 Why, Fishbone, Timeline Analysis. 
   ▪️ Важно: искать системную причину, а не виноватого.
 
3️⃣ Поиск постоянного решения
   ▪️ Это не обходное решение. 
   ▪️ Это изменение: в коде, архитектуре, процессе, документации.
 
5️⃣ Реализация через Change Management 
   ▪️ Никаких «сделал и забыл». 
   ▪️ Решение внедряется официально, с тестированием и апрувами.
 
5️⃣ Закрытие и артефакт 
   ▪️ Клиент доволен? 
   ▪️ Инциденты прекратились? 
   ▪️ Значит, проблема решена. 
   ▪️ И артефакт (документ, статья, чек-лист) — сохранён для команды.
 
Кто участвует?
 
▪️ Problem Manager - не техник, а аналитик. 
  Он видит систему, а не только симптомы.
▪️ L2/L3, SRE, DevOps, разработка - те, кто может глубоко копать.
▪️ Incident Manager - передаёт контекст: что, где, сколько раз.
▪️ Knowledge Manager - фиксирует решение, чтобы оно не потерялось.
 
 Зачем это измерять?
Потому что:
▪️ Сколько проблем выявлено и закрыто? 
  Если ноль — значит, вы не смотрите.
▪️ Среднее время на решение проблемы
  Не торопитесь. Главное — качество анализа.
▪️ Снижение количества инцидентов после решения
  Это и есть доказательство эффективности.
▪️ Доля инцидентов, связанных с известными проблемами 
  Если высокая - у вас есть «дыра», которую давно пора закрыть.
 
Типичные ошибки
▪️ Не начинают вовремя
  Ждут, пока станет «очень плохо».
 ▪️ Смешивают с Incident Management. 
  Инженер пытается «починить и разобраться» одновременно. 
  Не получается.
 ▪️ Не фиксируют артефакты. 
  Решение «в голове» - это не решение. 
  Это риск.
 ▪️ Не передают в Change Management. 
  «Поправили вручную» - и снова ждут, пока упадёт.
 
Итог
Incident Management - это пожарная команда 
Problem Management - это инженер, который проверяет проводку.
Хороший процесс - это когда пожаров становится всё меньше.

#ProblemManagement #ITIL #TechSupport

Change Management
Что? Зачем? И почему?

Incident Management - восстанавливает сервис.
Problem Management - убирает причину поломки.
Change Management - предотвращает сбои и улучшает сервис.

Если инцидент - пожар, проблема - неисправная проводка,
то Change - это разрешение на ремонт, проверенный план и подписанный акт.
Без него «быстрый фикс» становится бомбой.
Примеры:
▪️ Обновление операционной системы на критически важном сервере.
▪️ Развертывание новой версии корпоративного приложения.
▪️ Изменение конфигурации сетевого оборудования, чтобы увеличить пропускную способность.
▪️ Удаление устаревшего, неиспользуемого компонента инфраструктуры.

Что такое Change Management?
Это процесс контроля изменений в инфраструктуре, продуктах и процессах.
Не запрет на перемены.
А структура для безопасных изменений.

Основные цели Change Management
Цель - не замедлить.
Цель - предотвратить ущерб от "хорошей пятничной идеи в 20:37".

Почему это важно? Потому что:
▪️70% инцидентов начинаются с изменения.
▪️90% из них - с изменения, которое "никто не заметил".
▪️100% из них - с изменения, которое не прошло проверку.

1️⃣ Контроль рисков
Каждое изменение оценивается: что может пойти не так?
Кто пострадает?
Как откатим?
2️⃣Минимизация сбоев
Не "сделаем и посмотрим".
А: протестируем → согласуем → внедрим → проверим.
3️⃣ Прозрачность и аудит
Где, что, кем и когда было изменено?
Теперь вы можете ответить на этот вопрос.
5️⃣ Координация между командами
Разработка, SRE, поддержка, безопасность - все в одном поле.
Никаких сюрпризов в релизе.
5️⃣ Сохранение стабильности сервиса
Не ради "процедуры".
А ради того, чтобы клиенты продолжали пользоваться сервисом.

Когда запускается Change Management?
Всегда.
Если изменение касается:
▪️кода,
▪️конфигурации,
▪️сети,
▪️доступов,

Все идёт через Change Request (CRQ).
Даже если:
▪️"это мелочь",
▪️"раньше так делали без согласования",
▪️"сроки горят".
Горящие сроки - не повод для горящего сервиса.

Как работает процесс?
1️⃣ Инициация изменения
Кто-то хочет что-то изменить.
Пишет CRQ:
▪️Что?
▪️Зачем?
▪️Как?
▪️Риски?
▪️План отката?
2️⃣ Оценка и согласование
Change Advisory Board (CAB) - или упрощённый аналог - смотрит:
▪️Нет ли конфликтов с другими изменениями?
▪️Есть ли ресурсы?
▪️Достаточно ли тестов?
▪️Кто утвердит?
3️⃣ Реализация
Изменение внедряется в согласованное окно.
С контролем, мониторингом, поддержкой на связи.
5️⃣ Проверка и закрытие
Работает ли?
Клиенты не страдают?
Метрики в норме?
→ Закрываем CRQ.
→ Фиксируем в базе знаний.

Кто участвует?
▪️Change Manager - не бюрократ, а координатор.
Он держит процесс в чистоте и вовремя.
▪️Заявитель - разработчик, инженер, SRE, менеджер продукта - кто инициирует изменение.
▪️CAB (Change Advisory Board) - представители поддержки, безопасности, SRE, продуктовой команды.
▪️Incident Manager / ТехПод - на связи, если что-то пойдёт не так.

Типичные ошибки
▪️«Это быстро, давайте без CRQ»
→ Быстро - не значит безопасно.
→ Без CRQ - без отката.
→ А значит, и без контроля.
▪️Change Management = бюрократия
Нет.
Это инструмент доверия.
Ты уверен, что никто не полезет в прод в пятницу вечером без плана.
▪️Не фиксируют результат
Решение есть.
CRQ закрыт.
А в базе знаний - пусто.
→ Через месяц - тот же инцидент.
Потому что "все забыли".

Зачем это измерять?
Потому что:
▪️Количество изменений, прошедших через процесс
Если 30% - значит, у вас полумрак.
Если 100% - значит, порядок.
▪️Процент изменений, вызвавших инциденты
Должен стремиться к нулю.
Если не стремится - где-то прорыв.
▪️Среднее время согласования
Не должно быть "ожидание 5 дней".
Но и не "подписали за 2 минуты".
▪️Доля экстренных изменений
Если больше 10% - значит, процесс не работает.
Люди обходят его.

Итог
Change Management - это тормоз.
Но не для прогресса.
Для хаоса.
Он не запрещает ехать.
Он не даёт врезаться.

#ChangeManagement #ITIL #TechSupport

7 KPIs of world-class ITSM. Что показал Freshservice Service Management Benchmark Report 2024?

KPI - это не просто цифры. Это ваш GPS в мире ITSM.
На основе данных 9 400+ организаций, 100 стран и 167 миллионов(❗️) тикетов отчёт FBR 2024 выделил 7 ключевых метрик, которые определяют эффективность сервис-деска. Не теория. Реальные цифры. Реальный рынок.
Это не просто отчёт. Это бенчмарк для тех, кто хочет быть выше рынка.

7 KPI, по которым измеряют зрелость поддержки:
1️⃣CSAT - 97,4%
Почти полное удовлетворение клиентов. Теперь это не достижение - это ожидание.
2️⃣ART - 24,15 часа
Среднее время решения запроса. Ваш результат ближе к этому числу?
3️⃣AFRT - 10,82 часа
Первый ответ. Чем быстрее, тем лучше. Каждый час ожидания — снижение доверия.
4️⃣FCR - 73,9%
Доля тикетов, закрытых с первого контакта. Ниже? Значит, процесс хромает.
5️⃣Resolution SLA - 95,7%
Соблюдение сроков решения. Большинство тикетов закрывается вовремя. Но не у всех.
6️⃣First Response SLA - 95,5%
Сроки первого ответа соблюдаются почти всегда. Исключения - риск для репутации.
7️⃣AFAT - 17,47 часов
Время до назначения тикета специалисту. Каждый час в очереди - потеря лояльности.

Эти цифры - медиана по рынку.
Если вы ниже - догоняйте.
Если выше - вы впереди.
Если намного выше - вы задаёте тренд.

Где взять прорыв по метрикам?
Отчёт чётко показывает: технологии работают. Но только если они правильные.
1️⃣ Reply Suggester → -38,68% к первому ответу
Предлагает готовые, контекстно-ориентированные ответы прямо в интерфейсе специалиста.
Основано на базе знаний, истории обращения и типе запроса.
Специалист не ищет, не формулирует - он отправляет.
Результат: первый ответ за 6,56 часов вместо 10,82.
2️⃣ Ticket Summary Generator → -32,16% к времени решения
Автоматически создаёт краткое резюме длинного тикета.
Выделяет суть проблемы, действия специалистов, комментарии клиента.
Специалист не читает 50 сообщений - он видит суть за 10 секунд.
Итог: на треть быстрее закрываются сложные тикеты.
3️⃣ Help Article Generator → +15,48% к эффективности базы знаний
Автоматически создаёт статьи на основе реальных тикетов, переписок и внешних источников.
Решения из опыта специалистов сразу становятся доступны всей команде.
База знаний живёт и растёт без ручного труда.
Self-service становится мощнее. Повторяющиеся тикеты исчезают.

Итог
FBR 2024 - это не про «что делают другие».
Это про то, какие действия дают прирост.
Не гадайте.
Сравнивайте.
Улучшайте.
#Исследования #Тренды #TechSupport #Метрики

КтоЕстьКто в ТехПоде
За последнее годы, я провел больше 400 собеседований на tech и руководящие позиции, и этот опыт позволил мне сформулировать два ключевых наблюдения:

1️⃣ Успех приходит тогда, когда тебе не нужно «заставлять» себя работать, потому что процесс приносит радость. Когда твоя job становится хобби, ты не «ищешь время» на развитие, а просто не можешь без него жить. Следить за трендами, смотреть доклады с конференций, быть на острие - это не обязанность, а естественное состояние.
2️⃣ Существует разрыв в ожиданиях. Часто талантливые люди просто не понимают, каких конкретно знаний и навыков от них ждут на той или иной позиции. Они теряются в догадках, куда двигаться дальше.

Чтобы закрыть этот разрыв, я запускаю серию постов #КтоЕстьКто в #ТехПод с фокусом на роли в индустрии облачных провайдеров.
В первом выпуске разберем инженера технической поддержки 1-й линии (L1). Это тот самый старт, с которого начинаются многие великие карьеры в IT.
Вместе разберем:
▪️Что это за роль на самом деле
▪️Какие требования действительно важны
▪️Куда растут лучшие инженеры L1

А в конце серии постов вас ждет небольшой бонус - откровенный разговор о том, сколько можно зарабатывать на каждой из разобранных позиций.

#КтоЕстьКто #ТехПод #TechSupport

Service Request Management (SRM)
Что? Зачем? И почему это не «просто тикеты»?

Service Request Management (SRM) - обеспечивает выполнение рутинных запросов пользователей, чтобы они могли работать без лишних задержек.

Что такое сервисный запрос (или ЗНО - запрос на обслуживание)?
Это запрос пользователя на доступ к стандартизированным и предварительно одобренным услугам, информации, консультациям или рутинным изменениям. Отличительные черты:
▪️Предсказуемость: это не внезапный сбой, а ожидаемая потребность.
▪️Стандартизация: есть чёткий процесс выполнения.
▪️Низкий риск: обычно не приводит к критическим сбоям.

Примеры сервисных запросов
▪️сброс пароля, установка ПО, запрос нового оборудования, доступ к VPN.
▪️предоставление доступа новым сотрудникам, запрос оборудования, отзыв доступа при увольнении.
▪️настройка инструментов для отчётов.
▪️настройка мобильных устройств, доступ к Wi-Fi, выделение облачных ресурсов.

Что такое Service Request Management (SRM)?
Это процесс управления и выполнения запросов пользователей на IT-услуги. SRM - сердце ITSM, которое помогает оперативно и качественно обрабатывать запросы, от сброса пароля до выдачи нового оборудования.

Цель SRM: не просто закрыть запрос, а сделать это так, чтобы пользователь остался доволен, а поддержка не тратила лишнее время. Это про скорость, прозрачность и user-friendly подход.

Основные цели SRM:
1️⃣ Ускорить выполнение запросов.
Автоматизировать рутину, чтобы запросы решались в реальном времени.
2️⃣ Повысить удовлетворённость пользователей.
Прозрачные процессы и чёткая коммуникация создают позитивный опыт взаимодействия с IT.
3️⃣ Оптимизировать ресурсы IT-команды.
Категоризация и приоритизация помогают распределять задачи там, где они действительно нужны.
5️⃣ Обеспечить видимость и контроль.
Руководители видят статус запросов, тренды и узкие места, чтобы принимать взвешенные решения.
5️⃣ Двигать непрерывное улучшение.
Анализ данных запросов помогает находить проблемы и улучшать процессы.

Как работает процесс SRM?
Процесс SRM - это структурированный путь от подачи запроса до его выполнения. Всё ради удовлетворённости клиентов.

1️⃣ Запрос - через самообслуживания портал, почту, чат.
2️⃣ Логирование - уникальный ID, статус, трекинг.
3️⃣ Классификация - тип, команда, SLA.
4️⃣ Автоматизация - если можно - система делает сама.
5️⃣ Исполнение - человек вмешивается только там, где нужно.
6️⃣ Обратная связь - пользователь знает: «Всё готово».
7️⃣ Анализ - что можно автоматизировать/улучшить завтра?

Кто участвует?
▪️Пользователь/Клиент - подаёт запрос.
▪️IT-инженеры (L1/L2/L3) /Финансы/ИБ-специалисты - исполняет (или одобряет).
▪️ Менеджер процесса - настраивает процессы, каталог услуг, SLA

Приоритизация запросов: не всё сразу
Это основа управления очередями запросов. Она учитывает:
▪️Влияние: Насколько запрос важен для бизнеса?
▪️Срочность: Как быстро это нужно сделать?

Пример категорий:
▪️Критичный (P1): Запросы, влияющие на всю компания, от руководства (VIP-клиентов)
▪️Высокий (P2): Запросы, влияющие на целый отдел, важные проекты
▪️Средний (P3): Установка стандартного ПО
▪️Низкий (P4): Запрос информации, консультация

Что важно измерять?
▪️% автоматизированных запросов - чем выше, тем меньше рутины.
▪️Среднее время выполнения - если растёт, значит, что-то ломается.
▪️Удовлетворённость (CSAT/CDSAT) - пользователь доволен или злится?
▪️SLA - сколько заявок закрыты в срок.

Типичные ошибки
▪️Смешивают с инцидентами
Разные процессы. Разные цели.
▪️Нет self-service портала
Инженеры тонут в рутине.
▪️Нет каталога услуг
Каждый запрос - как первый.
▪️Не автоматизируют очевидное
Пароль сбросили 500 раз - и всё ещё вручную?
▪️Плохая коммуникация: пользователь не знает, на каком этапе его запрос, и теряет доверие.
▪️Игнорирование приоритизации: срочные запросы тонут среди незначительных.
▪️Отсутствие анализа: без обратной связи и метрик процесс не улучшается.

Итог:
Хороший SRM - когда никто не замечает поддержку
Потому что всё просто работает.
#SRM #ITSM #ITIL #TechSupport

TechSupportConf'25. Как это было?
Публичных конференций, где говорят на нашем языке, в России не было. До этой недели.
Давайте разберемся, почему это событие стало настоящим открытием.

Во-первых, это действительно первая конференция для специалистов техподдержки в России. Глоток свежего воздуха на фоне стандартных IT-ивентов. За рубежом такие события есть, слежу за ними онлайн, но увидеть что-то подобное у нас, да еще и оффлайн - это другое. Во-вторых, я имел честь выступить там. А в-третьих… это же Петербург! Кто не любит этот город?

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

День первый. Утро. Миран.
Экскурсия в дата-центр. Я думал, меня уже ничем не удивить. Человека, который на заре карьеры два года проработал в обслуживании дата-центров крупной IT-компании, создающей лучшие антивирусы. Стойки, серверы, коммутаторы, системы охлаждения, питание, ДГУ - все это видел сотни раз и для меня это родной язык.
Но это до тех пор, пока экскурсию не проводит человек, который строил этот ДЦ с нуля.

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

Затем - техпод Мирана. 80 человек в компании, 21 из них - в поддержке. Вопрос: чем можно выделиться на рынке colocation, где все делают одно и тоже?
Ответ: только сервисом. И они это поняли раньше конкурентов.
Что еще? Их фишка - прозрачность. Они сделали визуализацию, где каждый инженер видит свой вклад в общее дело. Штука простая, но рабочая.

День. Selectel. Собираю камни, как Танос💎
После «Мирана» нас погрузили в автобус и отвезли в Selectel. 40 минут экскурсионной поездки - и мы на месте. Сначала рассказали про команду Customer Success. Кто это такие и зачем они нужны?
Это голос крупных клиентов внутри компании. Их задача - сделать так, чтобы проблемы решались быстрее, а клиенту не приходилось доказывать, что он не верблюд.
После был обед. Но больше всего хотелось общения про техподдержку, особенно в облаке. Как Танос собирал камни бесконечности, так я собираю информацию с рынка облачных провайдеров. Какая структура поддержки? Сколько линий? Какие KPI? Идиллия с разработкой или классические битвы? Ответы я получил. На многие вопросы. И это оказалось ценно. А экскурсия по дата-центру стала приятным бонусом.

Итог дня:
К 78 причинам любить Петербург добавилась ещё одна - место, где рождаются крутые отраслевые инициативы.
Продолжение - во второй серии нашего сериала «TechSupportConf: Как это было?». Расскажу, что я такого наговорил со сцены, что заставило народ просыпаться, какие доклады прозвучали у коллег и что полезного можно вынести из таких мероприятий.

#TechSupport #TechSupportConf