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

Как мотивировать пользователей подавать заявки в Service Desk через портал?

Опубликовано 17 июля 2017
Рубрики: Service Desk, Вопрос из зала, Обо всём на свете
Комментарии

В редакцию портала поступил вопрос:

Приветствую, коллеги! Возникла следующая дилемма.

Есть три способа подачи заявок в ServiceDesk:

  1. Веб-портал (где пользователь сам выбирает сервис ИТ).
  2. Письмо по электронной почте (тогда все заявки сваливаются на первую линию и их категорирует один из сотрудников первой линии).
  3. По телефону (только в случае невозможности первых двух способов.

Самый эффективный способ с точки зрения руководителя ServiceDesk — первый. В этом случае, во-первых, значительная работа по категоризации заявки проводится самим пользователем (он сам выбирает тип заявки (инцидент, ЗНО, ЗНИ) и сервис ИТ). Во-вторых, по некоторым сервисам (которые первая линия всегда эскалирует на вторые) заявка сразу попадает на вторые линии, специалисты которых выставляют лишь срочность и влияние. В случае с заявкой по электронной почте, сначала она попадает в пул новых, если за 15 минут ее никто не возьмет (а это происходит в 90% случаев), то она назначается на одного из сотрудников первой линии. После чего еще в среднем 15 минут он ее категорирует. То есть в среднем заявка с портала решается на полчаса быстрее по вышеназванным причинам.

Отсюда задача мотивировать пользователей делать заявку с портала, а не по почте. Один из вариантов мотивации — объяснять, что с портала заявка быстрее решается (на 5 минут дольше формировать заявку самим пользователем, зато на полчаса быстрее решение).

Вопросы в следующем:

  1. Как это соотносится с методологиями ITIL?
  2. Целесообразно ли регулировать это на уровне SLA? Мол, заявка с портала идет по одним SLA (более жестким). С одной стороны, вроде как это криво: пользователей не должно волновать откуда заявка, IT служба должна максимально быстро ее решать. С другой стороны, объективно выходит, что заявка с Портала решается быстрее за счет небольшой (не больше 5 минут) допнагрузки на пользователя, небольшой (1 минута) нагрузки на вторую линию (приоретизация), и существенного ускорения (полчаса) прохода первой линии.

Коллеги, Ваше мнение?

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

Также по теме:

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

  • Владимир

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

    С пользователям проводите разъяснительную работу по оптимальному использованию портала. 

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

    • Антон Герасимов

      Владимир, спасибо за ответ! Несколько моментов по правилам маршрутизации.

      Конечно, нужно стремиться, чтобы как можно больше писем автоматически отправлялись на нужные линии. Но процент автоматически правильно переправленных пришедших по почте писем зависит не только от алгоритмов парсинга (что на нашей стороне), но и от того, как пользователи пишут письма (а на это мы воздействуем лишь косвенно). В общем случае по содержанию письма только человек может понять (да и то не всегда) как эту заявку категоризировать. Чтобы улучшить этот процент, придется все равно работать с пользователями, рассказывать им, как стараться формировать тело письма. Не лучше ли вместо того, чтобы рассказывать пользователям (и запутывать их), о том, что сначала нужно написать сервис, систему и прочее, просто отправить их на портал?  Мне кажется политика "если хотите ускорить время жизни заявки – формируйте ее через портал", а если хотите как можно быстрее создать заявку, при этом увеличив время ее жизни в среднем на полчаса – то используйте почту.

      Про шаблоны. А в каком виде их лучше делать? Мы делаем в виде гиперссылок на рабочий стол. Например "Заявка по сервисам бухгатерии" – при клике на ссылку пользователь сразу попадает в окно создания заявки в соотвествующий сервис на портале.

      И все-таки, как это согласуется с ITIL? И целесообразно ли управлять этим через SLA?

  • Сергей

    Очень интересный вопрос и для меня (нашей компании).

    С удовольствием почитаю мнение экспертов как это сделать.

  • Artem Beresnev

    Artem Beresnev

    Не принимать их иначе, кроме случаев, когда портал лежит 🙂 шутка конечно.

    • АнтонБоганов

      И вовсе не шутка! Вполне рабочий вариант

  • alex

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

    На портал заходит 50%. 10 пишут по почте если у них просто ЗНО или ЗНИ

    40% звонят, это инциденты, но я быстро во время разговора регистриую инцидент.

    Главное чтобы CMDB и пользователи были заведены.

    У меня ManageEngine SDP

    • Антон Герасимов

      alex, спасибо за ответ! Не очень понятно как CMDB помогает в мотивации о портале…

  • Илья

    Добрый день, коллеги!

    В сове время, когда внедрял ITSM в Компании, изначально выбрали для себя два свопособа подачи заявки: портал, телефон (в случае если через портал нет физической возможности) и закрепили это приказом генерального директора (чтобы тех. поддержки было на что ссылаться). Считаю, что если есть возможность не пользоваться порталом, люди им пользоваться не будут т.к. для того чтобы на портале создать запрос необходимо самому пользователю подумать и выбрать необходимую категорию и тут уже нельзя будет написать "у меня все не работает".

    По поводу шаблонов, в сове время, я оставлял категорию "Другое" и при ежемесячном аналази создавал новые категории + по максимому предзаполненные поля.

  • Даниил

    Добрый день!

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

  • Василий С.

    В нашей компании изначально предоставили пользователям лишь 2 способа обращения: портал (веб-форма подачи заявки с каталогом доступных пользователю услуг. Там, где требуется сделаны шаблоны с подсказками о том, что требуется заполнить, например, в случае запросов на предоставление доступа в системы) и телефон (при отсутствии возможности зайти на портал). Этого вполне достаточно, на мой взгляд. Поэтому, возможно, отказ от приема заявок по почте – это выход? Нужно только заручиться поддержкой высшего руководства в этом вопросе.

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

  • Сергей

    Нет тут универсального рецепта к сожалению… Если пользователей 50-100, то ещё не так страшно, тут можно поработать над "воспитанием" пользователей в ключе "если срочно и не работает – то звони, если не срочно и нужна консультация, то иди на портал". А если число пользователей превышает десятки/сотни тысяч (как например в моей организации ~250к.) то тут ничего не поделаешь. Нравится кому-то звонить и сообщать (кричать, жаловаться, ругаться, изливать душу) о проблемах на ПК и они будут это делать не смотря ни на что. А кому-то наоборот – проще написать на портал и не общаться операторами колл-центра. 

    Стремясь максимально упростить (с точки зрения пользователя) подачу заявки в ИТ-службу, мы провели большую работу по категоризации рабочих мест – выделили перечень VIP рабочих мест, оперативных (ОРМ), важных (ВРМ) и всех остальных. На VIP, ОРМ и ВРМ реализовали функционал "одной кнопки", по нажатия на которую пользователь видел всплывающее окно с выбором проблемы (техническая проблема, и небольшой список технологических проблем (уникально настраиваемый)) и выбирал соответствующий пункт. При этом определённым образом промаркированная заявка улетала сразу в заранее определённую группу поддержки, а те уже реагировали максимально оперативно.

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

    Кроме того, были максимально упрощены шаблоны на портале регистрации заявок. Все формулировки портала переписали языком пользователя на основе ТОПа формулировок запросов за прошлые годы.

  • Артём

    Я считаю, что при достаточно большом количестве сотрудников, их перевоспитание, это прежде всего, наличие корпоративной культуры, во-первых, а во-вторых, любой способ хорош, если пользователь видит, что его обращение\инцидент решается в разы быстрее, чем это было до этого. Тут возымеет большой эффект наличие, так называемого, сарафанного радио. Например, мы вводим как способ связи с сотрудниками: бота(обучаемого, как с помощью человека, так и спомощью машинного обучения, пусть даже на начальном этапе, как показывает практика 3000+ правил это уже достаточно грамотный бот) с возможностью переключения на онлайн консультанта по требованию. Что это дает, во-первых снимает половину легких запросов с первой линии, поступающих по неголосовому каналу, и дает возможность сотрудникам первой линии иметь больше времени. на решение более сложных обращений, а наличие онлайн консультанта даст, так необходимое в наше время, возможность поговорить с живым человеком в режиме реального времени, пусть и неголосовым каналом, а также получить ответ на несколько вопросов, возникших во время диалога, вместо одного. Вот мы и уровень удовлетворенности подняли, с одной стороны, а с другой максималньо уменьшили время решения простых запросов.

  • ДМБ

    Антон,

    Считаю что абсолютно корректно если вы отразите это в SLA. Безусловно это может вызвать вопросы – но у вас четкие, понятные аргументы – и это позволит говорить на одном языке с бизнесом – языком издержек.

    Кроме этого, можно подумать над дополнительными фишками. Например, на портале пользователь может дополнительно сразу указать важность тикета, а те что с почты – всегда идут как средневажные.

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

    Важно понять стратегически – прием с почты – это очень удобно для пользователя, слишком удобно. Вы готовы за это платить? Если да – купите еще спецов на 1 линию и тогда не снижайте SLA и будет у вас супер сервис. 

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.