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

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

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

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

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

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

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

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

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

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

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

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

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