Инструмент №2 Бомбардиры ⚽️
Раскручиваем тему футбола. Визуализировали соревнования, чтобы видеть лучших. Это полезно как для руководителей, так и для сотрудников.
Лучшие сотрудники технической поддержки у всех на виду, руководители понимают, кого можно развивать, повышать или сделать трансфер к себе в команду.
Сотрудники соревнуются и стараются примерить виртуальную корону :)
Приятно наблюдать, как в ТОП 10 лучших входят 4 сотрудника из твоей команды.
Это только начало. Идем дальше.
#Инструмент

Командные соревнования 👑

Хорошо, когда есть с кем посоревноваться. Здорово, когда команд технической поддержки больше 9 - 15 шт. Главное, чтобы соревнования были экологичными. Не идти по головам.
Рейтинг формируется на основании средней оценки полученной от клиента от 1 до 5 баллов.

Как появилось дополнение к инструменту: посмотрел выступление руководителя разработки крупнейшей в России IT-компании. И он поведал занимательную историю. В компании было несколько команд разработки. Каждые две недели выявляли, какая команда проработала лучше всех. За это полагались какие-то земные блага и флажок. Обычный физический флажок. И была команда чемпион, прям как мои инженеры L2-Net. которые постоянно получали эту награду. И в один прекрасный день этот символ победы достался другой команде. Команда - чемпион была с этим не согласна. Они прокрались ночью и выкрали флаг.
Все бы ничего, но средний возраст разработчиков в этой команде был 40 лет :)

Инженеры любят соревноваться, поэтому им нужен какой-то "символ победы". Так в системе регистрации заявок появился Dashboard, который показывает среднюю оценку от клиентов по командам. Напротив команды на первом месте красуется корона
Внедрен гандикап (система для уравновешивания команд). Команды и сотрудники соревнуются в разных номинациях : TOP trouble-shooter, TOP клиентоориентированности, TOP тестировщик и т.д.
#Инструмент

Инструмент Вызов 🎯
Что отличает команду от группы? У команды есть цель. Производительность команды выше, чем сумма производительности отдельных ее членов. Командная работа - именно те мускулы, которые нам нужны. Команда всегда бьет группу. Идем дальше.

Именно вызов может служить такой объединяющей целью. Нужно что-то амбициозное, драйвовое, бодрящее.

Для команды поставил такую цель: достичь среднюю оценку по клиентам 4.96, получив 100 оценок за квартал. Для себя ставил цель получить 80 оценок 5 звезд.
Это означало, что 96 раз нас должны оценить на 5 баллов и только четыре раза поставить 4 балла.
По итогам проделанной работы получили:
▪️ 86 оценок, 85 шт – 5 звезд, 1 шт – 4 звезды;
▪️ Средняя оценка 4.98 Q2 2023 vs 4.89 Q2 2022.
Превзошли свой лучший результат на 62%.

Моя команда - это экспертная линия поддержки по сложным случаям. Среднее время решения заявки на команде сократилось на 29 мин и продолжает сокращаться.
Оценку 4 получили из-за того, что клиента назвали Александром, вместо Вадима. Увидели ошибку, быстро и искренне извинились. Получили 4 балла. Выводы:
"Тщательнее надо, тщательнее" (c) Жванецкий

Цель по факту не достигли которые ставились перед командой. Вместе с тем, свою цель перевыполнил. Что получили:
▪️Повысили удовлетворенность клиентов;
▪️Группу превратили в команду;
▪️ Увеличился процент клиентов, которые оценивают заявку;
▪️Оценку 4 балла из 5 воспринимается как плохая. Потому что могли сделать лучше, выжать максимум из ситуации;
▪️ Получили удовольствие от работы и результата;
▪️ Добежали до конца года с оценкой 4.98.

Важный момент: при бросании вызова себе, стоит взять лучший результат команды и попытаться превзойти его на 20-30%, а не на 200-300%.
Разбор полетов сделан, летим дальше.
#Инструмент

