×Закрыть

10 проблем на первой линии поддержки и пути их решения

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

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

Ожидания пользователя обычно можно сформулировать следующим образом: «У меня возникла проблема, я ее озвучил кому-то или куда-то, ее решили немедленно (или время решения стремится к нулю)».

Отсюда сразу же возникает первая проблема организации поддержки:

Удобство доступа пользователя к службе поддержки

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

  • перечень каналов связи с техподдержкой;
  • описание процедуры регистрации пользователя в системе;
  • способы создания заявки;
  • классификация заявок по типам и важности;
  • способы отслеживания статуса заявки;
  • дополнительные возможности (редактирование, добавление вложений, комментариев).

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

Удобство интерфейса

Для того, чтобы не возникали проблемы типа: «пользователь не предоставил всю нужную информацию», «пользователь некорректно заполнил данные по заявке», «пользователь совсем не смог оставить заявку», интерфейс системы должен включать все необходимые специалисту поля, но при этом не запутывать заказчика. Часто серьезным барьером для использования системы является язык интерфейса. Кроме этого, необходимо продумать наличие обязательных полей, снабдить их подсказками, проверкой на корректность ввода. В некоторых системах техподдержки этот инструментарий доступен «из коробки». Нужно только потратить время на грамотное планирование интерфейса и его настройку. Хорошо, когда большинство полей при оформлении заявки пользователь может заполнить путем выбора из списка и для каждого типа заявки есть свой набор полей.

Интерфейс портала Service Desk со стороны пользователя

Поля, заполняемые пользователем при оформлении заявки в техподдержку

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

Быстрое решение проблемы или обратная связь с пользователем

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

Здесь на выручку приходит автоматизация. При оформлении заявки заказчик должен получать, как минимум, письмо о том, что заявка поступила в работу. А также письма при изменении статуса заявки. При желании, он может отказаться от этой рассылки, а может добавить комментарии или вложения к своей заявке. Таким образом, у пользователя не будет ощущения, что его «бросили».

Конечно же кроме писем заказчику, автоматизация должна подразумевать одновременное оповещение операторов первой линии. Задача действительно не должна «повиснуть в воздухе». Для этого в системе должны быть:

  • явно указаны ответственные за прием заявок специалисты;
  • прописан четкий регламент работы с новой заявкой;
  • оговорено время реакции на новую заявку;
  • автоматизированы оповещения ответственным лицам;
  • автоматизировано назначение ответственных за заявку при переводе ее в другой статус;
  • настроена аналитика с явным указанием критических по сроку выполнения заявок.

Настройка автоматических оповещений

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

Теперь рассмотрим ожидания специалиста первой линии.

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

Сбор информации

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

Для решения этой задачи хорошо подходят системы мониторинга или CMDB-системы. Использование такой системы предполагает создание хранилища всей информации об ИТ-среде компании. Это хранилище должно содержать в себе информацию об:

  • рабочих станциях пользователей;
  • используемом ПО, версиях, лицензиях;
  • периферийном оборудовании;
  • серверах;
  • облачных сервисах.

Интеграция CMDB-системы с системой сервис деска будет хорошим решением для повышения эффективности работы первой линии техподдержки.

Примеры CMDB-систем: Nagios, Zabbix, Zenoss, OpenNMS. Рассмотрение этих систем — тема для отдельной статьи.

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

База знаний для специалистов первой линии

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

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

  • Удобство пользования базой знаний: интерфейс должен быть максимально простым, а организационная структура логичной и понятной.
  • Модерация статей перед публикацией: нужно избегать перегруженности базы знаний, а также не допускать появления дубликатов.
  • Контроль версий: должна быть возможность редактировать статьи, вносить актуальные правки.
  • Возможность подачи заявки на необходимые статьи или разделы.

Единая точка входа

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

Каналы поступления заявок

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

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

Эскалирование задачи

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

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

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

Пример workflow для заявки, попавшей на первую линию

SLA и просроченные задачи

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

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

Для этого, как минимум, надо настроить адекватные SLA (Service Level Agreement), создать отчеты для просмотра статистики по выполнению этих SLA. Не лишним будет создание собственного отчета, показывающего, сколько существует просроченных задач и сколько их намечается в ближайшее время.

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

Ожидания владельца бизнеса, как и руководителя ИТ-отдела, состоят в повышении эффективности работы техподдержки, снижении стоимости ИТ-инфраструктуры, а следовательно, здесь очень важными будут возможности анализа.

История инцидентов

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

