Как сделать тикет систему

Создание тикет-системы на базе OTRS

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

Выбор решения для тикет-системы

Поиск тикет-системы производился, используя следующие требования:

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

Из всех решений, которые были рассмотрены, наиболее подходящим показался OTRS.

В таблице 1 ниже приведены наиболее распространенные термины которые используются при работе с системой.

Обзор OTRS

Рассмотрим функционал системы, который можно получить сразу после установки и базовой настройки:

Далее необходимо сопоставить приоритет заявки с ее типом и SLA. В таблице ниже настраивается матрица какой ID SLA будет выбран при определенном ID типа заявки и приоритете.

Оператор проводит классификацию заявки указывая приоритет и сервис. Далее может закрыть ее сам или же передать другому оператору или в другую очередь.

Настройка системы OTRS

Для реализации первого этапа установили систему и начали ее настройку.

Базовая настройка

После того как система была установлена, ее нужно было настроить.

В результате получился инструмент, позволяющий использовать такой функционал:

Базовая кастомизация

Для соответствия системы потребностям компании выполнили небольшую кастомизацию:

Настроен SLA. Регламентное время решения заявки вычисляется в зависимости от типа заявки (запрос на обслуживание или инцидент), приоритета и сервиса. Настроено рабочее время. Также выполнен расчет приоритета в зависимости от срочности и критичности заявки. Изначально в заявках есть только параметр приоритета.

Настроено ограничение на прием заявок. Настроили прием заявок только с почты клиентов или агентов. С адресов, не зарегистрированных в системе, заявки не принимаются, в ответ отправляется уведомление о незарегистрированном адресе.

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

Реализован механизм подсчета возвращенных заявок. Количество возвращенных заявок и количество раз, которое они были возвращены является очень важным показателем качества работы ИТ-службы, поэтому в форму заявки был добавлен счетчик возобновления заявок.

Отчеты

Для оценки качества работы ИТ-подразделения пока решили использовать 3 отчета:

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

Отчет «Возвращенные заявки». Показывает количество возвращенных заявок в абсолютном и процентном соотношении и показывает сколько раз была возвращена конкретно каждая заявка.

Планы по дальнейшему развитию

В будущем планируется реализовать следующий функционал:

Вывод

Мы запустили готовую тикет-систему в облаке и предлагаем её в аренду.

EFSOL Системная интеграция. Консалтинг

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

Источник

Как создать и запустить тикетную систему за один месяц?

Всем привет, я Максим Кутузов, предприниматель.

Первоначальная идея: приложение для регистрации посетителей и фронт для заказа пропусков.

Кликабельный прототип приложения был создан за неделю и следующие три месяца мой напарник писал код приложения, фронта и бека, а я провел более 100 встреч с потенциальными клиентами, показывая прототип и собирая обратную связь. Если мы получали какую-либо идею по доработке 3 раза, то мы ее внедряли. В сентябре мы получили работающий продукт, который кардинально отличался от нашей первоначальной задумки как по функционалу, так и по дизайну. Первая презентация решения была снята на мобильный телефон и выглядела так:

Первое внедрение решения случилось ровно через 100 дней после написания первой строчки кода, а счастливым дизайн-клиентом стало Министерство цифрового развития республики Татарстан (пруф). Если за час до внедрения нам казалось что продукт готов и теперь дело только за незначительными улучшениями, то через 2 часа после внедрения в Минцифре наш беклог увеличился на 5 эпиков и 100+ историй, потому что у министра и его аппарата было очень много обоснованных пожеланий, а voice of the customer, как известно, наше все. Параллельно другой потенциальный клиент, владелец офисной недвижимости, назовем его условно Леша, очень доходчиво объяснил нам что без интеграции с турникетами наше решение ему (и никому) не нужно, мягко говоря. И тут у нас случился первый пивот.

Пивот № 1. Сделали свой СКУД: терминалы саморегистрации + турникетное решение

Пивот № 2. Решение для оффлайн-регистраций на мероприятия.