Что почитать? 📚
Так, немного отвлечемся от инструменты.ру на книги.
Техническая поддержка - это часть клиентского сервиса. Чтобы быть успешным в клиентском сервисе, нужно читать про успешный успех хорошие книги:

1️⃣ "Клиенты на всю жизнь". Карл Сьюэлл
Читается: Легко
Полезность: Выше средней

Интересные мысли:
▪️Инновации могут быть скопированы на следующее утро. Любые нужные технологии внедряются в мгновение ока. Так что конкурентное преимущество могут создавать только люди и сервис, которые они предоставляют.
▪️ Наша работа - заботиться о клиенте настолько хорошо, чтобы он продолжал возвращаться к нам до конца своих дней. (Клиент не должен уйти живым, ибо он на всю жизнь - это добавил я).
▪️ Люди любят, когда их благодарят за то, что они имеют с вами дело.
▪️ Отличные услуги могут оказывать только отличные сотрудники.
▪️ Никакие улыбки не помогут вам, если ваш продукт или услуга не устраивают вашего клиента.
▪️ Системный подход составляет 80% обслуживания. Он позволяет давать именно то, что необходимо клиенту, - это важнее улыбок и "спасибо".
▪️ Вам не нужно откупаться от людей. Искренние извинения и своевременная корректировка ваших действий практически всегда способны решить возникшую проблему. (Мне не очень нравится sorry promocod, когда какая-либо компания косячит, простых извинений достаточно, а если еще и предпримут меры по недопущению повторения ситуации - то большие молодцы)
▪️ Лучшая в мире система клиентского сервиса является и самой простой: ДЕЛАЙ ТО, ЧТО ОБЕЩАЛ, И ДЕЛАЙ ЭТО С ПЕРВОГО РАЗА.

Это не все. Позвольте мне вам порекомендовать еще одну хорошую книгу.

2️⃣ “Доставляя счастье". Тони Шей
Слышим о клиентоориентированности, вспоминаем Zappos. Слышим Zappos, вспоминаем о клиентоориентированности. Все просто. Синонимы.
Читается: Легко
Полезность: Выше средней

Интересные мысли:
▪️Дифференцируйтесь. Делайте противоположное тому, что делают остальные.
▪️ Надежда не самый лучше план.
▪️ Читайте книги, учитесь у предшественников.🫡
▪️ Учитесь на деле. Теория - это прекрасно, но ничто не заменит опыта.
▪️Никогда не передавайте на аутсорсинг ключевые функции. Если мы хотим связать бренд с наилучшим обслуживанием клиентов, мы должны контролировать общение с ними.
▪️ Три ключевых детали успеха: обслуживание клиентов, корпоративная культура, развитие сотрудников. Все остальное может быть скопировано.
▪️ Большинство колл-центров фиксируется на среднем времени обработки звонка и количестве, которое принимает каждый сотрудник. Операторы стараются как можно быстрее положить трубку. Это не означает отличное обслуживание.
▪️ У них нет шаблонов. Мы хотим чтобы операторы личностно раскрывались и создавали персональный контакт.
▪️ Если покупатель не нашел необходимый товар на сайте, оператор отправит его как минимум к 3 конкурентам.
Таким образом, выстраиваются долгосрочные отношения с клиентом, а не максимизация прибыли с каждого заказа.
(это не просто смело, это очень смело!)
▪️Конкуренция не важна, когда вы последовательны в предоставлении первоклассного сервиса.
#Книга

На habr.com вышла моя статья в корпоративном блоге компании. В канале будет больше инструментов. Скоро продолжим.

Контроль достижения цели
Продолжим с инструментами и практиками, которые не вошли в статью.
Достижение цели нужно контролировать. Нужно демонстрировать, что ваш фокус на определенном направлении.
У меня в голове были картины из фильмов или книжек (Deadline. Роман об управлении проектами Том Демарко): нужно каждый день подходить к доске и рисовать маркером заветные цифры. Подошел молча увеличил или уменьшил число попугаев и ушел. Команда это видит, и сразу же это всех бодрит.
Доски у меня нет. Да и команда разбросана по разным городам страны. В связи с этим, я писал в рабочий чат (каждый день), сколько осталось дней и кто приносил оценку в команду.
Если по заявке работали несколько человек, отмечал вклад каждого.

