Showing 24 ideas for tag "sla"
kudos icon +

IT Service Management

Allow Type-SLA association

I suggest to enable Type-SLA association. That way it would be possible to automatically change the SLA associated with a Service, depending on the Type of ticket that is being reported.
Let's say we got a Service called Internet Access. If Type is Service Request, there's a 4-hour limit on Solution Time. If Type is Incident, there's a 2-hour limit on Solution Time. Most of our customers are picking up these options by... more »
kudos icon +

IT Service Management

Allow SLA-Priority association

I suggest to allow some sort of relation between two ITIL compliant features that are currently isolated: [ Criticality-Impact-Priority ] and [Service-SLA], so a change on Priority could somehow affect the SLA times.

I know you can relate Criticality to Service and Service to SLA but that relation is so indirect that barely adds value. A change on the priority of a ticket is currently not affecting the time an Agent... more »
kudos icon +

IT Service Management

Solution Time Clock Stop

This is essential for SLA management and I am amazed this doesn't exist, particularly when a quick google demonstrates the number of requests for this functionality. I along with many need to be able to pause or temporarily stop the solution time when a ticket is waiting customer interaction. This is particularly important when dealing with penalty clauses for missing SLA and turns the whole process into a manual one.... more »
kudos icon +


Sort tickets by last customer contact

Tickets now are sorted by pure age - which is misleading when a ticket stood closed for a certain time. Customers are awarded if they dig out old ticket numbers instead of opening a new case.

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 »
kudos icon +

IT Service Management

SLA escalation notification to specific email



My suggestion would be to send notifications on escalated tickets to a specific email/agent as an option.


Currently it sends notifications to everyone on the queue and this is really a problem for some users.


It could also have an option to send notification only to specific type of tickets


Thank you


kudos icon +

IT Service Management

Support SLA-Customer Company assocs, automate service assocs

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
is available... more »
kudos icon +


Link SLA's to Ticket Priority

The current SLA functionality is very limited and often we need work-arounds to get the desired SLA handling.

SLA's should be directly linked to the priority of a ticket. In other words, you may have an SLA called "Gold". If a customer with the "Gold" SLA creates a high priority ticket, then a 1st response time of 1 hour might be used. If a "normal" priority ticket is created, then a 1st response of only 4 hours is required.... more »
kudos icon +

IT Service Management

Allow SLA-Customer association

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 »
(@yor.feix) kudos icon +


Define working hours as time range.

In the SLA-Calendars it would be nice to to have the ability to define time ranges instead of klicking hours on or off.

That way you could define a service time from 8:15 until 17:30 with lunch break.

The data structure might look like this:

Monday = [

{ start = "8:15", end = "12:30" },

{ start = "13:00", end = "17:30" },


Tuesday ...


It would be much more flexible.