Создание опросника для оператора техподдержки

[usasacm]

Здравствуйте уважаемые форумчане.

Внедряем OTRs на предприятии, по большей степени все устраивает, вот только наткнулись на одну проблемку.
Чтобы сбить большинство заявок для передачи на 2 линию, требуется создать опросные листы для операторов техподдержки, например (заявка на неработающий принтер, оператор открывает опросник и начинает задавать пользователю вопросы и т.д.), отсюда вопрос есть ли такая функциональность в стандартной комплектации? Сложность в том, что на C#, PHP это я могу сделать, а вот с Perl вообще не в зуб ногой. Может подскажите с чего начать. Я понимаю в OTRs модульная система, один модуль - несколько файлов, а вот что дальше с ентим делать, не особо понимаю.

Если уж не трудно, то подскажите.

[usasacm]

Значит ни кто ни чего не знает?

[Romano]

А используя внешнюю заметку нельзя задать все нужные вопросы?

[yuri0001]

Если оператор создает заявку сам, как, например, Новая телефонная заявка, то можно создать шаблоны с такими вопросами в теле заявки. При выборе шаблона будут заполняться поля заявки, а в тесте можно составить Ваш опросник и задавая вопросы по телефону, заполнять поля опросника. Смотрите тему про шаблоны в разделе Howtos

[usasacm]

Если оператор создает заявку сам, как, например, Новая телефонная заявка, то можно создать шаблоны с такими вопросами в теле заявки. При выборе шаблона будут заполняться поля заявки, а в тесте можно составить Ваш опросник и задавая вопросы по телефону, заполнять поля опросника. Смотрите тему про шаблоны в разделе Howtos

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

[usasacm]

А используя внешнюю заметку нельзя задать все нужные вопросы?

Вы имеете ввиду, что допустим создаем шаблон заявки, там указываем ссылку на какой либо внешний опрос (который где то отдельно храним)?

[yuri0001]

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

А форматировнанный текст в тело(текст) можно подставить через файл локализации ru_custom. В теме про шаблоны об этом тоже есть. А про внешнюю заметку Вы неправильно поняли, это из-за Вашего еще малого знания OTRS. Внешняя заметка - это заметка, текст которой доступен для прочтения клиенту.

[usasacm]

Спасибо большое за консультацию, буду копать дальше.

[alexus]

Если у Вас 3.2 - попробуйте Process Management.

[usasacm]

Если у Вас 3.2 - попробуйте Process Management.

Мысль конечно отличная, но там разбираться долго, а то Process Management не особо интуитивный. Если у Вас есть доки с примерами, то буду благодарен.

[alexus]

doc.otrs.org - там все достаточно прозрачно.

[Creative]

Господа присяжные заседатели

А если задуматься над следующим вопросом.
Что есть такое, опросный лист?
Элемент, одна из составляющих технологии работы с клиентом в службе поддержки. Технологии являющейся внутренним стандартом.

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

Дык я к чему это всё
А почему бы и в своём инструменте не подумать над применением функциональности одной из составляющий базы знаний. То бишь, как это говорится, "FAQ вам в руки".

Для категории можно задать видимость только для определённых групп, к примеру для группы "1-st line" (Это чтобы технарям глаза не мозолило). Для самой статьи дать доступность только для агентов. Всех кому положено читать и исполнять эти опросники добавить в дополнительную группу "1-st line"
И использовать функцию вставки текста статьи в заявку.
В самой статье заполнить только одну секцию и в ней расписать сценарий опроса.
Таких статей можно создавать сколько душе угодно, при этом не нагружая интерфейс кучей кнопочек с темплейтами (как в варианте предложенном Юрием).
Единственная "загвоздка", это приучить агентов пользоваться этими статьями. Хотя это уже вопросы мотивации.
С другой стороны в плане дальнейшего развития, можно вызывать вставку статьи с определённым номером при выборе определённой классификации по сервису или типу заявки или их комбинации (это я думаю с применением java можно реализовать).

А дальше, на сколько фантазии хватит.

[ykolesnikov]

