Что такое тикет?
Создайте тикет в «Спринтхост». Не знаете, что это такое? Сейчас расскажем!
Если верить переводу с английского, то ticket — это билет. Получается, что клиент, создавая тикет, покупает билет на помощь от техподдержки.
Любой билет имеет свой идентификатор, по которому можно определить, кому он принадлежит. Если грубо приводить пример, то чек из магазина тоже является тикетом, таким своеобразным билетом на выход из супермаркета с покупками.
Возвращаемся к тикет-системе техподдержки. Суть в том, что: клиент создает обращение, например, из личного кабинета, система придает ему уникальный номер, по которому потом можно легко определить, чье это обращение, какая проблема описана, как давно существует переписка и многое другое. В билетах тоже указывается уникальный идентификатор, по нему клиент получает возможность что-то получить или сделать, например, проехать на автобусе.
Тикет также можно перевести как «заявка». Как раз в этом значении чаще всего его и используют. Билет — это, конечно, хорошо. Можно даже представить, будто клиент получает билет на необычный поезд, экспресс в диковинные страны. Но все же «заявка» больше подходит для техподдержки.
Тикет крепко укоренился в терминологии клиентской службы, с которой знакомы не все, в особенности те, кто никогда не обращался в поддержку. Потому и появляются вопросы «а что такое тикет?» и «как его создать?». Но теперь вы на шаг ближе к истинному знанию.
Основная задача поддержки — отвечать на обращения пользователей, клиентов, случайного прохожего на сайте и даже «троллей». Естественно, должен быть какой-то канал связи, желательно, несколько. В Спринтхост это телефон, чаты на сайте, в Панели управления (ПУ), в телеграм-боте и группа в ВК, электронная почта.
По телефону и чатам можно быстрее решить несложные вопросы, например, где у нас находится какой-либо раздел, как оплатить хостинг, как зарегистрировать домен. Но работа в поддержке не ограничивается такими простыми, хоть и не менее важными запросами. Сложные, трудные или требующие пристального внимания вопросы поддержка обрабатывает по электронной почте. Такие запросы требуют исчерпывающего ответа и времени.
Тикетом называется любое обращение пользователя, исходящее из Панели управления аккаунтом. Оно получает уникальный идентификатор, по которому мы можем найти карточку клиента, посмотреть, в чем проблема, и, конечно, помочь с ее решением.
Как мы отметили выше, с помощью тикетов легко поднимать историю переписки с пользователем. Согласитесь, очень удобно прочитать старое обращение, чтобы помочь с новым, а не переспрашивать тысячу раз логин аккаунта, историю решения старой проблемы и тд.
Помимо этого, наша система позволяет быстро перейти к карточке клиента и идентифицировать его. Это полезно, например, при смене почты или владельца аккаунта, так как для этого нужно подтверждение с почты или из ПУ, а раз тикет создается именно там, то и дополнительно просить об этом не нужно.
Поднять историю можем не только мы, но и клиент. То есть если он помнит, что проблема уже когда-то возникала, то можно поискать ее решение в переписке. Да и вообще удобно написать сразу из Панели управления, получить там же ответ и все решить. Этакая небольшая соцсеть, только в рамках хостинга.
Еще один плюс в том, что абсолютно любое обращение можно «завернуть» в тикет, будь то чат или звонок. То есть если пользователь напишет в чат, но, например, нужна диагностика, то этот чат превращают в тикет, чтобы не потерять его среди многих других обращение. В этом, опять же, очень помогает уникальный идентификатор.
Вообще, тикетница крайне удобна в использовании — сразу видно, кто пишет, с какой просьбой и кто занимается этим обращением. Это также помогает руководству следить за качеством работы поддержки, направлять ее в нужное русло.
Тикеты шикарны в своем использовании. Слово крепко вошло в обиход не только хостинг-провайдеров, но и везде, где есть клиентская служба поддержки. Теперь вы знаете, что означает это слово, и можете успешно создавать новые «билеты» на экспресс «Экспресс-поддержка Спринтхост».
5 правил работы с тикетами
Будь вы клиентом или специалистом технической поддержки, при удаленном взаимодействии (в нашем случае — посредством тикетов) и вам, и второй стороне требуется больше дисциплины. Каждый тикет — это отдельное задание со своим циклом исполнения, своими участниками и своей целью. Итак, как же оптимизировать взаимодействие посредством ?
1. Правило «один на один»
Каждый тикет (он же — «баг») представляет собой взаимосвязь между двумя людьми: тем, кто заявил о проблеме, и тем, кто будет ее решать. Если это баг — сообщает о нем, разбирается, если это вопрос — задает его, отвечает. Неважно, какое количество людей с обеих сторон вовлечено в решение вопроса, в этой коммуникации участвуют только двое.
Ответственность того, кто создает тикет — рассказать о проблеме. Когда вы создаете тикет, вы настаиваете на том, что проблема существует: может сказать, что все работает, может утверждать, что у него такой ошибки нет, еще — что описание проблемы слишком мутное и никто не понимает, в чем, собственно, дело. Задача создающего тикет — обеспечить его жизнеспособность. Если вы создали тикет — вы его до самого момента закрытия.
Задача второй стороны — обеспечить решение. Если тикет назначен вам — ваша задача убедить вторую сторону, что ваше решение — самое лучшее. Вам могут говорить, что этого решения недостаточно, что оно неэффективно или не до конца решает проблему. Конечно, ваша задача — исследовать корни проблемы, просчитать все возможные варианты и предложить хорошее решение, но все это второстепенно, ведь ваша главная задача — закрыть тикет.
В один всегда продает другому свое видение вопроса.
2. Закройте его!
— это не чат, и вы здесь не для того, чтобы разговаривать. Вы здесь для того, чтобы решить свой вопрос. Тикеты, которые не закрываются неделями, это настоящий ночной кошмар как для заявителя, так и для технического специалиста: их сложно отслеживать и еще сложнее контролировать. Тикет может иметь сотни комментариев, которые в конце концов заставляют забыть, в чем же, собственно, была проблема.
Все это — ошибка обеих сторон. Тикет должен быть сформулирован кратко и по существу. Сценарий идеального тикета таков: проблема — уточняющие вопросы — короткое объяснение — решение — закрытие тикета, всем спасибо.
3. Не закрывайте его!
Каждый раз, когда вы обнаруживаете баг и создаете тикет, вы тратите свое время. Каждый раз, когда сотрудник техподдержки обрабатывает ваш тикет, тратит массу ресурсов.
Если вы подтверждаете закрытие тикета, а проблема толком не решена, вы выбрасываете свои деньги и деньги провайдера в мусорное ведро. Если тикет создан, нельзя сказать «Ладно, разберемся позже». Если он запущен, должны быть предприняты все меры для решения возникшей неполадки.
Посмотрите на это с такой стороны: когда вы создали тикет, у вас в голове была определенная задача, пошло не так. Если у вас в данный момент недостаточно времени, и вы закрываете вопрос, другой в будущем найдет то же баг и будет снова тратить время — свое и провайдера — на решение этой проблемы. Сделайте мир немного лучше, не закрывайте тикет до тех пор, пока вы не получили полноценный ответ на свой запрос.
4. Тсс….Не шумите!
Каждый раз, когда вы оставляете комментарий по тикету, адресуйте его — в ином случае ваш комментарий посчитают просто высказыванием своего мнения, тем, что называется в психологии «коммуникационным шумом». Помните, тикет — это общение между двумя участниками.
Всегда адресуйте свой вопрос/просьбу/требование конкретному человеку, с которым вы общаетесь для закрытия своей проблемы. Все остальное просто усложняет процесс решения проблемы, но ни в коем случае не помогает в нем.
5. Говорите громче
Всегда говорите о том, что вас не устраивает. Каждый раз, когда вы сообщаете о проблеме, объясните, что именно пошло не так. Это ваша задача — объяснить, что именно в продукте работает некорректно, что не задокументировано, в чем есть вопросы. Вы получили услугу, и это ваше право — сообщить о проблеме, и ваша обязанность — объяснить, что конкретно не соответствует вашим ожиданиям.
Формула тикета такова: «Вот что мы имеем, а вот что мы должны иметь». Вы как бы передвигаете проект из точки, А в точку Б: пошло не так в точке, А, и для всех нас было бы лучше оказаться в точке Б. Очевидно, что ваша задача — нарисовать эту линию из точки, А в точку Б.
Скажем, если у вас вопрос, это значит, что в документах недостаточно информации — и это корень проблемы. Вместо того, чтобы спрашивать: «Как подключить Х?», скажите: «В текущих документах нет информации о том, как подключить Х. Пожалуйста, дополните их».
Каждый раз, создавая тикет, чувствуйте себя художником — рисуйте четкую линию из точки А в точку Б.
Тикет-система для техподдержки
Чем отличается «хорошее» ИТ-подразделение от «плохого»? Естественно, очень многим. Однако основным критерием такого отличия является эффективность его работы, которая выражается в способности специалистов техподдержки оперативно реагировать на проблемы и пожелания пользователей.
Казалось бы, залог «хорошего ИТ-подразделения» — это высококвалифицированная команда специалистов технической поддержки, но, к сожалению, профессионализма может быть недостаточно.
На сегодняшний день во многих компаниях принято использовать электронную почту для регистрации заявок пользователей. Такая тенденция обусловлена рядом существенный преимуществ данного способа:
Пользователь может обратиться в тех поддержку в свободной форме и сообщить о проблеме буквально в двух словах: «не работает…»;
Почта почти всегда у всех открыта, тех поддержка видит обращение и может быстро отреагировать;
Пользователю не надо никуда идти или дозваниваться до специалиста.
В то же время, регистрация заявок по электронной почте может затруднять работу ИТ-отдела, так как, наравне с преимуществами, такой способ имеет и достаточно серьезные минусы:
При большом потоке обращений, письмо может затеряться;
Техподдержка может выполнить обращение без участия пользователя и не сообщить ему о том, что все проблемы решены — пользователь может быть уверен, что его проблема до сих пор не решена, что вряд ли будет способствовать плодотворной работе;
Руководителю ИТ будет крайне затруднительно проконтролировать работу ИТ-подразделения, ведь придется потратить уйму рабочего времени, чтобы найти историю по запросу.
Все это побудило ИТ-подразделения к поиску альтернативных способов регистрации обращений. Сейчас многие компании используют Тикет-систему для тех поддержки. Тикет-система существенно развила способность ИТ-подразделения оказывать техподдержку своевременно и качественно.
Cистема тикетов для техподдержки
Одним из главных достоинств тикет-системы является систематизация запросов. То есть, с помощью тикет-системы:
Техподдержка может отделить одно обращение от другого. Раньше в одной переписке могла идти речь о многих запросах или несколько писем могли относится к одному запросу, поэтому восстановить историю обращения было, как минимум, сложно.
Специалисты техподдержки и пользователи могут увидеть историю по каждому обращению: как переписку, так и объективные данные – когда поступило, когда было выполнено, когда был изменен статус и т.д.
Как правило, тикет-системы технической поддержки имеют свою «веб-страницу», заходя на которую пользователи могут зарегистрировать заявки в структурированном виде: выбрав категорию, приложив скриншот и т.д. Однако есть системы с помощью которых пользователи могут обратится в техническую поддержку, направив заявку на общий электронный адрес. Все обращения направленные на данный адрес регистрируются технической поддержкой, что позволяет избежать их потери.
Тикет-система оказывает значительное влияние на совершенствование возможностей ИТ-подразделения. По итогам ее внедрения ИТ-отдел получает возможность оценивать свою работу на основании объективных данных, а именно: нагрузку – сколько запросов поступило, оперативность оказания помощи — насколько быстро приступили к решению вопроса, качество — сколько запросов было выполнено и в какой срок и т.д.
Однако, несмотря на то, что тикет-система помогает ИТ-подразделению совершенствовать свои способности в части поддержки пользователей, уровня этих способностей, чтобы конкурировать с профессиональными ИТ-подразделениями, будет по прежнему недостаточно. Систематизация потока поступающих заявок — это всего лишь начальный этап на пути становления зрелой команды, хоть он и является обязательным.
Стоит отметить, что тикет-система, также как и электронная почта, не является совершенным способом регистрации обращений. Одна из самых больших проблем тикет систем — это отсутствие ориентации на ИТ-сервисы (ИТ-услуги). Дело в том, что после систематизации потока заявок, ИТ-подразделение понимает, что в зависимости от контекста, заявки могут сильно отличаться друг от друга, а некоторые из них могут затрагивать не только техническую поддержку, но и другие ИТ-подразделения. Поэтому многие пытаются найти обходной путь, например добавить возможность учета ИТ-сервисов в тикет-системах. Однако, это все равно не приводит компанию к внедрению сервисного подхода, потому что оно возможно только с использованием систем класса Service Desk, но об этом мы расскажем уже в другой статье.
Тикет-система: как организовать учет заявок
Запросы в службу поддержки неслучайно обозначают термином «тикет» (от англ. ticket – билет). Как обычный билет гарантирует пассажиру проезд по нужному маршруту, так и тикет обеспечивает скорейшее решение проблемы клиента по регламентированному пути. Чтобы такое условие выполнялось, специалистам поддержки необходима автоматизированная тикет-система. О том, что это за инструмент, какие преимущества бизнесу дает работа с тикетами и как правильно ее выстроить, читайте в материале.
Тикет-система – что это
Тикет – это любая заявка, которая зарегистрирована службой поддержки. В свою очередь, тикет-система – это цифровой инструмент для автоматизации работы сервисного подразделения. Такие решения применяются для регистрации и обработки обращений пользователей.
Различаются два типа подобных ИТ-систем – help desk и service desk. Первые используется для того, чтобы систематизировать работу с обращениями. Возможности service desk гораздо шире: они позволяют сделать службу поддержки полноценной организацией согласно ITSM-подходу. Это достигается формированием в системе учета заявок каталога услуг, который упорядочивает сервис. Также в таких инструментах можно выстраивать сложные процессы по методологии ITIL (управление инцидентами, запросами на обслуживание, изменениями и т.д.).
Для чего нужны тикеты
Каждому зарегистрированному в ИТ-системе тикету присваивается номер, фиксируется заявитель и суть проблемы. Назначаются дедлайны и исполнители. Таким образом, пользовательское обращение выполняется по регламенту и контролируемой процедуре. Обозначим основные преимущества, которые получают служба поддержки и сами пользователи.
Исключается потеря обращений. Если обращения не регистрируются должным образом, они могут хаотически сыпаться на специалистов по телефону, электронной почте или по другим каналам. Контролировать поток разрозненной информации становится трудно, и часть заявок теряется. Избежать всего этого помогает работа с тикетами в единой ИТ-системе.
Сокращается количество ошибок. Правильно оформленный тикет дает специалисту важную информацию о характере проблемы, что помогает подобрать подходящее решение. Кроме того, появляется возможность прямо в ИТ-системе связаться с пользователем, чтобы задать ему уточняющие вопросы. Не возникает путаницы и со сроками, т.к. они фиксируются при регистрации тикета.
Снижается нагрузка на специалистов поддержки. Принять обращение по телефону, записать суть вопроса, найти свободного инженера и передать ему полученную информацию, а затем проконтролировать выполнение работ в «ручном режиме». Такие повторяющиеся действия отнимают массу времени у первой линии поддержки.
Работа с тикетами позволяет оптимизировать значительную часть описанных рутинных операций. Так, можно настроить автоматическую классификацию заявок, расчет дедлайнов, назначение ответственных.
Повышается прозрачность сервиса. Без единой формы учета заявок руководитель службы поддержки не всегда знает, сколько обращений в работе. Все фиксируется в разных инструментах, и получить цельную картину по сервису затруднительно. Пользователю же приходится постоянно связываться со специалистами, чтобы уточнить ход решения его вопроса.
При регистрации тикетов в ИТ-системе таких проблем не возникает. Руководство службы в любой момент может выяснить, сколько и какие заявки в исполнении, соблюдаются ли сроки, не возникают ли заминки. А пользователи получают уведомления о статусе выполнения запроса.
С чего начать и как вести учет заявок
Как именно выстроить работу с заявками, зависит от специфики процессов и задач бизнеса. Все же есть базовые шаги, которые следует пройти любой службе поддержки.
Решите, нужно ли автоматизировать учет заявок. Если служба поддержки принимает, скажем, 5 звонков ежедневно, автоматизировать работу необязательно. Даже одному диспетчеру по силам ответить пользователям и передать информацию специалистам при помощи телефона или электронной почты.
Не всегда требуется применение специализированных инструментов и в случае, если большинство вопросов направляется по одному-двум каналам и решается однотипными консультациями. Наглядный пример – служба поддержки небольшого онлайн-магазина, куда обращаются через соцсети за разъяснениями по стоимости либо доставке.
Напротив, внедрение системы тикетов для техподдержки необходимо при поступлении 100 и более сервисных заявок ежемесячно. Еще одна предпосылка к автоматизации – разнообразные по своей сути, сложности и срочности вопросы пользователей. Не обойтись без единого цифрового решения, если коммуникация пользователей со специалистами ведется по множеству каналов.
Подберите инструмент для обработки заявок. Такой выбор определяется несколькими факторами. Первый – бюджет, который бизнес готов выделить на инструмент автоматизации. На рынке представлены как бесплатные тикет-системы, так и дорогостоящие решения.
Второй фактор – цели использования инструмента. Если компании достаточно, чтобы заявки не терялись, подойдет простая help desk система. Когда требуется оптимизировать сервисные процессы (провести интеграцию системы с внешними инструментами, настроить специфические согласования), нужен service desk.
Другие два фактора – наличие у компании серверных мощностей и информационная политика. Можно выбрать автоматизированную систему, которая локализуется внутри компании (on-premise). Альтернативный вариант – облачная (SaaS) ИТ-система. Ее внедрение и эксплуатация требуют гораздо меньше ресурсов от бизнеса, поскольку поддержкой инфраструктуры занимается вендор.
Обеспечьте обработку заявок в режиме единого окна. Это достигается самим наличием ИТ-системы, куда поступают все обращения. Нередко на начальном этапе автоматизации приходится проводить информационную работу с пользователями, чтобы они отправляли свои запросы через service desk или help desk систему.
Задействуйте разные каналы для обработки заявок. Обычно для связи со службой поддержки доступны разные способы: телефон, почта, мессенджеры, мобильное приложение. Если они используются разрозненно, специалисты вынуждены разрываться между множеством звонков, писем и чатов. Возникает риск несогласованности, когда пользователь обращается по одному вопросу через разные каналы, и два специалиста параллельно берут заявку в работу. Вот почему каналы должны быть синхронизированы с единой ИТ-системой. Тогда любое обращение регистрируется как тикет, что обеспечивает своевременное решение проблемы ответственным исполнителем. Пользователи же получают возможность коммуницировать со службой поддержки так, как им удобнее.
Настройте правила обработки заявок. Прежде всего речь о создании в ИТ-системе соглашений SLA, в которых прописываются сроки реакции на обращения, графики работы специалистов и другие параметры сервиса. Специалистам не придется постоянно сверяться с регламентными документами. Система сама проинформирует их о приближающихся дедлайнах согласно SLA, если настроить соответствующие уведомления.
Другая актуальная задача – реализовать статусы, которые будут присваиваться заявкам по мере их выполнения. Возможный вариант – «В работе», «Отложено», «Ожидание ответа от пользователя», «Решена», «Закрыта», «Возобновлена». Статусная модель поможет держать под контролем ход запроса.
Наладьте процесс назначения ответственных по заявкам. Самый простой вариант – назначение ответственных диспетчером «вручную». По мере усложнения сервисных процессов такой способ теряет свою эффективность. Скажем, появляется необходимость настроить распределение ответственных в зависимости от услуги или клиента. При большом объеме обращений целесообразно реализовать сценарий, когда заявки автоматически назначаются на наименее загруженных специалистов. Возможна и другие варианты маршрутизации запросов.
Накапливайте историю запросов. Вся информация по выполненным обращениям должна быть доступна специалистам поддержки в единой ИТ-системе. Это поможет быстрее находить нужные решения при возникновении схожих проблем, оперативно погружаться в контекст предыдущего взаимодействия с клиентами.
Анализируйте эффективность работы с запросами. Сервисным специалистам важно отслеживать основные метрики по работе с заявками. Руководству же службы поддержки нужно мониторить основные результаты в деятельности подразделения и загрузку специалистов, чтобы рациональнее распределять задачи. Поэтому в некоторых системах автоматизации учета заявок реализована отчетность по метрикам соблюдения SLА (количество просроченных заявок, закрытие запроса при первом обращении), оценкам качества сервиса, трудозатратам персонала.
Описанные шаги помогут службе поддержки добиться максимального эффекта от автоматизированного учета заявок. При этом следует правильно расставить приоритеты в процессах поддержки и подобрать наиболее подходящую ИТ-систему для достижения желаемых результатов.