Что такое тикет?
Создайте тикет в «Спринтхост». Не знаете, что это такое? Сейчас расскажем!
Если верить переводу с английского, то ticket — это билет. Получается, что клиент, создавая тикет, покупает билет на помощь от техподдержки.
Любой билет имеет свой идентификатор, по которому можно определить, кому он принадлежит. Если грубо приводить пример, то чек из магазина тоже является тикетом, таким своеобразным билетом на выход из супермаркета с покупками.
Возвращаемся к тикет-системе техподдержки. Суть в том, что: клиент создает обращение, например, из личного кабинета, система придает ему уникальный номер, по которому потом можно легко определить, чье это обращение, какая проблема описана, как давно существует переписка и многое другое. В билетах тоже указывается уникальный идентификатор, по нему клиент получает возможность что-то получить или сделать, например, проехать на автобусе.
Тикет также можно перевести как «заявка». Как раз в этом значении чаще всего его и используют. Билет — это, конечно, хорошо. Можно даже представить, будто клиент получает билет на необычный поезд, экспресс в диковинные страны. Но все же «заявка» больше подходит для техподдержки.
Тикет крепко укоренился в терминологии клиентской службы, с которой знакомы не все, в особенности те, кто никогда не обращался в поддержку. Потому и появляются вопросы «а что такое тикет?» и «как его создать?». Но теперь вы на шаг ближе к истинному знанию.
Основная задача поддержки — отвечать на обращения пользователей, клиентов, случайного прохожего на сайте и даже «троллей». Естественно, должен быть какой-то канал связи, желательно, несколько. В Спринтхост это телефон, чаты на сайте, в Панели управления (ПУ), в телеграм-боте и группа в ВК, электронная почта.
По телефону и чатам можно быстрее решить несложные вопросы, например, где у нас находится какой-либо раздел, как оплатить хостинг, как зарегистрировать домен. Но работа в поддержке не ограничивается такими простыми, хоть и не менее важными запросами. Сложные, трудные или требующие пристального внимания вопросы поддержка обрабатывает по электронной почте. Такие запросы требуют исчерпывающего ответа и времени.
Тикетом называется любое обращение пользователя, исходящее из Панели управления аккаунтом. Оно получает уникальный идентификатор, по которому мы можем найти карточку клиента, посмотреть, в чем проблема, и, конечно, помочь с ее решением.
Как мы отметили выше, с помощью тикетов легко поднимать историю переписки с пользователем. Согласитесь, очень удобно прочитать старое обращение, чтобы помочь с новым, а не переспрашивать тысячу раз логин аккаунта, историю решения старой проблемы и тд.
Помимо этого, наша система позволяет быстро перейти к карточке клиента и идентифицировать его. Это полезно, например, при смене почты или владельца аккаунта, так как для этого нужно подтверждение с почты или из ПУ, а раз тикет создается именно там, то и дополнительно просить об этом не нужно.
Поднять историю можем не только мы, но и клиент. То есть если он помнит, что проблема уже когда-то возникала, то можно поискать ее решение в переписке. Да и вообще удобно написать сразу из Панели управления, получить там же ответ и все решить. Этакая небольшая соцсеть, только в рамках хостинга.
Еще один плюс в том, что абсолютно любое обращение можно «завернуть» в тикет, будь то чат или звонок. То есть если пользователь напишет в чат, но, например, нужна диагностика, то этот чат превращают в тикет, чтобы не потерять его среди многих других обращение. В этом, опять же, очень помогает уникальный идентификатор.
Вообще, тикетница крайне удобна в использовании — сразу видно, кто пишет, с какой просьбой и кто занимается этим обращением. Это также помогает руководству следить за качеством работы поддержки, направлять ее в нужное русло.
Тикеты шикарны в своем использовании. Слово крепко вошло в обиход не только хостинг-провайдеров, но и везде, где есть клиентская служба поддержки. Теперь вы знаете, что означает это слово, и можете успешно создавать новые «билеты» на экспресс «Экспресс-поддержка Спринтхост».
5 правил работы с тикетами
Будь вы клиентом или специалистом технической поддержки, при удаленном взаимодействии (в нашем случае — посредством тикетов) и вам, и второй стороне требуется больше дисциплины. Каждый тикет — это отдельное задание со своим циклом исполнения, своими участниками и своей целью. Итак, как же оптимизировать взаимодействие посредством ?
1. Правило «один на один»
Каждый тикет (он же — «баг») представляет собой взаимосвязь между двумя людьми: тем, кто заявил о проблеме, и тем, кто будет ее решать. Если это баг — сообщает о нем, разбирается, если это вопрос — задает его, отвечает. Неважно, какое количество людей с обеих сторон вовлечено в решение вопроса, в этой коммуникации участвуют только двое.
Ответственность того, кто создает тикет — рассказать о проблеме. Когда вы создаете тикет, вы настаиваете на том, что проблема существует: может сказать, что все работает, может утверждать, что у него такой ошибки нет, еще — что описание проблемы слишком мутное и никто не понимает, в чем, собственно, дело. Задача создающего тикет — обеспечить его жизнеспособность. Если вы создали тикет — вы его до самого момента закрытия.
Задача второй стороны — обеспечить решение. Если тикет назначен вам — ваша задача убедить вторую сторону, что ваше решение — самое лучшее. Вам могут говорить, что этого решения недостаточно, что оно неэффективно или не до конца решает проблему. Конечно, ваша задача — исследовать корни проблемы, просчитать все возможные варианты и предложить хорошее решение, но все это второстепенно, ведь ваша главная задача — закрыть тикет.
В один всегда продает другому свое видение вопроса.
2. Закройте его!
— это не чат, и вы здесь не для того, чтобы разговаривать. Вы здесь для того, чтобы решить свой вопрос. Тикеты, которые не закрываются неделями, это настоящий ночной кошмар как для заявителя, так и для технического специалиста: их сложно отслеживать и еще сложнее контролировать. Тикет может иметь сотни комментариев, которые в конце концов заставляют забыть, в чем же, собственно, была проблема.
Все это — ошибка обеих сторон. Тикет должен быть сформулирован кратко и по существу. Сценарий идеального тикета таков: проблема — уточняющие вопросы — короткое объяснение — решение — закрытие тикета, всем спасибо.
3. Не закрывайте его!
Каждый раз, когда вы обнаруживаете баг и создаете тикет, вы тратите свое время. Каждый раз, когда сотрудник техподдержки обрабатывает ваш тикет, тратит массу ресурсов.
Если вы подтверждаете закрытие тикета, а проблема толком не решена, вы выбрасываете свои деньги и деньги провайдера в мусорное ведро. Если тикет создан, нельзя сказать «Ладно, разберемся позже». Если он запущен, должны быть предприняты все меры для решения возникшей неполадки.
Посмотрите на это с такой стороны: когда вы создали тикет, у вас в голове была определенная задача, пошло не так. Если у вас в данный момент недостаточно времени, и вы закрываете вопрос, другой в будущем найдет то же баг и будет снова тратить время — свое и провайдера — на решение этой проблемы. Сделайте мир немного лучше, не закрывайте тикет до тех пор, пока вы не получили полноценный ответ на свой запрос.
4. Тсс….Не шумите!
Каждый раз, когда вы оставляете комментарий по тикету, адресуйте его — в ином случае ваш комментарий посчитают просто высказыванием своего мнения, тем, что называется в психологии «коммуникационным шумом». Помните, тикет — это общение между двумя участниками.
Всегда адресуйте свой вопрос/просьбу/требование конкретному человеку, с которым вы общаетесь для закрытия своей проблемы. Все остальное просто усложняет процесс решения проблемы, но ни в коем случае не помогает в нем.
5. Говорите громче
Всегда говорите о том, что вас не устраивает. Каждый раз, когда вы сообщаете о проблеме, объясните, что именно пошло не так. Это ваша задача — объяснить, что именно в продукте работает некорректно, что не задокументировано, в чем есть вопросы. Вы получили услугу, и это ваше право — сообщить о проблеме, и ваша обязанность — объяснить, что конкретно не соответствует вашим ожиданиям.
Формула тикета такова: «Вот что мы имеем, а вот что мы должны иметь». Вы как бы передвигаете проект из точки, А в точку Б: пошло не так в точке, А, и для всех нас было бы лучше оказаться в точке Б. Очевидно, что ваша задача — нарисовать эту линию из точки, А в точку Б.
Скажем, если у вас вопрос, это значит, что в документах недостаточно информации — и это корень проблемы. Вместо того, чтобы спрашивать: «Как подключить Х?», скажите: «В текущих документах нет информации о том, как подключить Х. Пожалуйста, дополните их».
Каждый раз, создавая тикет, чувствуйте себя художником — рисуйте четкую линию из точки А в точку Б.
The Whole Story: Technical Ticket Writing in Software Development
If you’re working on a distributed software development team alongside product and facilitation professionals, like scrum master, business analyst, etc… you’re probably prescribing your dev teams work using some sort of ticketing system, and the cornerstone of that system is usually a User Story.
What is a User Story
A user story is an informal, general explanation of a software feature written from the perspective of the end user or customer.
The keyword here is general… usually, user stories don’t provide technical detail, and the implementation of the story is often left up to the individual developer that picks it up. This leads to the inevitable technical interpretation of that user story by the developer, and — if you’re building, say, a mobile app — this can mean significantly different implementations, and even different logic, across platforms.
The interpretability of user stories is a persistent problem among software development teams and there are lots of ways to solve it. Before we get to that, though, let’s talk a little bit about…
Why this is a problem
Estimating User Stories
Because of how general they are, user stories don’t provide any real depiction of the actual work that needs to be done, because they lack technical detail. But we we still expect developers to estimate that work based only on the user story — that’s to say, without knowing exactly what the work is that they’re estimating.
This, unsurprisingly, leads to wildly inaccurate estimates, usually in the direction of underestimating work. When you generalize something, it almost always makes it seem easier and less complex than it actually is. This, in turn, makes releases difficult to deliver on time; and time is, of course, money. Timeline changes always have a cost, which is why we spend so much effort planning out development in the first place.
In addition, since technical discoveries might not be uncovered until we’re doing the work, we may need to create additional stories, or new stories, or re-point old stories to reflect that new knowledge. This mean a lot more work for a lot of the team, both developers and others.
With that in mind…
What do we do about it?
Admittedly, in order to create user stories that a developer can really use, and that can be estimated with any accuracy at all, we have to do more planning, and engineers have to be more involved in that process.
Now, you might say, what’s the difference between doing that work up front, or as part of the development work of the ticket? At the end of development you spent the same amount of time/money… right?
Well, not really. Building applications nowadays generally means multiple teams building the same front end products on different platforms. But a lot of the work of technical planning benefits all of those development teams, not just one. In that sense, planning the technical solutions first can cut your overall development effort by a considerable amount.
In addition to that, if we do the planning up front, we can finally develop a high confidence estimate of how complex the work will be, which we can then translate into an achievable timeline.
Well, hold on, you might say (god, you talk a lot)… what kind of technical planning are we talking about, exactly? Well, I’m glad you asked.
A Two Part System
The first part of a robust technical solution design system is: Documentation.
Yeah, yeah… you don’t want to talk about that, because you’re all Agile or whatever, and the Agile Manifesto says we don’t care about documentation. Well that’s just another reason that Agile is Wrong, and besides that, what you’re doing probably isn’t actually agile anyway, so you really just should stop saying “Agile.”
What was I saying? Right, documentation. When you’re building one app a bunch of times, you need documentation, in order to keep all the different platform versions in sync. But, just like a lot of your code, your documentation should be Platform Agnostic — in other words, we don’t care what widgets or programming language you’re using; we care about what data sources you’re using, how and where that data is displayed, and how it drives the experience. These things are generally identical across platforms, and can therefore be thoroughly documented.
Technical Documentation acts as a guide for ticket writing, and a record of what we intend to do as well as, hopefully, what we’ve done. This is superior to ticketing alone, because the tickets are transient — they exist to facilitate the development, and then they are generally archived away in the done column and we never hear from them again. But a document is a long-lived, evolving thing that records what we intend to build, what we’ve built, and how it works. We can always go back to it to see if the product is performing to spec, and we can use it as a guide to do QA, and audit the app across platforms for consistency.
Finally, after we agree and document the technical details of an experience, then we can write the Development Story
User Stories are great, but not for software development.
So, don’t use them. There are no rules in software development (despite what your scrum master says)… if traditional user stories are useless (spoiler: they are) — don’t use them.
Instead, write technically specific Development Stories whose content mirrors the process and addresses the needs of development. For instance, when we build a new screen there are some predictable steps:
- Create empty shell classes for the screen
- build the UI of any new components on the screen
- Assemble the data modeling and API calls
- Compose the presentation logic
Therefore there are going to be three main development stories, and one for each new component. Those tickets are going to contain technical details that BAs can collaborate with engineers to capture, and the tickets will reference the technical documentation that was already written to describe the solution for the screen. And none of those tickets is going to contain the words “As a user.”
Of course, we can still maintain user stories to guide the overall development direction, but we’ll never ask a developer to move a User Story through a development process, or use it to try and estimate anything.
Managing the Work
I know what you’re saying — you pay developers to write code, not tickets. But involving developers in technical planning will accelerate the development they have to do, and reduce the scope of that development by eliminating the interpretability of user stories. So, you’re doing less development overall, and the work is better defined, which allows you to do it faster, and the resulting product is better. Also, the technical documentation keeps different platforms in sync, cutting down on individual implementation errors, miscommunications and errant differences in logical design.
Better, faster development more than pays for the reduction in developers time that is available to write code, since they are dedicating more time to planning.
Development Stories aren’t just good engineering, they’re also good business.
Тикет-система: как организовать учет заявок
Запросы в службу поддержки неслучайно обозначают термином «тикет» (от англ. 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А (количество просроченных заявок, закрытие запроса при первом обращении), оценкам качества сервиса, трудозатратам персонала.
Описанные шаги помогут службе поддержки добиться максимального эффекта от автоматизированного учета заявок. При этом следует правильно расставить приоритеты в процессах поддержки и подобрать наиболее подходящую ИТ-систему для достижения желаемых результатов.