Horrible SLA Problems

[Emma]

Thing is, isn't the fact that an SLA assigned to a customer gets changed randomly more of a bug? I would have feature requests regarding the rest of the SLA functionality, definitely, but surely if you assign an SLA to a customer it should never pick another?

[kjoinson]

Hi Emma -

I was wondering if you were able to work around your SLA problem? (SLA Plan changing when a change is made to the ticket). I am having the same problem and in addition when the client replies back, the SLA plan changes which does not make sense at all because it is the same user email that originally created the ticket. Anyway, I will send a ticket to Kayako programming but our support staff will have to manually monitor the SLA plans and thats not good.

Thanks,
Karen

[Emma]

Originally Posted by kjoinson

Hi Emma -

I was wondering if you were able to work around your SLA problem?

I am actually getting somewhere but it has taken all this time!

I have a ticket open regarding the SLAs being useless when having multiple severity types for all the departments, and that is still ongoing.

In the end I decided I would have to give up and bring it down to the real basics of the issue, and when I discovered that I could assign specific SLAs to a customer group (or individual user) I decided to go down that route (this is what we do with our current software).

However when you set a specific user to have an SLA type I found with utter despair that any change to the ticket STILL changes the SLA to another random type

However this time it was clearly a very obvious and simple thing that was going wrong so I submitted a bug with high hopes of a fix. It was actually set to 'confirmed' yesterday - no comments but from what I've seen so far the 'confirmed' status means 'oh ****, she's right, better fix that...' so I am hoping that a fix is imminent.

This should resolve many of the headaches, but it stil does not fix the main issue with the SLAs - you simply cannot rely on them to do their own thing intuitively.

See here for the bug!

http://bugs.kayako.com/index.php?cmd=view&id=215

Will continue to update this thread when I find any solutions...

[kjoinson]

Thats great, thanks for the info. I added a comment to your incident so hopefully will help!

[PeteV]

... and we thought that we were too dumb to use SLAs properly...

We were never able to figure out how to get SLAs to work. We simply gave up (like the rest of the users who reported problems in the forum, apparently).

Frankly, we have an ever increasing number of problems with eSupport, and we simply do not have the time to debug eSupport with Kayako's Tickets or Live Help all the time. We need eSupport to save time, not to waste time. This is making our heads spin.

Our current approach is to try to get something to work, and if we cannot do this in a reasonable amount of time, to give up and either not do it or workaround it somehow. That is not good at all. It is sad to see that SLAs fall into this category too.

[Jamie Edwards]

I will work on getting a definitive explanation on how the SLA precedences are organised in SupportSuite up soon.

[Emma]

Originally Posted by Jamie Edwards

I will work on getting a definitive explanation on how the SLA precedences are organised in SupportSuite up soon.

That would be good. If we see what it is supposed to do in the background then maybe it will help me explain why I think that's wrong and what we actually want it to do.

[Rodney B]

Originally Posted by Jamie Edwards

I will work on getting a definitive explanation on how the SLA precedences are organised in SupportSuite up soon.

Any word on this?

[Emma]

No update on the ticket yet either - can anyone find out what's happening and when a fix is likely to be?

http://bugs.kayako.com/index.php?cmd=view&id=215

[Matthew]

I, too, have descended into the documentation-less snake pit that is home to SLA's, Escalations, and Ticket Statuses. I think I can explain, more or less, how it is *supposed* to work. So here goes my attempt...

SLA's assign an expiration time to an incoming ticket by filtering tickets by Department, Status and Priority. These filters form a logic statement that reads like this:

"If this ticket is for Department X AND is of Priority (A, B, OR C) AND has a Status of (D, E, OR F), THEN give it an expiration time of Y minutes."

In order to avoid conflicts between SLA's, you'll naturally want to make sure your defined SLAs' criteria do not overlap. For example, you would not create two SLA's each assigned to the same department, and applying to the same Statuses and Priorities, and give them different expiration times. How would the ticket 'know' which SLA it is supposed to adhere to? Automatic error checking for this would be nice, but it's probably complicated to code; so it's up to you to make sure your filter rules do not conflict.

Now that your ticket has an expiration time, it's internal 'clock' will count down to zero--but 'ticking' only during the hours of the schedule you have attached to the SLA. In effect, your ticket will sit there until either:

1. the ticket's 'clock' expires (shame on you!), or
2. the ticket's Status changes because (in one way or another) you or your staff are addressing the issue.

When the ticket's clock expires, you can now apply an Escalation rule so that the ticket gets somebody's attention. Escalation rules apply to a specific SLA, and only when that SLA's timer reaches 'zerio'. Escalation rules allow you to do 4 things, singly or in any combination:

1. move the ticket into a new department
2. assign the ticket to a specific person
3. change the Status of the ticket
4. change the Priority of the ticket

When a ticket's Status changes for whatever reason, things can get really interesting , but this is where the power of the system is, I think, supposed to show (assuming no bugs, of course!). So here we go...

