Портал №1 по управлению цифровыми
и информационными технологиями

Самостоятельная классификация обращений

Ситуация:

1. Очень большая доля обращений (порядка 60%) относится к  вопросам, касающихся функционирования специфических ИТ-систем.

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

3. Порядка 70% обращений поступает через портал и e-mail, остальное –  по телефону.

4. Очень небольшое количество человек на первой линии, и нет возможности добавить персонал (в том числе и за счёт организации распределённой первой линии со специализацией сотрудников).

5. Пользователи «натренированы» не звонить, а обращаться через портал или e-mail, более-менее грамотно описывать симптомы и прикладывать скриншоты :).

Решение:

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

Что скажете? :)

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

Комментариев: 10

  • Ilinskiy Andrey

    Очень знакомая ситуация. Но, на мой взгляд, все же не стоит сразу назначать запросы на вторую линию, а давать все же первой проверить, что пользователь не ошибся с классификацией, тем самым не привлекать L2 попусту. Так сказать “фаерволить”.

  • Вадим

    пацаны не против

  • По наиболее срочным обращениям пользователи скорее всего будут звонить, а не e-mail’ы слать. И именно по наиболее срочным обращениям, где более всего нужна оперативная помощь, они будут попадать на некомпетентную первую линию. Это основная проблема такой схемы. Риски:

    1. Обращения по наиболее срочным вопросам будут обрабатываться минуя первую линию и вероятно минуя процесс.
    2. Неудовлетворительное качество поддержки по наиболее срочным вопросам (именно там, где оперативная поддержка нужна больше всего).

    Зачем пользователям такой сервис деск? Зачем второй линии такой сервис деск?

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

  • Андрей Шилов

    Прямо сейчас то же самое обсуждаем. Действительно, в универсальном решении не хватает “другой” стороны – приоритет на FLR для критичных для бизнеса услуг (клиент стоит), проброс звонков на специализированные группы с высокой компетенцией в конкретной области. В остальном решение – то же. Портал должен обеспечивать полноту первоначального оформления заявки, не везде пользователи натренированные. Файрвол на первой линии – скорее нет.

    • “Файрвол на первой линии — скорее нет.”

      Это, конечно, вообще “мега-идея”. Еще бы пароли предложили ввести для обращения на первую линию. Всё для людей…

      • Дима, Андрей(Ш), если я верно понял Андрея(И), речь – о том, что первая линия работает как шлюз и фильтр, отсекая и корректируя обращения пользователей и повышая качество информации, поступающей на L2 и точность адресации (Андрей(И), так?).
        При этом доступ к самой L1 – максимально открытый и удобный, конечно, и все действительно для людей, без иронии.

        • А-а, в этом смысле. Ну я наверно слишком прямо воспринял глагол “фаерволить”. Наверно тогда больше подошёл бы глагол “помогать” 🙂

        • Андрей Шилов

          Здесь все от заявленных Михаилом целей и контекста танцует (сходных с моими). Ресурсы линий поддержки ограничены, потенциал повышения грамотности оформления обращений пользователями не исчерпан, повышать скорость и качество обслуживания – по-прежнему требуется. Появляется “тяга” увеличивать типизацию решений и автоматическое назначение, уводить ресурсы поддержки на быстрое обслуживание “точно попадающих” обращений и стимулировать пользователей так работать. Реально сейчас десятки процентов обращений вручную проверяются на полноту заполнения и возвращаются на уточнение. А так – написал пользователь верно название отказавшей системы, приложил снимок и указал свой логин – обслужили за 3 часа. Не указал – ждешь 2 дня… Естественно (чтобы вы меня сразу кирпичами не закидали), пользователя при обращении прямо из монитора хватают за руку и большими красными буками просят – заполни все, что надо, и будет тебе счастье. Фактор обеспечения возможности изменений, о котором рассказал Роман на последнем курсе, чуть ли не каждый день в голову возвращается. Полезный материал оказался.

  • Вадим Куприн

    Такие решения на практике существуют не первый год и при указанных условиях доказали свою полезность. Особенно при имеющихся ограниченных возможностях первой линии. Полезно будет также классификацию осуществлять на языке более понятном конечному пользователю (осуществлять перевод с человеческого языка на термины системы учёта). При такой системе регистрации обращений, всё равно будут такие, которые будут уходить “мимо”, но с другой стороны и первая линия ошибается. И поработав с системой классификации на портале (на языке пользователей) можно свести промахи к объему меньшему 1/10 поступающих обращений. Что при наличии большого потока обращений уже очень хорошо. Ошибочные можно возвращать на первую линию для правильной маршрутизации. Проводя переодически анализ ошибочно назначенных, можно “допиливать” систему классификации на портале, увеличивая процент попаданий. 🙂

  • Ilya Kuzin

    скажу только одно – позволить… работает ведь.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM