SLA Queries

[kool_kid]

Hi,

I would like to know some infomation about SLA/Services.

1) Which Escalations time takes precedence Queue level or SLA level?
2) If SLA Escalation time takes precedence over Queue Level then how I do set Escalation times for different queues. Example I have L1/L2/L3 Queues If First Response Time is Not Meet by L1 Queue the ticket moves to L2, my question is how do I set First Response for L2?
3) How does Service/SLA are applied if the ticket is incoming through Email?

4) This query is off the topic, In customer interface when creating new tickets I dont want to give the option of choosing the queue to the customer, is there a way to define default queue for all incoming tickets?

Thanks in advance

[crythias]

For number 4, start here: http://forums.otrs.org/viewtopic.php?f=60&t=7138

[kool_kid]

For number 4, start here: http://forums.otrs.org/viewtopic.php?f=60&t=7138

Awesome! that will do.

Waiting for replies/pointers for 1-3. I hope im able to explain my queries, feel free to ask if you need more info.

[kool_kid]

Just tested the Escalation precedence, its SLA escalation that takes precedence over Queue Escalations.

Now I'm wondering on how to cover point 2 and 3 above.

[kool_kid]

To cover point 2 I was thinking to create a Generic agent for L1 Queue which will moves escalated tickets to L2 Queue and changes the escalated values to new values using " Ticket CMD" or "Custom Module".

My question is how to use this Ticket CMD or Custom Module?

[kool_kid]

Still chasing this thing.

Anyone with any wild pointers??

[crythias]

since SLA takes precedence, the answer should be to change SLA when you change queues, which is what you're doing anyway.

[kool_kid]

Suppose I have 3 SLA's with customers and if im having L1/L2/L3 queues, then I needs to have total 3x SLA's ? SLA_1 will map to L1 queue, SLA_2 will map to L2 queue and etc. Also for every sla I will have to create a generic agent.

AM I understanding this correctly?

[crythias]

Yes, but you are causing this by changing queues. You should be changing Priority and/or escalation. There is no real need to change SLA or Queue just because the ticket is more critical to respond to. Those features are already built into the SLA.

[kool_kid]

Yes, but you are causing this by changing queues. You should be changing Priority and/or escalation. There is no real need to change SLA or Queue just because the ticket is more critical to respond to. Those features are already built into the SLA.

Thanks for the response but you left me lil a confused... here is my sceanrio.

We have 3 Queues and say 10 SLAs, I will take example "sla1". For sla1 which hits L1 queue first all sla escalation parameters will be checked and if anything is matching then the Ticket is moved to L2 Queues. Now for L2 Queue I believe the same SLA escalation parameters will be checked and the Ticket is moved to L3. I want to avoid this and make sure L2 is having different SLA escalation parameters. All queues have same calendar.

Example: SLA1 (Escalation Paramters for L1 Queue - 1st response: 6 hours; Solution Time: 24 hours)

If any escalation parameter is matched then the ticket is moved to L2. As you said I can change the priority of the ticket and move to L2.
Below are the L2 Parameters for same SLA.

SLA1 (Escalation Paramters for L2 Queue - 1st response: 3 hours; Solution Time: 12 hours)

If the above parameters are matched then the Ticket should be moved to L3 queue but in actual the SLA1 parameters will still remain same i.e 1st response: 6 hours; Solution Time: 24 hours. Then the ticket will be moved to L3.

Furthermore explanation to above example. if a ticket assigned with sla1 comes in L1 queue at 8am and none of L1 team responds to the ticket so ticket is moved to L2 at 2pm (becuz of no first response). Now at 2pm itself the ticket will be moved from L2 to L3 queue.

This is where the issue is coming up for me. If im using 3 x SLA1 with different escalation parameters for each queue then things work good, but I know this is not the right method to do. If I have total 10 SLA's then in system I will have to create 30 SLAs for 3 queues which is incorrect I know.

What is the right method to do this? If any part of this info is unclear please let me know I will try again to explain you.

[crythias]

Queues aren't (generally) supposed to be about "how critical is the ticket?" Queues are about categories (Printing, Phones, Maintenance) and what agents are proper to handle that category of ticket. The customer determines the SLA, not the queue.

I can't exactly address SLA in your case, but basically, you've violated the "A"greement at the point you've moved to a different queue.
http://forums.otrs.org/viewtopic.php?f=62&t=6337

If it indeed turns out you need to change the group of people that should respond to the ticket based upon time/priority instead of category, well, that puts a wrinkle in the works...

[Aaron pizz]

Service Level Agreement

COVERAGE:

This web site availability service level agreement (SLA) applies to you if you have ordered any hosting plan ("service") and you are in good financial standing with Donordepot.com.

SERVICE LEVEL:

Donordepot.com endeavors to have network connectivity available for http access by third parties 99% of the time ("web site availability").

CREDITS:

In the event that there is no web site availability, Donordepot.com will credit the monthly service charge for the service as calculated below and as measured 24 hours a day in a calendar month. The maximum credit is not to exceed the monthly service charge for the affected month:

Web site availability credit
95% to 99.4% = 25%
90% to 94.9% = 50%
89.9% or below = 100%

In order for you to receive a credit on your account, you must request such credit within seven (7) business days after you experienced no web site availability so that we may check our stats and your stats. You must request credit by sending a request to our support division through our Support Form. For security, the body of this message must contain your domain name, the dates and times of the unavailability of your web site, and such other customer identification requested by Donordepot.com. Credits will usually be applied within sixty (60) days of your credit request. Credit to your account shall be your sole and exclusive remedy in the event that there is no web site availability.



RESTRICTIONS:

Credits shall not be provided to you in the event that you have no web site availability resulting from (i) scheduled maintenance, (ii) your behavior or the performance or failure of your equipment, programs or applications, or (iii) circumstances beyond Donordepot.com's reasonable control, including, without limitation, acts of any governmental body, war, insurrection, sabotage, embargo, fire, flood, strike or other labor disturbance, interruption of or delay in transportation, unavailability of interruption or delay in telecommunications or third party services (including DNS propagation), failure of third party software or hardware or inability to obtain raw materials, supplies, or power used in or equipment needed for provision of your Web Site.

LIMITATIONS:

Online problems occur continuously. There might come a time when you cannot access your website or any other service. This is not necessarily due to Donordepot.com. Perhaps your ISP is experiencing technical difficulties, or there might be a routing problem between your ISP and the data center utilized and maintained by Donordepot.com, making communication difficult or impossible. We cannot bear the responsibility of such problems. Our monitoring agents determine the uptime of our service, and not any one client's experience.