Что такое система тикетов

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

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

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

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

Довольно часто приходится сталкиваться с описаниями такого рода:

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

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

Хорошее описание должно быть составлено по-другому. Например, так:

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

На выделенном сервере csXXXX подозревается неисправность жесткого диска. Данные SMART-таблицы: (. )

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

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

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

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

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

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

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

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

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

Источник

Тикет-системы: как бесплатная OTRS три платных уделала?

Бесплатный софт для бизнеса — спорная история. Компания, которая выбирает такое ПО, должна понимать, что либо ей придётся столкнуться с open source и искать разработчика на поддержку программы, либо принять бесплатную версию программы как есть, без надежды на поддержку, доработку и обучение. Так себе перспектива. Но это с позиций околоайтишного обывателя, который слова «open source» и «вендорское внедрение» выучил, а глубоко не погружался. А мы вот взяли и решили растолковать всё на примере одного популярного ПО, которое может пригодиться и большим, и маленьким компаниям. Давайте разбираться вместе.

Морали не будет, а вот выбор есть

Всё начинается с тикета

Всё началось недавно. Мы в RUVDS внедрили маркетплейс — платформу, на которой можно найти предварительно сконфигурированные приложения и решения, чтобы начать работу с необходимыми программами на виртуальных серверах в один клик. Первым запустили OTRS Community Edition — тикет-систему с открытым исходным кодом, основанную на системе OTRS.

Знаете, почему? Потому что она нужна абсолютно всем. Ну в смысле тикет-система, а какая — дело вкуса, бизнес-требований и выбора.

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

▍Необходимость использования тикет-системы по мере развития бизнеса

Если фирма небольшая и поддержку осуществляют 1 — 2 сотрудника, то особой необходимости в тикет-системе нет. Они могут просто отвечать на email, в соцсетях и на телефонные звонки. Когда объем заявок растет, то необходимо большее число сотрудников поддержки и здесь возникает ряд проблем.

Перейдём к сравнению

▍Участники

Мы решили рассмотреть несколько тикет-систем международного уровня.

▍OTRS и его «команда»

OTRS — самая строгая, функциональная, лаконичная и деловая из перечисленных: минимум «примочек», максимум пользы. OTRS Community Edition — тикет система с открытым исходным кодом, основанная на системе OTRS. Это значит, что вы сможете дорабатывать систему так, как вам нужно (ну или заказывать доработку). Первый релиз состоялся 18 лет назад, система стабильна, проверена временем, используется многими крупными и не очень фирмами. Ещё у OTRS есть важное преимущество — развитое международное коммьюнити, готовое помочь, подсказать, дать сотню ссылок на GitHub и, в случае необходимости, поработать с конфигурацией за плату. Все мы знаем, насколько важно коммьюнити для такого ПО и наличие большого сообщества уже многое говорит о самой системе.

Как мы уже говорили выше, Zendesk, Freshdesk, Kayako — это системы, похожие между собой. Они работают по модели SaaS (Software as Service), то есть необходимо оплачивать подписку за каждого сотрудника ежемесячно.Так как системы сильно похожи, то мы не будем вдаваться в детали (для каждого бизнеса они очень разные и обусловлены текущими бизнес-процессами) и рассмотрим 2 варианта:

▍Стоимость

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

Самое интересное начинается при увеличении числа сотрудников: например, если за год число сотрудников поддержки удвоилось и стало не 5, а 10. Тогда у всех тикет-систем стоимость возрастет в 2 раза. У всех, кроме OTRS CE. В случае OTRS CE вы по прежнему платите 20$ / месяц — за свою виртуалку. По нашему опыту такая конфигурация эффективно обслуживает несколько десятков сотрудников поддержки при большом объеме заявок.

▍Простота установки и обслуживания

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

В случае OTRS требуются базовые знания работы с Linux. На официальном сайте поставляется установочный пакет для CentOS. Необходимо установить базу данных и этот пакет. Далее настройка производится через веб интерфейс. Если в фирме есть сотрудник, обладающий навыками администрирования Linux, то установка и настройка не должна вызвать сложностей и занимает пару часов. Чтобы упростить данную задачу в RUVDS подготовили образ с установленной OTRS и необходимым ПО для его работы. После создания образа пользователю просто нужно зайти в веб-интерфейс мастера установки и указать необходимые параметры. Данный образ позволяет сократить время установки и даёт возможность как можно быстрее попробовать, насколько данный продукт подходит для нужд вашей компании.

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

▍Что по функциям?

В тикет-системе OTRS сть учёт клиентов, собственно ведение тикетов, календарь, отчётность, дашборд, панель администратора. Тикеты имеют скромный интерфейс, но в них есть всё, что необходимо: тело тикета, приоритет в очереди, статус, функции делегирования и эскалации и т.д. Есть шаблоны, подсказки, чат. Кроме того, напомним, что это открытый код и вы можете допились себе всё, что нужно для вашего экземпляра OTRS (разово заплатив программисту Perl).

Zendesk

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

Freshdesk

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

Kayako

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

Итак, подведём черту. Чем хороша тикет-система OTRS, доступная по лицензии GPL v.3? Её можно самостоятельно доработать, она простая и надёжная как автомат, вам не нужно платить за лицензии (даже при масштабировании!), у неё нет ограничений по количеству тикетов и операторов (как на стандартных SaaS-тарифах), при этом она ничем не уступает аналогичным «тарифицируемым» системам по базовым функциям и безопасности. Ну а мы упростили обращение с ней, создав образ в маркетплейсе RUVDS. Новый год — новый сервис, предлагаем вам не откладывать. Мы-то знаем — ваши конкуренты не дремлют 🙂

Источник

5 правил работы с тикетами

1. Правило «один на один»

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

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

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

В один всегда продает другому свое видение вопроса.

2. Закройте его!

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

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

3. Не закрывайте его!

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

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

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

4. Тсс….Не шумите!

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

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

5. Говорите громче

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

Формула тикета такова: «Вот что мы имеем, а вот что мы должны иметь». Вы как бы передвигаете проект из точки, А в точку Б: пошло не так в точке, А, и для всех нас было бы лучше оказаться в точке Б. Очевидно, что ваша задача — нарисовать эту линию из точки, А в точку Б.

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

Каждый раз, создавая тикет, чувствуйте себя художником — рисуйте четкую линию из точки А в точку Б.

Источник

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

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

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

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

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

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

Особо следует отметить, что быстрое решение проблемы во многом зависит от того, как составлен тикет. На какие моменты при составлении тикета следует обратить особое внимание?

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

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

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

Довольно часто приходится сталкиваться с описаниями такого рода:

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

Хорошее описание должно быть составлено по-другому. Например, так:

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

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

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

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

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

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

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

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

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

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

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

Источник

Тикет-система для техподдержки

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

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

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

Пользователь может обратиться в тех поддержку в свободной форме и сообщить о проблеме буквально в двух словах: «не работает…»;

Почта почти всегда у всех открыта, тех поддержка видит обращение и может быстро отреагировать;

Пользователю не надо никуда идти или дозваниваться до специалиста.

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

При большом потоке обращений, письмо может затеряться;

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

Руководителю ИТ будет крайне затруднительно проконтролировать работу ИТ-подразделения, ведь придется потратить уйму рабочего времени, чтобы найти историю по запросу.

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

Cистема тикетов для техподдержки

Одним из главных достоинств тикет-системы является систематизация запросов. То есть, с помощью тикет-системы:

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

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

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

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

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

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

Источник