# Use service level agreements (SLAs)

> A service level agreement, or SLA, is a method of measuring conversation metrics to ensure you are providing consistent support to your customers.

Source: https://help.kustomer.com/en_us/service-level-agreements-SyZ4xWcgf

Last updated: 2026-06-11T19:02:02.363Z

A 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:

1.  Setting conditions in which they apply to a conversation.
2.  Selecting the metrics you’d like to measure.
3.  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](https://help.kustomer.com/business-schedules-SJj3ZxD1E) 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](#create)
*   [Understand SLA metrics](#understand)
*   [How your team sees SLAs in a conversation](#team)
*   [How your team sees SLAs in a search](#search-status)
*   [How SLA changes impact a conversation](#impact)

### 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:**

1.  Go to **Settings**![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/1a7c47c9f73c68dde7a5031d505db422.png)**\>** **Workspace** > **Service Level Agreements**.
2.  Select **Add** **SLA**.
3.  Enter a policy name and description. This is important as it will help you reorder them properly later.
4.  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.![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/8fe73e25361fcc22ffdc0c69b4c5ea3e.png)
5.  In the Set SLA Metrics section, activate the metrics you’d like to measure by inputting the maximum allotted hours and/or minutes.
    
    **Note:** [Conversation Priority](https://help.kustomer.com/priority-SyBpkBHIZ) can be used in Service Level Agreements to set specific policies on conversations based on their set priority. If you choose not to use priority, enter your information into the default priority (3). 
    
    For details on these metrics, see [Understand SLA metrics](#understand).  
    ![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/1727491d75358caf3dbd9c371a9b288c.png)
6.  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.  
    ![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/eaf2a8fc0846a3adca1c12ac22bd988e.png)
7.  Once you are done configuring your SLA, select **Save**.

#### **Configure exclusion conditions**

You can add one or more conditions to exclude specific conversations from an SLA policy. When you configure multiple exclusion conditions, select ****ALL**** or ****ANY**** to control how the conditions work together.

*   ****ALL****: A conversation must match every condition to trigger the exclusion. Select ****ALL**** when each condition must be true at the same time.
*   ****ANY****: A conversation only needs to match one of the conditions. Select ****ANY**** when any single condition is enough to trigger the exclusion.

****Example:**** You want to exclude conversations where the NPS ID is not set or the Influence Form ID is not set. Add both conditions and select ****ALL****. This ensures that conversations missing both values are excluded, while conversations with at least one value set remain in the SLA.

#### **Understand "is set" and "is not set" conditions**

When you use "is not set" as an exclusion condition, the SLA excludes conversations where the field has no value.

*   ****"NPS ID is not set"**** as an exclusion condition: Conversations ****without**** an NPS ID are excluded from the SLA. Conversations ****with**** an NPS ID are included in the SLA and evaluated against the policy.

This is the expected behavior. If a conversation has the field set, it does not match the "is not set" condition and therefore is not excluded.

### **SLA policy evaluation order**

SLA policies evaluate from top to bottom. Kustomer applies the first policy that matches a conversation's conditions. Once a match is found, no further policies are evaluated.

****Common mistake:**** Placing a broad SLA policy (with no conditions or very general conditions) above a more specific policy. The broad policy matches every conversation and prevents the specific policy from ever applying.

****To fix SLA ordering:****

1.  From the left navigation, click ****Settings****. The Settings page opens.
2.  In the ****Settings**** page, click ****Platform****, then select ****SLAs****.
3.  Drag more specific policies (for example, a "Partnership SLA" or "VIP SLA") above broader policies (for example, "Email SLA" or "Phone SLA").
4.  Add conditions to broad policies so they match only their intended scope. For example, add a ****Conversation Channel equals Email**** condition to an Email SLA so it does not apply to all conversations.

### **Understand SLA evaluation order**

Kustomer evaluates SLAs from top to bottom. When a conversation matches an SLA's conditions, that SLA applies and no further SLAs are checked. This means a broad SLA without conditions placed above a specific one will match every conversation first.

To ensure specific SLAs apply correctly:

1.  From the SLA settings page, drag your more specific SLAs above broader ones using the order icon on the left side.
2.  Add channel conditions to broad SLAs. For example, set ****Conversation Channel equals Email**** on your Email SLA so it only matches email conversations.
3.  After reordering, test by creating a new conversation that matches the specific SLA's conditions and confirm the correct SLA applies.

### 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.  
          
        
*   **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 new `breachAt` 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 new `breachAt`  
          
        
*   **Total Customer Wait Time** is the total amount of time a customer waits for a human rep response. This includes time when the conversation is snoozed.  
      
    *   When a conversation matches an SLA policy, `totalCustomerWaitTime.breachAt` is set to the time when the metric will breach, for example: `breachAt: "2022-06-01T13:06:00.364Z"`.
    *   If a rep replies and then leaves the conversation open or snoozed, Kustomer calculates the time remaining in the policy and stores it in milliseconds as `totalCustomerWaitTime.remainingTime`. When the conversation is reopened, that stored value is used to create a new `totalCustomerWaitTime.breachAt`.
    *   If a rep snoozes the conversation without replying, the counter continues toward the existing `breachAt` time.
    *   If a rep marks the conversation done without replying, the metric is considered satisfied and Kustomer updates `totalCustomerWaitTime.satisfiedAt`.

### 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.

![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/81189b655b3956d3af221b4da6362367.png)

 The following states are available:

**State**

**Description**

**Badge**

Active

Time left remaining to the first breach.

![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/f09ea7b8208d69393290f4f5ad7b4134.png)

Breached  
(conversation open)

At least one metric in the policy was breached and the conversation is still Open.

![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/75e963f6eecf29904a06ee737517231a.png)

Breached  
(conversation done) 

At least one metric in the policy was breached and the conversation is marked Done.

![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/8a3651029156a5d9eb2446c15375c797.png)

Satisfied

All metrics in the policy were met.

![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/c66e9c314e853dfe7c12dcb7454113ed.png)

Paused

Countdown to the first breach is paused until the customer responds. 

![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/80518554bc8da7e1f3af73ce6c725880.png)

  

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. 

![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/9e979ac06272be3e8ebcf2201d2185da.png)

### 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. 

![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/750b585b4d8a872e12935f93323d3b04.png)

**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** ![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/ab0daafe754b88ce2aaecb29f337b4e9.png) and then select **SLA**. 

![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/80b7109f0fed3030b571f03ee9dd3be4.png)

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.

![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/c66e9c314e853dfe7c12dcb7454113ed.png)![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/8a3651029156a5d9eb2446c15375c797.png)

Pending

Some metrics in the policies have yet to be fulfilled.

![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/f09ea7b8208d69393290f4f5ad7b4134.png)

Paused

Countdown to the first breach is paused until the customer responds.

![](https://cdn.kustomerhostedcontent.com/media/570fad9d9001bc1000163b28/80518554bc8da7e1f3af73ce6c725880.png)

  

### 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**](https://help.kustomer.com/business-schedules-SJj3ZxD1E) 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.

### **How SLA breach timers calculate with business hours**

When an SLA uses business hours (tied to a business schedule), the breach timer only counts time during scheduled business hours. Here is how the calculation works for the ****Longest Unresponded Message**** metric:

*   If an inbound message arrives ****during**** business hours, the SLA clock starts immediately.
*   If an inbound message arrives ****outside**** business hours, the SLA clock starts at the next business day opening time.
*   The timer pauses outside of business hours and resumes at the start of the next business period.
*   For split-shift schedules (for example, 9:00 AM–12:00 PM and 1:00 PM–5:00 PM), the timer pauses during the gap and resumes when the next shift begins.
*   The breach fires at the exact moment the configured business hours threshold is exhausted.