Я написал в сообщество выпускников Сколково что мы готовы поработать на оффлайн-регистрациях бесплатно ради тестирования нового продукта. Мы предложили новый стандарт аккредитации на мероприятия — участники получают смску с QR-кодом за час до начала, приходят и сканируют QR-коды на наших терминалах, принтер сразу печатает бейдж, участник сам забирает бейдж из принтера и наклеивает себе на одежду (или на сумочку, портфель, телефон). И тут тема полетела — десятки приглашений, разные сценарии регистрации, обнаружение незаметных багов, выкатка новых обновлений эпика по регистрациям на мероприятия по три раза в неделю, установление отношений с новым поставщиками. Мы внезапно обнаружили себя в новой индустрии, о существовании которой ранее не подозревали: event-индустрия. Решение для оффлайн-регистраций мы решили назвать скромно и лаконично — Check-in by PeoplePass, и вывести его в отдельный бренд. Регистрации участников на оффлайн-ивенты у нас проходили ярко, весело, с удовольстием, и без очередей. Ролик отражает общее настроение:

Тем временем, приехали считыватели. Мы «на коленке» собрали турникетное решение для Леши (который и подкинул нам идею) и я опубликовал в фейсбуре видео, на котором показывалось как я прохожу через турникет, открывая его телефоном. Через полчаса после публикации звонят правильные парни из MR Group и задают очень простой вопрос: «Что нужно, кроме денег, чтобы это решение завтра было у нас?». Через неделю у них действительно было это решение, благо считывателей из Голландии мы закупили с резервом: (анонс MR Group) + видео:

В середине марта возник вопрос — что делать дальше. Наш инвестор, оказавшись на самоизоляции не в России, посмотрел на досуге фильм «Эпидемия», в котором все закончилось внедрением QR-кодов. Мы созвонились на троих, и решили быстренько запилить систему выдачи QR-кодов для выхода из самоизоляции.

Пивот № 3. Система выдачи QR-кодов для выхода из самоизоляции.

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

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

Пивот № 4. Тикетная система и агрегатор анонсов на бизнес-мероприятия.

Середина апреля. Мы достали из загашника разработанный зимой логотип Check-in. За два дня нарисовали дизайн прототипа сайта. Выкупили домен check-in.ru. Доработали бек. Натянули дизайн на фронт. Прошла неделя. Прикрутили эквайринг — еще неделя. Посмотрели — не понравилось. Решили — если делаем агрегатора анонсов и тикетную систему, то не в духе «yet another ticket app», а сделаем нормально и современно. Другими словами, «все супер, но надо переделать».

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

Во-вторых, всем нужны подписчики. Поэтому у каждого спикера рядом с фоткой будет целый букет его/ее социальных сетей, на которые можно кликнуть, подписаться, подружиться. Есть даже Likee, не говоря уж о TikTok (FB, VK, odnoklassniki, telegram, Youtube, почта и прочие ссылки — да, есть).

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

В-четвертых, комиссии! Они должны быть ниже! Раза в полтора! Так и сделали.

В-пятых, кто задумывался почему на бесплатные онлайн-ивенты приходит так мало людей? Наш ответ — потому что забывают, не в последнюю очередь. Чтобы не забывали, мы за 10 минут направляем напоминалочку по СМС. Доходимость выросла в 2 раза (примерно с 30% до 55-60%, в некоторых случаях до 90%).

В-шестых, дизайн. Он должен быть современным. Красивым. Приятным. Понятным. Встраиваемые виджеты с блоком регистрации ТОЖЕ должны быть красивыми, функциональными и понятными.

Мы запустили check-in.ru в середине мая, то есть через месяц после начала работы, и сразу разместили анонс нашей подруги Марины Филипповой, президента ассоциации выпускников бизнес-школы IMD, об онлайн-встрече выпускников IMD с генеральным директором аэропорта Пулково. Одно из требований Марины было добавить возможность сбора благотворительных средств. За день до запуска мы добавили и эту возможность. В итоге собрали приличную сумму и сразу переслали в фонд «Дорога Жизни». Поэтому еще один момент:

В-седьмых: благотворительные средства должны доставляться получателям сразу после завершения сбора. Не раз в год. И напрямую от площадки, без посредников. Согласны?

Сейчас система работает в режиме бета-теста. Создавать анонсы и продавать билеты могут только организаторы, получившие от нас инвайт. Причина очевидна — мы живем по принципу «если ты доволен своим продуктом в момент вывода его на рынок, то ты его вывел слишком поздно». Мы не очень довольны своим продуктом (несмотря на то, что NPS от клиентов уже 9-10), и это нас мотивирует каждый день его улучшать, получая обратную связь от ранних организаторов и быстро выкатывая обновления. Мы сейчас живем в режиме 1-2 обновлений в день, сразу измеряя NPS и конверсии. Беклог по основным улучшениям чек-ина расписан до конца июля, но время пролетит быстро. Примерно в июле откроем систему для широкой публики.

Источник