How do SLAs work in HappyFox?

INTRODUCTION

This article details out SLA behavior in HappyFox, including SLA objectives, conditions, exclusion statuses, breach time and work-schedule with examples. If you are trying to set up an SLA, please refer to the article related to set up before reading this article.

https://support.happyfox.com/kb/article/95-handling-service-level-agreements 

SLA-NUTS AND BOLTS

An SLA consists of the following components.

• Objective

• Conditions

• Category Association

• Goal Percentage

• Work Schedule

• Exclusion Statuses 

OBJECTIVE

Objective is a time-based condition that will be applied on tickets to meet service level quality commitments.

There are five SLA objectives available in HappyFox.

1. Time taken to send first response to a ticket

   • Utility: Ensure that the first response to a ticket is sent within a predetermined threshold

   • Start-Time: The begin time is always ticket-creation time

   • Invalidation Criteria: Becomes invalid when a agent responds to a ticket

2. Time taken to change a ticket from unassigned to assigned

   • Utility: Ensure that tickets are duly assigned within a specific time-interval

   • Start-Time: Specific point in time when the ticket status is unassigned(for existing tickets) and creation-time for newly created unassigned tickets

   • Invalidation Criteria: Ticket is assigned to an agent.

3. Time taken to respond to a contact response

   • Utility: Ensure quick responses to customer queries

   • Start-Time: Last customer-reply time

   • Invalidation Criteria: Gets invalidated as soon as an agent-reply is added 

4. Time taken to add response to an existing agent response

   • Utility: Ensure timely update from customer to gain sufficient context to resolve the issue

   • Start-Time: Begin time is the last agent-reply time

   • Invalidation Criteria: Gets invalidated when customer replies to the Agent response

5. Time taken to reach ticket status

   • Utility: Ensure that ticket reaches terminal/desirable status within a given threshold time

   • There are two scenarios

     1. New Tickets

        1. Start-Time: Last customer-reply time

        2. Invalidation Criteria: Every time a customer replies, SLA timer gets reset

     2. Re-opened Tickets

        1. Start-Time: ticket-reopen time

        2. Invalidation Criteria: When ticket reaches desired status. SLA timer is not reset when client replies

CONDITIONS

You can associate various ticket property conditions such as status, priority, contact group, subject, ticket and contact custom fields etc. with an SLA.

Match All and Match Any

For the SLA to be validated

1. If “Match All” or “Match Any” is used in isolation

• All the conditions under “Match All” need to be true.

• At least one condition under “Match Any” needs to be true.

2. If “Match All” and “Match any” are used in combination

• All the conditions under “Match All” need to be true AND at least one condition under  “Match Any” needs to be true.

SLA EXECUTION

SLA execution workflow can be modified by toggling/un-toggling the following checkbox.

“Start SLA evaluation only when all applicable conditions are met”

This checkbox can be found immediately beneath the SLA objective picker. The purpose of this is to allow customers to have greater control over their SLA workflow execution.

With this checkbox enabled, SLA target-time/evaluation begins only when both SLA objective and SLA conditions are valid. In other words, when an SLA contains “Match All/Match Any” conditions besides the objective, enabling this checkbox will reset(clear) SLA evaluation every time the conditions (as a whole) evaluate to false.

Let us consider two scenarios for the below objective and conditions.

Objective: Time taken to send first response to ticket is 2 hours

Conditions: Priority is Critical && Status is Open

For the above objective, customers can have different requirements on when this SLA needs to be triggered and when it needs to breach.

Checkbox disabled: Workflow as described in Scenario 1

Checkbox enabled: Workflow as described in Scenario 2

Scenario 1

• Requirement: Any new ticket that has been created in HappyFox should receive a response from agent within 2 hours, provided that Status is Open and Priority is Critical when the SLA is about to breach. Let us understand this better with the following example.

1. Time: 10:00 AM

   • Status: New

   • Priority: Medium

   • Event: Ticket creation

   • SLA target-time: 12.00 PM

   • Will SLA Breach with the above conditions? No

2. Time: 11:00 AM

   • Status: Open

   • Priority: Medium

   • Event: Status toggle by agent. No update yet

   • SLA target-time: 12.00 PM

   • Will SLA Breach with the above conditions? No

3. Time: 11.30 AM

   • Status: Open

   • Priority: Critical

   • Event: Priority escalation by agent. No update yet

   • SLA target-time: 12.00 PM

   • Will SLA Breach with the above conditions? Yes

4. Time: 12:00 PM

   • Status: Open

   • Priority: Critical

   • Event: SLA breach happens

• Despite Status and Priorities changing over the course of the time, if the conditions are satisfied i.e (Priority - Critical and Status - Open) during the SLA target-time (12.00 PM in this case), then the SLA would breach.

Scenario 2

• Requirement: Any new ticket that has been created in HappyFox should receive a response from agent within 2 hours from the time Status is Open and Priority is Critical. In other words, whenever the conditions change, the agent have 2 hours to respond to a customer from the point in time when the SLA conditions are satisfied. Consider the following example.

1. Time: 10:00 AM

   • Status: New

   • Priority: Medium

   • Event: Ticket creation

   • SLA target-time: Not Applicable

   • Will SLA Breach with the above conditions? No