Обратите внимание на комментарии. Клиентам нравится быстрое решение заявок. Прислушивайтесь к пожеланиям. Мы же с вами за лучшее обслуживание клиентов, верно?

В следующем посте поговорим, как держать геораспределенную команду в едином контексте.
#Инструмент

Единый контекст
Когда команда работает 24/7 и разделена на смены, возникает необходимость держать всех в одном информационном поле. Появились новости, все должны быть в курсе: кто-то сделал что-то хорошее, новые правила взаимодействия с клиентами и т.д. С этой задаче прекрасно помогают справятся инструменты ниже.
▪️ Отчет по итогам смены. Инженеры передают всю оперативную информацию, которая может быть полезна следующим коллегам по смене. В отчете заполняют поля по активностям, которым нужно уделить внимание: заявки, алерты, инциденты, другая важная информация.
▪️ Страница на wiki. Там отображаются новости компании, блока, группы, подводятся итоги работы команды. Также страница используется для разбора удачных запросов или сложных, с которыми возникли проблемы . Важно разбирать именно проблему или процесс, который пошел не так, а не сотрудника. Wiki - также хорошее место для доски почета.
▪️ Командные встречи и встречи тет-а-тет. Собирайте и обрабатывайте обратную связь от сотрудников. Решайте все их проблемы. Голова сотрудника должна думать только о том, как лучше помочь клиентам.
Только не стоит выставлять фотографии с подписями: "работник месяца". На мой взгляд, этот инструмент ассоциируется у IT инженеров с другой сферой.
А вот "работник года" – рабочий инструмент, особенно если это проводится на уровне всей компании и награды/дипломы вручает генеральный директор. Проверено на себе и своих сотрудниках.
В следующих постах будем копать в структуру технической поддержки. Пройдемся по минусам классической трёхуровневой структуры, где есть L1, L2 и L3. Посмотрим на альтернативные структуры, по которым работают компании: Cisco, Microsoft, BMC.

#Инструмент

Структура Технической Поддержки
Начнем погружаться в тему структуры Технической Поддержки.
Возможно, возникнут мысли, что тут обсуждать, все старо, как лохматый мамонт.
Бери трехуровневую структуру и все, выбора то нет.
Все просто и скучно, хоть мух ешь.

Ребята из BMC(пилят ITSM Remedy), Cisco, Microsoft заявляют, что есть достойная альтернатива.
Прежде чем погружаться в новую структуру, давайте выясним какие недостатки есть у классики.

Но сначало по верхам рассмотрим, что из себя представляет трехуровневая структура:

Уровень 1: Первая линия, непосредственно принимает входящие обращения заказчиков.

Уровень 2: Обладает более продвинутыми навыками или специализированными знаниями.

Уровень 3: Специализированные группы поддержки, сосредоточенные на конкретных технологиях и приложениях.

Так как DevOps практики проникли и проникают во все IT организации, трехуровневая иерархия вставляет палки в колеса, а именно:
1️⃣ Cоздает несколько очередей
Любая заявка, которая не решается на первой линии, создает беклог для L2 или L3.

Таким образом, уровни 2 и 3 являются накопителями незавершённых задач (Work in Progress), что является очень проблемной областью согласно философии бережливого производства (Lean), лежащей в основе DevOps.

2️⃣Разделённая на уровни поддержка мешает корректной маршрутизации
Заявка, которая может быть решена только специалистами L2 или L3, обязательно проходит через L1.
Часто бывает, что заявка возвращается назад, либо для предоставления уточнений, либо потому, что маршрутизация была выполнена не по назначению. Начинается "футбол".

DevOps ориентирован на повышение ответственности и автономности.
DevOps основывается на сотрудничестве между специалистами, участвующими в операционной деятельности, и их коллегами, решающими задачи развития. Вертикальные и горизонтальные барьеры, присущие многоуровневой поддержке, и пассивная передача заявок между линиями являют полную противоположность кросс-функциональному сотрудничеству, являющемуся основой DevOps.

