ситуация, когда клиент может быть агентом

[aid]

Добрый вечер!

Ситуация такова: у нас есть клиенты (К1), которые через клиентский интерфейс задают нам (агентам А) вопросы. Однако, поскольку у них самих есть конечные пользователи (К2), чаще удаленные, нужно последним также дать возможность задавать через OTRS вопросы. В итоге получаем (на бумаге) две параллельные схемы:
1) К1 --> А (клиенты создают тикеты, мы А, как первая линия поддержки)
2) К2 --> К1 --> A (К2 клиенты, К1 - первая линия (должны первичная обработка тикетов, возможно, сортировка, ответы на простые вопросы; при наличии сложностей эскалируют на нас), А - мы решаем серьезные вопросы и кидаем их обратно К1)
(!)важная особенность схемы 2 - нас (А) не интересует, как К1 доведет решение тикета до К2, то есть для нашей системы связь К1-->К2 одностороняя!!!
(!!)вторая важная особенность: от К2 тикет (заявка приходит через почту, то есть не через интерфейс)

Есть мысли по технической реализации? Может кто встречался?

На данный момент вижу один вариант: через почту тикет от К2 ложится в очередь, но сразу шедулером (автоматически) ставится ответ, поэтому он практически тут же возвращается К1, который либо закрывает его (и сообщает К2), либо эскалирует на А. Поругайте.

Заранее благодарен!

[yuri0001]

Вопрос не очень понятен.
У Вас К1 создает заявки от себя лично или все-таки от имени К2, в случае, когда не может ответить сам?
Или, грубо говоря, я, специалист первой линии, имею рабочее место и у меня вышел из строя коммутатор и починить его сам я не могу. Здесь я выступаю чисто как клиент. И должен создавать заявку от своего имени, будучи зарегистрированным в системе как клиент, хотя и являюсь агентом по отношению к обслуживаемой мною группы клиентов. Здесь вопрос только в разделении таких заявок для статистики.
При нормальной схеме работы и организации ее в виде 2-х линий поддержки, заявки клиента на вторую линию никогда не должны попадать минуя первую, либо должен быть четкий критерий иерархической эскалации (превышение времени ожидания ответа, определенные типы заявок и т. д. Кстати, не надо сбрасывать со счета и хитрость клиента, который, при определенном опыте, будет ставить тип, приводящий к эскалации, а на самом теле, надо только шнур в розетку воткнуть. )

[aid]

Вопрос не очень понятен.
У Вас К1 создает заявки от себя лично или все-таки от имени К2, в случае, когда не может ответить сам?
Или, грубо говоря, я, специалист первой линии, имею рабочее место и у меня вышел из строя коммутатор и починить его сам я не могу. Здесь я выступаю чисто как клиент. И должен создавать заявку от своего имени, будучи зарегистрированным в системе как клиент, хотя и являюсь агентом по отношению к обслуживаемой мною группы клиентов. Здесь вопрос только в разделении таких заявок для статистики.
При нормальной схеме работы и организации ее в виде 2-х линий поддержки, заявки клиента на вторую линию никогда не должны попадать минуя первую, либо должен быть четкий критерий иерархической эскалации (превышение времени ожидания ответа, определенные типы заявок и т. д. Кстати, не надо сбрасывать со счета и хитрость клиента, который, при определенном опыте, будет ставить тип, приводящий к эскалации, а на самом теле, надо только шнур в розетку воткнуть. )

Юрий добрый день!
Если еще раз посмотреть мой первый пост, то видно:
1. первый вариант стандартный, там все просто и понятно (K1-A);
2. второй вариант не совсем стандартный, т.к.
2.1. с одной стороны, все таки тикет создан К2, и первичная обработка за К1, который по факту является первой линией;
2.2. а с другой стороны, хотелось бы все подвести под общую схему общения К1-А;
2.3. а с третьей стороны, все действия укладываются в incident managment, и самое важно - закрыть обращение клиента. А это по сути делается К1.

[ykolesnikov]

Что касается 2.3, то клиенту не важно кто закрывает заявку, в том числе и в какую схему это укладывается, а решена его проблема или нет. Если это важно для менеджмента, то передавайте заявку на первую линию обратно с заметкой о выполнении и пусть они закрывают.
Это вопрос схемы работы и никак не OTRS.
На мой взгляд, не надо пытаться полностью все автоматизировать, это подчас вредно. Агенты должны знать и понимать схему работы и придерживаться ее. В первую очередь надо отлаживать схему (регламент) потом уже если инструмент позволяет вводить автоматизацию ряда функций, но не ставить это главной целью, также как и все натягивать на теоретический incident managment. ITIL/ITSM не догма а рекомендации, а жизнь разнообразнее теории. Они могут применяться и без системы автоматизации, инструмент лишь в помощь, не наоборот. Но это мое частное мнение.

[aid]

Спасибо, Юрий, ваши мысли учтены. Решили остановиться на моей схеме, так что все ок!

Что касается 2.3, то клиенту не важно кто закрывает заявку, в том числе и в какую схему это укладывается, а решена его проблема или нет. Если это важно для менеджмента, то передавайте заявку на первую линию обратно с заметкой о выполнении и пусть они закрывают.
Это вопрос схемы работы и никак не OTRS.
На мой взгляд, не надо пытаться полностью все автоматизировать, это подчас вредно. Агенты должны знать и понимать схему работы и придерживаться ее. В первую очередь надо отлаживать схему (регламент) потом уже если инструмент позволяет вводить автоматизацию ряда функций, но не ставить это главной целью, также как и все натягивать на теоретический incident managment. ITIL/ITSM не догма а рекомендации, а жизнь разнообразнее теории. Они могут применяться и без системы автоматизации, инструмент лишь в помощь, не наоборот. Но это мое частное мнение.