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

Меняют индустрию, как Tesla

ServiceNow - компания, которая стала де-факто стандартом в ITSM: её платформу используют 85% компаний из Fortune 500.
Недавно они представили AI Experience - новую надстройку для управления ИИ и автоматизацией в корпоративной среде.

Суть решения - единый интерфейс, объединяющий разные типы AI-агентов: текстовые, голосовые, визуальные и веб-агенты.
Цель - упростить взаимодействие пользователя с системой, чтобы задачи решались быстрее и без необходимости повторно описывать проблему.

В демонстрационном видео показано, как менеджер в Adobe голосом даёт команду: одобрить заявку. Одновременно с этим запускается диагностика проблем с VPN. Система автоматически создаёт заявку, анализирует телеметрию, проверяет интеграции и предлагает решение. Хотя ее никто не просил :)
Также AI Experience умеет работать со скриншотами ошибок - распознаёт визуальный контекст и подбирает релевантные действия.

Платформа собирает данные о работе процессов и даёт аналитические рекомендации по их улучшению.
Клиенты вроде Adobe, Pure Storage и Bell Canada сообщают о сокращении времени на решение инцидентов и росте эффективности.

Важный акцент сделан на управлении и безопасности ИИ: все агенты и данные работают в рамках единой контролируемой экосистемы, а не как набор разрозненных инструментов.

Такие решения требуют не только точности ИИ, но и чётких процессов, fallback-механизмов и человеческого контроля - особенно в production-среде.

В целом, AI Experience - не просто «ещё один ИИ-чат», а попытка системно интегрировать искусственный интеллект в рабочие процессы поддержки.
Работает ли это на практике - покажет время.
Но направление, безусловно, заслуживает внимания.
#TechSupport #AI

30% штата - поддержка. Что ещё делает Точку не похожей на банк
Вы когда-нибудь слышали, чтобы банк снимал про себя кино?
Не рекламный ролик с «счастливой майонезной семьёй», а честный, живой рассказ о том, как устроена компания, для которой клиент - не метрика, а человек.
«Точка» - сделала именно это.

Они нанимают не по дипломам, а по эмпатии. Часто - из сферы HoReCa, где слушать клиента -это мышечная память. Они отменили деление на «випов» и «простых смертных». Нет никаких KPI вроде среднего времени на звонок. Сотрудник может самостоятельно, без согласований, подарить клиенту подарок.

Но как это работает изнутри? Как не скатиться в хаос?
Ключ - в халократии. Это когда у тебя есть свобода, но и ответственность за нее - тоже твоя. 50% времени ты тратишь на основную работу, а остальное - на то, что считаешь полезным.
Представьте диалог сотрудника с руководителем:
- Что мне делать?
- Вот цели, стратегия и ценности. Приноси пользу. Решай сам, как.

Спойлер: идеи «Точки» - это не изобретение велосипеда, а гениальное заимствование и адаптация лучших мировых практик.
▪️Отказ от AHT и принцип «провести с клиентом хоть целый день» - это прямая отсылка к культуре Zappos и книге Тони Шея «Доставляя счастье».
▪️Право сотрудника дарить подарки и идея, что мимо проблемы клиента не пройдет никто - это устав отелей The Ritz-Carlton, который описал в своих правилах основатель Хорст Шульце.
▪️Собеседования, основанные на ценностях компании - это отголосок принципов лидерства Amazon и их знаменитого процесса найма с «Bar Raiser».
▪️Реальные полномочия у рядовых сотрудников - об этом подробно написано в книге Джона Шоула «Реальные полномочия: Самостоятельность сотрудников как ключ к успеху».
▪️Легенда про кирпичи. Даже гендир в фильме не вспомнил истоки, но эта история очень напоминает практику одного девелопера: когда компания зарабатывала 100 млн рублей, они приносили в кабинет кирпич и складывали его в стену. Символично и осязаемо.
▪️А их фокус на малом и среднем бизнесе очень напоминает стратегию американского банка Capital One, который также начал с этого.

Вывод? Этот фильм смотрится на одном дыхании, даже на скорости 2x. Это редкий и честный взгляд на компанию, которая не на словах, а на деле поставила клиента в центр. Рекомендую к просмотру всем, кто хочет понять, каким должен быть сервис. Точка.
#TechSupport

Волчий билет: почему тактика обмана на собеседовании ведет к карьерному краху
В индустрии растёт не тренд - а паразит.
Сами себя называют «ИТ-волки». В этом сообществе ~80 тысяч подписчиков.
Феномен? Да.
Полезный? Нет.

Это сообщество не учит работать.
Оно учит - как не работать, но получать.
Как выдать чужой опыт за свой.
Как пройти техническое собеседование, ничего не зная.
Как цитировать Трудовой Кодекс, чтобы не уволили - даже если вы ничего не делаете.
И как «накрутить» карьеру, которой не было.
Это не «недобросовестный кандидат».
Это - системный риск.

Вот что это даёт на практике:
▪️ Утечки данных от внутреннего инсайдера.
▪️ Сбои из-за некомпетентности - не злого умысла, а просто незнания.
▪️ Потеря времени на поиск/найм/собеседование
▪️ Неверные кадровые решения, которые тянут за собой простой систем, коллапс согласований, недовольство клиентов.
▪️ А в худшем случае - банкротство.

Вы получаете историю в духе Knight Capital Group.
2012 год.
Американская брокерская компания.
Один сотрудник - без должного контроля - запустил обновление ПО.
Старый код не удалили. Новый - активировали неправильно.
Система начала слать миллионы ложных ордеров.
150 акций в секунду.
За 45 минут - убытки в $440 миллионов.
Больше, чем весь капитал компании.
Результат? Банкротство.
Причина? Некомпетентность. Недоработок в процессах тестирования и контроля версий ПО. Отсутствие контроля. Доверие там, где нужно было проверять.

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

На Инфоцыган когда-то тоже закрывали глаза, пока их не прикрыли за месяц.

Моя позиция проста: волкам - волчий билет.
Тактически обман может принести быстрый результат. Стратегически же ложь всегда вскрывается. И падение с высоты мнимого успеха будет болезненным.

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

Проиграл на первом шаге.  
Или как НЕ нужно искать работу в технической поддержке.

Ко мне откликнулся кандидат на позицию инженера.  
Резюме - безупречное.  
Опыт - в компании, которая наш прямой конкурент.  
Знания - всё, что нужно.  
Я даже подумал: «Вот он - тот самый человек. Минимум адаптации. Максимум пользы. Может, даже чему-то нас научит».

И тут начинается самое интересное.

13 лет в индустрии - и я не пишу рекрутеру. Я пишу напрямую.  
Тому, кто руководит техподом у конкурента.  
Сообщение: «Привет. Такой-то у тебя работал? Ушёл пару месяцев назад. Что скажешь?»  
Ответ - через 3 минуты.  
Две строки.    
«Такого человека у меня никогда не было. Более того - он вообще никогда не работал в нашей компании».

Что это значит?  
Это не ошибка.  
Это не опечатка.  
Это сознательная ложь.  
И она ломает всё - с самого первого шага.

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

Но история на этом не заканчивается.  
Она только начинается.  
Потому что такие случаи - не редкость.  
Их становится больше.  
Но - и это важно - российский big tech начал реагировать.  
Активно.  
Системно.  
И это дает надежду.

Я видел одного. Потом второго. Потом понял - это не исключения.  
Скоро расскажу про новый мейнстрим: как люди без опыта, но подготовленные «менторами» и с «правильным» резюме, прорываются в топовые IT-компании.  
Метод - обман.  
Цель - зарплата.  
Результат - пожар. Ваш.

#Собеседование #TechSupport

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-инфраструктуру.

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

КтоЕстьКто: Инженер технической поддержки 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

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

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

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

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

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

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

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

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

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

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

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

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

Как устроена техническая поддержка в Яндекс.Клауде?

