Как мы «вскрывали кейсы»: практика управления повторяющимися обращениями

Меня зовут Светлана Долгополова. Я менеджер бизнес-приложений в Ингосстрахе и уже несколько лет отвечаю за сопровождение систем и сервисов, используемых в нашей компании.
Моя зона ответственности – стабильность работы сервисов на проде.

В 2025 году наша команда техподдержки столкнулась с ростом нагрузки в связи с увеличением количества поддерживаемых систем, а следовательно, и с ростом заявок.
Ниже – мой опыт ^[1] участия во внедрении методов улучшения наших внутренних процессов работы с заявками и сокращения воронки обращений от пользователей.

Статья полезна для тем, кто отвечает за метрики поддержки и хотел бы их улучшить.

Управление заявками в поддержку

Моя основная задача – оптимизировать процессы взаимодействия специалистов техподдержки и пользователей на всех этапах сопровождения ПО. Расскажу подробнее, как устроена работа наших инженеров.

Как у любой команды техподдержки, у нас есть внутренние метрики и SLA (Service Level Agreement). Нам в Управлении сопровождения информационных систем (Далее – УСИС) важно, чтобы сервисы были максимально доступны, поэтому мы отслеживаем их состояние. Мы анализируем данные мониторингов и пользовательские обращения в ITSM.

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

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

Трансформация процессов

Одним февральским утром 2025 года наше подразделение получило от руководства следующую информацию:

Под «кейсом» мы понимали следующее:

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

Для нас такая «акция» – принципиально новый вид деятельности, не похожий на наши рутинные задачи и поручения руководства. Это внутренний опыт нашей команды, который позволил нам применить нестандартные навыки исследований, координации и организации принципиально нового процесса.

Для участия в «акции», кейс должен состоять из более 10 заявок в месяц в течение 3-х месяцев (не обязательно подряд, чтобы исключить нерелевантные месяцы). Сейчас в виде исключения и с целью покрыть кейсами максимальное количество обращений, мы регистрируем и кейсы, где количество заявок ниже этого значения.

Методология

Перед нами стояла задача снизить поток обращений в поддержку и высвободить ресурсы для новых амбициозных целей: нам предстояло принять в сопровождение несколько новых сервисов без нарушения сроков SLA по нынешним и без увеличения численности инженеров.

Согласно ITIL 4, повторяющиеся инциденты с общей причиной классифицируются как Problems. Но как объединить между собой похожие консультации, заявки на корректировки, заявки на доступ?
Мы адаптировали принципы управления проблемами (Problem Management) и создали внутреннюю сущность «CASE» для систематизации не только инцидентов, но и повторяющихся запросов на обслуживание, доступ и консультаций.

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

Прежде всего, мы обозначили, что точно является кейсом, а что – нет.  Например, совокупность обращений, относящихся к одному массовому инциденту, вызванному ошибкой ^[2] в коде или крупному техническому сбою, отдельным кейсом не считается.

Определили, как именно можно не только «вскрыть», то есть обнаружить и зафиксировать его, но и разрешить сам кейс.
Также определили условия, по которым кейс считаем решенным, и кто может заниматься решением кейсов.

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

От ведения таблицы в Excel мы смогли постепенно отказаться после реализации ряда доработок в itsm системе (о них – чуть ниже).

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

Поиск кейсов

Как найти схожие обращения в скоупе заявок от пользователей?

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

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

Способы поиска кейсов:

1. по отчету о выполнении: например, фильтрация по значению «выполнена корректировка» (изменение настроек в меню администратора сервиса, изменения в БД, справочниках или иное).

2. по ключевым словам, или словосочетаниям (это может быть или название справочника, конкретный e-mail, настройка или иной параметр, по которому можно однозначно отделить этот кейс от всей массы заявок), использование в поиске регулярных выражений.

3. Фильтры по конкретным пользователям – инициаторам заявки.

4. Фильтр по тексту ошибки (не всегда помогал, так как иногда ошибку можно увидеть только на скрине).

5. Фильтр по группе инженеров, решающих те или иные инциденты

В дальнейшем мы планируем делегировать поиск кейсов искусственному интеллекту ^[3].

Техническая реализация

В первоначальном варианте Excel кейс выглядел в виде строки с определенными атрибутами. После добавления в ITSM отдельного, специально выделенного для кейсов пространства, появилась возможность фиксировать кейсы, присваивать им статус, и визуализировать работу с ними.

