SLA Guide

——Set ticket processing timeliness standards, automate timing and reminders, and improve ticket processing efficiency and customer experience

Role of SLA

SLA can set independent processing timeliness targets and reminder objects for different tickets. When a ticket is created or updated, it will calculate the processing time for the tickets. When the target time is reached, a reminder can be sent to the reminder object.
The ticket processing timeliness can also be used for report statistics to help enterprises improve processing efficiency and customer experience.
A ticket can only have one SLA at a specific time point, but multiple SLAs can exist throughout the life cycle of the ticket.
For example, in the on-site maintenance scenario, set SLA-A for Agent A, with a corresponding processing timeliness of 2 hours, and set SLA-B for Agent B, with a corresponding processing timeliness of 48 hours. After a customer reports a malfunction, agent A must assign a maintenance engineer within 2 hours, and the maintenance engineer must resolve the issue within 48 hours after receiving the ticket.

SLA Work Time

If you wish the SLA target not to count time during non-work time, you can set the work time for the SLA. We strongly recommend that you set the SLA work time to be the same as the agent/skill group's work time.

Figure 1: SLA Work Time

● 1st Reply Time

Refers to the time of the ticket's first public reply (agent replying to customers, trigger replying to customers, Q&A bot replying to customers, Amazon backend replying to customers, replies through API, etc.), independent of changes in ticket status and field updates.
Regardless of whether the ticket has a matching SLA, the ticket will have a first reply time after the first reply is generated.

Figure 2: 1st Reply Time

● Next Reply Time

Refers to the time the agent needs to make a public reply after the customer replies. Only when there is a customer reply will the target for the next reply time be triggered, and a public reply from agent counts as a response to that target. Therefore, a ticket will have multiple next reply time targets, and a complete next reply indicator always exists in a Q&A format between the customer and agent.
If the customer replies multiple times without any public reply from agent in between, the starting timing for the next reply will begin from the first customer reply.

● FCR Time

Refers to the time when the status of a ticket is first set to "Resolved" or "Closed" category (including agent, trigger, API), independent of replies and field updates. Regardless of whether the ticket has a matching SLA, the ticket will have a FCR Time after the first resolution.

Figure 3: FCR Time

● Final Resolution Time

Refers to the time when the status of the ticket was last set to "Resolved" or "Closed" category (including agent, trigger, API). Because there are scenarios where the ticket changes from "Resolved" to "Processing", the final resolution time is a continuous timing process.
Regardless of whether the ticket has a matching SLA, the ticket will have a final resolution time after the last resolution.

Figure 4: Final Resolution Time

● Customer Waiting Time

Refers to the actual waiting time of the customer from the moment the ticket is created until the ticket is resolved (when the ticket status is last set to "Resolved" or "Closed"). Because there are scenarios where the ticket changes from "Resolved" to "Processing", the customer waiting time is a continuous timing process.

Calculation formula: Last resolution time of the ticket - ticket creation time - duration of the ticket remained in the categories of "Resolved", "Closed", or "Awaiting Response" - Non-work time (this value exists if the SLA work time is set).

According to the formula, if the ticket has not been resolved, the customer waiting time cannot be calculated. Moreover, the duration that the ticket stays in the "Awaiting Response" category is completely determined by the customer, so reminders for about to timeout cannot be made for customer waiting time.

Figure 5: Customer Waiting Time

● Agent Work Time

Refers to the actual ticket processing time of agent from the moment the ticket is created until the ticket is resolved (when the ticket status is last set to "Resolved" or "Closed"). Because there are scenarios where the ticket changes from "Resolved" to "Processing", the agent work time is a continuous timing process.
Calculation formula: Last resolution time of the ticket - ticket creation time - duration of the ticket remained in the categories of "New", "Paused", "Resolved", "Closed", or "Awaiting Response" - Non-work time (this value exists if the SLA work time is set).
According to the formula, if the ticket has not been resolved, the agent work time cannot be calculated. Moreover, the duration that the ticket stays in the "Awaiting Response" and "Paused" categories is beyond the control of the agent, so reminders for about to timeout cannot be made for agent work time.

