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

Как мотивировать пользователей подавать заявки в 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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

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

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT