Use service level agreements (SLAs)
Last Update: Sep 2024 • Est. Read Time: 5 MINA service level agreement, or SLA, is a method of measuring conversation metrics to ensure you provide consistent customer support. In Kustomer, SLAs are designed by:
- Setting conditions in which they apply to a conversation.
- Selecting the metrics you’d like to measure.
- Inputting target times for each metric set.
You can link SLAs to your organization's availability and only have them run during set business schedule hours. This is especially helpful for organizations with distributed teams in various locations since you can configure business schedules for various time zones.
Who can access this feature? | |
User types | Admins can access the SLA page. |
In this article
- Create an SLA policy
- Understand SLA metrics
- How your team sees SLAs in a conversation
- How your team sees SLAs in a search
- How SLA changes impact a conversation
Create an SLA policy
When a conversation is created in Kustomer, it passes through your SLA policies. The order of your SLAs within the SLA Management page will be important to ensure the correct SLA is applied to the correct conversation. When a conversation is created, it will apply the first SLA that matches its criteria in order from top to bottom, moving down the list until the conversation matches an existing policy's criteria. For conversations that exist before the new SLA is created, the SLA will match its criteria against conversation updates, as long as they have not already matched a policy.
To create a policy:
- Go to Settings
> Workspace > Service Level Agreements.
- Select Add SLA.
- Enter a policy name and description. This is important as it will help you reorder them properly later.
- In the Create Conversation-Based Criteria section, set the criteria determining when the SLA will be applied. For example, it could apply to all inbound emails or specific inbound messages, such as VIP customers. The SLA will be applied to all currently open conversations in this example.
- In the Set SLA Metrics section, activate the metrics you’d like to measure by inputting the maximum allotted hours and/or minutes. You can have different SLA timers based on conversation priorities. If you choose not to use priorities, enter your information into the default priority (3). For details on these metrics, see Understand SLA metrics.
- You can apply the SLA to a specific business schedule, Calendar Hours, or the Default Business Schedule. If you only apply SLAs during business hours, metric timers will be paused while you’re unavailable, and time outside of business hours will not count against the SLA policy. With calendar hours selected, metric timers will be active 24/7.
- Once you are done configuring your SLA, select Save.
Understand SLA metrics
You can think of SLA metrics as a conversational stopwatch that tracks the time between two points in a conversation. There are four metrics available:
- First Response Time is the time between the first inbound message received from a customer and the first outbound message sent from an agent. Snoozing a respective conversation will not pause the First Response Time timer. Auto responses triggered by the system will not count towards the First Response Time. Only messages sent by an actual user will count. If a conversation starts with an initial outbound message, First Response SLA will be triggered by the customer's first inbound message.
- Longest Unresponded to Message is the time from the last inbound customer message to the agent outbound message. Snoozing a respective conversation will not pause Longest Unresponded to Message timer.
longestUnrespondedMessage.breachAt
date-time is set upon match- If a user replies, the SLA object is updated with the outbound message's timestamp to create
longestUnrespondedMessage.satisfiedAt
- If a user snoozes without a reply, we continue moving towards the
breachAt
time - If a user marks done without a reply, the metric is considered to be satisfied and the value is updated to
longestUnrespondedMessage.satisfiedAt
using the timestamp of the mark Done action - If the customer reopens the conversation with another message and the agent had never sent a response to the original inbound message,
breachAt
continues to be set based on the first inbound message.
- If a user replies, the SLA object is updated with the outbound message's timestamp to create
- Total Conversation Open Time is the total time a conversation remains open from the first inbound message received to when it is marked Done. This does not count the time the conversation spends snoozed.
totalConversationOpenTime.breachAt
is set upon match- If a user snoozes this conversation, we will pause the timer and add a
totalConversationOpenTime.remainingTime
value in milliseconds. When the snooze elapses or conversation is manually reopened we'll take the milliseconds value and compare it to the schedule associated with the policy to set the newbreachAt
time - If the conversation was marked done, we'll do a similar calculation but instead use the milliseconds value in the attribute
totalOpen.businessTimeByScheduleSinceLastDone
to determine the newbreachAt
- If a user snoozes this conversation, we will pause the timer and add a
- Total Customer Wait Time is the total time a customer waited for a response from an agent and includes the time the conversation spent snoozed.
totalCustomerWaitTime.breachAt
is set upon match. This is a time similar tobreachAt:"2022-06-01T13:06:00.364Z"
.- If a user replies and leaves the conversation open or snoozed the remaining time in the policy is calculated and stored in milliseconds as
totalCustomerWaitTime.remainingTime
. When the conversation is reopened, that milliseconds value is used to create a newtotalCustomerWaitTime.breachAt
- If a user snoozes without a reply, the counter continues towards its
breachAt
time - If a user marks the conversation done without a reply, that metric is considered satisfied and updates the value to
totalCustomerWaitTime.satisfiedAt
- If a user replies and leaves the conversation open or snoozed the remaining time in the policy is calculated and stored in milliseconds as
How your team sees SLAs in a conversation
SLAs are displayed in a timeline, giving you a quick view of their state. You can see the current state of your SLAs right in a conversation.
The following states are available:
State | Description | Badge |
Active | Time left remaining to the first breach. | ![]() |
Breached (conversation open) | At least one metric in the policy was breached and the conversation is still Open. | ![]() |
Breached (conversation done) | At least one metric in the policy was breached and the conversation is marked Done. | ![]() |
Satisfied | All metrics in the policy were met. | ![]() |
Paused | Countdown to the first breach is paused until the customer responds. | ![]() |
When a user hovers over an SLA badge, they will see the current state of individual metrics within the policy. The SLA state is still active in this example since two additional metrics haven't been breached or satisfied yet. The badge will display the first metric that will be breached.
How your team sees SLAs in a search
You can also search for conversation SLA status by setting the criteria to Conversation SLA Status is equal to and selecting one of the status options (Done, Pending, or Paused) from the drop-down menu.
Note: These statuses correspond to SLA status and not conversation status. Conversations shown in search results can either be open, done, or snoozed.
The SLA badge isn't shown in the search results by default. To add it, select Change Columns and then select SLA.
Below is a description of the three SLA statuses:
SLA Status | Description | Badge |
Done | All metrics in the policy have either been satisfied or breached. This result returns conversations that are open, done, or snoozed. | ![]() ![]() |
Pending | Some metrics in the policies have yet to be fulfilled. | ![]() |
Paused | Countdown to the first breach is paused until the customer responds. | ![]() |
How SLA changes impact a conversation
Making changes to an existing SLA creates a new SLA version. This latest version's criteria will be used to match to conversations that are created immediately after the version was created.
For existing conversations that are already matched to an older version of the same SLA policy, the new version's criteria will be applied to conversation updates. Upon the creation of the new SLA version, no changes will be made to SLA metrics that have already been breached, but any pending SLA metrics will follow the new version's criteria.
If you change the business schedule used in an SLA policy, any changes to the schedule will also impact the conversations that matched to that SLA, and will be applied on conversation updates.