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

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

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

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

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

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

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

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

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

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

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

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

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

Что еще почитать по теме

T-Rex 30 марта 2021

Что такое SMTP-протокол и как он устроен?

SMTP (Simple Mail Transfer Protocol) — протокол передачи почты. Он был представлен еще в 1982 году, но не теряет актуальности до сих пор. В статье разбираемся, какие задачи решает протокол и как он ра…
T-Rex 30 марта 2021
Владимир Туров 1 сентября 2020

Дело совершенно секретного iPod

Это был обычный серый день в конце 2005 года. Я сидел на рабочем месте и писал код для следующей версии iPod. Вдруг без стука ворвался директор ПО для iPod, начальник моего начальника, и закрыл дверь.
Владимир Туров 1 сентября 2020
T-Rex 21 августа 2020

TrendForce: цены на SSD упадут

Эксперты DRAMeXchange предсказывают значительное падение цен на оперативную память и твердотельные накопители в ближайшее время. Причина — сокращение спроса на чипы для NAND и DRAM.
T-Rex 21 августа 2020

Новое в блоге

Сравнение способов организации мультиклауд-решений

Рассказываем о типах мультиклауд-решений и схемах подключения к зарубежным облакам

Готовые кластеры Kubernetes: легкий старт, автоматизация и другие преимущества перед self-hosted

Рассказываем, чем отличается Managed Kubernetes от самостоятельного развертывания инфраструктуры. Объясняем, кому подойдет решение.
T-Rex 18 мая 2022

Что такое терминальный сервер и зачем он нужен

Разбираемся, что такое терминальный сервер, чем он похож на VDI и как подобрать сервер под роль терминала.
T-Rex 18 мая 2022