Хорошая идея, Андрей!
Имеет смысл взять на заметку.

[alexus]

А вот я с Андреем не согласен. Опросник нужен для того, чтобы понять что случилось, т.е. для диагностики. А ФАК поможет только если вы точно знаете (ну или думаете, что точно знаете ), что ищете.
Так что на мой взгляд это разные задачи. И притягивать сюда "за уши" ФАК нет никакого смысла.

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

[Creative]

А вот я с Андреем не согласен. Опросник нужен для того, чтобы понять что случилось, т.е. для диагностики. А ФАК поможет только если вы точно знаете (ну или думаете, что точно знаете ), что ищете.
Так что на мой взгляд это разные задачи. И притягивать сюда "за уши" ФАК нет никакого смысла.

Стоп паровоз

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

В любом случае опросник в его практическом применении на 1-й линии больше подходит на роль приёма, предназначенного для сбора более подробных сведений об инциденте, а не на роль средства для диагностики.
Пошаговая диагностика оператором 1-й линии (не обладающим, напомню, узкопрофильными навыками для полноценного анализа причин инцидента по каждой конкретной ситуации) возможна, по моему мнению, вообще только при применении функциональности экспертных систем.
Мы же сейчас говорим, как я понял, о первичном сборе сведений для детализации запроса с уровня "У меня тут не печатается" (обычно заявляемого пользователем) до уровня "программа вась-вась при отправке на печать на принтер Маши выводит пустой лист, из остальных программ на печать выводится нормально" (то что обычно требуется для передачи заявки профильным специалистам).
Ну и по классике. Сначала выполняется данный опрос и классифицируется заявка, а уже после производится поиск типового решения инцидента по FAQ и другим источникам, при отсутствии быстрого решения заявка эскалируется на вторую(третью) линию. Собранная при опросе информация как раз и избавляет от необходимости дополнительно классифицировать инцидент при передаче оператором 1-й линии, либо (ещё хуже) отдавать классификацию на откуп 2-й (3-й) линии, занимая больше их времени из-за отсутствия подробных сведений.

При этом служебная статья в FAQ в категории "опросы для регистрации заявок", подкатегории "проблемы печати", под названием "нет вывода на печать" поможет оператору 1-й линии задать ряд последовательных вопросов для сбора сведений. Сама статья не будет по сути являться элементом FAQ, а будет служебной инструкцией, или даже технологической картой. Если применять метод "менеджерского" мышления, то такую статью скорее можно назвать не опросником, а диалоговым модулем. В полезности и применимости диалоговых модулей в работе 1-й линии я думаю вы не сомневаетесь

Кстати, у cape-it в их KIX-е, есть реализация данного приёма. Они их назвали "Текстовые модули". Окно со списком модулей располагается в side области при вводе телефонной заявки и в compose модулях. Сами тексты управляются из админки, была вроде даже какая то привязка, то ли к очередям то ли к сервисам. Я даже подумывал углубиться в документацию и заняться частичной интеграцией отдельных функций KIX в нашу систему, благо набор файлов и опций для каждой функции в документации подробно расписан, так что не составит думаю особого труда выдернуть часть файлов из KIX и вшить их у себя. Но это пока задача на развитие.

[alexus]

Если рассматривать данное решение, как фактическую подмену части опроса (условно динамическая часть) категориями и статьями FAQ и части (статическая часть) в виде набора вопросов в статье FAQ, то конечно - ДА! Подход имеет право быть !
Но все равно это не избавляет нас от необходимости структуризации экспертных знаний . У нас тут недавно родилась идея создания виджета для динамического поиска FAQа по факту введенных данных в сабже тикета. Поиск можно вести по ключевым словам FAQа или\и по содержанию описания проблемы в статье.

[Creative]

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

Идея хорошая. Только писать свой поисковый движок я думаю нет смысла. Да и поиск по ключевикам, вроде как и так есть.
А вот прикрутить, к примеру, поиск от яндекса... Он всё-таки немного поумнее, чем поиск по маске, который используется в OTRS.