Умные уведомления
Модератор: ykolesnikov
Умные уведомления
Добрый день!
Подскажите, возможно ли настроить отправку уведомлений по заявкам, с разных почтовых адресов с привязкой по CustomerID или другому "спецполю" пользователя?
Немного поясню: есть несколько департаментов, достаточно больших по количеству пользователей и разделенных по задачам - почти как 2 разные компании. Соответственно в службе техподдержки выделены специалисты под каждый департамент (также есть смежные специалисты техподдержки). ОТРСка одна - для контроля, перераспределения задач и отчетности. Для каждого департамента есть своя почта техподдержки. Нужно сделать так, что бы при каких-либо действиях с заявкой (добавление внешнего комментария, запрос информации, закрытие заявки и т.д.), которые влекут за собой отправку уведомления тому, кто завел заявку, уведомления отправлялись с нужного почтового адреса и триггером для выбора нужного почтового адреса будет, например, поле CustomerID/
Надеюсь более менее нормально пояснил...
Спасибо!
Подскажите, возможно ли настроить отправку уведомлений по заявкам, с разных почтовых адресов с привязкой по CustomerID или другому "спецполю" пользователя?
Немного поясню: есть несколько департаментов, достаточно больших по количеству пользователей и разделенных по задачам - почти как 2 разные компании. Соответственно в службе техподдержки выделены специалисты под каждый департамент (также есть смежные специалисты техподдержки). ОТРСка одна - для контроля, перераспределения задач и отчетности. Для каждого департамента есть своя почта техподдержки. Нужно сделать так, что бы при каких-либо действиях с заявкой (добавление внешнего комментария, запрос информации, закрытие заявки и т.д.), которые влекут за собой отправку уведомления тому, кто завел заявку, уведомления отправлялись с нужного почтового адреса и триггером для выбора нужного почтового адреса будет, например, поле CustomerID/
Надеюсь более менее нормально пояснил...
Спасибо!
-
- OTRS Гуру
- Сообщения: 5196
- Зарегистрирован: 20 сен 2010, 18:17
- Откуда: Москва
- Благодарил (а): 92 раза
- Поблагодарили: 82 раза
Re: Умные уведомления
В базе нет такой фичи. Уведомления уходят всегда с 1 ящика. Для реализации нужна доработка. Обращайтесь, сделаем!
С уважением,
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
-
- OTRS Мастер
- Сообщения: 507
- Зарегистрирован: 22 апр 2015, 06:45
- Откуда: Томск
- Благодарил (а): 7 раз
- Поблагодарили: 45 раз
Re: Умные уведомления
Делите обработку заявок разных департаментов по очередям, к очередям привязывайте свой нужный почтовый ящик.
--
OTRS 6.0.22
OTRS 6.0.22
-
- OTRS Гуру
- Сообщения: 5196
- Зарегистрирован: 20 сен 2010, 18:17
- Откуда: Москва
- Благодарил (а): 92 раза
- Поблагодарили: 82 раза
Re: Умные уведомления
Ответы для разных очередей с разных ящиков - это не проблема. Но вопрос был про Уведомления. Или нет?
С уважением,
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
-
- OTRS Мастер
- Сообщения: 507
- Зарегистрирован: 22 апр 2015, 06:45
- Откуда: Томск
- Благодарил (а): 7 раз
- Поблагодарили: 45 раз
Re: Умные уведомления
Да, скорее так. Не подумал.
Неясна цель ТС. У нас есть подобная организация, достаточно сильно отделенная от основной. Клиенты и агенты практически не пересекаются. Сделано:
- свой урл для клиентского портала
- свой почтовый ящик для очереди организации
- своя подпись с урл-ом заявки
- свое уведомление для закрытых заявок организации, опять же с правильным урл-ом
- задача, направляющая заявки из рав в очередь организации на основе кастомер_ид.
Зачем свой адрес для уведомлений - не понятно
Неясна цель ТС. У нас есть подобная организация, достаточно сильно отделенная от основной. Клиенты и агенты практически не пересекаются. Сделано:
- свой урл для клиентского портала
- свой почтовый ящик для очереди организации
- своя подпись с урл-ом заявки
- свое уведомление для закрытых заявок организации, опять же с правильным урл-ом
- задача, направляющая заявки из рав в очередь организации на основе кастомер_ид.
Зачем свой адрес для уведомлений - не понятно
--
OTRS 6.0.22
OTRS 6.0.22
Re: Умные уведомления
Спасибо за ответы, попробую пояснить:
У нас есть несколько групп сотрудников. Для каждой группы сотрудников выделены отдельные почтовые домены ( не спрашивайте как и зачем, сам пытаюсь это принять как данность (( ). Для каждой группы сотрудников есть свой адрес тех поддержки и ответы должны приходить с него. Сейчас, действительно, это реализовано через очереди. Но это крайне неудобно, потому что сотрудников тех поддержки не много и они поддерживают все группы сотрудников.
Сейчас все запросы, требующие внимания определенной линии поддержки ( 2 линия, 3я линия, Админы приложения №1, Админы приложения №2, Запросы на подтверждение определенному одну сотруднику и т.д.) все в одной каше. И таких каш штук, допустим 5 ( по количеству групп сотрудников). Найти сотруднику 2 линии поддержки свои запросы - крайне трудно....
Обычно структура тикетинг системы строится по специалистам ( очередь 2й линии поддержки, очередь 3й линии т.д..) внутри уже идут подразбивки по определенным сервисам ( например очередь 2го уровня для 2й линии поддержки, под названием Новые сотрудники, Закупки, или Доступы). При такой организации выделенный человек на подготовку оборудования для нового сотрудника будет смотреть в очередь где будут ТОЛЬКО такие заявки, что гораздо удобнее поиска среди всех заявок....Или например сотрудник не упустит закупку, потому что в отдельной все закупки находятся в определенной очереди и их гораздо меньше обычных запросов - так их тоже не потерять.... Или, например - зачем 3й линии видеть все заявки 2й линии? и потом искать свои? тоже тяжело для повседневной работы - и т.д.. Также есть понятие срока жизни заявки и надо понимать в какой очереди сколько пробыла заявка и на какой линии она протухла..
Да, какие то вещи можно делать и через фильтры, но тогда колонок будет много, что тоже неудобно, и как выяснилось в другой теме от меня - не на все колонки можно поставить фильтр.
Единственный вариант это НЕ "проверять с какой почты отправлять уведомление по очереди", а "проверять с какой почты отправлять уведомление по полю Customer"....
как то так....
У нас есть несколько групп сотрудников. Для каждой группы сотрудников выделены отдельные почтовые домены ( не спрашивайте как и зачем, сам пытаюсь это принять как данность (( ). Для каждой группы сотрудников есть свой адрес тех поддержки и ответы должны приходить с него. Сейчас, действительно, это реализовано через очереди. Но это крайне неудобно, потому что сотрудников тех поддержки не много и они поддерживают все группы сотрудников.
Сейчас все запросы, требующие внимания определенной линии поддержки ( 2 линия, 3я линия, Админы приложения №1, Админы приложения №2, Запросы на подтверждение определенному одну сотруднику и т.д.) все в одной каше. И таких каш штук, допустим 5 ( по количеству групп сотрудников). Найти сотруднику 2 линии поддержки свои запросы - крайне трудно....
Обычно структура тикетинг системы строится по специалистам ( очередь 2й линии поддержки, очередь 3й линии т.д..) внутри уже идут подразбивки по определенным сервисам ( например очередь 2го уровня для 2й линии поддержки, под названием Новые сотрудники, Закупки, или Доступы). При такой организации выделенный человек на подготовку оборудования для нового сотрудника будет смотреть в очередь где будут ТОЛЬКО такие заявки, что гораздо удобнее поиска среди всех заявок....Или например сотрудник не упустит закупку, потому что в отдельной все закупки находятся в определенной очереди и их гораздо меньше обычных запросов - так их тоже не потерять.... Или, например - зачем 3й линии видеть все заявки 2й линии? и потом искать свои? тоже тяжело для повседневной работы - и т.д.. Также есть понятие срока жизни заявки и надо понимать в какой очереди сколько пробыла заявка и на какой линии она протухла..
Да, какие то вещи можно делать и через фильтры, но тогда колонок будет много, что тоже неудобно, и как выяснилось в другой теме от меня - не на все колонки можно поставить фильтр.
Единственный вариант это НЕ "проверять с какой почты отправлять уведомление по очереди", а "проверять с какой почты отправлять уведомление по полю Customer"....
как то так....
-
- OTRS Мастер
- Сообщения: 507
- Зарегистрирован: 22 апр 2015, 06:45
- Откуда: Томск
- Благодарил (а): 7 раз
- Поблагодарили: 45 раз
Re: Умные уведомления
Смысл первого пункта понятен, второго - нет.Vitaly писал(а):а) Для каждой группы сотрудников есть свой адрес тех поддержки...
б) и ответы должны приходить с него.
--
OTRS 6.0.22
OTRS 6.0.22
Re: Умные уведомления
К сожалению, как это часто бывает, когда приходит запрос "свыше" в нем присутствует оооочень много "не совсем понятных" хотелок... Какие то получается выкинуть, какие то - нет...
Собственно тут тот самый случай, когда есть жесткое требование, что бы ответы приходили с того ящика, на который шлют запрос о поддержке....
Я уже думаю, может джейсоновскими скриптами как то?
Собственно тут тот самый случай, когда есть жесткое требование, что бы ответы приходили с того ящика, на который шлют запрос о поддержке....
Я уже думаю, может джейсоновскими скриптами как то?
-
- OTRS Гуру
- Сообщения: 5196
- Зарегистрирован: 20 сен 2010, 18:17
- Откуда: Москва
- Благодарил (а): 92 раза
- Поблагодарили: 82 раза
Re: Умные уведомления
Вариантов всего два:
1. Изменить правила, сделав нормальный централизованный Help(Service) Desk
2. Если правила жёстко принципиальны, заплатить за доработку под жёсткие правила.
1. Изменить правила, сделав нормальный централизованный Help(Service) Desk
2. Если правила жёстко принципиальны, заплатить за доработку под жёсткие правила.
С уважением,
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!