Докладов про поддержку мало.
Толковых - ещё меньше.
А между тем, в крупном облачном провайдере поддержка - не просто «дежурный у телефона».
Это система, в которой всё продумано: от найма до культуры, от автоматизации до KPI, от первого тикета до инцидента уровня P0.
В докладе - разбор изнутри.
Не про теорию.
Про то, как это работает на практике.
Что узнаете:
▪️ Как организована поддержка в крупном облачном провайдере?
- Три линии
- L1 решает большую часть запросов, L2 и L3 - погружаются в сложные кейсы, работают с продуктами, участвуют в инцидентах.
- Поддержка - не «конвейер», а сеть экспертизы.
▪️ Сколько инженеров на каждой линии?
- Не просто цифры.
- Как они распределены по продуктам
▪️ Как и откуда они набирают людей?
- Не только по стеку и резюме.
▪️ Как устроен онбординг и развитие?
- Первые 90 дней - не «знакомство с системой», а глубокое погружение.
▪️ Что автоматизировали?
- Чтобы инженер мог решать проблему, а не искать её.
▪️ Чем занимаются L2/L3?
▪️ Какие KPI у инженеров и руководителей?
▪️ Как работают с инцидентами?
▪️ Что должна иметь любая ответственная компания?
▪️ Нужен ли Tone of Voice?
- Спойлер: Да.
▪️ Support - центр расходов или доходов?
▪️ Какая культура в команде?

Рекомендую.
Польза будет.
Однозначно.

#TechSupport

Читай и изучай в свободное время.
Не для галочки - чтобы проникаться, вариться, расти.
Твой путь в топ.

Легенда:
😎 - легко, сходу
🤓 - норм, но мозг включить надо
🙈 - сложнА

💻 База
▪️ Архитектура компьютера - Эндрю Таненбаум 🙈
▪️ Как работают компьютеры - Джастис Мэтью 🙈

👨‍💻Администрирование
▪️ Самоучитель системного администратора - Александр Кенин

🐧 Linux
▪️ Внутреннее устройство Linux - Брайан Уорд 🤓
▪️ Командная строка Linux. Полное руководство - Уильям Шоттс 🙈

☸️ Kubernetes / Docker
▪️ Kubernetes в действии - Марко Лукша 🤓
▪️ Docker. Вводный курс - Шая Кейн 🤓

🌐 Сети
▪️ Сети для самых маленьких (СДСМ) 😎
▪️ Компьютерные сети - Таненбаум / Олиферы 🤓

🐍 Python
▪️ Автоматизация рутинных задач с помощью Python - Эл Свейгарт 🙈
▪️ Python в системном администрировании UNIX и Linux - Ноа Гифт, Джереми М. Джонс 🤓

📊 SQL
▪️ Изучаем SQL - Алан Бьюли 🤓

🎓 Курсы
▪️ Selectel School 😎
▪️ Кирилл Семаев: видеокурсы по Linux 😎
▪️ Иннокентий Солнцев: курсы по сетям 😎

❤️ Клиентский сервис
▪️ ВкусВилл: Как совершить революцию в ритейле, делая всё не так - много про сервис внутри 😎
▪️ Книга про бизнес и сервис - Марина Вострикова 😎
▪️ Обнимите своих клиентов - Джек Митчелл 😎
▪️ Первоклассный сервис как конкурентное преимущество - Джон Шоул 😎
▪️ Доставляя счастье - Шей Тони 😎
▪️ Пиши, сокращай - Максим Ильяхов 😎

⏰ Тайм-менеджмент
▪️ Time Management for SysAdmins - Томас Лимонцелли 😎
▪️ Джедайские техники - Максим Дорофеев 😎

#TechSupport #Книги #Курсы

Недавно меня позвала одна молодая, но дерзкая онлайн-школа, которая растит инженеров технической поддержки.
Приглашение звучало так:
«Ринат, ты должен быть headliner. С нас sold out.»
Ну как тут откажешь?
Пришёл. Поговорили.
Они - с вопросами. Я - с ответами.
Что хотели знать больше всего?
Как не просто выживать в поддержке - а расти.
Куда смотреть. Что учить. Как не сгореть.
Как из L1-2 - вырасти в того, кого все зовут, когда «всё горит».
В посте ниже подборка материалов, которые работают:
▪️ по hard skills: Linux, сети, SQL, API, Docker, Kubernetes, Python;
▪️ по soft skills: как говорить с клиентом, не срываться, объяснять сложное - и оставаться в живых.
📌 Подборка живая - буду дополнять, обновлять, выкидывать устаревшее.
Если что-то пропустил - пиши в комменты, скажу спасибо.
Читай. Учись. Применяй.
#TechSupport #Книги

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

#ProblemManagement #ITIL #TechSupport

Исследование 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.

Нашел в канале Клиентский опыт и качество

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

Что такое 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 #ТехническаяПоддержка

Что такое 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 #ТехническаяПоддержка

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

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

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

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

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

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

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

Что такое 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

Продолжаем исследовать, как 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

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

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

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