Добрый вечер!
Ситуация такова: у нас есть клиенты (К1), которые через клиентский интерфейс задают нам (агентам А) вопросы. Однако, поскольку у них самих есть конечные пользователи (К2), чаще удаленные, нужно последним также дать возможность задавать через OTRS вопросы. В итоге получаем (на бумаге) две параллельные схемы:
1) К1 --> А (клиенты создают тикеты, мы А, как первая линия поддержки)
2) К2 --> К1 --> A (К2 клиенты, К1 - первая линия (должны первичная обработка тикетов, возможно, сортировка, ответы на простые вопросы; при наличии сложностей эскалируют на нас), А - мы решаем серьезные вопросы и кидаем их обратно К1)
(!)важная особенность схемы 2 - нас (А) не интересует, как К1 доведет решение тикета до К2, то есть для нашей системы связь К1-->К2 одностороняя!!!
(!!)вторая важная особенность: от К2 тикет (заявка приходит через почту, то есть не через интерфейс)
Есть мысли по технической реализации? Может кто встречался?
На данный момент вижу один вариант: через почту тикет от К2 ложится в очередь, но сразу шедулером (автоматически) ставится ответ, поэтому он практически тут же возвращается К1, который либо закрывает его (и сообщает К2), либо эскалирует на А. Поругайте.
Заранее благодарен!
ситуация, когда клиент может быть агентом
Модератор: ykolesnikov
Re: ситуация, когда клиент может быть агентом
Вопрос не очень понятен.
У Вас К1 создает заявки от себя лично или все-таки от имени К2, в случае, когда не может ответить сам?
Или, грубо говоря, я, специалист первой линии, имею рабочее место и у меня вышел из строя коммутатор и починить его сам я не могу. Здесь я выступаю чисто как клиент. И должен создавать заявку от своего имени, будучи зарегистрированным в системе как клиент, хотя и являюсь агентом по отношению к обслуживаемой мною группы клиентов. Здесь вопрос только в разделении таких заявок для статистики.
При нормальной схеме работы и организации ее в виде 2-х линий поддержки, заявки клиента на вторую линию никогда не должны попадать минуя первую, либо должен быть четкий критерий иерархической эскалации (превышение времени ожидания ответа, определенные типы заявок и т. д. Кстати, не надо сбрасывать со счета и хитрость клиента, который, при определенном опыте, будет ставить тип, приводящий к эскалации, а на самом теле, надо только шнур в розетку воткнуть. )
У Вас К1 создает заявки от себя лично или все-таки от имени К2, в случае, когда не может ответить сам?
Или, грубо говоря, я, специалист первой линии, имею рабочее место и у меня вышел из строя коммутатор и починить его сам я не могу. Здесь я выступаю чисто как клиент. И должен создавать заявку от своего имени, будучи зарегистрированным в системе как клиент, хотя и являюсь агентом по отношению к обслуживаемой мною группы клиентов. Здесь вопрос только в разделении таких заявок для статистики.
При нормальной схеме работы и организации ее в виде 2-х линий поддержки, заявки клиента на вторую линию никогда не должны попадать минуя первую, либо должен быть четкий критерий иерархической эскалации (превышение времени ожидания ответа, определенные типы заявок и т. д. Кстати, не надо сбрасывать со счета и хитрость клиента, который, при определенном опыте, будет ставить тип, приводящий к эскалации, а на самом теле, надо только шнур в розетку воткнуть. )
С уважением
Ю. Колесников
OTRS 3.3.1, ITSM 3.3.1, SUSE 12, MySQL5
Ю. Колесников
OTRS 3.3.1, ITSM 3.3.1, SUSE 12, MySQL5
Re: ситуация, когда клиент может быть агентом
yuri0001 писал(а):Вопрос не очень понятен.
У Вас К1 создает заявки от себя лично или все-таки от имени К2, в случае, когда не может ответить сам?
Или, грубо говоря, я, специалист первой линии, имею рабочее место и у меня вышел из строя коммутатор и починить его сам я не могу. Здесь я выступаю чисто как клиент. И должен создавать заявку от своего имени, будучи зарегистрированным в системе как клиент, хотя и являюсь агентом по отношению к обслуживаемой мною группы клиентов. Здесь вопрос только в разделении таких заявок для статистики.
При нормальной схеме работы и организации ее в виде 2-х линий поддержки, заявки клиента на вторую линию никогда не должны попадать минуя первую, либо должен быть четкий критерий иерархической эскалации (превышение времени ожидания ответа, определенные типы заявок и т. д. Кстати, не надо сбрасывать со счета и хитрость клиента, который, при определенном опыте, будет ставить тип, приводящий к эскалации, а на самом теле, надо только шнур в розетку воткнуть. )
Юрий добрый день!
Если еще раз посмотреть мой первый пост, то видно:
1. первый вариант стандартный, там все просто и понятно (K1-A);
2. второй вариант не совсем стандартный, т.к.
2.1. с одной стороны, все таки тикет создан К2, и первичная обработка за К1, который по факту является первой линией;
2.2. а с другой стороны, хотелось бы все подвести под общую схему общения К1-А;
2.3. а с третьей стороны, все действия укладываются в incident managment, и самое важно - закрыть обращение клиента. А это по сути делается К1.
FreeBSD 9.1, OTRS 3.2.2
-
- OTRS Гуру
- Сообщения: 3119
- Зарегистрирован: 24 дек 2010, 09:27
- Откуда: Череповец
- Благодарил (а): 4 раза
- Поблагодарили: 5 раз
- Контактная информация:
Re: ситуация, когда клиент может быть агентом
Что касается 2.3, то клиенту не важно кто закрывает заявку, в том числе и в какую схему это укладывается, а решена его проблема или нет. Если это важно для менеджмента, то передавайте заявку на первую линию обратно с заметкой о выполнении и пусть они закрывают.
Это вопрос схемы работы и никак не OTRS.
На мой взгляд, не надо пытаться полностью все автоматизировать, это подчас вредно. Агенты должны знать и понимать схему работы и придерживаться ее. В первую очередь надо отлаживать схему (регламент) потом уже если инструмент позволяет вводить автоматизацию ряда функций, но не ставить это главной целью, также как и все натягивать на теоретический incident managment. ITIL/ITSM не догма а рекомендации, а жизнь разнообразнее теории. Они могут применяться и без системы автоматизации, инструмент лишь в помощь, не наоборот. Но это мое частное мнение.
Это вопрос схемы работы и никак не OTRS.
На мой взгляд, не надо пытаться полностью все автоматизировать, это подчас вредно. Агенты должны знать и понимать схему работы и придерживаться ее. В первую очередь надо отлаживать схему (регламент) потом уже если инструмент позволяет вводить автоматизацию ряда функций, но не ставить это главной целью, также как и все натягивать на теоретический incident managment. ITIL/ITSM не догма а рекомендации, а жизнь разнообразнее теории. Они могут применяться и без системы автоматизации, инструмент лишь в помощь, не наоборот. Но это мое частное мнение.
С уважением Юрий Колесников
OTRS 5.0.22, ITSM 5.0.22
OpenSuse 13.2, MariaDB 10.0.22
OTRS 5.0.22, ITSM 5.0.22 тестовая
OTRS 5.0.22, ITSM 5.0.22
OpenSuse 13.2, MariaDB 10.0.22
OTRS 5.0.22, ITSM 5.0.22 тестовая
Re: ситуация, когда клиент может быть агентом
Спасибо, Юрий, ваши мысли учтены. Решили остановиться на моей схеме, так что все ок!
ykolesnikov писал(а):Что касается 2.3, то клиенту не важно кто закрывает заявку, в том числе и в какую схему это укладывается, а решена его проблема или нет. Если это важно для менеджмента, то передавайте заявку на первую линию обратно с заметкой о выполнении и пусть они закрывают.
Это вопрос схемы работы и никак не OTRS.
На мой взгляд, не надо пытаться полностью все автоматизировать, это подчас вредно. Агенты должны знать и понимать схему работы и придерживаться ее. В первую очередь надо отлаживать схему (регламент) потом уже если инструмент позволяет вводить автоматизацию ряда функций, но не ставить это главной целью, также как и все натягивать на теоретический incident managment. ITIL/ITSM не догма а рекомендации, а жизнь разнообразнее теории. Они могут применяться и без системы автоматизации, инструмент лишь в помощь, не наоборот. Но это мое частное мнение.
FreeBSD 9.1, OTRS 3.2.2