Существуют ли интересные применения искусственного интеллекта в технической поддержке, которые действительно облегчают работу инженеров или улучшают клиентский опыт?
Штош, давайте рассмотрим пять сценариев использования ИИ в технической поддержке, которые уже сейчас демонстрируют свою эффективность:
1. Умный поиск (Intelligent Search) с использованием RAG
Представьте себе ситуацию: вы задаете технический вопрос и вместо бесконечного списка ссылок получаете четкий и лаконичный ответ. Это не фантастика — это реальность с использованием умного поиска на основе RAG. Этот метод сочетает в себе мощные механизмы поиска информации и генеративные языковые модели, которые превращают сложные данные в простые и понятные ответы. Это как иметь личного юриста, который быстро находит нужные законы и объясняет их суть, адаптируя информацию под вашу ситуацию.
2. Предиктивная маршрутизация
Задумайтесь о том, как предиктивная маршрутизация может изменить подход к обработке запросов. Теперь каждый входящий вопрос автоматически направляется к нужному специалисту. Представьте: звонит клиент с проблемой виртуальной машины — и его запрос мгновенно попадает к инженеру по виртуализации. Это не только экономит время, но и повышает качество обслуживания. Согласитесь, приятно знать, что ваш вопрос будет решен именно тем, кто в этом разбирается лучше всего.
3. Саммаризация
Забудьте о длинных цепочках комментариев. ИИ сможет кратко изложить суть обращения, позволяя инженерам быстро понять, что именно требует внимания. Это словно иметь волшебную палочку, которая превращает сложные тексты в ясные и лаконичные отчеты. И теперь у вас больше времени для решения действительно важных задач.
4. Анализ настроений пользователей
Не стоит забывать и об анализе настроений пользователей. ИИ способен уловить тональность обращений клиентов, позволяя технической поддержке быстро реагировать на негативные отзывы. Это значит, что ваша команда всегда будет на шаг впереди, а клиенты — довольны.
5. ИИ для анализа комментариев инженеров по соответствию Tone of Voice компании
И вот мы подходим к финалу нашего путешествия. Как вы думаете, насколько важно анализировать комментарии инженеров на соответствие tone of voice компании? Искусственный интеллект может помочь в этом, оценивая стиль общения сотрудников и обеспечивая единообразие в коммуникации. Это не просто полезно — это необходимо для создания сильного бренда.
Штош, давайте рассмотрим пять сценариев использования ИИ в технической поддержке, которые уже сейчас демонстрируют свою эффективность:
1. Умный поиск (Intelligent Search) с использованием RAG
Представьте себе ситуацию: вы задаете технический вопрос и вместо бесконечного списка ссылок получаете четкий и лаконичный ответ. Это не фантастика — это реальность с использованием умного поиска на основе RAG. Этот метод сочетает в себе мощные механизмы поиска информации и генеративные языковые модели, которые превращают сложные данные в простые и понятные ответы. Это как иметь личного юриста, который быстро находит нужные законы и объясняет их суть, адаптируя информацию под вашу ситуацию.
2. Предиктивная маршрутизация
Задумайтесь о том, как предиктивная маршрутизация может изменить подход к обработке запросов. Теперь каждый входящий вопрос автоматически направляется к нужному специалисту. Представьте: звонит клиент с проблемой виртуальной машины — и его запрос мгновенно попадает к инженеру по виртуализации. Это не только экономит время, но и повышает качество обслуживания. Согласитесь, приятно знать, что ваш вопрос будет решен именно тем, кто в этом разбирается лучше всего.
3. Саммаризация
Забудьте о длинных цепочках комментариев. ИИ сможет кратко изложить суть обращения, позволяя инженерам быстро понять, что именно требует внимания. Это словно иметь волшебную палочку, которая превращает сложные тексты в ясные и лаконичные отчеты. И теперь у вас больше времени для решения действительно важных задач.
4. Анализ настроений пользователей
Не стоит забывать и об анализе настроений пользователей. ИИ способен уловить тональность обращений клиентов, позволяя технической поддержке быстро реагировать на негативные отзывы. Это значит, что ваша команда всегда будет на шаг впереди, а клиенты — довольны.
5. ИИ для анализа комментариев инженеров по соответствию Tone of Voice компании
И вот мы подходим к финалу нашего путешествия. Как вы думаете, насколько важно анализировать комментарии инженеров на соответствие tone of voice компании? Искусственный интеллект может помочь в этом, оценивая стиль общения сотрудников и обеспечивая единообразие в коммуникации. Это не просто полезно — это необходимо для создания сильного бренда.
👍5🔥3👏3
Forwarded from Железный Человек
Так ли хороша DeepSeek-R1?
Мир сейчас активно обсуждает новую китайскую модель DeepSeek. Команда Cloud․ru не смогла пройти мимо этой темы и решила провести собственное сравнение моделей.
Мы протестировали три модели: OpenAI o1-mini, DeepSeek-R1 и её облегчённую версию DeepSeek-R1 32B. Тестирование проводилось на 40 реальных пользовательских запросах.
Как проходило тестирование:
1️⃣ Для каждого запроса мы использовали систему поиска релевантных статей в документации, которые передавались в модель вместе с пользовательским запросом.
2️⃣ LLM получала системный промпт, требования к Tone of Voice компании, сам вопрос клиента и найденную документацию.
3️⃣ Ответы оценивал эксперт в области технической поддержки по пятибалльной шкале.
Вот, что получилось в результате:
DeepSeek-R1:4.3
OpenAI o1-mini:3.53
DeepSeek-R1 32B:1.75
💡DeepSeek-R1 отлично справляется с задачами, требующими анализа контекста, документации и рассуждений. Облегчённая версия DeepSeek-R1 32B сильно уступает, но её производительность может быть полезной в определённых сценариях.
Какие преимущества DeepSeek-R1 мы выделили:
🔍 В отличие от других популярных моделей, DeepSeek-R1 в обязательном порядке прикладывает настоящие ссылки документации к каждому ответу.
🔍 Эффективно применяет контекст запросов пользователя для генерации более персонализированных ответов.
🔍 Возможность локального развёртывания для обеспечения стабильности, безопасности и автономности.
Я вижу в модели DeepSeek-R1 потенциал. Мы уже начали рассматривать интеграцию модели в сервисы Cloud․ru и запуск нового виртуального ассистента для поддержки наших клиентов. Возможность локального использования — это стратегически важное преимущество, особенно для работы с конфиденциальными данными.
#СверхРазум
Мир сейчас активно обсуждает новую китайскую модель DeepSeek. Команда Cloud․ru не смогла пройти мимо этой темы и решила провести собственное сравнение моделей.
Мы протестировали три модели: OpenAI o1-mini, DeepSeek-R1 и её облегчённую версию DeepSeek-R1 32B. Тестирование проводилось на 40 реальных пользовательских запросах.
Как проходило тестирование:
1️⃣ Для каждого запроса мы использовали систему поиска релевантных статей в документации, которые передавались в модель вместе с пользовательским запросом.
2️⃣ LLM получала системный промпт, требования к Tone of Voice компании, сам вопрос клиента и найденную документацию.
3️⃣ Ответы оценивал эксперт в области технической поддержки по пятибалльной шкале.
Вот, что получилось в результате:
DeepSeek-R1:
OpenAI o1-mini:
DeepSeek-R1 32B:
💡DeepSeek-R1 отлично справляется с задачами, требующими анализа контекста, документации и рассуждений. Облегчённая версия DeepSeek-R1 32B сильно уступает, но её производительность может быть полезной в определённых сценариях.
Какие преимущества DeepSeek-R1 мы выделили:
Я вижу в модели DeepSeek-R1 потенциал. Мы уже начали рассматривать интеграцию модели в сервисы Cloud․ru и запуск нового виртуального ассистента для поддержки наших клиентов. Возможность локального использования — это стратегически важное преимущество, особенно для работы с конфиденциальными данными.
#СверхРазум
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍5❤1
Как ТехПод 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.
Сколько это стоит? Продолжение в комментариях
Переход на облачные технологии порождает у компаний опасения по поводу утраты контроля над своей инфраструктурой и данными. Эти опасения замедляют процесс миграции в облачные решения, несмотря на преимущества, такие как:
▪️Снижение. затрат Облачные решения позволяют избежать значительных капитальных расходов на оборудование и инфраструктуру.
▪️Масштабируемость. Облачные услуги легко масштабируются в зависимости от потребностей бизнеса.
▪️Безопасность. Многие облачные провайдеры предлагают передовые меры безопасности.
▪️Экспертные инженеры. Облачные провайдеры часто располагают большими командами опытных инженеров и специалистов. Список можно продолжать еще долго.
Многие организации опасаются неопределенности, связанной с облаком. Некоторые даже возвращаются к локальной инфраструктуре, как например сделал 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.
Сколько это стоит? Продолжение в комментариях
👍9
Как ИИ превращает техподдержку из «позвать человека» в «спасибо, вы лучшие»?
Время погрузиться в мир практического применения искусственного интеллекта в технической поддержке.
Посмотрите захватывающий доклад: Как мы меняем клиентский сервис с помощью AI [AI&ML]:
Что увидите:
🔥 Как AI-agent работают «по-настоящему» :
▪️ Примеры, когда ИИ не просто отвечает, а решает проблему.
▪️ Почему «сценарный» подход в чат-ботах — это ловушка. И как выйти за их пределы с помощью AI.
🛠️ Секреты масштабирования :
▪️ Как организовать обработку обращений для сотен продуктов без потери качества обслуживания?
🤖 Переход к AI-Агенту
▪️ Не просто чат-бот, а полноценный участник диалога. Он анализирует историю обращений, предлагает решения и даже «улыбается» в ответах .
Почему стоит смотреть?
Потому что это не просто про технологии, а про результаты :
▪️ Как изменились метрики и показатели эффективности после внедрения AI.
▪️ Как инженеры используют простые инструменты — "молнию", "лампочку", "карандаш" и "бумажку" — для улучшения работы.
▪️ Как перейти к AI-Агенту и какие шаги предпринять дальше.
P.S. В конце — секретный бонус: как измерить «дружелюбие» бота и почему это важнее, чем вы думаете.
Время погрузиться в мир практического применения искусственного интеллекта в технической поддержке.
Посмотрите захватывающий доклад: Как мы меняем клиентский сервис с помощью AI [AI&ML]:
Что увидите:
🔥 Как AI-agent работают «по-настоящему» :
▪️ Примеры, когда ИИ не просто отвечает, а решает проблему.
▪️ Почему «сценарный» подход в чат-ботах — это ловушка. И как выйти за их пределы с помощью AI.
🛠️ Секреты масштабирования :
▪️ Как организовать обработку обращений для сотен продуктов без потери качества обслуживания?
🤖 Переход к AI-Агенту
▪️ Не просто чат-бот, а полноценный участник диалога. Он анализирует историю обращений, предлагает решения и даже «улыбается» в ответах .
Почему стоит смотреть?
Потому что это не просто про технологии, а про результаты :
▪️ Как изменились метрики и показатели эффективности после внедрения AI.
▪️ Как инженеры используют простые инструменты — "молнию", "лампочку", "карандаш" и "бумажку" — для улучшения работы.
▪️ Как перейти к AI-Агенту и какие шаги предпринять дальше.
P.S. В конце — секретный бонус: как измерить «дружелюбие» бота и почему это важнее, чем вы думаете.
YouTube
Как мы меняем клиентский сервис с помощью AI [AI&ML]
#GoCloud2025
☁️ Попробуй наше облако бесплатно https://clck.ru/3Ljx6D
Трек: AI&ML
Спикер: Максим Михайлов. Менеджер продукта, Cloud.ru
Обсудим co-pilot и боты в поддержке, новые инструменты, аналитику, будущее Al-агентов и реальные результаты.
☁️ Попробуй наше облако бесплатно https://clck.ru/3Ljx6D
Трек: AI&ML
Спикер: Максим Михайлов. Менеджер продукта, Cloud.ru
Обсудим co-pilot и боты в поддержке, новые инструменты, аналитику, будущее Al-агентов и реальные результаты.
🔥9
Продолжаем исследовать, как AI agent-ы меняют будущее технической поддержки — уже сегодня.
Кейс AstraZeneca
AstraZeneca — глобальная биофармацевтическая компания с выручкой более $27 млрд в год , которая делает ставку на искусственный интеллект, облачные технологии и кибербезопасность.
Мне нравится их лозунг — «Every minute matters» . Красиво звучит, особенно в медицине.
А теперь — сам кейс:
Cотрудник получает уведомление об отключении оборудования. Он звонит AI agent-у и рассказывает, что видит ошибку на экране.
1️⃣ AI просит прислать фото — и начинает действовать: Анализирует изображение и определяет тип повреждения
2️⃣ Проверяет гарантийный статус устройства
3️⃣ Инициирует замену
4️⃣ Организует закупку нового оборудования и отправляет номер заказа для отслеживания
Это. Очень. Круто.
Но вот что ещё круче:
С помощью AI agent-ов компания сократила время обработки запроса на поставку оборудования с 20–30 минут до нескольких секунд .
Это звучит особенно впечатляюще, если понимать масштаб:
У AstraZeneca ежегодно возникает около 60 000 таких запросов , что ранее занимало примерно 90 000 человеко-часов .
Теперь эти часы можно направить на действительно важную работу.
Будущее техподдержки — это когда ИИ берёт рутину, а люди — результат.
#кейс #ТехническаяПоддержка #AI
Кейс AstraZeneca
AstraZeneca — глобальная биофармацевтическая компания с выручкой более $27 млрд в год , которая делает ставку на искусственный интеллект, облачные технологии и кибербезопасность.
Мне нравится их лозунг — «Every minute matters» . Красиво звучит, особенно в медицине.
А теперь — сам кейс:
Cотрудник получает уведомление об отключении оборудования. Он звонит AI agent-у и рассказывает, что видит ошибку на экране.
Это. Очень. Круто.
Но вот что ещё круче:
С помощью AI agent-ов компания сократила время обработки запроса на поставку оборудования с 20–30 минут до нескольких секунд .
Это звучит особенно впечатляюще, если понимать масштаб:
У AstraZeneca ежегодно возникает около 60 000 таких запросов , что ранее занимало примерно 90 000 человеко-часов .
Теперь эти часы можно направить на действительно важную работу.
Будущее техподдержки — это когда ИИ берёт рутину, а люди — результат.
#кейс #ТехническаяПоддержка #AI
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥2
Что такое 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
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
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11
Прочитал книгу Real ITSM: Проверено временем от Cleverics. Все главы также также доступны у них на сайте.
Какие мысли понравились:
Мысль 1: Люди важнее процессов. Или почему ITIL не работает без культуры
Есть одна старая мудрость:
Это сказал Роб Ингланд. Один из самых уважаемых голосов в ITSM.
И вот что важно: большинство ITSM-проектов заканчиваются внедрением инструментов или документации. Но настоящий успех приходит только тогда, когда меняется поведение людей.
Ты можешь написать идеальные SLA, внедрить AI и автоматизировать Incident Management.
Но если никто не понимает, зачем это делается — процессы останутся бумагой. А команда будет работать так, как привыкла.
В этом фундаментальная проблема многих проектов: мы меняем систему, но забываем про культуру.
Если ты руководишь — твоя задача не запустить процесс. Твоя задача — создать условия, где он будет жить, развиваться и помогать людям делать лучше.
Потому что технологии работают только тогда, когда за ними работают люди.
Мысль 2: Управление проблемами — ключ к скорости
Вы замечали: одни и те же инциденты возникают снова и снова?
Типичный ответ техподдержки:
Но если проблема остаётся — она будет стоить вам больше времени, больше нервов и больше денег .
🔍 Управление проблемами — это не про реакцию. Это про профилактику.
Когда инженер второй линии решает один и тот же инцидент по 20 раз в месяц, он тратит часы на то, что можно было бы решить один раз, но глубоко .
⚙️ Как это работает:
1️⃣ Фиксируется повторяющийся инцидент
2️⃣ Создаётся проблема
3️⃣ Диагностируется корень
4️⃣ Разрабатывается обходное решение или исправление
5️⃣ Информация передаётся в Change Management
Это не просто работа с ошибками. Это работа над тем, чтобы этих ошибок становилось меньше.
Мысль 3: 🎯 Метрики без целей — это шум
Метрики нужны, чтобы видеть картину.
Но они должны отвечать на вопросы:
1️⃣ Как мы улучшаем опыт клиента?
2️⃣ Что работает хорошо, а что требует корректировки?
3️⃣ Какие точки в процессе тормозят команду?
Если метрика не помогает ответить на эти вопросы — она бесполезна.
Даже если она красиво оформлена в дашборде.
#ITIL #Метрики
Какие мысли понравились:
Мысль 1: Люди важнее процессов. Или почему ITIL не работает без культуры
Есть одна старая мудрость:
Хорошие люди могут работать с плохими процессами.
Хорошие процессы могут компенсировать плохое ПО.
Но лучшее ПО не спасёт плохие процессы.
А лучшие процессы — не создадут хороших людей.
Это сказал Роб Ингланд. Один из самых уважаемых голосов в ITSM.
И вот что важно: большинство ITSM-проектов заканчиваются внедрением инструментов или документации. Но настоящий успех приходит только тогда, когда меняется поведение людей.
Ты можешь написать идеальные SLA, внедрить AI и автоматизировать Incident Management.
Но если никто не понимает, зачем это делается — процессы останутся бумагой. А команда будет работать так, как привыкла.
В этом фундаментальная проблема многих проектов: мы меняем систему, но забываем про культуру.
Если ты руководишь — твоя задача не запустить процесс. Твоя задача — создать условия, где он будет жить, развиваться и помогать людям делать лучше.
Потому что технологии работают только тогда, когда за ними работают люди.
Мысль 2: Управление проблемами — ключ к скорости
Вы замечали: одни и те же инциденты возникают снова и снова?
Типичный ответ техподдержки:
«Я закрыл обращение. SLA соблюдено. Все довольны».
Но если проблема остаётся — она будет стоить вам больше времени, больше нервов и больше денег .
🔍 Управление проблемами — это не про реакцию. Это про профилактику.
Когда инженер второй линии решает один и тот же инцидент по 20 раз в месяц, он тратит часы на то, что можно было бы решить один раз, но глубоко .
⚙️ Как это работает:
Это не просто работа с ошибками. Это работа над тем, чтобы этих ошибок становилось меньше.
Мысль 3: 🎯 Метрики без целей — это шум
Метрики нужны, чтобы видеть картину.
Но они должны отвечать на вопросы:
Если метрика не помогает ответить на эти вопросы — она бесполезна.
Даже если она красиво оформлена в дашборде.
#ITIL #Метрики
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤🔥2✍1❤1
Что такое 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 #ТехническаяПоддержка
Incident Management - это управление жизненным циклом инцидента, от первого сигнала до полного восстановления сервиса.
Цель - не просто закрыть заявку.
Цель - восстановить нормальную работу как можно быстрее, с минимальным влиянием на клиентов и бизнес.
Что такое инцидент?
Инцидент - это любое событие, которое нарушает нормальную работу сервиса.
Это не обязательно «всё упало».
Это может быть:
▪️ пользователь не может войти в систему,
▪️ сервис работает медленно,
▪️ кто-то увидел ошибку в логах и напугался,
▪️ или просто: «Я не понимаю, что происходит».
Главное - влияние на пользователя.
Основные цели Incident Management
Не обязательно найти корневую причину.
Достаточно вернуть работоспособность - даже временным решением.
Чем дольше сервис недоступен - тем больше ущерб.
Это не бюрократия.
Это обещание, которое вы даёте клиенту.
Инцидент - это симптом.
А значит, за ним может быть проблема, которую нужно изучить.
Кто участвует?
Это фронт.
Их задача - не решить всё, а:
▪️ зарегистрировать инцидент,
▪️ определить приоритет,
▪️ передать в нужную группу,
▪️ держать клиента в курсе.
Это эксперты.
У них глубокие знания по конкретным сервисам.
Они:
▪️ диагностируют,
▪️ ищут корень,
▪️ создают обходные решения,
▪️ инициируют изменения.
Те, кто делает сервис снова рабочим.
Не каждый инцидент требует менеджера.
Но если инцидент критичный - он появляется.
Его задача:
▪️ координировать,
▪️ следить за SLA,
▪️ информировать бизнес,
▪️ и не давать процессу выйти из-под контроля.
Он - дирижёр, а не музыкант
Как начинается инцидент?
Инцидент может начаться:
▪️ от пользователя («не работает»),
▪️ от мониторинга («сервер не отвечает»),
▪️ от внутренней команды («заметили аномалию»).
🔄 Жизненный цикл инцидента: от «сломалось» до «всё снова работает»
Каждый инцидент проходит через четыре ключевые фазы:
Инцидент поступает - через портал, чат, телефон.
Его нужно: зарегистрировать, присвоить ID, указать категорию и приоритет.
Что не работает?
Где?
Кто ответственный/может помочь?
Нужна ли эскалация?
Найден обходной путь?
Устранена ошибка?
Сервис восстановлен?
Клиент подтвердил?
Есть ли риск повтора?
Нужно ли передать в Problem Management?
🔥 Срочность и влияние: как определить, что срочно, а что — критично
Не все инциденты одинаковы.
Именно поэтому в Incident Management есть два ключевых параметра:
Влияние (Impact)
Кто и что пострадало?
Насколько широко проблема затрагивает бизнес?
Высокое - сервис недоступен для большого числа пользователей или критичных подразделений.
Среднее - несколько пользователей или одно подразделение.
Низкое - один пользователь, не критичная функция.
⏱Срочность (Urgency)
Насколько быстро нужно решить?
Высокая - требует немедленного вмешательства, например, остановка бизнес-процесса
Средняя - важно, но можно подождать несколько часов
Низкая - стандартный запрос, срок решения - дни
Из этих двух параметров формируется приоритет инцидента.
Приоритет = Влияние × Срочность
Зачем это нужно?
Чтобы:
▪️ не терять время на низкоприоритетные задачи, пока горит критичный сервис,
▪️ правильно распределять нагрузку,
▪️ соблюдать SLA,
▪️ и главное - говорить с бизнесом на одном языке.
«срочно» и «важно» - это не одно и то же.
Во второй части поговорим о Major Incident, метриках и связи с другими процессами.
#ITIL #IncidentManagement #TechSupport #ТехническаяПоддержка
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11👍3
Что такое 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 #ТехническаяПоддержка
🚨 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 #ТехническаяПоддержка
🔥8👍2✍1
The State of Tech support 2025.pdf
781.4 KB
Исследование HDI The State of Tech support 2025
HDI опросил 115 лидеров отрасли. Вот что показал отчёт.
1. Технологии меняются быстрее, чем мы успеваем учиться
▪️ 54% компаний говорят: обучение стало сложнее за последние 3 года.
▪️ 67% - проблема не в людях, а в информационной перегрузке.
▪️ 34% видят рост числа тикетов. Средний объём - 10 675 заявок в месяц.
▪️ 45% чувствуют, что отстают в освоении новых инструментов.
Технологии опережают подготовку. Поддержка бежит в гору, но с рюкзаком из устаревших процессов.
2. Жёсткие навыки важны. Но мягкие - решают
▪️ 55% - главная проблема найма: не хватает soft skills.
▪️ Только 39% жалуются на нехватку hard skills.
▪️ Теперь важно не только знать, но и объяснить, выслушать, поддержать.
▪️ Критическое мышление, эмпатия, умение работать в команде - стали must-have.
▪️ И найти человека с этим балансом - тяжелее, чем сдать экзамен по CCNA.
3. AI - не угроза. Это шанс перестроиться
▪️ 71% вкладывают в технологии ради лучшего опыта клиента.
▪️ 42% считают, что ИИ будет играть ключевую роль в обучении.
▪️ 14% уже используют ИИ в тренировках, 38% - готовятся к внедрению.
Да, 50% ожидают, что некоторые позиции станут ненужными.
Но другие - появятся. Главное - не сопротивляться, а переквалифицироваться.
4. Экономика давит
▪️ В 2024 повышения получили 56% сотрудников.
В 2025 - ожидает только 42%.
▪️ 46% чувствуют себя недооценёнными.
▪️ 12-13% ждут сокращения льгот (в 2024 - 5-7%).
▪️ 30% сомневаются, что найдут такую же работу, если уволят.
▪️ 15% ожидают заморозки найма.
Но есть и свет: 45%, кто пытался договориться о зарплате - получили.
5. Уважение - это не бонус. Это основа
▪️ 75% команд столкнулись с высокой текучкой
▪️ 59% отметили: это влияет на сервис и на продуктивность.
Что работает:
▪️ Честная оплата - подтверждает ценность.
▪️ Баланс - уважает личное время.
▪️ Карьерные пути - показывают: ты не расходный материал.
▪️ Признание - напоминает: тебя видят.
«Уважение - это инвестиция. И оно окупается стабильностью, качеством и лояльностью» - Томас HDI.
Нашел в канале Клиентский опыт и качество
#Исследования #Тренды
HDI опросил 115 лидеров отрасли. Вот что показал отчёт.
1. Технологии меняются быстрее, чем мы успеваем учиться
▪️ 54% компаний говорят: обучение стало сложнее за последние 3 года.
▪️ 67% - проблема не в людях, а в информационной перегрузке.
▪️ 34% видят рост числа тикетов. Средний объём - 10 675 заявок в месяц.
▪️ 45% чувствуют, что отстают в освоении новых инструментов.
Технологии опережают подготовку. Поддержка бежит в гору, но с рюкзаком из устаревших процессов.
2. Жёсткие навыки важны. Но мягкие - решают
▪️ 55% - главная проблема найма: не хватает soft skills.
▪️ Только 39% жалуются на нехватку hard skills.
▪️ Теперь важно не только знать, но и объяснить, выслушать, поддержать.
▪️ Критическое мышление, эмпатия, умение работать в команде - стали must-have.
▪️ И найти человека с этим балансом - тяжелее, чем сдать экзамен по CCNA.
3. AI - не угроза. Это шанс перестроиться
▪️ 71% вкладывают в технологии ради лучшего опыта клиента.
▪️ 42% считают, что ИИ будет играть ключевую роль в обучении.
▪️ 14% уже используют ИИ в тренировках, 38% - готовятся к внедрению.
Да, 50% ожидают, что некоторые позиции станут ненужными.
Но другие - появятся. Главное - не сопротивляться, а переквалифицироваться.
4. Экономика давит
▪️ В 2024 повышения получили 56% сотрудников.
В 2025 - ожидает только 42%.
▪️ 46% чувствуют себя недооценёнными.
▪️ 12-13% ждут сокращения льгот (в 2024 - 5-7%).
▪️ 30% сомневаются, что найдут такую же работу, если уволят.
▪️ 15% ожидают заморозки найма.
Но есть и свет: 45%, кто пытался договориться о зарплате - получили.
5. Уважение - это не бонус. Это основа
▪️ 75% команд столкнулись с высокой текучкой
▪️ 59% отметили: это влияет на сервис и на продуктивность.
Что работает:
▪️ Честная оплата - подтверждает ценность.
▪️ Баланс - уважает личное время.
▪️ Карьерные пути - показывают: ты не расходный материал.
▪️ Признание - напоминает: тебя видят.
«Уважение - это инвестиция. И оно окупается стабильностью, качеством и лояльностью» - Томас HDI.
Нашел в канале Клиентский опыт и качество
#Исследования #Тренды
👍7🔥3❤2
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
Что? Зачем? И почему?
Incident Management - восстанавливает сервис.
Problem Management - убирает причину, по которой он сломался.
Если инцидент - это симптом, то проблема - это источник боли.
Что такое проблема?
Проблема - это неизвестная корневая причина одного или нескольких инцидентов.
Примеры:
▪️ У 15 клиентов за день упал один и тот же сервис.
▪️ Сервер каждый понедельник в 9:00 замедляется на 30 минут.
▪️ После каждого обновления падает интеграция с биллингом.
Инцидент - это «не могу войти».
Проблема - это «почему у 200 пользователей каждый четверг в 14:00 падает авторизация».
Что такое Problem Management?
Это процесс поиска и устранения корневых причин инцидентов.
Не чтобы закрыть тикет. А чтобы больше не открывать такие тикеты.
Цель - не реагировать. Цель - предотвратить.
Основные цели Problem Management
Не «починили» - а поняли, почему сломалось.
Устранить не симптом, а источник.
Чтобы инцидент больше не возникал.
Не временный обходной путь, а постоянное исправление - в коде, в архитектуре, в процессе.
Увидеть, что 10 разных инцидентов — на самом деле одна проблема.
Зафиксировать решение в базе знаний.
Чтобы следующий инженер не изобретал велосипед.
Когда запускается Problem Management?
Проблема может начаться:
▪️ после серии повторяющихся инцидентов,
▪️ после Major Incident (там всегда есть корень),
▪️ по инициативе инженера: «Я вижу закономерность»,
▪️ из аналитики: «Сервис падает каждый раз после бэкапа».
Главное - не ждать. Если инцидент повторяется - пора искать проблему.
Как работает процесс?
▪️ Анализ инцидентов.
▪️ Выявление паттернов.
▪️ Сигнал: «Никогда такого не было. И вот опять».
▪️ Не «что упало», а «почему упало».
▪️ Методы: 5 Why, Fishbone, Timeline Analysis.
▪️ Важно: искать системную причину, а не виноватого.
▪️ Это не обходное решение.
▪️ Это изменение: в коде, архитектуре, процессе, документации.
▪️ Никаких «сделал и забыл».
▪️ Решение внедряется официально, с тестированием и апрувами.
▪️ Клиент доволен?
▪️ Инциденты прекратились?
▪️ Значит, проблема решена.
▪️ И артефакт (документ, статья, чек-лист) — сохранён для команды.
Кто участвует?
▪️ Problem Manager - не техник, а аналитик.
Он видит систему, а не только симптомы.
▪️ L2/L3, SRE, DevOps, разработка - те, кто может глубоко копать.
▪️ Incident Manager - передаёт контекст: что, где, сколько раз.
▪️ Knowledge Manager - фиксирует решение, чтобы оно не потерялось.
Зачем это измерять?
Потому что:
▪️ Сколько проблем выявлено и закрыто?
Если ноль — значит, вы не смотрите.
▪️ Среднее время на решение проблемы
Не торопитесь. Главное — качество анализа.
▪️ Снижение количества инцидентов после решения
Это и есть доказательство эффективности.
▪️ Доля инцидентов, связанных с известными проблемами
Если высокая - у вас есть «дыра», которую давно пора закрыть.
Типичные ошибки
▪️ Не начинают вовремя
Ждут, пока станет «очень плохо».
▪️ Смешивают с Incident Management.
Инженер пытается «починить и разобраться» одновременно.
Не получается.
▪️ Не фиксируют артефакты.
Решение «в голове» - это не решение.
Это риск.
▪️ Не передают в Change Management.
«Поправили вручную» - и снова ждут, пока упадёт.
Итог
Incident Management - это пожарная команда
Problem Management - это инженер, который проверяет проводку.
Хороший процесс - это когда пожаров становится всё меньше.
#ProblemManagement #ITIL #TechSupport
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥6
Недавно меня позвала одна молодая, но дерзкая онлайн-школа, которая растит инженеров технической поддержки.
Приглашение звучало так:
«Ринат, ты должен быть headliner. С нас sold out.»
Ну как тут откажешь?
Пришёл. Поговорили.
Они - с вопросами. Я - с ответами.
Что хотели знать больше всего?
Как не просто выживать в поддержке - а расти.
Куда смотреть. Что учить. Как не сгореть.
Как из L1-2 - вырасти в того, кого все зовут, когда «всё горит».
В посте ниже подборка материалов, которые работают:
▪️ по hard skills: Linux, сети, SQL, API, Docker, Kubernetes, Python;
▪️ по soft skills: как говорить с клиентом, не срываться, объяснять сложное - и оставаться в живых.
📌 Подборка живая - буду дополнять, обновлять, выкидывать устаревшее.
Если что-то пропустил - пиши в комменты, скажу спасибо.
Читай. Учись. Применяй.
#TechSupport #Книги
Приглашение звучало так:
«Ринат, ты должен быть headliner. С нас sold out.»
Ну как тут откажешь?
Пришёл. Поговорили.
Они - с вопросами. Я - с ответами.
Что хотели знать больше всего?
Как не просто выживать в поддержке - а расти.
Куда смотреть. Что учить. Как не сгореть.
Как из L1-2 - вырасти в того, кого все зовут, когда «всё горит».
В посте ниже подборка материалов, которые работают:
▪️ по hard skills: Linux, сети, SQL, API, Docker, Kubernetes, Python;
▪️ по soft skills: как говорить с клиентом, не срываться, объяснять сложное - и оставаться в живых.
📌 Подборка живая - буду дополнять, обновлять, выкидывать устаревшее.
Если что-то пропустил - пиши в комменты, скажу спасибо.
Читай. Учись. Применяй.
#TechSupport #Книги
🔥9👍1
Читай и изучай в свободное время.
Не для галочки - чтобы проникаться, вариться, расти.
Твой путь в топ.
Легенда:
😎 - легко, сходу
🤓 - норм, но мозг включить надо
🙈 - сложнА
💻 База
▪️ Архитектура компьютера - Эндрю Таненбаум 🙈
▪️ Как работают компьютеры - Джастис Мэтью 🙈
🐧 Linux
▪️ Внутреннее устройство Linux - Брайан Уорд 🤓
▪️ Командная строка Linux. Полное руководство - Уильям Шоттс 🙈
☸️ Kubernetes / Docker
▪️ Kubernetes в действии - Марко Лукша 🤓
▪️ Docker. Вводный курс - Шая Кейн 🤓
🌐 Сети
▪️ Сети для самых маленьких (СДСМ) 😎
▪️ Компьютерные сети - Таненбаум / Олиферы 🤓
🐍 Python
▪️ Автоматизация рутинных задач с помощью Python - Эл Свейгарт 🙈
▪️ Python в системном администрировании UNIX и Linux - Ноа Гифт, Джереми М. Джонс 🤓
📊 SQL
▪️ Изучаем SQL - Алан Бьюли 🤓
🎓 Курсы
▪️ Selectel School 😎
▪️ Кирилл Семаев: видеокурсы по Linux 😎
▪️ Иннокентий Солнцев: курсы по сетям 😎
❤️ Клиентский сервис
▪️ ВкусВилл: Как совершить революцию в ритейле, делая всё не так - много про сервис внутри 😎
▪️ Книга про бизнес и сервис - Марина Вострикова 😎
▪️ Обнимите своих клиентов - Джек Митчелл 😎
▪️ Первоклассный сервис как конкурентное преимущество - Джон Шоул 😎
▪️ Доставляя счастье - Шей Тони 😎
▪️ Пиши, сокращай - Максим Ильяхов 😎
⏰ Тайм-менеджмент
▪️ Time Management for SysAdmins - Томас Лимонцелли 😎
▪️ Джедайские техники - Максим Дорофеев 😎
#TechSupport #Книги #Курсы
Не для галочки - чтобы проникаться, вариться, расти.
Твой путь в топ.
Легенда:
😎 - легко, сходу
🤓 - норм, но мозг включить надо
🙈 - сложнА
💻 База
▪️ Архитектура компьютера - Эндрю Таненбаум 🙈
▪️ Как работают компьютеры - Джастис Мэтью 🙈
🐧 Linux
▪️ Внутреннее устройство Linux - Брайан Уорд 🤓
▪️ Командная строка Linux. Полное руководство - Уильям Шоттс 🙈
☸️ Kubernetes / Docker
▪️ Kubernetes в действии - Марко Лукша 🤓
▪️ Docker. Вводный курс - Шая Кейн 🤓
🌐 Сети
▪️ Сети для самых маленьких (СДСМ) 😎
▪️ Компьютерные сети - Таненбаум / Олиферы 🤓
🐍 Python
▪️ Автоматизация рутинных задач с помощью Python - Эл Свейгарт 🙈
▪️ Python в системном администрировании UNIX и Linux - Ноа Гифт, Джереми М. Джонс 🤓
📊 SQL
▪️ Изучаем SQL - Алан Бьюли 🤓
🎓 Курсы
▪️ Selectel School 😎
▪️ Кирилл Семаев: видеокурсы по Linux 😎
▪️ Иннокентий Солнцев: курсы по сетям 😎
❤️ Клиентский сервис
▪️ ВкусВилл: Как совершить революцию в ритейле, делая всё не так - много про сервис внутри 😎
▪️ Книга про бизнес и сервис - Марина Вострикова 😎
▪️ Обнимите своих клиентов - Джек Митчелл 😎
▪️ Первоклассный сервис как конкурентное преимущество - Джон Шоул 😎
▪️ Доставляя счастье - Шей Тони 😎
▪️ Пиши, сокращай - Максим Ильяхов 😎
⏰ Тайм-менеджмент
▪️ Time Management for SysAdmins - Томас Лимонцелли 😎
▪️ Джедайские техники - Максим Дорофеев 😎
#TechSupport #Книги #Курсы
🔥11👍5💯4👎1
Как устроена техническая поддержка в Яндекс.Клауде?
Докладов про поддержку мало.
Толковых - ещё меньше.
А между тем, в крупном облачном провайдере поддержка - не просто «дежурный у телефона».
Это система, в которой всё продумано: от найма до культуры, от автоматизации до KPI, от первого тикета до инцидента уровня P0.
В докладе - разбор изнутри.
Не про теорию.
Про то, как это работает на практике.
Что узнаете:
▪️ Как организована поддержка в крупном облачном провайдере?
- Три линии
- L1 решает большую часть запросов, L2 и L3 - погружаются в сложные кейсы, работают с продуктами, участвуют в инцидентах.
- Поддержка - не «конвейер», а сеть экспертизы.
▪️ Сколько инженеров на каждой линии?
- Не просто цифры.
- Как они распределены по продуктам
▪️ Как и откуда они набирают людей?
- Не только по стеку и резюме.
▪️ Как устроен онбординг и развитие?
- Первые 90 дней - не «знакомство с системой», а глубокое погружение.
▪️ Что автоматизировали?
- Чтобы инженер мог решать проблему, а не искать её.
▪️ Чем занимаются L2/L3?
▪️ Какие KPI у инженеров и руководителей?
▪️ Как работают с инцидентами?
▪️ Что должна иметь любая ответственная компания?
▪️ Нужен ли Tone of Voice?
- Спойлер: Да.
▪️ Support - центр расходов или доходов?
▪️ Какая культура в команде?
Рекомендую.
Польза будет.
Однозначно.
#TechSupport
Докладов про поддержку мало.
Толковых - ещё меньше.
А между тем, в крупном облачном провайдере поддержка - не просто «дежурный у телефона».
Это система, в которой всё продумано: от найма до культуры, от автоматизации до KPI, от первого тикета до инцидента уровня P0.
В докладе - разбор изнутри.
Не про теорию.
Про то, как это работает на практике.
Что узнаете:
▪️ Как организована поддержка в крупном облачном провайдере?
- Три линии
- L1 решает большую часть запросов, L2 и L3 - погружаются в сложные кейсы, работают с продуктами, участвуют в инцидентах.
- Поддержка - не «конвейер», а сеть экспертизы.
▪️ Сколько инженеров на каждой линии?
- Не просто цифры.
- Как они распределены по продуктам
▪️ Как и откуда они набирают людей?
- Не только по стеку и резюме.
▪️ Как устроен онбординг и развитие?
- Первые 90 дней - не «знакомство с системой», а глубокое погружение.
▪️ Что автоматизировали?
- Чтобы инженер мог решать проблему, а не искать её.
▪️ Чем занимаются L2/L3?
▪️ Какие KPI у инженеров и руководителей?
▪️ Как работают с инцидентами?
▪️ Что должна иметь любая ответственная компания?
▪️ Нужен ли Tone of Voice?
- Спойлер: Да.
▪️ Support - центр расходов или доходов?
▪️ Какая культура в команде?
Рекомендую.
Польза будет.
Однозначно.
#TechSupport
RUTUBE
Как мы делаем Yandex Cloud — Support
В новом выпуске «Как мы делаем Yandex Cloud» познакомились с руководителем третьей линии поддержки Александром Житным. Обсудили, как устроена поддержка Yandex Cloud, чем занимаются команда автоматизации и AI-роботы, какие у команды KPI и принципы работы.…
🔥8👍7✍3👎1
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
Что? Зачем? И почему?
Incident Management - восстанавливает сервис.
Problem Management - убирает причину поломки.
Change Management - предотвращает сбои и улучшает сервис.
Если инцидент - пожар, проблема - неисправная проводка,
то Change - это разрешение на ремонт, проверенный план и подписанный акт.
Без него «быстрый фикс» становится бомбой.
Примеры:
▪️ Обновление операционной системы на критически важном сервере.
▪️ Развертывание новой версии корпоративного приложения.
▪️ Изменение конфигурации сетевого оборудования, чтобы увеличить пропускную способность.
▪️ Удаление устаревшего, неиспользуемого компонента инфраструктуры.
Что такое Change Management?
Это процесс контроля изменений в инфраструктуре, продуктах и процессах.
Не запрет на перемены.
А структура для безопасных изменений.
Основные цели Change Management
Цель - не замедлить.
Цель - предотвратить ущерб от "хорошей пятничной идеи в 20:37".
Почему это важно? Потому что:
▪️70% инцидентов начинаются с изменения.
▪️90% из них - с изменения, которое "никто не заметил".
▪️100% из них - с изменения, которое не прошло проверку.
Каждое изменение оценивается: что может пойти не так?
Кто пострадает?
Как откатим?
Не "сделаем и посмотрим".
А: протестируем → согласуем → внедрим → проверим.
Где, что, кем и когда было изменено?
Теперь вы можете ответить на этот вопрос.
Разработка, SRE, поддержка, безопасность - все в одном поле.
Никаких сюрпризов в релизе.
Не ради "процедуры".
А ради того, чтобы клиенты продолжали пользоваться сервисом.
Когда запускается Change Management?
Всегда.
Если изменение касается:
▪️кода,
▪️конфигурации,
▪️сети,
▪️доступов,
Все идёт через Change Request (CRQ).
Даже если:
▪️"это мелочь",
▪️"раньше так делали без согласования",
▪️"сроки горят".
Горящие сроки - не повод для горящего сервиса.
Как работает процесс?
Кто-то хочет что-то изменить.
Пишет CRQ:
▪️Что?
▪️Зачем?
▪️Как?
▪️Риски?
▪️План отката?
Change Advisory Board (CAB) - или упрощённый аналог - смотрит:
▪️Нет ли конфликтов с другими изменениями?
▪️Есть ли ресурсы?
▪️Достаточно ли тестов?
▪️Кто утвердит?
Изменение внедряется в согласованное окно.
С контролем, мониторингом, поддержкой на связи.
Работает ли?
Клиенты не страдают?
Метрики в норме?
→ Закрываем 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11👍3✍2🤝1
FS_Benchmark_2024.pdf
24.5 MB
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 #Метрики
KPI - это не просто цифры. Это ваш GPS в мире ITSM.
На основе данных 9 400+ организаций, 100 стран и 167 миллионов(
Это не просто отчёт. Это бенчмарк для тех, кто хочет быть выше рынка.
7 KPI, по которым измеряют зрелость поддержки:
Почти полное удовлетворение клиентов. Теперь это не достижение - это ожидание.
Среднее время решения запроса. Ваш результат ближе к этому числу?
Первый ответ. Чем быстрее, тем лучше. Каждый час ожидания — снижение доверия.
Доля тикетов, закрытых с первого контакта. Ниже? Значит, процесс хромает.
Соблюдение сроков решения. Большинство тикетов закрывается вовремя. Но не у всех.
Сроки первого ответа соблюдаются почти всегда. Исключения - риск для репутации.
Время до назначения тикета специалисту. Каждый час в очереди - потеря лояльности.
Эти цифры - медиана по рынку.
Если вы ниже - догоняйте.
Если выше - вы впереди.
Если намного выше - вы задаёте тренд.
Где взять прорыв по метрикам?
Отчёт чётко показывает: технологии работают. Но только если они правильные.
Предлагает готовые, контекстно-ориентированные ответы прямо в интерфейсе специалиста.
Основано на базе знаний, истории обращения и типе запроса.
Специалист не ищет, не формулирует - он отправляет.
Результат: первый ответ за 6,56 часов вместо 10,82.
Автоматически создаёт краткое резюме длинного тикета.
Выделяет суть проблемы, действия специалистов, комментарии клиента.
Специалист не читает 50 сообщений - он видит суть за 10 секунд.
Итог: на треть быстрее закрываются сложные тикеты.
Автоматически создаёт статьи на основе реальных тикетов, переписок и внешних источников.
Решения из опыта специалистов сразу становятся доступны всей команде.
База знаний живёт и растёт без ручного труда.
Self-service становится мощнее. Повторяющиеся тикеты исчезают.
Итог
FBR 2024 - это не про «что делают другие».
Это про то, какие действия дают прирост.
Не гадайте.
Сравнивайте.
Улучшайте.
#Исследования #Тренды #TechSupport #Метрики
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17🔥5❤2🤝1
КтоЕстьКто в ТехПоде
За последнее годы, я провел больше 400 собеседований на tech и руководящие позиции, и этот опыт позволил мне сформулировать два ключевых наблюдения:
1️⃣ Успех приходит тогда, когда тебе не нужно «заставлять» себя работать, потому что процесс приносит радость. Когда твоя job становится хобби, ты не «ищешь время» на развитие, а просто не можешь без него жить. Следить за трендами, смотреть доклады с конференций, быть на острие - это не обязанность, а естественное состояние.
2️⃣ Существует разрыв в ожиданиях. Часто талантливые люди просто не понимают, каких конкретно знаний и навыков от них ждут на той или иной позиции. Они теряются в догадках, куда двигаться дальше.
Чтобы закрыть этот разрыв, я запускаю серию постов #КтоЕстьКто в #ТехПод с фокусом на роли в индустрии облачных провайдеров.
В первом выпуске разберем инженера технической поддержки 1-й линии (L1). Это тот самый старт, с которого начинаются многие великие карьеры в IT.
Вместе разберем:
▪️Что это за роль на самом деле
▪️Какие требования действительно важны
▪️Куда растут лучшие инженеры L1
А в конце серии постов вас ждет небольшой бонус -откровенный разговор о том, сколько можно зарабатывать на каждой из разобранных позиций.
#КтоЕстьКто #ТехПод #TechSupport
За последнее годы, я провел больше 400 собеседований на tech и руководящие позиции, и этот опыт позволил мне сформулировать два ключевых наблюдения:
Чтобы закрыть этот разрыв, я запускаю серию постов #КтоЕстьКто в #ТехПод с фокусом на роли в индустрии облачных провайдеров.
В первом выпуске разберем инженера технической поддержки 1-й линии (L1). Это тот самый старт, с которого начинаются многие великие карьеры в IT.
Вместе разберем:
▪️Что это за роль на самом деле
▪️Какие требования действительно важны
▪️Куда растут лучшие инженеры L1
А в конце серии постов вас ждет небольшой бонус -
#КтоЕстьКто #ТехПод #TechSupport
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥5
КтоЕстьКто: Инженер технической поддержки 1-й линии (L1 Support Engineer)
Обзор роли
Инженер L1 в облачном провайдере - это первая и ключевая точка контакта между клиентом и компанией. Основная задача - приём обращений, первичная диагностика и решение базовых инцидентов, связанных с облачной инфраструктурой и сервисами клиента. Роль требует понимания облачных технологий и направлена на максимально быстрое восстановление работоспособности услуг или грамотную эскалацию для минимизации времени простоя.
Цель позиции
Обеспечить оперативное и квалифицированное реагирование на входящие запросы клиентов, эффективно используя инструменты мониторинга и базу знаний. Минимизировать время на первичную обработку и эскалацию инцидентов, соблюдая SLA и обеспечивая высокий уровень клиентского сервиса.
Кому подходит роль
▪️ Выпускникам технических вузов, интересующимся облачными технологиями
▪️ Кандидатам, которые хотят построить карьеру в одной из самых востребованных областей IT
▪️ Тем, кто готов учиться, обладает развитыми коммуникативными навыками и хочет работать в динамичной среде
Роль и обязанности
▪️ Приём и обработка запросов клиентов
▪️ Приём инцидентов от клиентов через выделенные каналы связи: тикет-система, телефон, портал
▪️ Профессиональное и вежливое общение, направленное на уточнение и понимание сути проблемы
▪️ Проверка прав клиента на получение технической поддержки по договору
Первичная диагностика и решение
▪️ Оперативный сбор информации: идентификаторы облачных ресурсов (ID инстанса, ID проекта), ошибки с консоли управления, логи, скриншоты
▪️ Проведение базовой диагностики с использованием внутренних инструментов мониторинга и панелей управления: дашборды состояния сервисов, метрики виртуальных машин, статус сетевых интерфейсов
▪️ Решение распространённых проблем:
• Консультации по настройке и использованию панели управления (Cloud Console)
• Проблемы с доступом к виртуальным машинам (ВМ) через SSH/RDP
• Сброс паролей или ключей доступа к ВМ
• Консультации по работе с базовыми сервисами (объектное хранилище, CDN, базы данных)
• Проверка доступности сервисов в зоне клиента и идентификация массовых инцидентов
Эскалация инцидентов
▪️ Чёткое определение категории проблемы: сбой платформы, сетевые проблемы, проблемы с производительностью, консультационный запрос
▪️ Назначение тикетов соответствующим экспертным командам: L2/L3, сетевым инженерам, инженерам по хранению данных, специалистам по виртуализации - с полным комплектом собранной информации
▪️ Мониторинг статуса эскалированных тикетов и поддержание коммуникации с клиентом о прогрессе
Документирование и управление знаниями
▪️ Ведение детальной и точной записи по каждому инциденту в системе Service Desk
▪️ Создание и обновление статей в базе знаний на основе повторяющихся запросов: How-To, частые ошибки, рекомендации
▪️ Ведение внутренней документации по процедурам эскалации
Требования к навыкам
Обязательные Hard Skills
▪️ Базовое понимание облачных концепций: IaaS, PaaS, виртуальные машины, виртуальные сети, блочное и объектное хранилище
▪️ Базовые знания сетевых технологий: понимание TCP/IP, DNS, HTTP(S); умение использовать ping, traceroute, nslookup, curl для первичной диагностики
▪️ Основы безопасности: понимание разницы между логином/паролем и ключевой парой SSH, принципов работы файрволов
▪️ Работа с API: базовое понимание REST, методов запросов, кодов ответов
▪️ Опыт работы с CLI (командной строкой) на базовом уровне в Linux: работа с файловой системой, основные команды - ls, cd, cat, grep, ps, chmod, chown
▪️ Английский язык на уровне чтения технической документации (как минимум)
Продолжение в комментариях
#КтоЕстьКто #TechSupport
Обзор роли
Инженер L1 в облачном провайдере - это первая и ключевая точка контакта между клиентом и компанией. Основная задача - приём обращений, первичная диагностика и решение базовых инцидентов, связанных с облачной инфраструктурой и сервисами клиента. Роль требует понимания облачных технологий и направлена на максимально быстрое восстановление работоспособности услуг или грамотную эскалацию для минимизации времени простоя.
Цель позиции
Обеспечить оперативное и квалифицированное реагирование на входящие запросы клиентов, эффективно используя инструменты мониторинга и базу знаний. Минимизировать время на первичную обработку и эскалацию инцидентов, соблюдая SLA и обеспечивая высокий уровень клиентского сервиса.
Кому подходит роль
▪️ Выпускникам технических вузов, интересующимся облачными технологиями
▪️ Кандидатам, которые хотят построить карьеру в одной из самых востребованных областей IT
▪️ Тем, кто готов учиться, обладает развитыми коммуникативными навыками и хочет работать в динамичной среде
Роль и обязанности
▪️ Приём и обработка запросов клиентов
▪️ Приём инцидентов от клиентов через выделенные каналы связи: тикет-система, телефон, портал
▪️ Профессиональное и вежливое общение, направленное на уточнение и понимание сути проблемы
▪️ Проверка прав клиента на получение технической поддержки по договору
Первичная диагностика и решение
▪️ Оперативный сбор информации: идентификаторы облачных ресурсов (ID инстанса, ID проекта), ошибки с консоли управления, логи, скриншоты
▪️ Проведение базовой диагностики с использованием внутренних инструментов мониторинга и панелей управления: дашборды состояния сервисов, метрики виртуальных машин, статус сетевых интерфейсов
▪️ Решение распространённых проблем:
• Консультации по настройке и использованию панели управления (Cloud Console)
• Проблемы с доступом к виртуальным машинам (ВМ) через SSH/RDP
• Сброс паролей или ключей доступа к ВМ
• Консультации по работе с базовыми сервисами (объектное хранилище, CDN, базы данных)
• Проверка доступности сервисов в зоне клиента и идентификация массовых инцидентов
Эскалация инцидентов
▪️ Чёткое определение категории проблемы: сбой платформы, сетевые проблемы, проблемы с производительностью, консультационный запрос
▪️ Назначение тикетов соответствующим экспертным командам: L2/L3, сетевым инженерам, инженерам по хранению данных, специалистам по виртуализации - с полным комплектом собранной информации
▪️ Мониторинг статуса эскалированных тикетов и поддержание коммуникации с клиентом о прогрессе
Документирование и управление знаниями
▪️ Ведение детальной и точной записи по каждому инциденту в системе Service Desk
▪️ Создание и обновление статей в базе знаний на основе повторяющихся запросов: How-To, частые ошибки, рекомендации
▪️ Ведение внутренней документации по процедурам эскалации
Требования к навыкам
Обязательные Hard Skills
▪️ Базовое понимание облачных концепций: IaaS, PaaS, виртуальные машины, виртуальные сети, блочное и объектное хранилище
▪️ Базовые знания сетевых технологий: понимание TCP/IP, DNS, HTTP(S); умение использовать ping, traceroute, nslookup, curl для первичной диагностики
▪️ Основы безопасности: понимание разницы между логином/паролем и ключевой парой SSH, принципов работы файрволов
▪️ Работа с API: базовое понимание REST, методов запросов, кодов ответов
▪️ Опыт работы с CLI (командной строкой) на базовом уровне в Linux: работа с файловой системой, основные команды - ls, cd, cat, grep, ps, chmod, chown
▪️ Английский язык на уровне чтения технической документации (как минимум)
Продолжение в комментариях
#КтоЕстьКто #TechSupport
👍13🔥4❤2
SysAid-SOSM-2025.pdf
12.3 MB
The Rise of Agentic AI in ITSM (2025 Mega-Trends) SysAid
Развитие агентного ЫЫ в ITSM (Мега-тренды 2025 года) от SysAid
2025 год меняет ITSM: на смену автоматизации приходит агентный ИИ, который не просто выполняет задачи, а действует автономно - анализирует контекст, принимает решения и решает проблемы без участия человека.
Основные тренды, формирующие будущее ITSM:
▪️ Автономность вместо помощи: 52% руководителей ИТ хотят, чтобы ИИ автоматически устранял повторяющиеся инциденты. Агенты уже способны решать до 23% запросов уровня 1 без участия человека, автоматически классифицировать тикеты и выполнять рутинные операции - от сброса паролей до онбординга.
▪️ Чат-боты становятся обязательным стандартом: От «приятной опции» они превращаются в ядро сервис-деска, значительно снижая нагрузку на персонал. AI-усиленные порталы самообслуживания сокращают объем тикетов в 3 раза чаще, чем традиционные SSP, причем 43% организаций фиксируют снижение более чем на 30%.
▪️ Умное управление активами: 30% компаний до сих пор используют ручной учет активов, а 12% - вообще не имеют системы. Автоматизированное, основанное на ИИ отслеживание активов в реальном времени становится критически важным для снижения рисков, соблюдения норм и экономии средств.
▪️ Приоритеты внедрения: ИТ-команды в первую очередь ценят простоту использования (63%), безопасность (56%) и стоимость решения (52%). Успех зависит не только от технологий, но и от проектирования интерфейсов вокруг потребностей человека - подход, основанный на human-centered design.
▪️ Профилактика и прогнозирование: Агенты ИИ не ждут проблем - они их предотвращают. С помощью анализа данных в реальном времени, прогнозирования сбоев и автоматической инициации корректирующих действий они повышают надежность систем и снижают простои.
▪️ Реальная трансформация роли ИТ-персонала: Рутинные задачи передаются ИИ, освобождая специалистов для работы над сложными, креативными и стратегическими задачами. Это меняет саму природу ИТ-поддержки - от реактивной к проактивной и интеллектуальной.
▪️ Барьеры остаются: Несмотря на энтузиазм, ключевые препятствия - это опасения по поводу безопасности, конфиденциальности данных и нехватки ресурсов для внедрения.
▪️ Гибридная работа усиливает спрос: 38% лидеров планируют использовать ИИ для упрощения поддержки в условиях распределенных команд - особенно важно, чтобы решения были интуитивно понятны, как личный офисный helpdesk.
Вывод:
Успех зависит не от технологии самой по себе, а от её интеграции в процессы с фокусом на простоту, безопасность и удобство людей. Итог: пользователи получают мгновенную помощь, IT-специалисты - время на сложные задачи, а бизнес - надежную и экономичную IT-инфраструктуру.
#Исследования #Тренды
Развитие агентного ЫЫ в ITSM (Мега-тренды 2025 года) от SysAid
2025 год меняет ITSM: на смену автоматизации приходит агентный ИИ, который не просто выполняет задачи, а действует автономно - анализирует контекст, принимает решения и решает проблемы без участия человека.
Основные тренды, формирующие будущее ITSM:
▪️ Автономность вместо помощи: 52% руководителей ИТ хотят, чтобы ИИ автоматически устранял повторяющиеся инциденты. Агенты уже способны решать до 23% запросов уровня 1 без участия человека, автоматически классифицировать тикеты и выполнять рутинные операции - от сброса паролей до онбординга.
▪️ Чат-боты становятся обязательным стандартом: От «приятной опции» они превращаются в ядро сервис-деска, значительно снижая нагрузку на персонал. AI-усиленные порталы самообслуживания сокращают объем тикетов в 3 раза чаще, чем традиционные SSP, причем 43% организаций фиксируют снижение более чем на 30%.
▪️ Умное управление активами: 30% компаний до сих пор используют ручной учет активов, а 12% - вообще не имеют системы. Автоматизированное, основанное на ИИ отслеживание активов в реальном времени становится критически важным для снижения рисков, соблюдения норм и экономии средств.
▪️ Приоритеты внедрения: ИТ-команды в первую очередь ценят простоту использования (63%), безопасность (56%) и стоимость решения (52%). Успех зависит не только от технологий, но и от проектирования интерфейсов вокруг потребностей человека - подход, основанный на human-centered design.
▪️ Профилактика и прогнозирование: Агенты ИИ не ждут проблем - они их предотвращают. С помощью анализа данных в реальном времени, прогнозирования сбоев и автоматической инициации корректирующих действий они повышают надежность систем и снижают простои.
▪️ Реальная трансформация роли ИТ-персонала: Рутинные задачи передаются ИИ, освобождая специалистов для работы над сложными, креативными и стратегическими задачами. Это меняет саму природу ИТ-поддержки - от реактивной к проактивной и интеллектуальной.
▪️ Барьеры остаются: Несмотря на энтузиазм, ключевые препятствия - это опасения по поводу безопасности, конфиденциальности данных и нехватки ресурсов для внедрения.
▪️ Гибридная работа усиливает спрос: 38% лидеров планируют использовать ИИ для упрощения поддержки в условиях распределенных команд - особенно важно, чтобы решения были интуитивно понятны, как личный офисный helpdesk.
Вывод:
Успех зависит не от технологии самой по себе, а от её интеграции в процессы с фокусом на простоту, безопасность и удобство людей. Итог: пользователи получают мгновенную помощь, IT-специалисты - время на сложные задачи, а бизнес - надежную и экономичную IT-инфраструктуру.
#Исследования #Тренды
🔥11👍5❤1
Проиграл на первом шаге.
Или как НЕ нужно искать работу в технической поддержке.
Ко мне откликнулся кандидат на позицию инженера.
Резюме - безупречное.
Опыт - в компании, которая наш прямой конкурент.
Знания - всё, что нужно.
Я даже подумал: «Вот он - тот самый человек. Минимум адаптации. Максимум пользы. Может, даже чему-то нас научит».
И тут начинается самое интересное.
13 лет в индустрии - и я не пишу рекрутеру. Я пишу напрямую.
Тому, кто руководит техподом у конкурента.
Сообщение: «Привет. Такой-то у тебя работал? Ушёл пару месяцев назад. Что скажешь?»
Ответ - через 3 минуты.
Две строки.
«Такого человека у меня никогда не было. Более того - он вообще никогда не работал в нашей компании».
Что это значит?
Это не ошибка.
Это не опечатка.
Это сознательная ложь.
И она ломает всё - с самого первого шага.
Потому что в техподдержке, как нигде, всё строится на доверии.
Если его нет на нулевом этапе - дальше ничего хорошего не будет.
Никаких «но», «вдруг», «может быть».
Нет доверия - нет сотрудничества.
Но история на этом не заканчивается.
Она только начинается.
Потому что такие случаи - не редкость.
Их становится больше.
Но - и это важно - российский big tech начал реагировать.
Активно.
Системно.
И это дает надежду.
Я видел одного. Потом второго. Потом понял - это не исключения.
Скоро расскажу про новый мейнстрим: как люди без опыта, но подготовленные «менторами» и с «правильным» резюме, прорываются в топовые IT-компании.
Метод - обман.
Цель - зарплата.
Результат - пожар. Ваш.
#Собеседование #TechSupport
Или как НЕ нужно искать работу в технической поддержке.
Ко мне откликнулся кандидат на позицию инженера.
Резюме - безупречное.
Опыт - в компании, которая наш прямой конкурент.
Знания - всё, что нужно.
Я даже подумал: «Вот он - тот самый человек. Минимум адаптации. Максимум пользы. Может, даже чему-то нас научит».
И тут начинается самое интересное.
13 лет в индустрии - и я не пишу рекрутеру. Я пишу напрямую.
Тому, кто руководит техподом у конкурента.
Сообщение: «Привет. Такой-то у тебя работал? Ушёл пару месяцев назад. Что скажешь?»
Ответ - через 3 минуты.
Две строки.
«Такого человека у меня никогда не было. Более того - он вообще никогда не работал в нашей компании».
Что это значит?
Это не ошибка.
Это не опечатка.
Это сознательная ложь.
И она ломает всё - с самого первого шага.
Потому что в техподдержке, как нигде, всё строится на доверии.
Если его нет на нулевом этапе - дальше ничего хорошего не будет.
Никаких «но», «вдруг», «может быть».
Нет доверия - нет сотрудничества.
Но история на этом не заканчивается.
Она только начинается.
Потому что такие случаи - не редкость.
Их становится больше.
Но - и это важно - российский big tech начал реагировать.
Активно.
Системно.
И это дает надежду.
Я видел одного. Потом второго. Потом понял - это не исключения.
Скоро расскажу про новый мейнстрим: как люди без опыта, но подготовленные «менторами» и с «правильным» резюме, прорываются в топовые IT-компании.
Метод - обман.
Цель - зарплата.
Результат - пожар. Ваш.
#Собеседование #TechSupport
👍9🔥5🤔3🤝2😁1