ТехПод от А до Я

Как небольшой пиццерии из Сыктывкара удалось стать лидером рынка и попасть на страницы мировых изданий?

История «Додо Пиццы» - это не история удачи, а результат выстроенной системы.

Когда основатель Фёдор Овчинников пришёл работать в Papa John’s, он не искал «секретный соус». Он искал систему.
Потом он создал свою.

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

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

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

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

Такая надёжная операционная основа позволяет «Додо» экспериментировать с инновациями. Компания первой в мире испытала доставку пиццы квадрокоптером. Мировые СМИ - от The Washington Post до Le Monde - написали об этом.

Поэтому при выборе партнёров для франшизы «Додо» смотрит не на размер инвестиций, а на готовность разделить этот подход. Готов ли будущий партнёр начать с работы на кухне? Принять принцип тотальной открытости? Улучшать процессы, а не наращивать ресурсы?

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

#Книги

Зачем руководителю поддержки читать книги?

Большинство думает: «Зачем читать? У меня и так X лет опыта!»
Отлично! Опыт - это здорово.
Но опыт без рефлексии - это как бег по кругу с граблями в руках. Вы уже наступили на них сотню раз. А книги? Это чужие грабли, аккуратно выложенные на стол. С подписями: «Тут споткнулись - не повторяйте».
Зачем наступать самому, если можно заранее увидеть яму?

Клиентский сервис - это не про «реагировать».
Это про проектировать.
И книги - это не сборник советов «как быть вежливым».
Это как строить системы, которые уже работают.

Книги дают вам:
▪️Процессы вместо хаоса: не «как ответить на гневное письмо», а как создать схему, чтобы такие письма просто не появлялись.
▪️Метрики, которые имеют смысл: не просто «удовлетворённость», а точки влияния на неё - от первого ответа до решения проблемы.
▪️Карту клиентского пути: где на самом деле ломается опыт, и как это починить - на уровне логики, а не эмоций.
▪️Инструменты масштабирования: как растить команду, не теряя качества. Не магией, а процессами.

Когда вы читаете про компании - ДОДО, Southwest, ВкусВилл и др. - вы видите не «улыбки».
Вы видите систему решений.

И в следующем посте я покажу это на живом примере - книге про ДОДО.
Там будет не про «быструю пиццу» и «просто будьте вежливыми».
А про то, как система принятия решений создают тот самый «вау-эффект», который все хотят, но мало кто строит.

Читайте. Внедряйте. Систематизируйте.

Ваш автор, который верит в силу книг, систем и здравого смысла.

#TechSupport #Книги

3 ключевые задачи руководителя технической поддержки

Когда-то Билл Гейтс сформулировал три ключевых задачи CEO:
1️⃣ Привлекать капитал.
2️⃣ Нанимать ключевых людей.
3️⃣ Закрывать ключевые сделки.
Просто. Гениально. Вся суть - в трёх строчках.

А вот как выглядит эта формула, если вы "СЕО" техподдержки?

Я конечно не миллиардер из Сиэтла, с моей колокольни триада такая:
1️⃣ Обеспечивать доверие клиентов - через надёжность, прозрачность и скорость решения проблем.
2️⃣ Формировать сильную команду - нанимать, развивать и удерживать специалистов, которые делают поддержку конкурентным преимуществом.
3️⃣ Превращать опыт поддержки в ценность для бизнеса - через обратную связь, знания и данные, которые улучшают продукт, процессы и стратегию компании.

Деньги - капитал компании. Доверие - ваш капитал. Ваша работа - делать его ликвидным.

Если короче:
Доверие, команда, влияние. Всё остальное - тактика.

#TechSupport #Management

TOPdesk Inside ITSM 2026: The Future of Internal IT
Будущее внутреннего IT

Охват: опрос 6000 ИТ-специалистов Европы, август 2025 г.

Ключевые выводы
▪️ИТ - основа бизнеса: критичен для продуктивности, удовлетворённости сотрудников и инноваций.
▪️Кризис реактивности: 40% ИТ-специалистов заняты только "тушением пожаров", нет времени на профилактику. 29% организаций сталкиваются с серьёзными сбоями еженедельно.
▪️Новая роль: переход от "пожарной команды" к стратегическому партнёру, фокусирующемуся на устойчивости и инновациях.

