OTRS.ru

Необходимо добавить в автоответ на заявку время её выполнения в соответствии с регламентом. Зависит от приоритета и типа заявки. Как это можно сделать?

Например, чтобы автоответ выглядел так:

• Спасибо за ваш запрос.
  Ваша заявка будет решена в течение 2х часов.

ЕМНИП можно в ответе указать время до ближайшей эскалации.
У себя убрал, т.к. первая эскалация настроена на первый ответ, и только вторая на решение (эскалация на обновление не используется у меня).
А вот различное время решения в зависимости от тип заявки, важности и т.п. на сколько я знаю до сих пор так и не реализован.
Только в зависимости от очереди или от SLA.

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

Я бы сначала решил задачу по автоматическому SLA или времени решения на основе типа и приоритета.

Уровни обслуживания есть, в каждом из них заданы эскалации (время первого ответа и время решения). Приоритеты, их влияние и критичность (матрица), типы проблем также заданы.
Нашёл такие тэги:
<OTRS_TICKET_FirstResponseTime>
(Время, пока клиент должен получить ответ)
<OTRS_TICKET_SolutionTime>
(Время, когда билет должен быть закрыт)
Однако при вставке в автоответ у пользователя их значения отображаются как "-".

JohniGo писал(а):ЕМНИП можно в ответе указать время до ближайшей эскалации.

Это и есть нужные тэги? Если да, то подскажите пожалуйста, как их правильно использовать\настроить?

Да именно так.
Работает только такой:
OTRS_TICKET_EscalationDestinationDate

alexus писал(а):Я бы сначала решил задачу по автоматическому SLA или времени решения на основе типа и приоритета.

Долго и упорно жду, когда же наконец это сделают...
Просто жизненно необходимая вещь...
Нет-ли каких разведданных про это?

JohniGo писал(а):Только в зависимости от очереди или от SLA.

Как включить "Уровни обслуживания"?
При оформлении заявки данный пункт есть, но выбрать не из чего, тока "-".
И как можно получить выбранный параметр для использования его в автоответе?

Клиентам назначаются Сервисы. При настройке СЛА указываете сервисы. Когда выбираете клиента, становятся доступны сервисы. После выбора сервиса появляются СЛА, в которых начтроен выбранный сервис.

PastoriXx
Я так думаю, что пакет ITSM установлен? (пока писал, Алексей уже все остальное рассказал.. )

Jonni
По поводу автоматического выбора.
В базе такой функционал делать не имент смысла, т.к
у всех подходы разные. А вот сделать легкий кастом - без проблем. Мы, например, делали автозаполнение времени решения на основе приоритета по аналогии с HPOV. Сделать такое и для типа тикета несложно. У вас же есть программист.

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

Программер на других проектах занят... ОТРС - так, побочный продукт автоматизации собственной работы... Пилим "на досуге"... Появится побольше досуга, будем делать сами...

Может кто и поддержит. Но я лично считаю, что менять SLA нельзя на основе приоритета. Я еще понимаю, если приоритет ставить на основе SLA. На мой взгляд приоритет нужен лишь для определения порядка исполнения тикетов при равнозначном SLA. Возможно так же повышение приоритета по "просьбе" клиента. Но при этом SLA, который зафиксирован в договоре и не может быть изменен. Так не будет формально зафиксировано нарушение условий.
Так что тут еще очень много методических вопросов и стоит смешивать все в одну кучу. Все-таки SLA - это характеристика сервиса, а приоритет - характеристика тикета.

Про то, что методических заморочек куча - полностью согласен.
А вот про SLA - можно и поспорить. ИМХО - это не признак сервиса, а независимый объект, имеющий определенные характеристики.
Согласитесь, текущая ситуация, когда тип инцидента никак не влияет на скорость его решения не совсем правильная. На сколько я понимаю, на текущий момент тип - просто некий классификационный признак и для реализации различного времени выполнения разного типа заявок относящихся к одному даже сервису необходимо заводить несколько сервисов, каждый со своим SLA... Т.е. если у нас есть сервис "персональный компьютер", то заявки "сменить пароль на вход в компьютер", "как правильно выключать компьютер" и "не включается компьютер.. помогите..." буду либо равнозначны по нормативным срокам решения, либо надо заводить 3 разных "сервиса"... что имхо не правильно (мало того представление данных не нормализовано, так для нормальной опять же классификации признак "персональный компьютер" все равно придется куда-то писать для дальнейшего анализа)...

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

Плюс мои пять копеек.
SLA - это не отдельный объект, а полная привязка к Сервису - ибо это соглашение об уровне Сервиса.
Здесь, как всегда, некое несовпадение между теорией и конкретной реализацией в OTRS, достаточно упрощенной.
И выходов несколько - упрощать конкретный SLA, здесь я имею в виду, то что написано в приложении к договору с конкретным Заказчиком, либо глубокая кастомизация, хотя здесь уже есть ограничения - ее объем и "стоимость", а вернее ТСО. В ряде случаев, если это инсорсинг - т.е. обслуживаем свой, скажем завод, легче переписать SLA, если реальный аутсорсинг (много разных обслуживаемых компаний) практически нереально, особенно, если это крупные, продвинутые заказчики - навязать им свою форму SLA - вряд ли. Значит искать компромиссы. Пытаться включать в договор все наши имеющиеся атрибуты - приоритет, тип и т.д.... Использовать вложенные сервисы (структурировать).
Жалко, конечно, что в основном функционале нет возможности назначать Сервисы компаниям.

JohniGo писал(а):Согласитесь, текущая ситуация, когда тип инцидента никак не влияет на скорость его решения не совсем правильная.

Не соглашусь! Чем один инцидент отличается от другого, чем одна проблема отличается от другой? Или может мы о разных типах говорим? Я так понимаю, что ТС говорил об инцидентах, проблемах, RfC и т.д.

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

И все-таки это достаточно индивидуальная задача. Я не спорю, что так может кому-то и надо. Но чтоб это делать в базе - вряд ли немцы будут.

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

Пример простого присваивания (в скрипте это делается switch'ами):
Можно ли как-то разблокировать (позволять выбрать) уровень обслуживания и сервис в заявке без выбора клиента?

Клиент-Сервис-SLA - эта последовательность не может быть нарушена.
"А можно стулья утром, а деньги - вечером? - Можно, но деньги - вперед!"