Для того, чтобы поиск кейсов разными специалистами в одной базе заявок был максимально удобным и прозрачным, а фиксация найденного кейса сразу была заметна всему подразделению, реализовали доработку ITSM.
К имеющимся инструментам мы добавили:

• Новую сущность «Case» с такими атрибутами, как:
  – уникальный номер,
  – краткое описание,
  – статус,
  – список связанных заявок,
  – время, затраченное на обработку всех связанных заявок,
  – информация о решении,
  – ответственный за кейс исполнитель;

• Возможность связать каждую заявку с тем или иным кейсом;
  – форма связи инцидента при редактировании уже созданного кейса выглядит так:

     В строке поиска необходимо ввести номер инцидента, который хотим связать с кейсом.

• Дашборды для визуализации найденных кейсов за последний месяц и за все время для каждого отдела и общий по всем отделам управления.
  – форма добавления нового кейса теперь выглядит так:

Итоговая статистика

В результате удалось сформировать следующие дашборды:

• Топ наиболее «затратных» кейсов. Величину трудозатрат выражали в человеко-часах путем автоматического суммирования затрат на работу с каждым отдельным обращением в поддержку:

• Топ кейсов – лидеров по количеству обращений:

Оба дашборда реализованы как для открытых, так и для уже закрытых кейсов.

Здесь самым удивительным оказалось, что в топе по трудозатратам находились в том числе кейсы, обращения по которым приходят всего раз в месяц.

Начиная с декабря 2025 года привязка к кейсу каждой заявки в поддержку является для нас обязательной.

Так мы смогли:

• типизировать наши обращения;

• визуализировать временные затраты для решения обращений;

• создать потенциал для дальнейшей оптимизации работы поддержки;

• улучшить пользовательский путь.

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

Но пол дела – отыскать и зарегистрировать кейс. Самое главное – решить его.
В качестве решения предполагалось:

• передать часть функциональности ответственным бизнес-пользователям;

• сделать некую доработку, итог которой бы снизил поток обращений в поддержку по данной теме;

• найти корневую причину появления обращений и устранить ее;

• провести дополнительное обучение ^[4], прописать инструкции пользователям или поддержке,

• добавить нужные подсказки на портале самообслуживание и много чего еще.

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

По каким критериям можно было считать кейс решенным?
Количество заявок, относящихся к данному кейсу, должно сократиться более чем на 70% (либо совсем закрыться и не появляться) в течение следующих трех месяцев по сравнению с 3-х месячным средним количеством заявок.

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

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

Эксперт по анализу и систематизации кейсов

Для того, чтобы помочь нам в навигации среди различных способов решения кейсов, а также следить за появлением возможных дублей кейсов и своевременном их закрытии, выделили конкретного ответственного, который отлично разбирался и в нашей внутренней структуре, и в ограничениях (и возможностях) нашего itsm.

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

Это позволило упорядочить сами кейсы, оперативно актуализировать их статус, и главное – существенно увеличить количество закрытых кейсов (и – довольных пользователей, ведь им больше не нужно тратить время на то, чтобы писать нам в поддержку, ожидать решения,
отвечать на дополнительные вопросы и другое). Также в обязанности эксперта входит проверка, действительно тот или иной кейс можно считать решенным, верно ли он оформлен, корректен ли его статус, достаточно ли по нему информации для перевода в статус «решен».

Выводы

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

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

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

Поделюсь результатами, которых мы добились через год после внедрения кейсов в работу с обращениями:

1. Обнаружили и зафиксировали кейсы более чем в 100 наших системах/сервисах.

2. Закрыли около 20 кейсов. Только по одному кейсу за 2,5 месяца и до момента закрытия самого кейса мы успели принять и отработать 252 заявки. Целевое решение данного кейса позволило впоследствии сэкономить нам более 25 часов рабочего времени ежемесячно.

3. Провели серии встреч с пользователями для повышения их уровня владения продуктами.

4. Сформировали шаблоны и обучающие инструкции для передачи части функциональности от поддержки к ответственным пользователям.

5. Отметили лидеров по числу закрытых кейсов, в том числе кейсов наиболее крупных.

Расскажите, как процесс оптимизации входящих заявок в поддержку устроен у вас?