Закрытие создаваемой заявки

[paver]

Описываю ситуацию.
Агент начинает оформлять заявку уже после того, как она выполнена. Ситуация вполне штатная, например, клиент звонит агенту с проблемой, и вопрос решается в процессе разговора, или агента срочно вызвали на решение проблемы не с рабочего места, а отловили по мобильному в коридоре.
По результатам работы агент открывает новую телефонную заявку, тут же описывает выполненную работу и жмет "Создать", предварительно установив следующее состояние в "Завершено успешно".
Это удобно с точки зрения уменьшения нагрузки на агентов, но:
1. Насколько это неправильно методически?
2. В таком варианте клиент вообще не получает никаких уведомлений (чревато тем, что нерадивые агенты для отчетности могут "придумывать" себе вымышленные заявки).
Хотелось бы прочитать мысли форумчан по этому поводу, и заодно узнать решение 2й проблемы

[alexus]

клиент звонит агенту с проблемой

Клиент не должен звонить напрямую агенту никогда! При таком звонке агент должен вежливо "послать" клиента в почту или на клиентский портал

агента срочно вызвали на решение проблемы не с рабочего места, а отловили по мобильному в коридоре

Значит кто принимал обращение, уже должен был создать тикет.

2. В таком варианте клиент вообще не получает никаких уведомлений (чревато тем, что нерадивые агенты для отчетности могут "придумывать" себе вымышленные заявки).

Бывает, когда заявка решается на первой линии в момент обращения. Это стандартный First Call Resolution - один из самых важных KPI для сервисдеска. Надо делать уведомление клиенту, что тикет создан, но закрыт в момент обращения. Не вижу тут проблем.

[paver]

клиент звонит агенту с проблемой

Клиент не должен звонить напрямую агенту никогда! При таком звонке агент должен вежливо "послать" клиента в почту или на клиентский портал

Отвалился тырнет ))

Бывает, когда заявка решается на первой линии в момент обращения. Это стандартный First Call Resolution - один из самых важных KPI для сервисдеска. Надо делать уведомление клиенту, что тикет создан, но закрыт в момент обращения. Не вижу тут проблем.

Создал уведомление
Событие: TicketCreate
Фильтр-состояние: закрыт успешно
Получатель: Клиент
Тема
Текст
Тип сообщения: email-notification-ext (кстати, почему-то не "внешний email", может тут собака порылась?)

Создаю телефонную заявку, заполняю клиента, очередь, агента, устанавливаю состояние "закрыт успешно".
Заявка корректно обрабатывается, в истории первая запись: Новая заявка [2015082502000087] (Q=ОЦАИР;P=3 normal;S=closed successful).
Но уведомление не генерируется.
ЧЯДНТ?

[alexus]

Покажите полный скриншот тикета с историей

[alexus]

Отвалился тырнет ))

Клиент звонит на номер 911 службы поддержки, а не на мобилу агенту!

[paver]

Покажите полный скриншот тикета с историей

tick.png (83.76 КБ) 11910 просмотров

hist.png (43.18 КБ) 11910 просмотров

[alexus]

Ответ тут -viewtopic.php?f=4&t=1605.

[paver]

Ответ тут -viewtopic.php?f=4&t=1605.

И на десерт фича OTRS - если Вы для тестов создали клиента и агента с одинаковым email, и под этим же агентом что-то делаете, то уведомления уходить не будут! Зачем слать уведомления самому себе

Зачем слать? Так для тестов же! ))

Спасибо, есть контакт.

[paver]

Но!..
Появилась другая (обратная) проблема.
Если закрыть заявку из Ответить через установку статуса в Закрыто успешно, то клиент получит два одинаковых по смыслу сообщения: сам ответ и стандартное автоуведомление о закрытии заявки (смена статуса на Закрыто успешно).
Есть ли возможность заблокировать отправку уведомления, если закрытие выполнено из ответа?

[alexus]

До тех пор, пока у вас не будут определены регламент по обработке запросов и конкретные процедуры по жизненному циклу тикетов, скелеты так и будут из шкафов вываливаться !

[paver]

До тех пор, пока у вас не будут определены регламент по обработке запросов и конкретные процедуры по жизненному циклу тикетов...

Вы б еще добавили - все!
Специфика информационных технологий - они добавляют новые возможности и накладывают новые ограничения при проектировании или оптимизации бизнес-процессов. Т.е. для определения регламента исполнения процесса с использованием ИТ требуется знать, позволит ли система его реализовать.

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

[alexus]

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

Тогда не отправляйте клиенту уведомление о закрытии для данной конкретной процедуры. Не вижу вообще никакой проблемы. Я лично вижу, навскидку, 2-3 способа решения Вашей задачи. Но это уже профессиональный консалтинг по процессу и продукту. Бесплатный продукт и бесплатная реализация/оптимизация бизнес-процессов - это совсем не одно и тоже. Согласны?
Если Вы сможете показать мне в открытом доступе описание по реализации Вашего конкретного бизнес-процесса для любого другого бесплатного или платного продукта, я, так уж и быть, тоже поделюсь опытом.

[paver]

Тогда не отправляйте клиенту уведомление о закрытии для данной конкретной процедуры. Не вижу вообще никакой проблемы.

Ну так я и спросил, "есть ли возможность заблокировать отправку уведомления, если закрытие выполнено из ответа"? Или под процедурой вы понимаете процессную заявку?

Я лично вижу, навскидку, 2-3 способа решения Вашей задачи. Но это уже профессиональный консалтинг по процессу и продукту. Бесплатный продукт и бесплатная реализация/оптимизация бизнес-процессов - это совсем не одно и тоже. Согласны?.

Безусловно. Поэтому вопрос адресовал не вам в личку, а на форум: возможно кто-то из форумчан готов поделиться опытом подобной реализации.
За профессиональным консалтингом следует обращаться, когда имеется внятная проектная задача (у нас в перспективе такая намечается), сейчас же мы больше пытаемся "пощупать" инструмент на примере использования его в повседневной деятельности.

[alexus]

1. Под процедурой я подразумеваю фиксированную последовательность действий агентов по исполнению обращения определённого типа для определённого сервиса.
3. Нам часто встречается внятная проектная задачп - автоматизация повседневной сераисной деятельности. И мы её успешно решаем.

[paver]

... обращения определённого типа

Я собственно пытался понять, по какому признаку смогу отфильтровать заявки в уведомлениях. Про тип заявки не подумал, поскольку он в конфиге просто отключен. Спасибо за подсказку! Вот ведь можете, если захотите )

3. Нам часто встречается внятная проектная задачп - автоматизация повседневной сераисной деятельности. И мы её успешно решаем.

Имел в виду - внятная для нас. Мы пока не знаем сами, чего хотим. Вполне штатная для заказчиков ситуация, согласитесь. ) Поэтому и сформулировать требования не готовы. Ну и от дефолтсити достаточно далеко, чтоб покалякать о делах наших скорбных за кружкой пива.

[alexus]

Спасибо за подсказку! Вот ведь можете, если захотите )

Имел в виду - внятная для нас. Мы пока не знаем сами, чего хотим. Вполне штатная для заказчиков ситуация, согласитесь. ) Поэтому и сформулировать требования не готовы. Ну и от дефолтсити достаточно далеко, чтоб покалякать о делах наших скорбных за кружкой пива.

Да, знаю, понятная и частая задача. Для таких у нас есть "Быстрый старт" - http://www.radiantsystem.ru/byistryiy-start/
В любом случае, Вы же понимаете, что вам нужна автоматизация сервисных процессов. Вы же не за рецепты пирожков и раскройку пальто здесь ищете ?