OTRS.ru

Добрый день!

Подскажите, возможно ли настроить отправку уведомлений по заявкам, с разных почтовых адресов с привязкой по CustomerID или другому "спецполю" пользователя?

Немного поясню: есть несколько департаментов, достаточно больших по количеству пользователей и разделенных по задачам - почти как 2 разные компании. Соответственно в службе техподдержки выделены специалисты под каждый департамент (также есть смежные специалисты техподдержки). ОТРСка одна - для контроля, перераспределения задач и отчетности. Для каждого департамента есть своя почта техподдержки. Нужно сделать так, что бы при каких-либо действиях с заявкой (добавление внешнего комментария, запрос информации, закрытие заявки и т.д.), которые влекут за собой отправку уведомления тому, кто завел заявку, уведомления отправлялись с нужного почтового адреса и триггером для выбора нужного почтового адреса будет, например, поле CustomerID/

Надеюсь более менее нормально пояснил...

Спасибо!

В базе нет такой фичи. Уведомления уходят всегда с 1 ящика. Для реализации нужна доработка. Обращайтесь, сделаем!

Делите обработку заявок разных департаментов по очередям, к очередям привязывайте свой нужный почтовый ящик.

Ответы для разных очередей с разных ящиков - это не проблема. Но вопрос был про Уведомления. Или нет?

Да, скорее так. Не подумал.

Неясна цель ТС. У нас есть подобная организация, достаточно сильно отделенная от основной. Клиенты и агенты практически не пересекаются. Сделано:
- свой урл для клиентского портала
- свой почтовый ящик для очереди организации
- своя подпись с урл-ом заявки
- свое уведомление для закрытых заявок организации, опять же с правильным урл-ом
- задача, направляющая заявки из рав в очередь организации на основе кастомер_ид.

Зачем свой адрес для уведомлений - не понятно

Спасибо за ответы, попробую пояснить:

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

Сейчас все запросы, требующие внимания определенной линии поддержки ( 2 линия, 3я линия, Админы приложения №1, Админы приложения №2, Запросы на подтверждение определенному одну сотруднику и т.д.) все в одной каше. И таких каш штук, допустим 5 ( по количеству групп сотрудников). Найти сотруднику 2 линии поддержки свои запросы - крайне трудно....

Обычно структура тикетинг системы строится по специалистам ( очередь 2й линии поддержки, очередь 3й линии т.д..) внутри уже идут подразбивки по определенным сервисам ( например очередь 2го уровня для 2й линии поддержки, под названием Новые сотрудники, Закупки, или Доступы). При такой организации выделенный человек на подготовку оборудования для нового сотрудника будет смотреть в очередь где будут ТОЛЬКО такие заявки, что гораздо удобнее поиска среди всех заявок....Или например сотрудник не упустит закупку, потому что в отдельной все закупки находятся в определенной очереди и их гораздо меньше обычных запросов - так их тоже не потерять.... Или, например - зачем 3й линии видеть все заявки 2й линии? и потом искать свои? тоже тяжело для повседневной работы - и т.д.. Также есть понятие срока жизни заявки и надо понимать в какой очереди сколько пробыла заявка и на какой линии она протухла..


Да, какие то вещи можно делать и через фильтры, но тогда колонок будет много, что тоже неудобно, и как выяснилось в другой теме от меня - не на все колонки можно поставить фильтр.

Единственный вариант это НЕ "проверять с какой почты отправлять уведомление по очереди", а "проверять с какой почты отправлять уведомление по полю Customer"....

как то так....

Vitaly писал(а):а) Для каждой группы сотрудников есть свой адрес тех поддержки...
б) и ответы должны приходить с него.

Смысл первого пункта понятен, второго - нет.

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

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

Я уже думаю, может джейсоновскими скриптами как то?

Вариантов всего два:
1. Изменить правила, сделав нормальный централизованный Help(Service) Desk
2. Если правила жёстко принципиальны, заплатить за доработку под жёсткие правила.