3️⃣ Многоуровневая поддержка не решает проблему перегрузки профильных экспертов
Одно из положительных качеств многоуровневой поддержки является предотвращение маршрутизации легко решаемых заявок специалистам более высокой квалификации, но она не защищает ключевых специалистов от большого объема сложных задач.
Ит-сфера страдает от «героев». Это, весьма умные люди, которые, вносят огромный вклад в успех организации, неоднократно являя чудо решения архисложных проблем.

На самом же деле, герой – это перегруженная, подверженная сбоям точка отказа, преднамеренно или непреднамеренно действующая как хранитель эксклюзивных знаний, которые следовало бы распространить. Многоуровневая поддержка, являющаяся линейной и разделённой структурой, не делает ничего, чтобы предотвратить "культ Героя". Скорее, даже усиливает его.

С точки зрения подхода DevOps ключевые инженеры при этом не участвуют в развитии, а занимаются “тушением пожаров”, эскалированных им с других линий поддержки.

В следующем посте рассмотрим, как альтернативная структура решает проблемы выше.

Swarming (Роение) 🐝

Товарищи из serviceinnovation.org пишут: интеллектуальное роение (Intelligent Swarming ) — это более разумный способ объединить людей с работой.
Звучит красиво. Теперь посмотрим, что нам предлагают инновационного и интеллектуального.

Первое, что хочу отметить, нет готовой инструкции, как правильно построить сворминг. Каждая компания идет своим путем.

Каждый «рой» представляет собой небольшую команду, сосредоточенную на входящем потоке заявок от заказчиков.

Severity 1 Swarm(Рой «Критичность 1»)
Основной фокус: Обеспечить немедленный ответ и решить как можно скорее.

Рой «Критичность 1» сосредоточен на наиболее критичных обращениях. Рой координирует решение критичных задач, распределяя их «правильным» людям, чтобы обеспечить решение настолько быстро, насколько возможно. По сути, нечем не отличается от Incident management по ITIL.

Dispatch Swarm(Диспетчерский рой)
▪️ Основной фокус: «сборщики вишни». Какие из новых заявок можно решить немедленно?
▪️ Вторичный фокуc: проверка заявок перед назначением группам поддержки продуктовых линеек.

Диспетчерский рой устраняет ключевой недостаток многоуровневой поддержки: заявки могут быть решены быстро, если попадут к «профильным» специалистам, но они теряются в бэклоге. В результате чего «пятиминутная» задачка по факту может занять несколько дней.
Диспетчерский рой в первую очередь занимается «сбором вишни», игнорируя всё, что невозможно решить очень быстро

Тут нужно понимать, что рой - это кроссфункциональное объединение инженеров, т.e. В рой могут входить инженеры L1,L2 и L3.
Какие это дает дополнительные плюсы?
Специалисты начальных линий быстрее обучаются. Специалисты старших линий становятся ближе к клиентам.
В BMC данный рой решал 30% заявок от общего объема.

Остальные заявки улетали в рой третьего типа.
Backlog Swarm (Бэклог рой)
• Основной фокус: рассмотреть сложные заявки, переданные из групп поддержки продуктов.
• Вторичный фокус: заместить отдельных экспертов по предмету.

Для решения наиболее сложных проблем Backlog Swarm объединяет группы опытных и квалифицированных инженеров, географические и структурные границы не имеют значения. Они получают задачи от специалистов на местах, которым теперь запрещено напрямую обращаться к экспертам индивидуально. Вместо этого они должны передавать задачи в соответствующий Backlog Swarm.

Итого:
Минусы 3-х уровневой системы поддержки
▪️ Разрыв между первой линией и DevOps-командой может приводить к
задержкам маршрутизации заявок и ошибкам их категоризации.
▪️ Отсутствие понимания всех инструментов (DevOps) для младших линий. Старшие линии не в курсе болей клиентов.
▪️ Попытка сформировать жесткую вертикальную и горизонтальную разделённую структуру приводит к созданию барьеров для кросс-функционального сотрудничества, которое является залогом внедрения «правильных» практик DevOps.

