Service Desk редко воспринимают как что-то героическое. Обычно о нём вспоминают тогда, когда что-то перестало работать, нужно получить доступ к системе или просто непонятно, куда отправить запрос.

Но в большом банке Service Desk — это не просто форма для создания заявок. Это единая точка входа для сотрудников, механизм маршрутизации задач и источник данных для анализа работы поддержки.

Сегодня наша система обрабатывает в среднем 3,5 тысячи обращений в месяц, из которых 550-600 задач приходится непосредственно на команду Service Desk.

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

Что такое Service Desk Portal

Если упростить, Service Desk Portal — это единая точка входа для внутренних пользователей, через которую они могут сообщить о проблеме или создать запрос.

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

Дальше Service Desk помогает определить:

• тип и категорию обращения;

• последовательность его обработки;

• ответственного исполнителя;

• необходимые действия на каждом этапе;

• сроки обработки.

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

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

От простого портала к полноценной системе

Когда Service Desk Portal запускался в Своем Банке, довольно быстро стало понятно, что все задачи необходимо разделить как минимум на два больших направления: обращения клиентов и внутренние запросы сотрудников.

Дальше структура начала усложняться: внутри каждого направления появились категории, подкатегории и отдельные сценарии обработки.

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

Именно здесь проявляется одно из главных преимуществ Service Desk: пользователь взаимодействует не со структурой компании, а с понятным ему процессом.

Ему не нужно знать, кто такой L1, L2 или L3, какая команда отвечает за конкретный сервис и кому написать в мессенджер. Он просто создаёт обращение через портал.

Проблема №1. Слишком много заявок

На старте команда поддержки столкнулась с достаточно очевидной проблемой: обращений было много, а ресурсов команды не хватало, чтобы оперативно обрабатывать весь поток.

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

Поэтому следующим шагом стало создание матрицы ответственности.

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

На практике это позволило перейти от модели:

«Создали заявку — дальше кто-нибудь разберется»

к модели:

«Создали заявку — система понимает, кому и куда её необходимо направить».

Проблема №2. Неправильная классификация

Следующей проблемой стала классификация обращений.

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

Это создавало сразу несколько проблем:

• разработчики получали задачи, которыми заниматься не должны;

• увеличивалось время обработки;

• поддержка теряла часть обращений, которые могла решить самостоятельно;

• статистика по подразделениям становилась менее объективной.

Мы решили проблему сразу с двух сторон.

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

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

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

Результаты не заставили себя ждать: если в 2024 году мы зафиксировали 400 ошибочных маршрутизаций, то в 2025 году их число снизилось до 202, а к 2026 году упало до 94 случаев.

Данные помогают улучшать процесс

После накопления статистики стало значительно проще понимать, где именно находятся узкие места.

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

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

В этом, на мой взгляд, одно из главных преимуществ Service Desk: он позволяет принимать решения не только на основе субъективного ощущения «заявок стало много», а на основе конкретных данных.

Проблема №3. Формы тоже требуют настройки

Сам по себе Service Desk не решает проблему плохого процесса.

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

Поэтому мы постепенно перерабатывали формы и автоматизации:

• упростили создание обращений и структурировали интерфейс;

• заменили часть текстовых полей на выпадающие списки и настроили автозаполнение;

• усовершенствовали маршрутизацию, сократив количество ручных действий.

В результате время первой реакции на заявку сократилось в разы: с ~40–50 минут до ~3–5 минут. Пользователь тратит меньше времени на создание обращения, а сотрудник поддержки — на уточнение базовой информации. В масштабе банку это дает колоссальную экономию ресурсов.

Почему Service Desk полезен руководителю

Для меня как руководителя поддержки Service Desk важен ещё и из-за прозрачности работы команды.

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

Мы отслеживаем ключевые метрики:

• скорость взятия задачи в работу и время решения;

• количество обработанных и просроченных задач;

• распределение нагрузки и удовлетворенность пользователей.

Системный подход к аналитике дал отличный эффект: за 1,5 года доля просроченных задач сократилась с ~40% до комфортных ~3–5%.

При этом сами метрики нужны не только для контроля сотрудников. Если показатель систематически проседает, это повод разобраться в причине.

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

Метрики помогают ответить не на вопрос:

«Кто работает хуже?»,

а на гораздо более полезный —

«Почему процесс работает именно так?».

Что в итоге

За время работы с Service Desk мы пришли к довольно простой модели: портал должен быть удобным для пользователя, понятным для поддержки и полезным для руководителя.

• Для пользователя — это единая точка входа, где не нужно искать нужного человека.

• Для поддержки — понятный поток обращений с заранее определенной маршрутизацией.

• Для руководителя — данные, на основании которых можно находить узкие места и улучшать процессы.

И здесь Service Desk действительно начинает напоминать того самого супергероя из вступления. Только вместо плаща у него отлаженные сценарии, вместо паутины — автоматизации, а вместо суперсилы — правильно настроенный процесс.

Но есть важный нюанс: Service Desk сам по себе ничего не улучшает. Он лишь делает процессы видимыми и управляемыми.

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

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