Механизм передачи заявок между очередями

Обсуждение вопросов и решений

Модератор: ykolesnikov

Ответить
elislis
OTRS Новобранец
Сообщения: 13
Зарегистрирован: 16 апр 2013, 07:07

Механизм передачи заявок между очередями

Сообщение elislis » 29 апр 2013, 21:40

Здравствуйте! Подскажите пожалуйста, как лучше организовать такой механизм:
Хотелось бы, чтобы связь с Клиентами осуществлялась только из одной очереди. Есть очередь Общая. Из нее письма уходят в Отдел_1, Отдел_2 и тд. после решения проблемы письма с заметками попадают обратно в Общую, откуда агенты уже отвечают клиентам. Желательно как-то немного автоматизировать эти все переходы.
Придумали такое решение: При переносе писем из Общей в Отдел_1 ставится галочка чекбокс у свободного поля "Перенесено". После решения проблемы в Отдел_1 тикет переносится назад в Общую(с созданием заметки). Если эскалация наступила, а никто с проблемой не разобрался, тикет из Отдел_1 переносится назад в Общую автоматически.

Вижу такой минус данного подхода - неудобно осуществлять быстрый перенос в другие очереди (Приходится в окне типа newWindow писать заметки, менять владельца и тд) . Посоветуйте пожалуйста, как еще можно было бы реализовать такой механизм?


И еще вопрос - возможно ли автоматически изменять значения динамических полей при переносе заявки?

Creative
OTRS Новобранец
Сообщения: 132
Зарегистрирован: 22 июн 2011, 14:33
Откуда: Татарстан, Альметьевск

Re: Механизм передачи заявок между очередями

Сообщение Creative » 30 апр 2013, 07:18

Как-то всё сложно и нерационально.

Расскажите про ваши процессы и иерархическую организацию служб.
Сдаётся мне, решение с очередями не совсем верное.
Хотя если быть точным, оно совсем не верное :) (каламбурчик такой получился).
Мозг человека обычно загружен лишь на 10% своей мощности, остальное - резерв для операционной системы.

OTRS 3.1.4; ITSM 3.1.6; Ubuntu Server 12.04 LTS
Андрей Ананьев

elislis
OTRS Новобранец
Сообщения: 13
Зарегистрирован: 16 апр 2013, 07:07

Re: Механизм передачи заявок между очередями

Сообщение elislis » 30 апр 2013, 09:10

У нас есть Клиентский отдел, есть еще другие отделы - например IT, Бухгалтерия.
Мы хотим, чтобы тикеты приходили в клиентский отдел, потом ребята раскидывали их по очередям в зависимости от типа проблемы. Плюс ПостМастер фильтры тоже раскидывают тикеты. Хочется, чтобы на заявки отвечал Клиентский, а в IT и бухгалтерии их просматривали. Но не очень здорово ставить права на очередь только просмотр, потому что иногда понадобится отвечать. При эскалации тикеты из IT выносятся в очередь Эскалация_IT, доступную ответственному по эскалациям. И вот хочется, чтобы те особенные тикеты, которые пришли из Клиентского, после эскалации назад в Клиентский и возвращались. Как-то так :)

alexus
OTRS Гуру
Сообщения: 5192
Зарегистрирован: 20 сен 2010, 18:17
Откуда: Москва
Благодарил (а): 92 раза
Поблагодарили: 82 раза

Re: Механизм передачи заявок между очередями

Сообщение alexus » 30 апр 2013, 09:15

elislis писал(а):Подскажите пожалуйста, как лучше организовать такой механизм
Опишите Вашу задачу не так, как Вы УЖЕ видите ее решение в OTRS, а как Вы видите процесс обработки заявки в общем. Просто представьте, что у вас нет никакого OTRS.
elislis писал(а):Хотелось бы, чтобы связь с Клиентами осуществлялась только из одной очереди
Вот это чем, например, обусловлено? В чем истинный смысл? Ведь по идее клиент вообще не видит, в какой очереди обрабатывается тикет.
С уважением,
Алексей Юсов

Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal

Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!

Creative
OTRS Новобранец
Сообщения: 132
Зарегистрирован: 22 июн 2011, 14:33
Откуда: Татарстан, Альметьевск

