As a service manager I would like to be notified during several steps of an escalation. E.g. when having a queue based escalation, I want to be notified after 30% and 50% and 90% of reaching the escalation time. So in conclusion it would be great if you could change the "Notify by" field type to multiselect except of dropdown.
In heterogenious environments it would be helpful if ticket notifications could be configured per queue (similar to escalations) instead of configuring them globally. Some teams are working email focussed others are not. Some teams like to receive an email for every update of a ticket others want as few emails as possible. Ideally there could be a default configuration for all and a dedicated configuration per queue... more »
With an increasing number of queues in the system it gets harder and harder to quickly pick the right queue in the To: / MoveTo: / ... dropdowns.
Adding the personal queues as favorites to the dialogue would increase the accessibility of the most important ones.
If you have a deep queue structure you have to click a long time after you reach your favorite queue.
My idea is to use a pulldown menu as it is used for the ticket move action.
Just a button add at the main bar. You choose your favorite queue and do not need to click subqueue per subqueue anymore.
When creating a new queue in admin interface you have to start from scratch each time. I do suggest to allow creation of a new queue by using an existing queue as template. All settings ( access rights, templates, etc.) are copied from the template - you just need to define a new name of the queue.
Mandatory "My Queues" for Agents Agents can select from the Queues they are able to Read (or further rights) those Queues from which they want to be informed of new Tickets. At the moment the agents are able to deselect all "My Queues" and will then do not receive notifications on new tickets and so on. Therefor I do suggest to add a new feature for a queue to be a mandatory queue. All agnets that are abel to read... more »
I think it's very useful to see a tree view of the queue, being able to browse the ticket inside of each queue and sub queue.
Queueview in OTRS allows you to see the ticket in the queue, but only of those unlocked.
I suggest to enable some kind of grouping for response templates. Currently it gets quite messy if you define a lot of response templates for different queues. Therefore a sorting / filtering by queue or groups would be very helpful and you don't longer need some workarounds with running numbers at the beginning of the response template name.
Not every queue needs a salutations and or signatures. By now it's not even possible to define an empty salutations or signatures. It's not even possible to get a space accepted as text.
It would be great if queues could go without both. Easiest would be to set an empty salutation/signature as default. This would also speed up queue creation a big time.
Fix precedence on calendar usage when using SLAs.
If an SLA does not have a specific calendar, queue calendar should be used and if not set, use system default workhours/calendar.
Today if an SLA is used and has no calendar, OTRS uses system calendar even is the queue for the ticket has a calendar
Currently sub-queues and sub-services are represented in the database in an un-normalized manner, the parent child relationship is defined via the name string, not by a key reference. This will hamper efforts to improve the visual representation and functions of these items, requiring further perl hacks to manage the parent-child relationship until it becomes unmanageable.
I suggest to allow definition of email notifications individually for all "my queues". For example you should be able to define notification for new tickets in queue "A" and for queue "B" you just would like to be informed on follow-ups. Within preference page all my queues should be listed separately and for each queue I can select via a tick if I would like to get one of the different notifications (new, follow-up,... more »
Often when working on tickets in different queues the 'back' button does not work as intended. In addition the way back into a queue or into the superordinate queue takes more than 3 clicks.
In the ticket zoom the queue display should be displayed as links into the given queues:
Queue::Subqueue should be [linktoqueue]::[linktosubqueue]
This would speed up queue access in complex setups.
Tickets which are worked on by different departments often change queues back
To easify and speed up the workflows it would be nifty to have a button "Move
back to...", which automatically pushes the ticket back into the last queue.
This could be a button in the ticket zoom as well as a quick choice in the move
I suggest to improve the way OTRS truncates the title of Tickets, Name of Queues and so on by simply limiting it to a fix amount of characters and just adding [...] this at the end.
As OTRS 3.0 adjust the size of tables and their cells automatically based on the screen you use, I would love to see the full Title as it will most definitely fit in my 30'' screen. ;-)