2. Time: 11:00 AM

   • Status: Open

   • Priority: Medium

   • Event: Status toggle by agent. No update yet

   • SLA target-time: Not Applicable

   • Will SLA Breach with the above conditions? No

3. Time: 11.30 AM

   • Status: Open

   • Priority: Critical

   • Event: Priority escalation by agent. No update yet

   • SLA target-time: 1.30 PM

   • Will SLA Breach with the above conditions? Yes

4. Time: 12:00 PM

   • Status: Waiting

   • Priority: Critical

   • Event: Status change by agent. No update yet

   • SLA target-time: Not applicable

   • Will SLA Breach with the above conditions? No

5. Time: 1:00 PM

   • Status: Open

   • Priority: Critical

   • Event: Status change by agent. No update yet

   • SLA target-time: 3.00 PM

   • Will SLA Breach with the above conditions? Yes

6. Time: 3:00 PM

   • Status: Open

   • Priority: Critical

   • Event: SLA breach

• For this scenario, SLA enforcement gets reset everytime applicable conditions change. Also, unlike Scenario 1, the SLA target-time is relative to the time the conditions are satisfied.

CATEGORY ASSOCIATION

An SLA can be associated to multiple categories at once. This will enable the SLA to be active only for select categories 

GOAL PERCENTAGE

This refers to the percentage of tickets that should meet the SLA objective. This percentage will be calculated based on the conditions and category association.

WORK SCHEDULE

Work Schedule indicates the time period within which SLA timer needs to operate upon. Please refer to the article related to Work Schedule setup to learn more.

https://support.happyfox.com/kb/article/166-create-a-new-work-schedule 

Work Schedule affects the breach time of an SLA as described below.

When we set SLA objective’s breach time in:

1. Hours/Minutes - This is of lower granularity and hence operates as per work schedule hours

2. Days - There are two scenarios.

   • The current day is a holiday(when SLA becomes valid) - Always ignores current day and sets up the breach-time as End of Day (E.O.D.)of “nth” working day from current day i.e if SLA is set to breach in 2 days, it will breach on 2nd working day E.O.D.

   • The current day is a working day - SLA will breach on the same time on “nth working day” from today. For e.g., if SLA becomes valid at 1.00 PM on Monday and is set to breach in 2 days, then the breach time will be set as 1.00 PM on Wednesday 

EXCLUSION STATUSES

1. Whenever a ticket is moved to an exclusion status, the SLA timer “pauses”.

2. When it comes out of the excluded status and SLA condition gets active, the new breach time will be calculated as the original breach time plus by the time that the ticket spent in exclusion status 

NOTE:

1. Newly created SLAs can still be evaluated for old tickets when the old tickets are updated.

2. Merge Ticket

   • On merging tickets, behavior varies as shown below.

     1. Loser ticket has only one update - Here, this update is carried forward to winner ticket as a contact response. This can potentially trigger an SLA to start evaluation on the winner ticket.

     2. Loser ticket has multiple updates - No update is carried forward to the winner ticket.

3. Category Change

           On category change, SLA behavior is as shown below.

• Consider a scenario in which a ticket is moved from L1 to L2, and there are SLAs exclusive to L2.

  1. For example, assume that an SLA is set up ONLY for L2 support tickets with time-taken to reply to the customer as 2 hours.

  2. The ticket is moved to L2 category 2 hours after it remains in L1 category (with no update).

  3. Now, SLA breach happens immediately after the ticket is moved to L2.

Examples:

We need to send first response to “High” priority tickets within 1 hour.

• Ticket gets created at 1:00 PM with priority “Medium”.

• Ticket is updated by agent at 1:30 PM after review. Priority is now “High”.

• The SLA will breach at 2:00 PM although the condition matched only at 1:30 PM.

2. Time taken to reach closed status for “High” Priority tickets needs to be less than 2 days.   Work Schedule -Monday to Friday 9:00 AM -5:00 PM needs to be considered.

• A new ticket is created at 9:00 AM on Friday, Jan 06, 2017 and priority is set to “Low”.

• The customer sends a reply and the priority is changed to “High” at 10:00 AM on Friday, Jan 06, 2017.

• The SLA will breach at 10:00 AM on Tuesday, Jan 10, 2017 since work-schedule has been set up.

• However, if there is a customer reply is sent at 11:00 AM on Monday, Jan 09, 2017, the SLA timer is reset and the new breach time is 11:00 AM on Wednesday.

3. Time taken to respond to a contact response should be less than one hour for “High”  Priority tickets.

• A new ticket is created at 9:00 AM on Friday, Jan 06, 2017 and priority is set to “Low”.

• Agent replies to the customer at 10:00 AM on Friday and sets the priority as “High”.

• Now customer replies at 10:30 AM.

• The SLA timer starts at 10:30 AM and the expected breach time is 11 30 AM.

4. Time taken to respond to a contact response should be less than one hour for “High”  Priority tickets.

• A new ticket is created at 9:00 AM on Friday, Jan 06, 2017 and priority is set to “Low”.

• Agent sets the priority as “High” at 10:00 AM on Friday, Jan 06, 2017.

• The SLA breaches immediately as one hour has passed since the last customer response.

• This behavior is different from that in Example # 3 because agent reply was added along with the priority change in that case.