Re: Механизм передачи заявок между очередями

Сообщение Creative » 30 апр 2013, 10:18

Не совсем понятно конечно, почему IT или бухгалтерия не могут напрямую ответить клиенту. Зачем это посредничество? А если клиент захочет получить ответ на дополнительный вопрос по проблеме? Так и будет клиентский отдел работать "передастами"?

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

Клиентский отдел при этом должен будет общаться с клиентом по заявке и назначать исполнителя по конкретной заявке. А "внутренние" отделы будут писать служебные заметки по решениям. Клиентский отдел соответственно будет при контакте с клиентом дублировать эти заметки во внешних.

Ерундистика конечно это, и процессы надо строить по другому, без дублирования. Но раз так хотите, обозначенное решение как вариант.
При этом "внутренним" отделам не обязательно давать "RW" на группу. достаточно дать "RO" и дополнительные действия которые им доступны.
В дайджесте можно сделать для работы только с назначенными заявками отдельный виджет, засунуть этих "внутренних" агентов в доп группу и объявить этот виджет только для данной группы.

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

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

З.Ы. И ещё один момент, что такое очередь для эскалаций и за каким нужен отдельный сотрудник отвечающий за эскалации (совершенно непонятно, каким образом он должен за них отвечать, эскалация это даже не процесс а событие) и что будет если он "проотвечается"... будет эскалация за которую будет отвечать "отвественный по эскалациям ответственных за эскалации"?
Мозг человека обычно загружен лишь на 10% своей мощности, остальное - резерв для операционной системы.

OTRS 3.1.4; ITSM 3.1.6; Ubuntu Server 12.04 LTS
Андрей Ананьев

alexus
OTRS Гуру
Сообщения: 5192
Зарегистрирован: 20 сен 2010, 18:17
Откуда: Москва
Благодарил (а): 92 раза
Поблагодарили: 82 раза

Re: Механизм передачи заявок между очередями

Сообщение alexus » 30 апр 2013, 11:42

Здесь надо четко понимать, для чего используется OTRS, как происходит обработка запроса с учетом специфики процесса. Без этого выбор решения сравним с поиском черной кошки в темной комнате.
С уважением,
Алексей Юсов

Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal

Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!

Creative
OTRS Новобранец
Сообщения: 132
Зарегистрирован: 22 июн 2011, 14:33
Откуда: Татарстан, Альметьевск

Re: Механизм передачи заявок между очередями

Сообщение Creative » 30 апр 2013, 14:21

alexus писал(а):Здесь надо четко понимать, для чего используется OTRS, как происходит обработка запроса с учетом специфики процесса. Без этого выбор решения сравним с поиском черной кошки в темной комнате.
В данном случае было бы хорошо понять вообще что это за процесс. В таком виде как его описал ТС, понять его трудновато конечно. И моё решение это как вариант технической реализации варианта когда де-факто есть несколько линий но с клиентом работает только 1-я (а это есть модель больше похожая на работу диспетчерских служб)
С одной стороны приём и обработку заявок ведёт клиентский отдел (1-я линия), с другой стороны вроде как IT и Бухгалтерия тоже должны просматривать. Для чего?
Что это за функция?
Наставничество?
Наблюдение?
Или же это отделы 2-й линии?
В таком случае почему после эскалации на 2-ю линию клиенту решение представляет 1-я линия? По классике жанра 1-я линия после выдачи решения на другой линии максимум что должна сделать, это отмониторить и подтвердить успешное решение инцидента, но никак не дублировать сообщения 2/3-й линий и не выступать в роли "передастов".
И самое интересное... что же это всё таки за "ответственный за эскалации" и почему у него отдельная очередь :)

Такое построение, как описанное в первом сообщении, очень напоминает одну сценку из Мадагаскар 2.

- "Надо набрать высоту. Иначе мы погибнем. И поскорее. Пе-ре-дай."
...
...
...
- "Не набирать высоту. Пусть мы погибнем. Лишь бы скорее. По-пу-гай."
- "Ты уверен?"
Мозг человека обычно загружен лишь на 10% своей мощности, остальное - резерв для операционной системы.

OTRS 3.1.4; ITSM 3.1.6; Ubuntu Server 12.04 LTS
Андрей Ананьев

Ответить