Обобщенный сценарий обработки запросов

[Jammer]

Привет,

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

У заказчика есть главная(одна очередь?) и дочерние компании(подочередь очереди главной компании?; количество подочередей равняется количеству дочерних компаний?). Предполагается, что главный офис может видеть запросы всех дочерних компаний, которые, в свою очередь, видят только свои заявки.

Время наработки решения по кажой заявке(DeadLine) конкретного заказчика определяется приоритетом запроса(отдельный SLA).

Сейчас делегирование запроса представителю заказчика реализуется через отдельный статус Hold; время пребывания запроса в этом сосотоянии не учитывается при расчете SLA - DeadLine увеличивается на длительность пребывания запроса в статусе Hold.

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

Заранее благодарен за Ваши ответы и советы.

[JohniGo]

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

[Jammer]

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

Хочу услышать общую последовательность обработки запроса агентами+пользователями с комментариями опытных коллег - что, кто, как, где, когда: от создания до закрытия запроса.

[JohniGo]

Ну для начала, эт конечно RTFM, если еще не видели: http://doc.otrs.org/3.0/ru/html/.
Коротко могу рассказать, как работает у меня.
1. Создание заявки - 3 варианта - web (NTLM авторизация), почта (общий ящик техподержки - авмтоматическое создание тикетов) ну и звонок - пеший приход с поблемой (заносит агент от имени пользователя).
2. Все заявки валятся в очередь первой линии техподдержки. (очередь - склад заявок для конкреного агента или группы агентов если они занимаются одним и тем-же).
3. Общение происходит посредством заметок. При появлении заметки у тикета в почту уходит уведомление как клиенту так и агенту.
4. Агенты могут переносить заявку в другие очереди (отдельного диспетчера нет в штате).
5. Эскалация настроена не для SLA, а для каждой очереди (можно и так и так, но я пока организационно не готов к эскалации по SLA). При эскалации отправляется уведомление. Можно настроить функциональную - чтоб отправлялось уведомление всем участникам очереди или иерархическую, чтобы вышестоящии колллеги получили уведомление. Можно в общем-то и автоматом между очередями перемещать.
6. Заявку агенты закрывают сами после решения. Если решение не помогло, клиент ее открывает опять.

[Jammer]

Ну для начала, эт конечно RTFM, если еще не видели: http://doc.otrs.org/3.0/ru/html/.
....
5. Эскалация настроена не для SLA, а для каждой очереди (можно и так и так, но я пока организационно не готов к эскалации по SLA). При эскалации отправляется уведомление. Можно настроить функциональную - чтоб отправлялось уведомление всем участникам очереди или иерархическую, чтобы вышестоящии колллеги получили уведомление. Можно в общем-то и автоматом между очередями перемещать.

Спасибо за развернутый ответ.

Мануал активно читаю. Не понимаю суть понятия эскалации в OTRS; задавал отдельно вопрос на форуме, но ответа не получил. Можно немного подробнее об организации эскалации в отношении очереди и на основании SLA, мы, скорее всего, будем использовать второй вариант. В чем сложности 2-го варианта?

Еще один вопрос: установлен модуль ITSM, но расширить список доступных сервисов, как и добавить новые элементы SLA невозможно - отсутствуют кнопки добавления элементов на соответствующих формах. Что необходимо сделать для расширения этих двух списков, которые в данное время пусты?

[JohniGo]

Можно настроить 2 эти вараинта. Имеются временных 3 параметра эскалации. (первый ответ, ответ и решение).
Их можо настроить либо для кокретной очереди, тогда при перемещении в другую время сбрасывается, либо для SLA к которому соответсвенно приявязан конкретный сервис. Тогда время сбрасываться не будет (возможно нужно будет обнулиьт эскалации по очередям, не проверял, что будет если настроены обе, у кого боьлший приоритет).
У меня сейчасм используется первый вариант, т.к. пока сотрудники не готовы к рабюоте в рамках SLA (да и руководство не ставит такие сроки восстановления серсиса, которые реально сложно реализовать без коренной смены системы мотивации.. на которую в свою очередь неготово руководство.. ) Т.е. сложность-то не техническая, а исключительно организационная.

Текущий механизм работы с эскалациями:
Эскалация предстваляет собой уведомление (как в веб интерфейсе, так и соответвенно по почте) о наступлении события. При этом уведомление отправляется агентам, имеющим права 'ro' на данную очередь (легкий перепил родного примера с правами 'rw', как сделать тут уже писал). Соответвенно таким образом сможно гибко настраивать эскалацию отдельных очередей.

По поводу добавления сервисов и SLA - очевидно надо включить возможность их использования: Ticket -> Core::Ticket Ticket::Service.
И тогда все будет. (Честно сказать, давно настроил уже, могу ошибаться.)

P.S. Пользуйтесь поиском по крнфигурации системы. А еще лучше выбрать время и пролистать все вкладки настройки, почитав описания. некоторые вопросы пропадут, некоторые наоборот, появятся.
P.P.S. Рекомедую сперва разобраться с "голой" OTRS. От обилия настроек ITSM глаза разбегаются. Сам по первости хотел с наскока разобраться. Пришлось удалять пакеты.

[alexus]

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

[ALX]

Доброго времени суток всем участникам форума.

Вопрос к JohniGo (или мне надо поднимать отдельную тему?):

Вы писали:

3. Общение происходит посредством заметок. При появлении заметки у тикета в почту уходит уведомление как клиенту так и агенту.

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

Ткните начинающего, пожалуйста, - где RTFM'ить?

Заранее большое спасибо всем откликнувшимся.

[ALX]

Вопрос снят.

Нашел на англоязычном форуме:
http://forums.otterhub.org/viewtopic.ph ... ion#p51965

Re: Email notification when using note-internal

by 0trs » 29 Dec 2011, 03:24
This "Event: ArticleCreate" did it. It worked. Thanks so much

Может быть, кому-то поможет...