что такое тикет на сайте

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Тикет-система: что это, возможности, интерфейс и как работать в ней

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

Содержание

Что такое тикет-системы

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

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

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

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

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

Система тикетов для сайта

Примерно 20−25 лет назад, когда не было соцсетей и мессенджеров, а электронная почта была платной, существовали только системы тикетов для сайта. Всё что они позволяли сделать — разместить базу знаний и через форму обратной связи на сайте принять запрос от клиента.

Не удивительно, что клиенты не любят формы обратной связи.

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

Тикет-система для работы с электронной почтой

Где-то 15 лет назад, с появлением доступного интернета и распространением электронной почты, появился новый тип сервисов — для работы с электронной почтой. Они умели всё то же самое, что тикетницы для сайтов, но научились автоматически регистрировать обращения из почты.

Громоздкий и непонятный интерфейс OTRS — тикет-системы для работы с электронной почтой.

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

Обращения клиентов в социальных сетях и мессенджерах

С приходом соцсетей и мессенджеров взаимодействие с клиентами изменилось кардинально. Теперь клиенты обращаются куда им удобно, а не только на почту; вместо подробного описания проблемы пишут «Привет! Ау, вы здесь?» и рассчитывают, что вы сами спросите всё что нужно; и не готовы ждать ответов по несколько дней и недель, как это было раньше в электронной почте.

Переписка с нетерпеливым клиентом в интерфейсе Еадеска.

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

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

Zendesk предлагает 90% времени проводить в этом маленьком окошке…

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

Простая тикет-система для технической поддержки на русском

Еадеск — это простая тикетная система для технической поддержки на русском языке. Он помогает увеличить скорость обработки обращений в 3−5 раз за счёт объединения разных каналов и источников в одном окне, интуитивно понятного интерфейса, автоматизации и контроля работы через наглядные показатели.

Главное отличие Еадеска в том, что это тикет-система без тикетов. Он решает те же задачи, что и обычная тикетница, но в первую очередь создан для поддержки клиентов через социальные сети и мессенджеры, где тикеты не нужны.

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

В этом разговоре нет ни одного тикета, зато есть диалог между начальником и сотрудником, например, по телефону или в переписке WhatsApp. Из диалога можно извлечь три задачи для сотрудника:

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

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

Работа в тикетной системе: 4 универсальных правила

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

Правило №1: фиксируйте все обращения

Чтобы ничего не потерять и не забыть — все обращения клиентов должны быть зафиксированы в одном окне.

Часто бывает, что сначала клиент напишет в чат, а по телефону сообщает важные детали — потом их невозможно будет найти и восстановить. Хорошо, если есть запись звонка, а если нет? И если записей по одному клиенту несколько, придётся переслушать все, чтобы найти нужный момент. Бывает, клиенты просят написать в WhatsApp или ВКонтакте и менеджеры пишут с личных профилей, а потом увольняются. Как найти о чём был разговор, что и к какому сроку обещали клиенту?

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

Главные каналы при работе с клиентами:

Подключив нужные каналы, вы соберёте все обращения клиентов в одном окне, автоматически будете фиксировать клиентов и их контакты, а также собирать всю история взаимодействий в одном месте.

Еадеск поддерживает 9 каналов связи, в том числе WhatsApp и Instagram. С помощью API и разработчиков вы сможете подключить любой другой канал, которого у нас ещё нет, например, чат из вашего мобильного приложения.

Правило №2: поддерживайте порядок в обращениях

Чтобы клиентам быстро отвечали и вопросы решались, нужно поддерживать порядок в обращениях.

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

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

У нас есть всё, что поможет навести и поддерживать порядок в обращениях. Подробнее о том, как правильно работать в Еадеске, читайте в нашем руководстве – используйте его для обучения ваших сотрудников.

Правило № 3: ускорьте обработку обращений

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

Чтобы повысить скорость обработки, необходимо устранить всё, что замедляет работу специалистов. Обычно они тратят время на бесконечный перебор обращений, чтобы выбрать, на какие нужно ответить в первую очередь. На написание ответов, в том числе одних и тех же ответов на типовые вопросы клиентов: в какие дни работаете, адреса магазинов, как вернуть товар, как связаться с бухгалтерией и так далее.

Стандартный набор инструментов для повышения эффективности и скорость обработки выглядит так:

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

Правило №4: контролируйте показатели

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

Это правило последнее и будет ошибкой начинать работу в тикет-системе с отчётов и показателей. Показатели — это обратная связь по проделанной работы, которую нужно сначала сделать. Представьте, вы решили получить водительские права, и чтобы сдать экзамен в ГИБДД, вам нужно освоить базу: изучить теорию, пройти практику, закончить автошколу. И тогда набранные на экзамене баллы — это ваши показатели, но чтобы их получить — начать нужно с базы.

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

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

Ключевые показатели в службе поддержки:

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

В Еадеске вы найдёте единый дашборд, на котором собраны все необходимые данные: по нагрузке, по каналам, по сотрудникам. А вот заметка, как с его помощью принимать управленческие решения.

Резюмируем

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

Чтобы правильно работать в таких системах, следуйте четырём правилам:

Источник

Как эффективно работать с тикетами (issues) на GitHub

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

Содержание:

Что такое тикет?

Для многих команд «тикет» — это общий термин, который может означать:

Публичный или приватный?

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

Для публичных тикетов

Для приватных тикетов

Оценка

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

Оценка по приоритетности

Оценка по степени влияния

Оценка по степени ущерба

Оценка по размеру

Оценка по критерию MoSCoW

Оценка по частоте

Совокупная оценка

Пример: оценивание тикета по комбинации приоритетности, влияния, ущерба, размера, MoSCoW и частоты.

Допустим, в офис приехал важный клиент, чтобы в течение часа подписать договор, а команда продавцов обнаружила на сайте опечатку в названии компании клиента.

Обсуждение оценок

Здесь приведены примеры обсуждения оценок тикетов.

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

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

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

— QA-инженер в ходе начального исследования задал опасность на основе технических критериев. Это лишь один из факторов, которые продуктолог использует при определении приоритетности, которая с этого момента становится ключевым параметром.

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

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

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

— Внутренняя система отслеживания ошибок в Google оперирует и приоритетностью, и опасностью. P0 S0 — самая срочная задача, P2 S2 — стандартная, P4 S4 — наименее срочная. Это нечто вроде дежурной шутки, что опасность не имеет смысла (потому что по сути она не отличается от приоритетности).

— Мы используем только приоритетность. Тестировщик присваивает на основании эвристик начальное значение (например, падениям — П1, косметическим улучшениям — П5). Разработчик ориентируется на это значение, чтобы выбрать баги, с которыми нужно начать работать в первую очередь. А затем приоритетность корректируется в зависимости от пользовательского опыта и поведения приложения. Если нам действительно нужно посмотреть, какие значения задал тестировщик, то мы используем функцию «истории» или «ревизии» в нашем приложении для отслеживания ошибок.

Шаблон тикета

Шаблон поможет вашей команде эффективно и ёмко охватить важные темы.

В нем могут использоваться:

Запуск постмортемов

Запуск постмортемов подскажет команде, когда нужно заняться описанием ситуации.

Запустить разбор можно:

Источник

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

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

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

Чем точнее, подробнее и логичнее описана проблема, тем быстрее смогут ее решить наши специалисты. Желательно, чтобы описание было подкреплено конкретными примерами. Если вы, например, пишете о проблемах с сетевой доступностью, то прилагайте к тикету ответы на 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.

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

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

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

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

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

Источник