Портал №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 не будет опубликован.

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT