It would be great to have different service criticalities for different customers.
It will be great if you can expand the functionality so we can create associations with GROUPS also.
There is such free module :
It would be great to have a serivce heat map as dashboard widget; config options should be time period; number of top services to show
To our understanding of ITIL, the SLA sits in between the customer and the service--no ticket for a service without a corresponding SLA that governs it. The OTRS model already includes the association between the SLA and the service, but otherwise associates services directly to individual customer users. A commercial extension from OTRS.com (http://www.otrs.com/solutions/subscriptions/feature-add-ons/) is available ...more »
Allow setting Service and SLA mandatory or not
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 you to enable the Service and SLA selection for the Ticket Bulk Action.
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. ;-)
I suggest adding "categories" which could be associated with services (note, this is very different from the "add service categories" idea). The purpose of this is more to keep down the size of the service tree, because if there is "Printing service" there may be several sub-services in there to allow full classification - "Desktop can't print", "Printer does not adhere to configured document settings" etc. "Desktop can't ...more »
I suggest establishing SLA-Customer associations since different customers pay for different SLAs typically, so it makes sense. The issue with the current data model is the technician or customer needs to know what SLA they have when opening a ticket, either that, or we need duplicate services on a per-SLA basis to limit the options in the drop-down list (i.e. an Internet Down service for Premium SLA and a separate Internet ...more »
I suggest that you split the current mechanism of SLAs up into two - Templates and Instances. We have a single mega-customer with 84 companies inside it. The SLAs cover minimum time between incidents on a per-company basis. Because of this, we need to create 84 individual SLAs per company (usually more because we want one SLA for critical issues and one SLA for non critical like printer problems). If OTRS was designed ...more »
Actually if you try to organize your service tree all services you got are selectable and some times parent services are just to organize.
I suggest you to add categories-subcategories for services and one view to see them organized by categories like a tree.
Categories are not selectable as part of some ticket, are just to organize the services.