5 правил работы с тикетами
1. Правило «один на один»
Каждый тикет (он же — «баг») представляет собой взаимосвязь между двумя людьми: тем, кто заявил о проблеме, и тем, кто будет ее решать. Если это баг — сообщает о нем, разбирается, если это вопрос — задает его, отвечает. Неважно, какое количество людей с обеих сторон вовлечено в решение вопроса, в этой коммуникации участвуют только двое.
Ответственность того, кто создает тикет — рассказать о проблеме. Когда вы создаете тикет, вы настаиваете на том, что проблема существует: может сказать, что все работает, может утверждать, что у него такой ошибки нет, еще — что описание проблемы слишком мутное и никто не понимает, в чем, собственно, дело. Задача создающего тикет — обеспечить его жизнеспособность. Если вы создали тикет — вы его до самого момента закрытия.
Задача второй стороны — обеспечить решение. Если тикет назначен вам — ваша задача убедить вторую сторону, что ваше решение — самое лучшее. Вам могут говорить, что этого решения недостаточно, что оно неэффективно или не до конца решает проблему. Конечно, ваша задача — исследовать корни проблемы, просчитать все возможные варианты и предложить хорошее решение, но все это второстепенно, ведь ваша главная задача — закрыть тикет.
В один всегда продает другому свое видение вопроса.
2. Закройте его!
— это не чат, и вы здесь не для того, чтобы разговаривать. Вы здесь для того, чтобы решить свой вопрос. Тикеты, которые не закрываются неделями, это настоящий ночной кошмар как для заявителя, так и для технического специалиста: их сложно отслеживать и еще сложнее контролировать. Тикет может иметь сотни комментариев, которые в конце концов заставляют забыть, в чем же, собственно, была проблема.
Все это — ошибка обеих сторон. Тикет должен быть сформулирован кратко и по существу. Сценарий идеального тикета таков: проблема — уточняющие вопросы — короткое объяснение — решение — закрытие тикета, всем спасибо.
3. Не закрывайте его!
Каждый раз, когда вы обнаруживаете баг и создаете тикет, вы тратите свое время. Каждый раз, когда сотрудник техподдержки обрабатывает ваш тикет, тратит массу ресурсов.
Если вы подтверждаете закрытие тикета, а проблема толком не решена, вы выбрасываете свои деньги и деньги провайдера в мусорное ведро. Если тикет создан, нельзя сказать «Ладно, разберемся позже». Если он запущен, должны быть предприняты все меры для решения возникшей неполадки.
Посмотрите на это с такой стороны: когда вы создали тикет, у вас в голове была определенная задача, пошло не так. Если у вас в данный момент недостаточно времени, и вы закрываете вопрос, другой в будущем найдет то же баг и будет снова тратить время — свое и провайдера — на решение этой проблемы. Сделайте мир немного лучше, не закрывайте тикет до тех пор, пока вы не получили полноценный ответ на свой запрос.
4. Тсс….Не шумите!
Каждый раз, когда вы оставляете комментарий по тикету, адресуйте его — в ином случае ваш комментарий посчитают просто высказыванием своего мнения, тем, что называется в психологии «коммуникационным шумом». Помните, тикет — это общение между двумя участниками.
Всегда адресуйте свой вопрос/просьбу/требование конкретному человеку, с которым вы общаетесь для закрытия своей проблемы. Все остальное просто усложняет процесс решения проблемы, но ни в коем случае не помогает в нем.
5. Говорите громче
Всегда говорите о том, что вас не устраивает. Каждый раз, когда вы сообщаете о проблеме, объясните, что именно пошло не так. Это ваша задача — объяснить, что именно в продукте работает некорректно, что не задокументировано, в чем есть вопросы. Вы получили услугу, и это ваше право — сообщить о проблеме, и ваша обязанность — объяснить, что конкретно не соответствует вашим ожиданиям.
Формула тикета такова: «Вот что мы имеем, а вот что мы должны иметь». Вы как бы передвигаете проект из точки, А в точку Б: пошло не так в точке, А, и для всех нас было бы лучше оказаться в точке Б. Очевидно, что ваша задача — нарисовать эту линию из точки, А в точку Б.
Скажем, если у вас вопрос, это значит, что в документах недостаточно информации — и это корень проблемы. Вместо того, чтобы спрашивать: «Как подключить Х?», скажите: «В текущих документах нет информации о том, как подключить Х. Пожалуйста, дополните их».
Каждый раз, создавая тикет, чувствуйте себя художником — рисуйте четкую линию из точки А в точку Б.
Советы по работе с тикет-системой
Первое, что видят инженеры службы технической поддержки — это заголовок тикета. Он должен быть кратким, емким и максимально отражать суть описываемой проблемы. Если в тикете речь идет о неисправностях сервера, то в заголовке желательно указать его номер.
Приведем примеры корректных и некорректных заголовков:
| Некорректно | Корректно |
| ПРОБЛЕМЫ С СЕРВЕРОМ. | Проблемы с сетевой доступностью у сервера csXXXX |
Краткие и точные заголовки впоследствии помогут и вам лучше ориентироваться в собственных тикетах и находить среди них нужный.
Чем точнее, подробнее и логичнее описана проблема, тем быстрее смогут ее решить наши специалисты. Желательно, чтобы описание было подкреплено конкретными примерами. Если вы, например, пишете о проблемах с сетевой доступностью, то прилагайте к тикету ответы на 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.
Некоторые ошибки возникают только при работе с определенными браузерами. В таком случае нужно указать версию используемого браузера и приложить соответствующий скриншот.
Избегайте слишком кратких описаний: сотрудники техподдержки будут вынуждены задавать вам дополнительные вопросы, и на выяснение деталей уйдет немало времени, которое могло бы быть потрачено непосредственно на исправление неполадок.
Еще одно важное правило формулируется так: одна проблема — один тикет. Создавайте отдельный тикет для каждой из возникших у вас неисправностей — это поможет лучше скоординировать работы саппорт инженеров и ускорить рассмотрение проблемы. Кроме того, следование этому правилу также поможет вам быстрее осуществлять поиск по тикетам.
Если проблема, о которой вы уже сообщали и которая была решена, вдруг снова дала о себе знать, не создавайте новый тикет, а напишите об этом в том, который был посвящен этой проблеме ранее.
Закрывать тикет нужно только тогда, когда проблема окончательно решена. Даже если вы ничего не написали, закрытие тикета для инженеров технической поддержки является сигналом, сообщающим о том, что вас больше ничего не беспокоит.
Что значит тикет закрыт
Что такое тикет ордера?
Спасибо, Ваш голос учтён
Что такое тикет ордера?
Это словосочетание состоит из двух слов: тикет и ордер или на английском языке order ticket, что, переводится как бланк приказа. В отношении биржевой торговли это означает, что представитель брокерской конторы заполняет соответствующий бланк приказа, в который заносит приказ от своего клиента, поступивший по телефону: Джим, голубчик, купи мне 100 акций Дженерал Моторс по цене 10 долларов за акцию. После выполнения приказа и покупки акций брокерская контора сохраняет эти бланки на всякий случай проверки официальными органами, если клиент подаст в суд, что его обманули и купили не те акции, которые он хотел.
В терминале МТ 4 под этим понятием подразумевается присвоение каждому ордеру, отложенному или рыночному уникального ордера, который отражается в терминале, к которому может обращаться советник форекс, присваивая ему магическое число.
В широком смысле это выражение подразумевается как бланк-форма, куда заносятся данные обо всем или даже в лотерейный билет.
А билет в один конец переводится как One Way Ticket
Спасибо, Ваш голос учтён
Комментарий
Спасибо, Ваш голос учтён
Комментарий
Что такое тикет ордера?
В торговом терминале все ордера имеют уникальный номер или идентификатор, который присваивается автоматически и после совершения и закрытия сделки отображается, вместе с остальной информацией, в журнале сделок. Этот номер называют order ticket или тикетом ордера.
Не важно, был ли это отложенный или рыночный ордер, для всех видов и типов работает присвоение уникального индивидуального ордера. Данная функция предусматриваете корректную работу терминала в общем, и всех дополнительных программ и функций, будь то торговые роботы, советники и т.д.
Найти данную информацию в платформе МТ-4, можно в журнале сделок в частности:
А так же в истории счёта, сформировав нужный вам период:
Спасибо, Ваш голос учтён
Комментарий
Спасибо, Ваш голос учтён
Комментарий
Тикет ордера широко используется в программировании роботов или советников для того, чтобы разграничивать несколько открытых позиций и по определенным условиям эти ордера закрывать.
Спасибо, Ваш голос учтён
Комментарий
Спасибо, Ваш голос учтён
Комментарий
Что такое тикет ордера?
Спасибо, Ваш голос учтён
Комментарий
Тикет ордера, это уникальный номер, состоящий исключительно из цифр. Он присваивается каждому распоряжению клиента открыть или закрыть позицию. То есть, каждому торговому приказу, или ордеру, что одно и то же. Для трейдера, который не занимается советниками, до этих тикетов, в принципе, нет никакого дела.
Когда трейдер глядит на окно «торговля», он, прежде всего, обращает внимание на инструмент, направление сделки и объем. Исходя из этой информации, он может вспомнить, по каким соображениям открывал или закрывал какую-то позицию. Вряд ли кому придет в голову где-то отдельно записывать тикеты.
Но вот если будут какие-то спорные моменты насчет исполнения сделок, то в технический отдел может попросить тикеты тех проблемных ордеров.
Спасибо, Ваш голос учтён
Комментарий
Если рассматривать понятия отдельно, то тикет является уникальным номером, что устанавливается для определённого ордера. Ордер – это запрос, который принят на торговой площадке и работает по требованиям платформы. Поэтому запрос не сможет работать без уникального номера, ведь данный идентификатор создан, чтобы проводилась корректная работа в торговом терминале или другой программе.
Из этого следует, что тикет ордера – это номерной запрос. При этом запрос должен составляться грамотно на торговой платформе, иначе работа будет проводиться некорректно. Уникальный номер ордера несёт обозначение именно внутри программного обеспечения, что позволяет клиенту осуществлять торговлю на платформе.
Ордер может быть немедленного исполнения, например, покупка или продажа по текущим рыночным ценам в определённом объёме. Некоторые ордера такие, как отложенные несут приказ на то, чтобы осуществить операцию на платформе по определённым условиям.
Каждый клиент, который проводит продажу или покупку на торговой площадке должен пользоваться тикет ордером. Ведь без этого не будут соблюдены условия клиентом по торговым операциям на платформе. А значит, операция не сможет осуществиться клиентом.
Тема: Возможность ответа в тикет
Опции темы
Поиск по теме
Не нашел как пометить тикет «прочитанным», после того как прочитал тикет(через api), тег unread не исчезает.
Что значит «закрыть тикет»?
Это и есть сделать прочитанным?
Я думал, что закрытый тикет = тикет в архиве
Здравствуйте, да, закрытий тикет это тикет в архиве. Для пометки тикета как прочитанного попробуйте использовать func=clienttickets.view&elid=код_тикета
Отвечать в тикет как Client у меня получилось, все работает отлично, но если залогиниться как Provider, то выдает такой ответ
Запрос такой же как для клиента, изменил только функцию с clienttickets.edit на tickets.edit
Попробуйте добавить в запрос
responsible=id_отдела
спасибо, теперь, видимо, нужно какое-то имя
Вызовите функцию без sok=ok. Получите в XML значение name, которое надо передать.
Подозреваю, что это название запроса.
Тега name там нет, если речь о названии тикета, то это тег subject, непонятно только зачем его передавать, сейчас попробую
__
Указал name=название тикета
Здравствуйте, проще всего Вам чтобы не гадать выполнить нуное действие в интерфейсе и посмотреть в логе какой при этом был запрос.
При ответе клиента и админа набор параметров разный, так как к них разные права доступа
Советы по работе с тикет-системой
Предыдущая статья об организации работы службы нашей техподдержки стала предметом оживленной дискуссии. Многие читатели высказали сомнения в том, что эффективная коммуникация между саппорт-инженерами и пользователями может осуществляться исключительно через тикет-систему. Наша практика показывает, что это вполне возможно при соблюдении определенных условий. Чтобы у новых клиентов не возникало сомнений, а коммуникация была еще более эффективной и продуктивной, мы решили опубликовать набор советов по работе с тикет-системой.
Тикет-система — специальный раздел нашей панели управления, с помощью которого осуществляется взаимодействие между клиентами и специалистами службы технической поддержки.
Тикетом называется письменное обращение клиента в службу поддержки по какому-либо вопросу или проблеме. В тикет-системе сохраняется вся цепочка сообщений между клиентом и саппорт-инженерами.
Тикет-система является главным инструментом взаимодействия с клиентами. С ее помощью клиенты могут:
Ее несомненные плюсы заключаются в следующем:
Особо следует отметить, что быстрое решение проблемы во многом зависит от того, как составлен тикет. На какие моменты при составлении тикета следует обратить особое внимание?
Первое, что видят инженеры службы технической поддержки — это заголовок вашего тикета. Он должен быть кратким, емким и максимально отражать суть вашей проблемы. Если проблемы касаются сервера, то желательно указать в заголовке номер сервера, о проблемах с которым идет речь. Приведем примеры корректных и некорректных заголовков:
| Некорректно | Корректно |
| ПРОБЛЕМЫ С СЕРВЕРОМ. | Проблемы с сетевой доступностью у сервера csXXXX |
Краткие и емкие заголовки впоследствии помогут и вам лучше ориентироваться в собственных тикетах и находить среди них нужный.
Чем точнее, подробнее и логичнее вы опишете свою проблему, тем быстрее смогут ее решить наши специалисты. Очень желательно, чтобы описание было подкреплено конкретными примерами. Если вы, например, пишете о проблемах с сетевой доступностью, то прилагайте к тикету ответы на 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.
Некоторые ошибки возникают только при работе с определенными браузерами. В таком случае нужно указать версию используемого браузера и приложить соответствующий скриншот.
Избегайте слишком кратких описаний: сотрудники техподдержки будут вынуждены задавать вам дополнительные вопросы, и на выяснение деталей уйдет немало времени, которое могло бы быть потрачено непосредственно на исправление неполадок.
Еще одно важное правило формулируется так: одна проблема — один тикет. Создавайте отдельный тикет для каждой из возникших у вас неисправностей — это поможет лучше скоординировать работы саппорт инженеров и ускорить рассмотрение проблемы. Кроме того, следование этому правилу также поможет вам быстрее осуществлять поиск по тикетам.
Если проблема, о которой вы уже сообщали и которая была решена, вдруг снова дала о себе знать, не создавайте новый тикет, а напишите об этом в том, который был посвящен этой проблеме ранее.
Закрывать тикет нужно только тогда, когда проблема окончательно решена. Даже если вы ничего не написали, закрытие тикета для инженеров технической поддержки является сигналом, сообщающим о том, что вас больше ничего не беспокоит.