Главные направления
1️⃣Опыт сотрудников (DEX) - приоритет
▪️Инвестируют 95% организаций. Качество ИТ напрямую влияет на продуктивность (90%).
▪️Барьеры: высокая нагрузка (51% в Великобритании), гибридная работа (58%), нехватка ресурсов (43%).

2️⃣ Критерии "будущего" IT
▪️Главное - кибербезопасность (53%). Далее: использование ИИ (49%), самообслуживание (38%).
▪️Только 45% отделов считают себя "готовыми к будущему".
▪️Барьеры: нехватка кадров (28%), бюджета (27%), автоматизации (22%), разобщённость (16%).

3️⃣ ИИ как ускоритель
▪️Великобритания лидирует: 36% организаций полностью внедрили ИИ для стратегических целей.
▪️Драйвер - ИТ-отдел (70%). 86% видят в ИИ позитивное влияние, 74% не считают угрозой.
▪️Риски: безопасность данных (37%), излишняя зависимость (31%).
▪️Роль ИТ-специалистов смещается в сторону кибербезопасности (34%), сложных задач (21%), стратегии (21%).

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

Вопроса для старта:
1️⃣ Главная проблема DEX для решения завтра?
2️⃣ Какая рутинная задача съедает больше всего времени команды?
3️⃣ Какую задачу можно отдать ИИ уже сегодня для высвобождения времени?

#Исследования #Тренды #HelpDesk

4️⃣
Как стать крутым в ТехПоде?

Продолжаем собирать 100 коротких советов от руководителей и директоров в ТехПоде.

Сегодня в главной роли - Инга Лабахуа, основательница консалтингового агентства Supprt.Science, ex-шеф clients operations Рокетбанка, перезапускала поддержку в Райффайзен, Яндексе и десятке компаний финтеха и ритейла:

— Ответ во многом зависит от того, что именно считать «крутым»: хочется вырасти вверх или прокачать навыки в роли спеца поддержки. Отвечу скорее на второе.

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

Бизнес всегда будет стараться привлекать больше клиентов и расширять ЦА, поддержке нужно уметь работать с очень разными людьми с разным бэком, уровнем знаний. Без софтов, умения вести диалог, разруливать конфликты, считывать собеседника даже самый классный спец разрушит лояльность клиента. А бизнес потеряет деньги и репутацию.

Клиенты же точно становятся всё более требовательными. Решить проблему уже недостаточно. Важно оставить приятное послевкусие. Поэтому мой совет — качайте софты. Вы точно не должны быть психотерапевтами, но понимать, где уместно признать ошибку и извиниться, а где спуститься на уровень клиента и успокоить, супер-важно.

#TechSupport #Сто_Советов_ТехПод

Сегодня мы с коллегой Ринатом Саитовым знакомим вас с материалами о работе с инцидентами.

Речь о ITIL, способах строить процессы так, чтобы 31 декабря в 17.59 никто не катил срочные обновления, а поддержку не заваливало тикетами, чтобы жалобы клиентов влияли на решения продукта, а бизнес не терял связи с клиентом.

Ринат — шеф поддержки и автор канала «ТехПод от А до Я». Он умеет раскладывать сложные процессы по полочкам.

🧷 В карточках — тезисы из его статей, а полные версии тут:
⚪️ Incident Management часть 1 и 2
⚪️ Problem Management
⚪️ Change Management

#ITIL #техпод #incidentmanagement #ТочкаТрения

3️⃣
Как стать крутым в ТехПоде?

Добавляем в коллекцию новый совет от руководителей в ТехПоде. Делится Ольга Елисеева, руководитель технической дирекции, Инфосистемы Джет:

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

#TechSupport #Сто_Советов_ТехПод

Дифференцируйтесь или теряйте кадры. Онбординг в мире технической поддержки.

Вы наверняка слышали это на собеседованиях.
Я слышу всё чаще: «Меня просто бросили в огонь с первого дня».
Или: «Дали доступ в вики - и сказали: иди, читай».
Никто не объяснил, кто за что отвечает. Ни один вопрос не получил ответа.

