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

в 11:29, , рубрики: selectel, Блог компании Селектел, рекомендации, селектел, техподдержка, метки: , , ,

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

На приеме у психотерапевта

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


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

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

Ее несомненные плюсы заключаются в следующем:

  • информация по каждому тикету оперативно передается между инженерами, что позволяет всему отделу техподдержки быть в курсе проблем клиента;
  • сохраняется история всех сообщений по конкретному вопросу, и потеря сообщений исключена;
  • к сообщениям можно прикреплять графические файлы в форматах 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%logscbscbs.log.

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

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

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

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

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

Автор: AndreiYemelianov

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js