I suggest to allow a relation between Queues and Services. It frequently happens that a ticket for a given Service will most likely be first attended by the same old queue. Say, if you report a ticket related to your VoIP device, chances are the Telephony queue will deal with that. If a Queue-Service relation exist, few clicks will be needed and less mistakes due to missassignation will be made
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. ;-)
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
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.
I attached a module (2.4.x) with a well thought concept which was developed with help of the OTRS AG.
In short: A FreeTime field is used to store the last customer contact. The last sender is stored on top to hinder repeated mails... more »
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.
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.
I suggest to display FreeFields (config per sysconfig) in AgentDashboard, AgentTicketQueue and AgentTicketSearch (Search Results).
All views should be sortable by these freefields.
I suggest you enable support for FreeText fields by Queue. So OTRS administrators can create FreeText fields by Queue.
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 »
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.
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.
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.
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