Background

We use first- and next-reply-time targets in our SLA policies, however, there are certain scenarios where intuitively you would expect to be covered by one of these targets, but you are not.

For example, our phone integration creates a ticket with a private note containing call data, this does not satisfy the conditions that activate the first reply target, so if the ticket needs to be followed up in its open state, it will not have a target applied and will likely be missed.

Another example, we have a trigger that changes ticket status to Open if a side conversation is responded to, here the requester is not the current user, so again the reply-time target isn't activated.

A more detailed explanation of SLA target activation and satisfactioncan be found here.

Why is this an issue?

Sorting views by Next SLA Breachis the best way I know of to make sure that agents are handling tickets in the correct order. When a ticket that agents should handle has no SLA target applied, it goes to the bottom of their list, so out of view and in danger of getting a very late reply.

What can be done to get full SLA coverage on these edge case tickets?

I originally began a very convoluted setup where I manipulated priority to set different targets, but it was a mess and didn't really give the results I wanted.

Hat tip toPedro Rodrigues (opservator.com), who outlined a better approach that informed the setup I'm presenting here.

Let's get cookin'!

Ingredients

• 1 (or more) tags are to be added to tickets that are in one of these SLA blind spots (edge cases)
• 1(或是几部)边界情况SLA策略。
• Triggers that apply the edge-case SLA policy (indirectly by setting a tag) to tickets using conditions that hook into the events representing the edge-case.
• A trigger to remove the edge-case tag whenever a public reply is added to the ticket, so the ticket enters into your standard SLA policy if the ticket returns to the support team.

Directions

1. Create a tag for the purpose of enabling the alternate edge-case policy, let's call it "sla_edge_case".
2. Create a new SLA policy with a single condition being the presence of the above tag.
   Set a "Requester Wait Time"*target value that corresponds to the target you would want from the event to breach.
   
   
   这一政策在最顶端的SLA波里cy list (policies are checked top to bottom, so this should ensure that this policy is only applied on tickets with the tag, and you don't need to add further conditions on your other policies).
   
   
   
3. Create a trigger per event that you have identified as the cause of an SLA blind spot - these would be unique to your particular setup, so I add examples here only to demonstrate the idea.
   
   Example where a ticket is created with a private note as the description.
   
   
   Example where a ticket is opened because a reply has come in on a side conversation.
   
   
   
4. Create a trigger that removes the tag from a ticket when a public reply has been added to the ticket**.
   

*Keep in mind that Requester Wait Time never resets, if a ticket is placed into the edge-case policy repeatedly, the time accumulates.

**You may want to consider an additional trigger to remove the tag when a ticket is solved - in case a follow-up ticket is created and you don't want it to go directly into the edge-case Policy.

More advanced challenges

First replies vs. Next replies

I already mentioned the limitations of the Requester Wait Time target - if you have tickets that repeatedly move into an edge-case SLA policy, the target may breach unexpectedly.

One possibility is to only use that target for edge cases that await afirst replyand use a different target (and policy) fornext-replyedge-case scenarios - like Periodic Update for example.

Multiple teams/policies with varied schedules and targets

If you already have multiple policies set up to accommodate teams that have different targets, that may necessitate the creation of

• Multiple edge-case policies that mirror existing team policies, or
• Ballpark targets - if your main policies don't differ much, but there are more than warrants creating multiple policies, or
• Calendar hour targets - if the reason for varied targets is the individual teams work different hours per day, but the overall target towards the customer is the same. The drawback here is that breaches would happen on weekends and holidays.

I'm not happy with any of these solutions, so if someone has a better idea, I'm happy to hear from you.