Однако суть проблемы в том, что кто-то должен заниматься классификацией заявок. Конечно, логичнее всего поручить эту обязанность специалистам первой линии. Чтобы не слишком усложнять процесс принятия заявки, интерфейс системы должен позволять использовать различные шаблоны или метки для разных типов задач. В таких системах обычно есть возможность настраивать различные workflow для каждого типа заявки, что еще больше упростит работу оператора.

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

Прочие возможности анализа

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

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

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

Резюме

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

LinkedIn

13 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Неочевидная истина: таких систем должно быть две. Абсолютно разных. Иначе, даже самая правильно построенная и настроенная — в случае любой поломки (а человеческие системы всегда деградируют, и достаточно быстро) — она не имеет механизма чтобы поломку исправить, а «сломавшихся» людей уволить.

Сколько я этих систем ни встречал, суть у всех одна: сделать иллюзию что все пользователи довольны, и поместить руководство в зону комфорта. Мол, они сделали что могли, по максимуму.

А на самом деле в самой сути задач ВСЕГДА лежит человеческий фактор. И «прекрасно построенный» service-desk ускоряет смерть компании как раковая опухоль, сумевшая поразить систему иммунитета.

Ключевое правило: НЕЛЬЗЯ строить систему обратной связи по той же линии субординации, что и основное руководство. Теоретически, конечно, можно. Точно так же, как теоретически, наркотики улучшают самочувствие и повышают трудоспособность — если не злоупотреблять. Но факты есть факты, и они таковы: вмешательство в систему обратной связи гарантировано формирует неадекватное руководство.

И чем лучше технически и организационно устроена система — тем скорее она убьёт предприятие. Потому что ключевое звено, структуру высшего руководства, как правило не меняет никто. Потому что полномочий на это нет ни у кого. Об этом даже говорить боятся, даже шёпотом. Предпочитая убить компанию, чем собственную карьеру. Собственно, людей понять можно — это адекватное для них поведение.

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

Друзья, подскажите, кто как решает вопрос передачи тикета с первой линии на вторую? Поясню — изначально мы вели поддержку в едином проекте типа SD, и для передачи задачи на разработчика, оператору по поддержке достаточно было перевести задачу в определенный статус и заасайнить на соответвуещего сотрудника, соответсвенно был довольно большой и сложный workflow содержащий часть работы с клиентом и часть работы отдела разработки. Но затем выяснилось, что алчный Атлассиан :) позволяет работать с задачами внутри SD проекта только агентам, каждый из которых стоит денег. Идея с раздельным проектом SD и отдельным проектом для разработки, кажется хорошим решением, если бы не терялась связь между задачами — например разработчик в своем проекте перевел в To test, и у оператора поддержки появилась эта информация в клиентском тикете. Пока так и не придумал как решить этот момент и уже подумываю соскочить на ZenDesk, там с этим проблем быть не должно.

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

Для настройки требуется плагин Jira cli.

пишите в скайп — помогу !

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

Можно использовать любые системы в качестве CMDB , это просто база, всё зависит от полей которые вам необходимо быстро получить, тот же nagios отлично справиться с задачей для небольшой ИТ инфраструктуры на 10-30 серверов

«Любые системы» нужно интегрировать с существующей мониторинговой системой и это нужно делать как можно раньше, иначе стоимость такой интеграции возрастает многократно.

В пустыне встречаются прапорщик и осел. Осел спрашивает:
— Ты кто?
Прапорщик оглядывается по сторонам и отвечает:
— Офицер.
Осел тоже оглядывается по сторонам:
— А я конь!

Примеры CMDB-систем: Nagios, Zabbix, Zenoss, OpenNMS.

вот только среди приведенных примеров систем мониторинга нет ни одной CMDB :-)

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

Основні проблеми першої лінії техпідтримки: це низькі зарплати, висока текучість кадрів, низький технічний рівень. Перше тягне за собою друге, а друге — третє. :) Чим більша компанія, тим більш гостра ця проблема.

Робити когось конкретного з першої лінії відповідальним за заявку погана ідея — особливо коли операторів і заявок багато. А коли оператори працюють в змінному режимі — нереально.
Більш-менш нормально працює callback — після закриття заявки ініціатору приходить повідомлення по ел.пошті або телефонує робот, для підтвердження, що проблема вирішена.
Плюс можна виділити окремо групу клієнтів, для яких гарантований SLA і групу операторів, яка ними буде займатися.

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

Но оно не решает проблему, потому как закрыть можно не решив вопрос )

Якщо ініціатор натиснув на телефоні кнопку, що проблема не вирішена, або на email про закриття хоть щось у відповідь написав, заявка автоматично з закритих знову переходить у відкриті. :)

А время уже потрачено в пустую ) Юзаем мы эту опцию иногда!
Но обычно открываем новый что бы попасть на другого человека, так как это реально быстрее ...

Подписаться на комментарии