Что остаётся у новичка?
Вопросы - в воздухе.
Команда - как чужая.
Стресс - как единственный спутник.

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

Раньше я слышал от инженеров на испытательном сроке :
«Боялся, что меня уволят - потому что чувствовал себя тупым».
Не потому, что они не могли.
А потому, что им не дали ни карты, ни компаса.

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

Но мы не оставляем его в этом состоянии.
Мы даём ему путь.
Не бросаем в огонь - проводим через него по надёжному маршруту.
Обещаем: через три месяца ты освоишься.
Через шесть - уже будешь приносить реальную пользу.
И не просто выполнять задачи - а улучшать то, что раньше работало хуже, чем должно.

А как построить онбординг, который не ломает, а заряжает?

Вот как мы это делаем.
▪️Шаг первый: личная встреча с руководителем.
Не формальность. Не ритуал.
Разговор один на один - где объясняют не только, какие системы использовать, но и: что здесь ценят, а что - нет.
Где закладывается фундамент.
Потому что человек, который чувствует, что его видят - не как ресурс, а как человека - уже на полшага ближе к тому, чтобы остаться.

▪️Шаг второй: знакомство с командой.
Не просто добавить в десяток чатов.
А представить так, чтобы новичок почувствовал: его ждали.

▪️Шаг третий: наставник.
Не просто старший инженер.
Тот, кто знает, как объяснить сложное просто.
Кто не отвечает «прочитай вики» - а говорит: «Давай сядем. Я покажу».

Шаг четвёртый: Ключевой. Структурированное погружение.
Трёхмесячный курс - как путешествие.
Первый день - что делать.
Первая неделя - что изучить.
Первый месяц - что понять.
Всё: от Service Request до Incident Management, от Linux до сетевых диаграмм.
Каждый модуль - тест.
Не для оценки.
Для обратной связи.
Результаты автоматически приходят руководителю и наставнику.
Ни один пробел не остаётся незамеченным.
Ни один вопрос - без ответа.

Шаг пятый: фидбек после завершения.
После успешного прохождения - не просто «молодец».
Сообщение на команду. Поздравляем.
Спрашиваем: что помогло? Что мешало? Что нужно изменить?
Потому что онбординг - не разовая акция.
Это живой процесс. И если он не улучшается - он умирает.

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

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

Дифференцируйтесь.
Делайте противоположное тому, что делают остальные за столом.
Погружайте плавно. Без стресса.
Нарабатывайте лояльность не с момента первой победы - а с первого рабочего дня.

Эта стратегия окупается.
С головой.

P.S.
Читал статью на Indeed: средняя стоимость обучения одного сотрудника - около $1252 при 33 часах обучения.
Рекомендации: удержание через комфортную среду, найм квалифицированных кадров, цифровизация документооборота, целенаправленное обучение на основе оценки.
#TechSupport #Onboarding

2️⃣
Как стать крутым в ТехПоде?

Собираем 100 коротких советов от руководителей и директоров в ТехПоде! У микрофона - Полина, CXO(Chief Experience Officer) в Giftery,:

Измеряй, упреждай и действуй на результат

#TechSupport #Сто_Советов_ТехПод

TechSupportConf. Вторая серия. На сцену залез вдруг.

В зале - 600 рук, а я вдруг оказываюсь на сцене. Что я там делаю? Делюсь опытом, конечно: как найти своих инженеров и проводить поведенческое интервью - с чего начать, какие вопросы задавать, а какие лучше обходить стороной. Здесь и сейчас: бери и применяй завтра же. А если этого мало - в конце есть список литературы, которая расширит твой арсенал как руководителя.

Мой критерий успеха прост: если хотя бы один человек вынес пользу - значит, время потрачено не зря. Если больше десяти - отлично. Судя по отзывам, получилось именно так. (Кстати, в каждом посте тоже должно быть что-то полезное.)

Что понравилось в докладах?

▪️Miran рассказал о стандартном, но важном Incident Management. Особенно интересен их подход к накоплению и повторному использованию знаний.
▪️Ecom.Tech (Самокат) удивил стендап-стилем подачи и юмором. Спикер поделилась практическим чек-листом для подготовки статей в Confluence с учётом работы любых LLM - польза, которая точно пригодится.
▪️Selectel привёл ценные цифры: средний срок работы в поддержке - 2,7 года, состав команды, направления карьерного роста сотрудников. Захотелось сравнить с нашими данными за последние пять лет.
▪️UseDesk продемонстрировал мастерство живого реагирования: когда презентация внезапно перелистнулась на последний слайд, спикер легко справился с ситуацией.
▪️Swarmica движется в том ж направлении, что и мы: сочетает KCS, ИИ и автогенерацию статей.
▪️TimeWeb и Support.Science - органичный тандем с отличным темпом и подачей.
- Один момент особенно поразил: во время инцидента в поддержку может прилететь тысяча заявок. Хорошо, что есть инструменты, которые помогают сократить поток обращений - например, status page, как у AWS.

Аудитория?
На мой взгляд, 70–90 % - это руководители техподдержки. Когда спросили, кто знает и использует ITIL, руки подняли лишь около 5 %. Это вызвало интерес: как на практике решают инциденты, проводят корневой анализ и планируют работы?

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

Зачем нужны такие конференции?
1️⃣Познакомиться с интересными людьми: организаторами, спикерами, коллегами из других компаний.
2️⃣Получить опыт выступления.
3️⃣Собрать команду на тимбилдинг.
5️⃣Мотивировать сотрудников, беря с собой лучших инженеров.

Будет ли следующая конференция?
Конечно! Следите за новостями.

Ps. Спасибо организаторам!

#TechSupport #TechSupportConf

«Как стать крутым в ТехПоде?»

1️⃣
Мы соберем 100 коротких и мощных советов от руководителей и директоров, которые прошли этот путь. Без воды. Только конкретика.

Первый в рубрике - Сергей Харитонов, директор центра ИТ-поддержки, Президентская академия РАНХИГС:

Как стать крутым в Технической Поддержке?

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

Если сильнее развернуть ответ, то у сотрудника поддержки есть 4 основых области знаний:
1. Знание предметной области и процессов, которые поддерживаешь.
2. Знание продукта и технологии, которую поддерживаешь
3. Знание основ поддержки (например, практики ITIL)
4. Умение в софтскиллы - эмпатия, ответственность, умение видеть картину целиком, умение читать между строк.

Как правило поддержка является первым шагом в карьере ИТ-специалиста и именно тут ты определяешься с тем вектором, куда развиваться. В зависимости от области знаний, которая ближе к сердцу, ты становишься - разработчиком, тестировщиком, бизнес-аналитиком, техписом, ITSM-специалистом, менеджером или другим специалистом из миллиона вариантов.
Определяешься, выбираешь сферу и начинаешь углубляться - улучшать процессы, находить неочевидные решения, проявлять инициативу, залезать вглубь продукта - в зависимости от области знаний. А дальше всё зависит только от твоего желания.

#TechSupport #Сто_Советов_ТехПод

Коллеги, вчера Amazon упал. Не просто «подтормаживал» — упал.
142 сервиса. Более 20 тысяч жалоб. Snapchat, Perplexity, Zoom, Slack, Microsoft Teams и многие другие - все в одной лодке. И все смотрят на одну страницу: https://health.aws.amazon.com/health/status. Самый масштабный сбой с 2011 года.

К вопросу о прозрачности в управлении инцидентами.
Когда рушится всё, каждая секунда на счету. Клиенты не просто ждут исправления - они ждут информации. И здесь AWS демонстрирует мастер-класс.
Два ключевых принципа, которые нельзя разделять: быстро решить проблему и постоянно быть на связи. Но что именно делает их подход образцовым?

Взгляните на страницу статуса AWS. Обновления каждые 30-40 минут. Не формальность, а содержательный диалог: что произошло, как обойти проблему, какие шаги предпринимаются дальше.
Это управление ожиданиями в реальном времени. Прозрачность, которая превращает хаос в контролируемый процесс.

Кому интересно, что сломалось и как решали, можно почитать тут
#ITIL #IncidentManagement #TechSupport #ТехническаяПоддержка

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

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

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

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

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

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

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

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

#TechSupport #TechSupportConf

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