company_banner

Советы по работе с тикет-системой

  • Tutorial
Советы по работе с тикет-системой

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

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

Ее несомненные плюсы заключаются в следующем:
  • информация по каждому тикету оперативно передается между инженерами, что позволяет всему отделу техподдержки быть в курсе проблем клиента;
  • сохраняется история всех сообщений по конкретному вопросу, и потеря сообщений исключена;
  • к сообщениям можно прикреплять графические файлы в форматах png, gif, jpg, а также файлы в формате pdf;
  • клиенты могут сами оценивать работу персонала службы техподдержки;
  • оперативность ответа гарантируется нашей компанией.

Наши саппорт-инженеры каждый день имеют дело с десятками тикетов. И быстрое решение проблемы во многом зависит от того, как эти тикеты составлены. На какие моменты при составлении тикета следует обратить особое внимание?

Первое, что видят инженеры службы технической поддержки — это заголовок тикета. Он должен быть кратким, емким и максимально отражать суть описываемой проблемы. Если в тикете речь идет о неисправностях сервера, то в заголовке желательно указать его номер.
Приведем примеры корректных и некорректных заголовков:
Некорректно Корректно
ПРОБЛЕМЫ С СЕРВЕРОМ!!!! Проблемы с сетевой доступностью у сервера csXXXX
Краткие и точные заголовки впоследствии помогут и вам лучше ориентироваться в собственных тикетах и находить среди них нужный.

Чем точнее, подробнее и логичнее описана проблема, тем быстрее смогут ее решить наши специалисты. Желательно, чтобы описание было подкреплено конкретными примерами. Если вы, например, пишете о проблемах с сетевой доступностью, то прилагайте к тикету ответы на ping-запросы и данные трассировки (они могут быть получены с помощью как стандартных утилит traceroute/tracert, так и более специализированной утилиты MTR).

Довольно часто приходится сталкиваться с описаниями такого рода:
Добрый вечер.
У меня опять сервер не работает. Что случилось?

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

Хорошее описание должно быть составлено по-другому. Например, так:
Доброе утро,
Вчера я поменял на облачном сервере IP-адрес c (....) на (...). Проверил все настройки несколько раз — вроде бы все верно, но новый адрес почему-то не работает.
(К описанию прилагаются также результаты ping-запроса).

Если вы подозреваете наличие проблем c жестким диском, также постарайтесь представить детальное описание проблемы. Иногда к нашим саппорт-инженерам поступают заявления вроде:
У меня сдох жесткий диск.

Такой запрос вряд ли можно назвать ясным: совершенно не понятно, на каком основании сделан вывод о “смерти” жесткого диска. Заявления подобного рода лучше подкреплять примерами:
На выделенном сервере csXXXX подозревается неисправность жесткого диска. Данные SMART-таблицы: (....)

SMART (self-monitoring, analysis and reporting technology) — это технология, позволяющая оценить состояние жесткого диска с помощью внутренней аппаратуры самодиагностики, а также спрогнозировать время его выхода из строя. Более подробно о S.M.A.R.T.-таблицах и и их интерпретации можно прочитать, например, здесь (на русском языке), а также здесь (на английском языке).

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

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

Все действия, которые производятся с сервером (в том числе внезапные перезагрузки и другие непредвиденные моменты) находят отражение в системных журналах. Выдержки из системных журналов также можно (а в некоторых случаях — даже необходимо) прикладывать к тикетам. Даже если вы не можете расшифровать системные логи, наши специалисты обязательно помогут и дадут конкретные рекомендации по решению проблемы. В Linux-системах журналы обычно хранятся в каталоге /var/log, в Windows — в каталоге %windir%\logs\cbs\cbs.log.

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

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

Еще одно важное правило формулируется так: одна проблема — один тикет. Создавайте отдельный тикет для каждой из возникших у вас неисправностей — это поможет лучше скоординировать работы саппорт инженеров и ускорить рассмотрение проблемы. Кроме того, следование этому правилу также поможет вам быстрее осуществлять поиск по тикетам.

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