Figure 6: Agent Work Time

SLA Management

Admin can add multiple ticket processing timeliness schemes for the enterprise. When a ticket is created, the scheme will judge according to the set conditions, record the SLA that meets the conditions, and give a countdown reminder according to the targets. You can add multiple sets of rules to meet the efficiency requirements of different business scenarios and users.

● Creation

Click [+ Create SLA], fill in the title and description, add one or more filter conditions, select or add timing rules, set SLA targets and reminder methods, and you have completed the setting of an SLA.

Figure 7: Creation

● Sort

You can create multiple SLAs, and when a ticket is created or updated, it will match in the order of the SLAs, and stop further matching once an SLA is matched.

Figure 8: Sorting

● Editing

After editing the SLA, it will only take effect on subsequent created or updated tickets, but the SLA targets that the ticket have already been responded to will still be recorded and counted.

● Deletion

After deleting the SLA, it will only take effect on subsequent created or updated tickets, but the SLA targets that the ticket have already been responded to will still be recorded and counted.

SLA Map

● Processing Timeliness for Ticket List

The processing timeliness field displays the maximum remaining time of the ticket until the set target time. When the target is responded to, the remaining time will not be displayed.
The processing timeliness has 6 display forms:
Display "--" when there is no applicable SLA for the ticket or all targets have been responded to;
Display green when the remaining time > 15 minutes;
Display yellow when 0 < remaining time <= 15 minutes;
Display "now" when remaining time = 0 minutes;
Display "-" + red when remaining time < 0 minutes;
Display "paused" when the target has been paused, for example, when the ticket has an agent work time target but the current status category of the ticket is "Awaiting Response";

For example: If the target for the 1st reply time of a ticket has already timed out by 1 hour, and there are still 3 hours left for the FCR time target, the processing timeliness field will display -1h (red), and after agent first reply, it will display 3h (green).

Processing timeliness supports sorting, and agent can prioritize processing tickets that have already timed out or are about to time out through sorting.

Figure 9: List - Processing Timeliness

● Ticket Details Show the Timeliness of All Targets

When entering the ticket detail page, the current deadline and processing timeliness of all targets for the ticket will be displayed in the upper left corner. When the target is responded to, the remaining time will not be displayed.

Figure 10: Details - Processing Timeliness

● SLA Operation History

Ticket compliance, SLA changes, target achievements, timeouts, and deadline changes will all be recorded in the operation history. When the SLA target for the ticket is not met, you can check the operation history to find out which step is problematic.

Figure 11: Operation History

Differences Between Old and New Version SLA

● Old Version SLA

If your system displays an upgrade prompt, then the version you are currently using is the old version.

Figure 12: Upgrade SLA

● Difference Description

The new version of the SLA will rematch the SLA during the creation and updating of tickets, while the old version only matches the SLA at the time of ticket creation. The new version of the SLA includes additional targets such as the next response time, final resolution time, customer waiting time, and agent work time;
After upgrading to the new version of the SLA, ticket compliance, SLA changes, target achievements, timeouts, and deadline changes will all be recorded in the operation history;
After upgrading to the new version of the SLA, the "processing timeliness" field in the ticket list supports sorting. The data statistical dimensions of the new version of the SLA are more comprehensive and detailed; specific information can be found at SLA Statistics Guide;
The SLA statistics for tickets that were not completed before the upgrade will be somewhat affected, so it is recommended to choose an appropriate time to upgrade;

● Data Statistics after Upgrading to the New Version

After the upgrade, we will provide a brand new SLA statistical report and leave an entry to view the statistical data from before the upgrade;
After the upgrade, the SLA data statistics will be calculated according to a new statistical method, and the original statistical method will stop immediately. Therefore, the SLA data statistics for tickets that have not been completed before the upgrade may experience some discrepancies. We recommend that you choose an appropriate time to upgrade;