Looking for SLA tips and tricks for first time implementation.

One thing coming up is how to account for time multiple agents spent on a single ticket. It appears meeting (or breaking) the SLA is only applied to the agent who resolved it. This would make it hard to track how a particular agent is performing on SLA metrics.

We do not use them yet but will be at some point in the future.  I would suggest that if possible just isolate the tickets that need multiple agents from the tickets that are “Solo” agent solved.  I would also suggest looking at your current average times and seeing if they are within parameters that you find acceptable or if they need improvement start by trimming them in 10% or 5 % increments over quarters or bi-annually.  Also you can look at just an agents performance in the Analytics Explorer and that should help you to tune your SLAs  

I had a plan going into implementation, understanding I wanted a reply to all tickets within 1 business day and various resolution timeframes based on some assessment of the ticket. As I implemented IIQ, I realized the platform didn’t align with my vision, so things may not work like I thought. For example, in my prior system, SLAs triggered ‘escalations’ which then updated elements of the ticket. It was similar to the entire rule action in IIQ, but more granular. SLAs weren’t editable by agents, either. My point: it didn’t work like I wanted and I’m still wanting to dive deeper (when I can find time).

So here’s my SLAs:

My default SLA, applied to all tickets, is ‘Reply 1day Resolve 1week’. This should be most user support type of tickets. I have rules that are looking for issues, such as chromebook breakage, and applying other SLAs, removing the need for the Agent to reply. Otherwise, the Agent working the ticket can apply a shortcut to change the SLA. Maybe it’s a classroom project or a programming request that isn’t a one week job. I created 9 shortcuts of various time frames from now, next, 1-week, 1-month, 3-months, etc, etc:

This ties into custom views based on the shortcuts that provide quick looks into what the agent has prioritized:

It’s one big chain. For the most part, it accomplishes the outcome of helping agents prioritize work. There is no way to track SLA failures (the ‘escalation’ tool I discussed earlier in my old system allowed that, as an escalation was an SLA failure) except through extensive rule use. Agents just change the SLA to get one with a longer resolution timeframe.

So sorry that I can't be of more help, but we just don't use SLA’s. I guess I don’t really see the point in them. Could someone give me an example of how and why you use them?

The short version is that we’re using a Rule to apply SLAs based on priority. Higher priority = shorter SLA.

At the moment, this is only good for analytics, and tracking the agents or teams who are hitting or missing their priority resolution marks. My hope is that when Due Dates come out of beta, we’re able to link them to the SLA resolution date. If this comes to pass, we would be able to set priority on the ticket, and then have SLA and Due Date automatically update based on Rules logic. Then we could sort by “what’s due next?” in our ticket views.