Service Level Agreement (SLA)
A Service Level Agreement, or SLA, is an agreed-upon measure of the response times that your support team delivers to your customers. Providing support based on service levels ensures that you’re delivering measured and predictable service. It also provides greater visibility when problems arise.
You can define SLA service targets in Sparkcentral so that you and your agents can monitor your service level performance and meet your service level goals. Sparkcentral highlights conversations that fail to meet service level targets so that you can promptly identify and address problems.
Understanding how SLA policies are applied to conversations
When a new conversation is started, it runs through all of the normal automations you’ve already set up in your Sparkcentral instance. After the automations have been executed, we run that conversation through the SLA system.
Getting started with SLA
In order to enable the SLA feature in your instance, you will need to configure the following:
- SLA policies: define how quickly you would like to respond to your customers
- Business hours: set the times is your team available to help customers
- Prioritization rules: change the order of the queue depending on priorities you set
In the SLA policy you define the following:
- First Response Time: What is the longest time a customer should wait before an initial response from one of your agents.
- Conversation Response Time: Once the agent has responded to a customer, we consider this to be an active conversation. To offer a good experience you might want to set a shorter time to respond for active conversations.
- Actions if the SLA is breached: Once the SLA is (almost) breached you can send a system message to your customer automatically. Also you can decide to remove ownership of a conversation once the SLA is breached.
Once you have created a new policy, you can apply it to one or more channels.
SLA policies and chatbots
If the customer sends an inbound message and a chatbot immediately responds, we do not consider this being part of the SLA. Only when the conversation becomes available in the new queue for a (human) agent the SLA starts counting.
Adding a new SLA policy
Navigate to Settings – Queue – SLA and click on Add SLA to configure your first SLA policy.
You will need to specify the following:
- Name: Give this SLA policy a name. This name will become visible in the reporting. So make sure you give it a name you can easily recognize.
- Mark conversation as breached: Set the maximum time your customers should have to wait to get a response.
- Mark conversation as urgent: If your First Response Time is 30 minutes, for example, you can decide to mark the conversation as urgent if there is only 15 minutes left to respond for example.
- Release ownership (optional): If the SLA is breached and the conversation is owned by one of your agents, you can automatically release ownership. This will enable other team members to take over the conversation and therefore increase chances that the conversation is being handled.
- Intermediate customer feedback: If the SLA is either Urgent or Breached you can decide to automatically send a message to your customer. You can let them know it still has your attention but it takes longer than expected to respond.
- Channel selection: The SLA configuration can be applied to 1 or more channels. You can also set a different SLA for mediums that support both public and private messages (e.g. Twitter/Facebook).
Business Hours are the scheduled hours that the agents are available to answer customers. The SLA is calculated based on the business hours you have configured.
First Response Time SLA example: Your business hours are weekdays Monday to Friday from 9 AM to 5 PM. Your First Response Time SLA is 30 minutes. If you received an inbound message from your customer on Friday at 4:45 PM the SLA expires on Monday at 9:15 AM.
This article explains how to configure business hours in your instance.
The prioritization feature helps you to change to order of conversations in your New queue. The prioritized conversations show at the top of your queue.
If you set an SLA for public channels to 1 hour and direct messaging channels to 30 minutes, you can use prioritization to make sure direct messages also appear on top of the public messages.
This article explains how to use prioritization in your instance.
Agents can see the SLA status of a conversation in the queue. On each conversation where an SLA has been applied, we will show a badge with a color (gray orange, red) and time left before the SLA is breached or how long the conversation is already overdue.
30m : A new conversation well within SLA has a gray badge with an indicator how much time remains before the SLA is breached.
15m : If the conversation has been in your new queue for some time it turns orange if time is running out.
-5m : If the SLA is breached the badge will turn red. The time will indicate how long ago the SLA was breached.
Breach email notification
We have implemented a useful feature that allows you to receive an email if there are one or more breached SLA’s. This can be turned on or off. It is also possible to specify the amount of SLA breaches that are needed in order for the email to be sent out. This might especially come in handy for an administrator that wants to be updated on the breaches by mail.
- You can enable this by clicking on your account dropdown at the top right of the Sparkcentral app.
- A menu will drop down, in which you can select My Settings.
- On the left of the window that just appeared, click on Notifications.
- On this page, you will see a section with SLA Notifications.
- Check the checkbox to receive mails.
- You can specify the amount of breaches to the right of that.
Reporting on SLA
You can now view how well you are meeting your SLA policies with the SLA reporting dashboard. This dashboard gives you relevant information for each SLA metric you measure. The reports enable you to pinpoint areas where you might need to increase efficiency or staffing based on weekly and hourly information.
The SLA dashboard is available through Analytics (BETA) – SLA. If no SLA policies have been configured in your instance this dashboard will contain no information.
The following charts are available on the dashboard:
- SLA: Overall SLA performance (First Response Time SLA and Conversation Response SLA), based on SLA events. The graph displays all the SLA events which occurred during the selected time period and for which the conversation has been resolved.
- First Response Time SLA: Based on First Response Time SLA events only. The graph displays all SLA events which occurred during the selected time period and for which the conversation has been resolved.
- Conversation Response Time SLA: Based on Conversation Response Time SLA events only. The graph displays all SLA events which occurred during the selected time period and for which the conversation has been resolved.
- Agent First Response Time: The average of all first response times. Only for those channels which have an SLA Policy enabled. All SLA events which occurred during the selected time period and for which the conversation has been resolved are included.
- Average Conversation Response Time: The average of all conversation response times. Only for those channels which have an SLA Policy enabled. All SLA events which occurred during the selected time period and for which the conversation has been resolved are included.
How the SLA metric is calculated
For example, suppose you answered your customers’ message within the target time once, but breached the target three times after. Each of those achievements and breaches are calculated as separate instances.
Now how would this work if you are trying to calculate your SLA percentage?
Let’s say you have five conversations:
Number of instances
Overall, there are 20 instances of your agent’s reply time measured across five conversations. Your SLA % is calculated by taking the number of achieved instances over the total number of instances. In this case, your achieved percentage would be 15 achieved instances/20 measured instances = 75%