Swarming:
▪️ Динамичное кросс-функциональное сотрудничество, объединяющее специалистов с различными компетенциями в команды.
▪️ Гибкая структура команд вместо жёстких иерархических структур.
▪️ Высокий уровень автономии вместо жёстко регламентированных процессов (ключевой пример – «сборка вишни» в Диспетчерском рое).
▪️ Акцент на предотвращении роста бэклога незавершённых задач.
▪️ Кросс-функциональный обмен навыками и опытом между сотрудниками.

Ушел за хлебом. Вернулся. В руке буханка. А в голове идеи, как создавать и улучшать техническую поддержку.
За прошлый год у меня было два повышения по должности. Теперь управляю несколькими направлениями, в каждом из которых трудятся по доброму десятку инженеров, а то и по два.
Работа поглощает почти целиком и полностью. И будет как-то неприлично не делиться опытом, раз я всех вас тут собрал :)

Что нас ждет впереди?
Поговорим о видах технической поддержки и их подвидах. Мы погрузимся в мир ITIL и узнаем, какие процессы активно используются в российском Big Tech. Знание этих процессов откроет перед вами двери в мир, куда обычным людям путь заказан. Понимание сути этих процессов делает вас профессионалом с особым чутьем и навыками.

ИИ — наше всё. Мы обсудим практическое применение искусственного интеллекта в технической поддержке: как он помогает и кому именно. Копнем глубже в сценарии использования, cможете блеснуть знаниями о методе RAG.
Также рассмотрим тренды в техподдержке и поговорим о том, как строить команды мечты. Нырнем в обслуживание разных вселенных: B2C, B2B.
Не забудем про метрики. Разберемся, как это всё оцифровать и превратить в полезные данные.

Вечный двигатель я вам не обещаю, но то, что вы найдете что-то новое и интересное, гарантирую. Устраивает? Тогда начнем.
Завтра пост по ИИ.

Существуют ли интересные применения искусственного интеллекта в технической поддержке, которые действительно облегчают работу инженеров или улучшают клиентский опыт?

Штош, давайте рассмотрим пять сценариев использования ИИ в технической поддержке, которые уже сейчас демонстрируют свою эффективность:
1. Умный поиск (Intelligent Search) с использованием RAG
Представьте себе ситуацию: вы задаете технический вопрос и вместо бесконечного списка ссылок получаете четкий и лаконичный ответ. Это не фантастика — это реальность с использованием умного поиска на основе RAG. Этот метод сочетает в себе мощные механизмы поиска информации и генеративные языковые модели, которые превращают сложные данные в простые и понятные ответы. Это как иметь личного юриста, который быстро находит нужные законы и объясняет их суть, адаптируя информацию под вашу ситуацию.

2. Предиктивная маршрутизация
Задумайтесь о том, как предиктивная маршрутизация может изменить подход к обработке запросов. Теперь каждый входящий вопрос автоматически направляется к нужному специалисту. Представьте: звонит клиент с проблемой виртуальной машины — и его запрос мгновенно попадает к инженеру по виртуализации. Это не только экономит время, но и повышает качество обслуживания. Согласитесь, приятно знать, что ваш вопрос будет решен именно тем, кто в этом разбирается лучше всего.

3. Саммаризация
Забудьте о длинных цепочках комментариев. ИИ сможет кратко изложить суть обращения, позволяя инженерам быстро понять, что именно требует внимания. Это словно иметь волшебную палочку, которая превращает сложные тексты в ясные и лаконичные отчеты. И теперь у вас больше времени для решения действительно важных задач.

4. Анализ настроений пользователей
Не стоит забывать и об анализе настроений пользователей. ИИ способен уловить тональность обращений клиентов, позволяя технической поддержке быстро реагировать на негативные отзывы. Это значит, что ваша команда всегда будет на шаг впереди, а клиенты — довольны.