Закрывать тикет нужно только тогда, когда проблема окончательно решена. Даже если вы ничего не написали, закрытие тикета для инженеров технической поддержки является сигналом, сообщающим о том, что вас больше ничего не беспокоит.
Selectel
150,97
ИТ-инфраструктура для бизнеса
Поделиться публикацией

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

    +4
    К сожалению, написание такетов по подобным правилам требует определенной дисциплины ума, понимания работы службы ИТ и уважения к этой работе. То есть — быть ИТшником. Обычно же практикуется более расслабленный вариант заявок — «СДЕЛАЙТЕ МНЕ ХОРОШО!». По опыту, переход из второго состояния в первое происходит через несколько лет полоскания мозга.

    Так что, время работает на вас! Удачи!
      +1
      К сожалению, соглашусь.
      Из собственных лет работы в саппорте — пишут/звонят либо
      а) редко — технически подкованные клиенты, кто уже почти знает или почти локализовали причину проблемы, с пратически полной диагностикой и L1 саппорт либо решает либо эскалирует выше
      б) злые как черт, матерящиеся клиенты, у которых всё не работает, сапорт и компания козлы и «сделайте хорошо и немедленно, а то засужу». — из лично моей статистики чаще всего, к сожалению, чем дешевле тариф, тем больше звонков и мозгополоскания, особенно при попытках запустить что-то толстое вроде (украденного) битрикса на тарифе из минимальной линейки атомов с маленькой базой и зарезанными iops'ами
        0
        Я с большим сарказмом высказался в прошлом комментарии. Если говорить серьёзно, техподдержка по ITIL с системой тикетов — это необходимое минимальное зло при больших масштабах поддерживаемой системы. Своего рода конвейер, который хорош только для владельца — потому как массово и дёшево. Работа на конвейере — тупая, мало влияющая на конечный результат. И то, что выходит с конвейера — лишенное индивидуальности и для нетребовательного потребителя. Зато ДЁШЕВО!

        И убеждать пользователей, что тикетная система — большой плюс для них, столкнётся с простым пониманием — «На нас экономят!». А они не хотят, чтобы на них ещё и на этом экономили, потому и не напрягают мозг, когда пишут заявки. Со временем привыкают — техподдержка не столь формально отрабатывает запросы, а пользователи дают подробности в тикетах. Время лечит…
          0
          В большинстве компаний, где я работал — по телефону выполнялись исключительно справочно-консультативные функции, вроде «скажите, а как настроить такую-то фигню?» При просьбе «а сделайте, пожалуйста, сами, а то я не понимаю/не умею/не хочу» — Либо в режиме поддержки по телефону клиент проводится по админке пошагово, либо отказ вроде
          «Простите, но без письма с контактной почты, закреплённой за аккаунтом, техподдержка не имеет права вмешиваться в работу клиентского сервиса», будь то сайт, сервер, или, тем более, параметры аккаунта.

          Исключения — юр. лица, где может пройти контактная смена эл. почты для аккаунта, по письменному обращению с печатью компании, например в случае увольнения администратора — попытки увести сайт/фтп/хостинг/домен компании «х» далеко не единичны, минимум раз в месяц 2-3 случая.
      0
      Из самых частых тем в тикетах у нас это «Здравствуйте» и «Проблема».
      Очень оригинально когда их штук несколько с одной темой от разных людей.
      Напоминает курсы английского и enlargment в почтовых ящиках десяток лет назад.
        +1
        второй вариант обычно капсом и с орфографическими ошибками уровня младшей школы.
        0
        Есть маленькое пожелание по тикетнице Селектела: когда проблема решена, и тикет в принципе можно закрыть, но при этом очень хочется поблагодарить ребят за работу простым «Спасибо», то нельзя сделать это за одно действие. Когда отправляешь ответ со «спасибо», тикет снова как бы блокируется на сотрудников Селектела, и закрыть его уже нельзя (кнопка пропадает). Через некоторое время либо сотрудники сами «отпускают» тикет, и кнопка «закрыть» появляется, либо пишут ответ с «пожалуйста», и кнопка тоже появляется. Вот только к этому моменту клиент уже может давно закрыть тикетницу…

        p.s. у ребят в дц Селектела на ул. Берзарина видел висящий на стене монитор, куда выводятся тикеты — смотрится впечатляюще.
          +1
          Разрешение заявки — лучшая благодарность, не стоит забивать мусором багтрекер и создавать людям дополнительный головняк.
            0
            Такое поведение реализовано специально, это не баг. Зачастую клиенты ошибочно полагают, что кнопка «Закрыть» просто закрывает диалог. Случалось, что клиент писал что-то очень важное и срочное в тикет и закрывал его, а через несколько дней гневался в этот же тикет на долгое решение проблемы.
            Сказать «спасибо» выможете оценив любой комментарий в тикете. Все оценки анализируются и используются для улучшения работы поддержки.
            +1
            Любого начинающего линуксоида, после пары-тройки вопросов обязательно ткнут носом в руководство Эрика Реймонда «Как правильно задавать вопросы». И правильно сделают. После прочтения появляется навык правильного анализа проблемы. И часто надобность задавать вопросы тоже отпадает :)

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

            Самое читаемое