What happens next depends on two factors:

1. a setting in Tickets>Manage Statuses>StatusName for the status the ticket is moving to or from.
2. whether the ticket's timer is already at zero (or has no timer). If the status has been changed by an escalation rule, then this will certainly be the case, since escalations only happen upon timer expiration.

The setting I mentioned in Tickets>Manage Statuses>StatusName is called Reset Due Time On Status Change, but I think a better label would be Reset SLA On Status Change. Because the idea is not just to reset the timer to what it was before, but to check to see if this changed ticket should not have a different SLA (with possibly a different timer) attached to it. Setting this open to 'yes' should cause the ticket to be 'kicked' (again) into the SLA arena, where it 'searches' about (once more) for an SLA that matches its new set of criteria. Finding one, it will start a (new) countdown. If it can't find one, it will take the default countdown time defined in Settings>Tickets. If the default SLA time is turned off, then the ticket gets no countdown time and just sits there, waiting for someone to notice it.

This is seriously powerful, because you can specify different response times according to the changed status (and department, and priority) of your ticket. You might specify a maximum of 15 minutes to assign the ticket to a help desk staff member, but then give an extra 45 minutes until that issue must be addressed.

What if Reset Due Time On Status Change is set to 'No'?

If the clock is no longer ticking, or if there never was a clock, then nothing happens. If the clock is still ticking on a ticket, then it will continue to count down to zero. If the timer reaches zero, an escalation rule associated with the previous SLA will kick in, if one has been defined. If one has not been defined, then nothing happens, and the ticket simply becomes overdue.

Change the Status again, and the process repeats itself. If Reset Due Time On Status Change is 'Yes', then the search begins again for a matching SLA...

Group and User SLAs. A group can be assigned any SLA; the normal 'filtering' aspect of the SLA (i.e., by department, priority, and status) is essentially ignored. An SLA assigned to an individual user works in the same way, and takes precedence over any SLA attached to the group of which that user is a member. There's still a question here: what happens when the Status of a ticket attached to a User or Group SLA changes, and the due time must be reset? Will it stick with the same User/Group SLA, or will it 'grab' an SLA according to it's Department/Status/Priority properties? (I would hope the latter, as this would be more flexible!)

I believe the whole arrangement can be charted as shown here:



Did I get this right? All of that being said, the work flow I have been trying to implement to take advantage of these features has exposed a serious bug--which has been mentioned elsewhere in these forums. The Reset Due Time option for the statuses is simply not working as of v3.11.01: the due time just gets zeroed. But if this option doesn't work, then all the oomph is gone, because you can't kick a ticket back to attach to another SLA!

I hope this helps. How about we massage it until the theory of SLAs, escalations, and statuses is perfect? And the developers can fix that bug so that this cool system actually works!

[Matthew]

Here's my go at a tutorial for setting up SLAs. I've focused only on how to apply a scheme to web-based tickets. Using email tickets may require some additional setup.

The Scenario:

You run an IT help desk for a financial services company located on a single high-rise floor. Response times must be relatively fast, as your clients are processing stock and other time-sensitive financial transactions. You have only one support department, and your help desk office hours are always the same.

For your SLA scheme, you decide on the following:

1. You'll have 4 user-assigned Priority Levels (1-4). You'll give these descriptive text so that your non-techie clients have a better sense of the urgency implied:
   1. When you have time
   2. Soon please, if possible
   3. This is holding me up!
   4. I need this right away!
2. You'll have 2 staff-assignable Priority Levels (5-6). These follow in the same style, as they will be visible to clients (if used), but will not be selectable by clients:
   • Drop everything else!
   • Everyone! Critical!
3. You decide on 6 possible ticket statuses:
   • Open - a new ticket
   • Assigned - someone is scheduled to work on this
   • In Progress - some is actually working with the client on this
   • On Hold - resolution is pending some event
   • Closed - issue is resolved
   • Escalated - we haven't lived up to the SLA. Start fixing it now!
4. You'll divide your staff into a Level 1 Support group and a Level 2 Support group. New staff tickets always go to Level 1 first; your 'Level 2' people are sysadmins, often doing project work, who should not be bothered when someone's email client stops working.
5. You want a deadline for assigning a new ticket to a Level 1 support person. When the ticket is assigned, the status should change from 'Open' to 'Assigned', and this should be visible on the ticket status as seen by your highly-impatient clients. The deadline will be based on the user-assigned ticket priority. You decide that a deadline of 15 minutes will work just fine for both priorities 1-2; but for priorities 3-4 you want the ticket to be assigned within 5 minutes.
6. You want another deadline for the Level 1 support person to actually start working on the issue. Once the problem is being addressed, the deadline countdown will stop and the status should change to 'In Progress'. In this case, you decide that each priority should have its own deadline: 105, 45, 25, and 10 minutes respectively. Adding the 'assignment' deadlines to the corresponding 'start working' deadlines gives you the following scheme for starting to work on the issue. This is what you'll publish on your internal web site:
   • Priority 1: Maximum 2 hours to begin work
   • Priority 2: Maximum 1 hour to begin work
   • Priority 3: Maximum 30 mins to begin work
   • Priority 4: Maximum 15 mins to begin work
   • For emergency issues, please call the help desk directly (but we may still assign a lower priority afte evaluating the request)
