Автоназначение заявок из очереди агентам

[xpasha]

Всем доброго дня,

Подскажите пожалуйста, возможно ли в OTRS сделать автоназначение заявок из очереди агентам. Было бы удобно, чтобы система назначала заявки направленные в очередь операторами агентам-инженерам автоматически, тогда было бы исключена проблема недовольства инженеров тем что у операторов есть любимчики среди инженеров, которым назначают заявки полегче, а при использовании системы выборки из очереди заявок операторами самостоятельно , была бы исключена ситуация с выборкой некоторыми операторами самых легких заявок. Возможно ли сделать автоназначение заявок вообще какое бы то ни было?


Еще вопрос, если использовать систему при которой не оператор назначает исполнителя заявки, то может ли оператор скинуть в очередь заявку без владельца? Я пробовал имитировать создание заявки оператором, когда владелец не назначается, в этом случае происходит назначение владельцем заявки самого оператора.

[ykolesnikov]

Для автоназначения нужны критерии, тогда можно пытаться искать способы реализации.
По второму вопросу - и что здесь страшного? Если у Вас операторы не работают над заявками, надо только настроить, чтобы ее состояние было "новая" и все агенты этой очереди будут знать, что заявка свободна и ждет владельца. Выбравший ее для работы агент должен заблокировать ее и вперед.

[xpasha]

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

[xpasha]

Нашел решение. Настройки интерфейса создания телефонных заявок находятся в модуле Ticket -> Frontend::Agent::Ticket::ViewPhoneNew, нужно поставить параметр Ticket::Frontend::AgentTicketPhone###StateDefault в значение new. И добавить состояние new в список возможных состояний заявки при создании Ticket::Frontend::AgentTicketPhone###StateType.

По вопросу критерия автоназначения, самый простой критерий это отсутствие заявок у агента,причем только из группы инженеров. Но тут правда возникают дополнительные трудности. Днем раньше этого треда, я открывал другой с просьбой помочь найти придумать способ создания заявок операторов в очереди Инженеры, без их членства в группе Инженеров, если не дать операторам двух пермишенов в группе Инженеры - Create и RW, то они не смогут создавать заявки направляя их в очередь Инженеры, в том числе и с назначением владельца при создании заявки, в выпадающем списке агентов при назначении владельца присутствуют и инженеры и операторы, поскольку вторые тоже считаются членами группы Инженеры раз имеют право RW на группу.
Как их различать непонятно.Разве что создать группу операторов и не назначать заявки тем кто состоит в группе Операторы. Но это уже из области кодинга наверно, вряд ли такое можно сделать обычными средствами через настройки OTRS. Другая трудность это то что критерия отсутствия заявок у оператора может быть недостаточно, поскольку бывает так, что решение вопроса клиента по каким-то причинам откладывается и заявка(или больше одной заявки) стоит в ожидании. Но может быть можно реализовать хоть какой-то вариант автоназначения, хотябы по простому критерию отсутствия открытых заявок у агента. А вопрос с членством операторов в группе Инженеры можно как-то обойти. Возникает идея о том, чтобы создать заявку в другой очереди, а потом перенести в очередь Инженеры, с какими правами на очередь Инженеры это можно делать? Можно ли вообще перемещать заявки между очередями?

[yuri0001]

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

[alexus]

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

[xpasha]

Заявки различаются по сложности выполнения, вот если бы удалось как-то эту сложность оценивать и переводить оценку в денежный эквивалент, тогда да, это будет хорошая мотивация брать сложные заявки, а так есть опасение, как я уже и писал, что заявки могут быть явно сложные, которые брать стараться не брать, и они будут висеть в очереди. Такая же проблема с приоритетными заявками, их нужно выполнять быстрее остальных, а это значит нужно отложить в сторону другие заявки, которые могут достингнуть порога эскалации, за время пока решается проблема с приоритетной заявкой, нужно дергать сильнее смежные службы, чтобы они шевелились быстрее. Все это создает антимотивацию к тому, чтобы брать такие заявки. Был бы способ блокировки заявки инженером, без просмотра содержимого, поскольку по заголовку оценить сложность заявки непросто, нужно заглянуть в комментарий оставленный оператором со слов клиента, тогда проблема бы решилась по большей части.

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

[alexus]

Оптимальный вариант - сложность оценивает руководитель группы. Оценка оплаты в зависимости от сложности - идея хорошая, но критерии оценки остаются на ваше усмотрение.
В целом, для формирования фонда оплаты труда в зависимости от результатов необходимо принимать как личные, так и групповые показатели эффективности. Но важно, чтобы они были прозрачны для всех участников. Групповой показатель - среднее за месяц ежедневное количество просроченных по SLA заявок. Если меньше условно 10 - есть премиальный фонд на группу, больше 10 - нет премии ни для кого в группе. Дальше - личные показатели:
1. разница между лично закрытыми тикетами и средним значением по группе - Это показатель скорости
2. разница между лично закрытыми тикетами, но переоткрытыми заново, и средним значением по группе - Это показатель качества
Такие же показатели можно сделать для каждой категории сложности заявок и для сложных заявок сделать коэффициент 2,3 или 5, чтобы не получилось так, что один крутой товарищ делает все сложные заявки и "тащит" всю команду, а остальные "халявят". С помощью таких множителей можно мотивировать реально сложные работы.