5. ИИ для анализа комментариев инженеров по соответствию Tone of Voice компании
И вот мы подходим к финалу нашего путешествия. Как вы думаете, насколько важно анализировать комментарии инженеров на соответствие tone of voice компании? Искусственный интеллект может помочь в этом, оценивая стиль общения сотрудников и обеспечивая единообразие в коммуникации. Это не просто полезно — это необходимо для создания сильного бренда.

Жесткий DeepSeek

Как ТехПод Google повышает доверие к облачным провайдерам?
Переход на облачные технологии порождает у компаний опасения по поводу утраты контроля над своей инфраструктурой и данными. Эти опасения замедляют процесс миграции в облачные решения, несмотря на преимущества, такие как:
▪️Снижение. затрат Облачные решения позволяют избежать значительных капитальных расходов на оборудование и инфраструктуру.
▪️Масштабируемость. Облачные услуги легко масштабируются в зависимости от потребностей бизнеса.
▪️Безопасность. Многие облачные провайдеры предлагают передовые меры безопасности.
▪️Экспертные инженеры. Облачные провайдеры часто располагают большими командами опытных инженеров и специалистов. Список можно продолжать еще долго.

Многие организации опасаются неопределенности, связанной с облаком. Некоторые даже возвращаются к локальной инфраструктуре, как например сделал Dropbox, покинув AWS.

Каждый из нас инстинктивно боится потерять контроль. И чем выше ставки, тем сильнее тревога. Поэтому неудивительно, что многие организации испытывают страх перед облаком.
Поставщики облачных услуг должны понимать эти опасения и работать над их устранением.

Что предлагает Google? Они создали роль Customer Reliability Engineer(CRE) c учетом их успешного многолетнего опыта Site Reliability Engineering (SRE)

Прежде, чем раскрыть CRE, мы должны узнать, в чем суть SRE?
Представьте себе два враждующих королевства: разработчиков, стремящихся к инновациям, и эксплуатацию, охраняющих стабильность. Каждый из них борется за внимание и признание, но в этой борьбе страдают пользователи. Как же наладить мирное сосуществование?

Революцию принес Бенджамин Трейнор-Слосс с идеей бюджета ошибок. Он осознал, что 100% доступности невозможна, и предложил определить допустимый уровень недоступности. Например, 99,9% означает 43 минуты простоя в месяц — это нормально.

Так родилась новая профессия — инженер по обеспечению надежности объектов (SRE). В Google установилось базовое соглашение между SRE и разработчиками: SRE берет на себя ответственность за бесперебойную работу системы при условии, что:

1️⃣ Система может пройти строгую проверку готовности к производству PRR(Production Readiness Review).
2️⃣ Команда разработчиков согласна поддерживать критически важные системы мониторинга и активно участвовать в ключевых мероприятиях.
3️⃣ Система не превышает своего бюджета ошибок.
Если разработчики не выполняют свои обязательства, SRE могут их «отключить» от прода.
Эти основы сотрудничества создали культуру, способствующую как невероятной надежности, так и быстрому внедрению инноваций.

Согласие на этот бюджет создало новый баланс. Инженеры могут разрабатывать и внедрять новые функции, пока остаются в рамках бюджета. Как только он исчерпан, внимание переключается на стабильность. Это привело к невероятной надежности и стремительному внедрению инноваций.

Теперь этот опыт перенесли на уровень клиентов, и появилась профессия Customer Reliability Engineer (CRE). CRE строит доверительные отношения с клиентами, применяя принципы SRE для их нужд.

Вы не просто обслуживаете клиентов — вы становитесь их надежным партнером, помогая управлять ожиданиями и обеспечивать стабильность. Это новая миссия, создающая крепкие связи и настоящую надежность.

CRE — это то, что вы получаете, когда берете принципы и уроки SRE и применяете их к клиентам.
Команда CRE проверяет ключевые элементы критического приложения/инфраструктуры клиента — код, дизайн, инфраструктуру, операционные процедуры, проводя строгий PRR. В конце указывают на пробелы в надежности системы и дают рекомендации для улучшения.