7. You want to escalate a ticket to a Level 2 support group if either of the above deadlines expires. If it's only the 'assignment' deadline, the ticket Status should not change--as that's not part of your published (client-facing) SLA. However, if the ticket has been assigned and the Level 1 staff have failed to get started on it, you want the status to show as 'Escalated'. That should tell your clients that someone is getting on the issue right away.

You may also want a deadline for resolving 'In Progress' issues completely, but we'll leave that out for now to keep things simple.

It helps a lot to make a diagram, something like this:



To do all of this, you'll need to build the following components:

• 2 staff Departments, for your Level 1 and Level 2 people
• 1 work Schedule
• 6 ticket Priorities
• 6 ticket Statuses
• 6 SLAs, with...
• 6 corresponding Escalation rules, and...
• A par-tridge in-a pear tree

The Steps:

1. Set up your departments and assign staff, if you haven't already. We'll call them Level 1 and Level 2, although you'll want to change these names to reflect the culture of your company, keeping in mind that (by default) clients will see the department name when they go to submit a ticket on the web page.
2. Create a work schedule in SLA>Insert Schedule. (Aw gee... there's no lunch break. Why didn't Kayako think of that one?)
3. Set up priorities in Tickets>Manage Priorities. Give them pretty colors.
4. Set up ticket statuses in Tickets>Manage Statuses. For the 'Open' status, the option Reset Due Time On Status Change should be 'Yes'. For all others it should be 'No'.
5. Create SLAs in SLA>Insert Plan:
   • SLA 1 Name: Open Tickets (priority 1-2). Due time: 0.25 hours. Department: Level 1. Priorities: select 1 and 2. Statuses: select Open.
   • SLA 2 Name: Open Tickets (priority 3-4). Due time: 0.083 hours. Department: Level 1. Priorities: select 3 and 4. Statuses: select Open.
   • SLA 3 Name: Assigned Tickets (priority 1). Due time: 1.75 hours. Department: Level 1. Priorities: select 1. Statuses: select Assigned.
   • SLA 4 Name: Assigned Tickets (priority 2). Due time: 0.75 hours. Department: Level 1. Priorities: select 2. Statuses: select Assigned.
   • SLA 5 Name: Assigned Tickets (priority 3). Due time: 0.416 hours. Department: Level 1. Priorities: select 3. Statuses: select Assigned.
   • SLA 6 Name: Assigned Tickets (priority 4). Due time: 0.166 hours. Department: Level 1. Priorities: select 4. Statuses: select Assigned.
6. Create 6 Escalation rules in Escalations>Insert New Rule:
   • Rule 1 Name: Open Tickets (priority 1-2). SLA Plan: Open Tickets (priority 1-2). Set Move Department to Level 2.
   • Rule 2 Name: Open Tickets (priority 3-4). SLA Plan: Open Tickets (priority 3-4). Set Move Department to Level 2.
   • Rule 3 Name: Assigned Tickets (priority 1). SLA Plan: Assigned Tickets (priority 1). Set Move Department to Level 2. Set Change Ticket Status to Escalated.
   • Rule 4 Name: Assigned Tickets (priority 2). SLA Plan: Assigned Tickets (priority 2). Set Move Department to Level 2. Set Change Ticket Status to Escalated.
   • Rule 5 Name: Assigned Tickets (priority 3). SLA Plan: Assigned Tickets (priority 3). Set Move Department to Level 2. Set Change Ticket Status to Escalated.
   • Rule 6 Name: Assigned Tickets (priority 4). SLA Plan: Assigned Tickets (priority 4). Set Move Department to Level 2. Set Change Ticket Status to Escalated.

That's it, your SLA scheme is all set up! Oh, except for one more very important thing: pray that the bugs have been worked out of the SLA system by the time you try this tutorial.

Note that during daily operations, when a ticket is assigned to a Level 1 staff person, the ticket's Status must manually be updated to 'Assigned'. I'm not aware of a way to make this happen automatically, but I'll bet someone could make a hack for it.

If there are errors in the way I've approached this, I'm sure someone will let me know, and I will edit accordingly. Hope it helps!

[Jamie Edwards]

Originally Posted by Emma

No update on the ticket yet either - can anyone find out what's happening and when a fix is likely to be?

http://bugs.kayako.com/index.php?cmd=view&id=215

Bugs are not timetabled; aside from the critical / security related, they are simply progressively fixed (i.e. similar bugs fixed in one batch).

Matthew; your SLA implementation tutorial is excellent, thank you very much for sharing it with everyone. I have copied it to another new thread and made it a sticky: The SLA system explained with example implementation. Please check your e-mail