Разный набор действий по заявке

[ykolesnikov]

Добрый день!
Давно обратил внимание, теперь хочу разобраться.
При просмотре заявки агентом в развернутом виде, ниже области заметок/сообщений, есть меню действий по заявке - ниже заголовка с темой сообщения.
Так вот выбирая разные строки мы видим, что набор пунктов этого меню меняется. Скажем, то пропадает, то появляется кнопка "Ответить", "Разделить", "Переслать".
Чем это обусловлено?
Логично было предположить, что агент должен работать с последним сообщением, но в этом случае, не все действия доступны и надо выбирать строку, где есть нужные действия. И в инструкции агентам надо все эти варианты описывать.
Права у агента в очереди полные (rw).
Или я что-то неправильно настроил?

[ykolesnikov]

А с этим кто-нибудь прольет свет?

[alexus]

Ваши 2 поста связаны по логике. Набор действий проистекает от типа заметки.

[ykolesnikov]

Вроде и понятно, но не могу постичь логику подхода.
Если некий набор действий допустим для заявки, почему бы ему не быть независимо от типа заметки? Ведь агент, порыскав по заметкам все равно может стать там, где есть действия, которых нет в других заметках и выполнить их?!? Или это некая защита? От дураков с инициативой никто не спасет.

[alexus]

Защититься от дурака еще можно, а вот от злодея практически невозможно, если у него есть права. Вопрос ИБ и вопрос контроля за общением с клиентами со стороны СТП - суть комплексные.

[Creative]

С позволения присутствующих вставлю свои пять копеек.

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

К примеру если заметка создана агенетом и имеет тип "внутренняя", совершенно нелогичным было бы открывать для такой заметки доступ к функции пересылки, либо ответа по почте, ведь клиент при просмотре заявки просто не видит эту заметку. И случайное (я не говорю сейчас о преднамеренном) исполнение действия с применением цитирования такой заметки просто внесёт некоторое замешательство в ход мыслей клиента, и вынудит его задать уточняющие вопросы на тему "а я не совсем понял что вы здесь упомянули, я не вижу этого сообщения". Чего нам совершенно не хочется, так как в этом случае клиенты своим любопытством и уточняющими вопросами просто будут создавать дополнительную нагрузку на саппорт.

Так что логика проста... из набора действий по контексту исключаются нелогичные действия.

Ведь агент, порыскав по заметкам все равно может стать там, где есть действия, которых нет в других заметках и выполнить их?!? Или это некая защита? От дураков с инициативой никто не спасет.

Здесь я полностью согласен.
"Бесполезно придумывать защиту от дурака - ведь дураки так гениальны." - (с) Э.Мэрфи, DEC

Но вопросы связанные с организацией работы и регламентированием действий, как я всегда напоминаю клиентам, нельзя возлагать на систему.В деятельности любой службы могут возникать ситуации требующие принятия решений. Это, как справедливо заметил Алексей, уже вопросы решаемые организационными и зачастую мотивационными методами.
Плюс к этому... Нельзя ни одной пусть даже самой проработанной автоматизированной системе доверять управление процессами. Система не умеет принимать решения. А на описание и программирование алгоритмов всех возможных вариантов одного и того же события уйдёт сотни, если не тысячи лет.

[ykolesnikov]

Это не на пять копеек, а на целый рубль.
Согласен с Вами полностью, сам это пропагандирую.
+5 рублей за то, что по конкретному, своему вопросу, наконец, понял (лучше поздно, чем никогда!) что это меню относится не к заявке в целом а к конкретной заметке (хотя выполняемы действия, в конечном итоге, могут относиться и к заявке, например ее закрытие через следующее сосотояние), отсюда и недоумения. Наводит на мысль - прикрыть лишние телодвижения типа (Переслать и Возвратить) для агентов - исполнителей и возложить сию миссию на менеджера заявок или прикрыть вообще, т.к. имеется и без того много других возможностей, дабы не засорять мозги вариантами действий.
Спасибо.

[Creative]

...наконец, понял (лучше поздно, чем никогда!) что это меню относится не к заявке в целом а к конкретной заметке (хотя выполняемы действия, в конечном итоге, могут относиться и к заявке, например ее закрытие через следующее сосотояние), отсюда и недоумения.

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

Наводит на мысль - прикрыть лишние телодвижения типа (Переслать и Возвратить) для агентов - исполнителей и возложить сию миссию на менеджера заявок или прикрыть вообще.

Здесь уже стоит видимо обратиться к регламенту по которому у вас распределены роли. Я например полагаю что навряд ли стоит заводить такую роль как менеджер заявок. А право на отклонение (насколько я понимаю назначение функции "Возвратить", так как сам её ещё не тестировал) запросов отдать менеджеру услуг. Единственное, при достаточно большом количестве сотрудников саппорта может иметь смысл завести такую вспомогательную роль как менеджер очереди, дабы уменьшить нагрузку на менеджера услуг.
Совсем прикрывать возможность отклонить, а тем более перенаправить заявку, думаю не стоит. Так как всегда должна быть возможность отказать в выполнении заявки, по причине (к примеру) отсутствия запрашиваемой услуги, грубого нарушения условий договора (это для аутсорсеров)и т.п. А уж тем более должна быть сохранена возможность отправить данные на линию поддержки более высокого уровня. Элементарный случай, отправка данных разработчику продукта в рамках выполнения работ по заявке.

Спасибо.

На здоровье, приходите ещё

[ykolesnikov]

Здесь уже стоит видимо обратиться к регламенту по которому у вас распределены роли. Я например полагаю что навряд ли стоит заводить такую роль как менеджер заявок. А право на отклонение (насколько я понимаю назначение функции "Возвратить", так как сам её ещё не тестировал) запросов отдать менеджеру услуг. Единственное, при достаточно большом количестве сотрудников саппорта может иметь смысл завести такую вспомогательную роль как менеджер очереди, дабы уменьшить нагрузку на менеджера услуг.
Совсем прикрывать возможность отклонить, а тем более перенаправить заявку, думаю не стоит. Так как всегда должна быть возможность отказать в выполнении заявки, по причине (к примеру) отсутствия запрашиваемой услуги, грубого нарушения условий договора (это для аутсорсеров)и т.п. А уж тем более должна быть сохранена возможность отправить данные на линию поддержки более высокого уровня. Элементарный случай, отправка данных разработчику продукта в рамках выполнения работ по заявке.

Теоретически, Вы правы. В данном случае, под Менеджером заявок я понимал обе роли - и заявок и услуг, она де-факто уже существует. Менеджер очереди, мне не очень понятен, если только это не менеджер очереди Общая (см выше менеджер заявок). Отказ с объяснением причины можно сделать средствами верхнего меню - Заметка, Закрыть и т.д. с типом заметки внешняя и следующим состоянием "закрыта" или через стандартные ответы. Кроме того, я пробовал сегодня покрутить возможности этих опций и получается, что при пересылке, если я правильно все сделал, не меняя других настроек экрана Forward пересылается текст последней заметки, а не содержание заявки или надо кодировать, чтобы добиться нужного.
Кроме того есть мне пока непонятные ограничения на адрес пересылки, хотя это может быть связано с нашим почтовиком. Есть сообщения типа - Укажите правильно адрес email или не используйте локальный адрес email (что это такое?)