Создают общую систему мониторинга для синхронизации алертинга и тикетов. Взамен за совместные усилия, клиенты получают:
▪️ Совместный алертинг.
▪️ Автоматическое создание и эскалацию приоритетных заявок.
▪️ Участие CRE в переговорах.
▪️ Систему, одобренную Google.

Сколько это стоит? Продолжение в комментариях

Как ИИ превращает техподдержку из «позвать человека» в «спасибо, вы лучшие»?

Время погрузиться в мир практического применения искусственного интеллекта в технической поддержке.
Посмотрите захватывающий доклад: Как мы меняем клиентский сервис с помощью AI [AI&ML]:
Что увидите:
🔥 Как AI-agent работают «по-настоящему» :
▪️ Примеры, когда ИИ не просто отвечает, а решает проблему.
▪️ Почему «сценарный» подход в чат-ботах — это ловушка. И как выйти за их пределы с помощью AI.
🛠️ Секреты масштабирования :
▪️ Как организовать обработку обращений для сотен продуктов без потери качества обслуживания?
🤖 Переход к AI-Агенту
▪️ Не просто чат-бот, а полноценный участник диалога. Он анализирует историю обращений, предлагает решения и даже «улыбается» в ответах .
Почему стоит смотреть?
Потому что это не просто про технологии, а про результаты :
▪️ Как изменились метрики и показатели эффективности после внедрения AI.
▪️ Как инженеры используют простые инструменты — "молнию", "лампочку", "карандаш" и "бумажку" — для улучшения работы.
▪️ Как перейти к AI-Агенту и какие шаги предпринять дальше.

P.S. В конце — секретный бонус: как измерить «дружелюбие» бота и почему это важнее, чем вы думаете.

Что такое Incident Management? Часть 2/2
 
🚨 Major Incident: когда всё пошло не так
 
Major Incident - это не просто «очень плохой» инцидент. 
Это событие, которое лишает бизнес критичной услуги.
 
▪️ Много пользователей не могут работать. 
▪️ Сервис остановлен. 
▪️ Финансовые потери растут. 
▪️ Появляется давление сверху.
 
В таких случаях включается отдельная процедура:
▪️ Назначается менеджер Major Incident (лучше - менеджер процесса, а не техник). 
▪️ Собирается команда из нескольких групп. 
▪️ Включается режим постоянного информирования. 
▪️ Все обращения от пользователей связываются с основным инцидентом.
 
На что опирается Incident Management?
 
Это не изолированный процесс. 
Он живёт за счёт других:
 
▪️ Configuration Management - карта сервисов и их зависимостей - чтобы понять, кто пострадал.
▪️ Problem Management -  чтобы найти корневую причин, а не просто лечить симптомы.
▪️ Change Management -  понимание, не было ли изменения причиной инцидента.
▪️ Knowledge Management - готовые решения, которые можно применить сразу.
▪️ Service Level Management - чтобы знать, что обещано клиенту.
 
Без этих процессов - Incident Management превращается в бег по кругу.
Хороший инцидент - это тот, который уже был решён раньше.
 
📊 Метрики: что измерять?
 
Не ради отчётов.  Они - чтобы видеть, где ты теряешь контроль.
 
▪️ FCR (First Contact Resolution) - Сколько инцидентов решено с первого раза
▪️ TTR (Time to Resolve) - Среднее время решения
▪️ SLA Breach % Сколько инцидентов вышло за срок
▪️ Escalation Rate - Сколько инцидентов ушло на вторую линию
▪️ CSAT -  Удовлетворённость клиента
 
Итог
Incident Management - это не просто реакция. 
Это система, которая:
▪️ восстанавливает сервис,
▪️ восстанавливает доверие,
▪️ учится на ошибках,
▪️ и делает так, чтобы их было меньше.
 
Если у вас нет Incident Management - вы не управляете. 
Вы просто тушите пожары.
#ITIL #IncidentManagement #TechSupport #ТехническаяПоддержка