Service Level Agreements (SLAs)
Use policies to measure conversation metrics.Articles
Use service level agreements (SLAs)
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: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 typesAdmins can access the SLA page.In this articleCreate an SLA policyUnderstand SLA metricsHow your team sees SLAs in a conversationHow your team sees SLAs in a searchHow SLA changes impact a conversationCreate an SLA policyWhen 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 metricsYou 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 matchIf a user replies, the SLA object is updated with the outbound message's timestamp to create longestUnrespondedMessage.satisfiedAtIf a user snoozes without a reply, we continue moving towards the breachAt timeIf 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 actionIf 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 matchIf 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 timeIf 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 breachAtTotal 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 to breachAt:"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 new totalCustomerWaitTime.breachAtIf a user snoozes without a reply, the counter continues towards its breachAt timeIf a user marks the conversation done without a reply, that metric is considered satisfied and updates the value to totalCustomerWaitTime.satisfiedAtHow your team sees SLAs in a conversationSLAs 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:StateDescriptionBadgeActiveTime 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.SatisfiedAll metrics in the policy were met.PausedCountdown 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 searchYou 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 StatusDescriptionBadgeDoneAll metrics in the policy have either been satisfied or breached. This result returns conversations that are open, done, or snoozed.PendingSome metrics in the policies have yet to be fulfilled.PausedCountdown to the first breach is paused until the customer responds.How SLA changes impact a conversationMaking 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.Service Level Agreements (SLA) report
The SLA report helps you identify how your team is trending for each policy you’ve created. You can use this information to ensure that you provide consistent customer support. See Service Level Agreements (SLAs) for more information on creating policies.Who can access this feature?User typesManagers or users with custom permission set access to reporting can access this feature.In this articleOverview metricsConversations by Status chartConversations by Metric chartSLA report drilldownsMetric calculationsTo access the SLA report, go to Reportingand then select SLAs.Overview metricsThe following metrics are an overview of the selected SLA policy or all policies.The following metrics are available in the SLA report:Conversations in Policy - The total count of unique conversations that have matched to a SLA policy during the selected time range. % Achieved - The percentage of conversations that satisfy the SLA requirements for all metrics on the policy during the selected time range.Breached Conversations - The total count of unique conversations that have breached the SLA requirements of their matched policy up until the current date and time.Note: If a conversation matched with a policy with two metrics and one breached, the entire conversation will show as breached.Conversations by Status chartThis chart shows conversations with SLA policies that have been breached, achieved, or are still pending, by the date they were breached or achieved. Pending conversations (gray columns) show the future dates that conversations may possibly breach if the SLA is not met.Note: Achieved refers to conversations that satisfied all of their SLA policies before breaching.Conversations by Metric chartThis chart shows the count of conversations that breached or satisfied each metric across all policies. You can view the breakdown of metrics by day, week, or month and switch between Breached or Satisfied statuses.SLA report drilldownsYou can gain more insight into your SLA report using drilldowns. To better understand the data you will see when drilling down into the SLA report, it's necessary to understand how SLAs determine when a conversation is breached.When a conversation is created in Kustomer and it matches an SLA policy, all of the metrics in the policy get a breachAt timestamp that calculates when the policy is going to breach. If the policy is satisfied, the breachAt timestamp is replaced with a satisfiedAt timestamp that shows the date and time that the policy was actually met.If the conversation doesn't satisfy the policy, the breachAt timestamp permanently remains on the conversation to show that the policy was breached.Due to how this metric is calculated, you can use the SLA report to not only view conversations that failed to meet an SLA policy in the past, but also conversations that may breach in the future. When using drilldowns in these charts, keep the following in mind:The Breached Conversations chart will only show data for conversations that breached up to the current date and time. Any conversations that may breach in the future are not reflected in this count and won't appear in the View Data table.The Conversations by Status chart shows all of the conversations that are already breached, achieved, or pending breach. All conversations that might breach after the current date and time are considered pending. In the following image, the line shown in the highlighted area marks the current date (April 28th) and time. As you can see, all conversations shown below this line are still considered pending, even though it's the same day. Drilling down on the Breached and Achieved sections for April 28th is going to show conversations from the start of the day until the current time, while the Pending section is going to show them from the current time to the end of day, in your respective time zone.The breached section of the Conversations by Metric chart shows all of the individual metrics that have a breachAt timestamp, regardless of whether the conversation already breached or is pending a future breach.Metric calculationsBelow you'll find descriptions of the calculations for each metric including the attributes used in their formation. These can be beneficial when rebuilding standard report metrics in your custom reports or referenced when building metrics or performing analysis outside the Kustomer platform with data sourced from our API's or data services, such as Kinesis.The Date Anchor is the attribute which is linked to the date range picker in each report's header that determines whether or not any objects that fit the calculation criteria will appear in your chart or table.MetricCalculationDate AnchorConversations In Policydistinct conversation.id where conversation.sla.summary is presentconversation.sla.summary.firstBreachAt or conversation.sla.summary.firstSatisfiedAt% Achieveddistinct conversation.id where conversation.sla.summary.firstSatisfiedAt is set divided conversation.id where conversation.sla.summary is present and multiplied by 100conversation.sla.summary.firstSatisfiedAtBreached Conversationsdistinct conversation.id where conversation.sla.summary.firstBreachAt is setconversation.sla.summary.firstBreachAtConversations By Statusdistinct conversation.id where either conversation.sla.summary.firstBreachAt or conversation.sla.summary.firstSatisfiedAt is setconversation.sla.summary.firstBreachAt or conversation.sla.summary.firstSatisfiedAtConversations By Metricdistinct conversation.id where any of the date anchor attributes falls within the date range selectedany of: conversation.sla.metrics.totalCustomerWaitTime.breachAt, conversation.sla.metrics.totalCustomerWaitTime.satisfiedAt, conversation.sla.metrics.firstResponse.breachAt, conversation.sla.metrics.firstResponse.satisfiedAt, conversation.sla.metrics.totalConversationOpenTime.breachAt, conversation.sla.metrics.totalConversationOpenTime.satisfiedAt, conversation.sla.metrics.longestUnrespondedMessage.breachAt, conversation.sla.metrics.longestUnrespondedMessage.satisfiedAtReset your SLAs (Beta Access)
Sometimes, a customer can contact your support team again days or weeks after their initial request, which might cause an issue with your established SLAs. For example, let's say an agent is done with a support issue and marks the conversation as done without responding to a final "thank you" message from the customer that they were supporting. Three days later, that same customer replies to the same thread, which automatically reopens that conversation. Since the agent never replied to the last message, your SLA for Longest Unresponded to Message will be breached since a reply was never sent and the message is technically still unanswered.In this type of scenario, you want the new incoming message to be considered the first message in the conversation in order to avoid having a breach, since it wouldn't accurately represent the agent's response time to the issue. You have the option of enabling a reset feature that will help avoid scenarios such as the one described above. With this setting, any time a conversation is re-opened, the SLA timer is reset and all metrics will be accurately measured against the first inbound message received since the conversation was re-opened.Note: Resetting your SLAs will clear previous metric data, and any satisfied or breached events that are old or have been cleared will not be visible in reports. You can view cleared events in the conversation view and the Audit Log.To turn on the ability to reset your SLAs:Go to Settings> Workspace > Service Level Agreements.Select the Advanced tab.Turn on the Reset SLAs toggle.Now, when a conversation that was previously marked done is reopened, the timer for any SLA metrics that you have turned on will restart.SLA Alerts
Service Level Agreements (SLAs) are used to measure conversation metrics and ensure that you're providing consistent support to your customers. SLA alerts are a way for you to send in-app notifications to select users and/or teams to notify them of any conversations that are at risk of breaching their SLA policy metric(s). Once a user receives a notification, they can click on it to view a search with the at-risk conversations and re-prioritize their workload in order to satisfy the SLA policies This way you can be sure that your customers are getting the responses they need when they contact you. Who can access this feature?User typesAdmins can access SLA settings.In this articleSetting up your SLA alertsBest practices for setting up your alertsSetting up your SLA alertsOnce you create an SLA policy, you can create alerts that notify you of any metric within a policy that is close to breaching. Each policy can have up to 5 alerts. You must set at least one metric in a policy to create an SLA alert.Go to Settings> Workspace > Service Level Agreements.Create a new policy by selecting Add SLA or open an existing policy.Select Add SLA Alert and enter a name for the alert.Select the metric you want to create an alert for from the drop-down menu. You can only create alerts for metrics that have been defined in the policy. If you select Any Metric, you will be notified of the first metric in the policy that is close to breaching. Once the first metric is either breached or satisfied, you'll receive another alert if a different metric in the policy is about to breach.Note: You need to take an action on the conversation for the first metric that you were alerted to in order for you to get notified of any future breaches. For example, let's say your policy is set up with a First Response Time (FRT) of 10 minutes and a Total Conversation Open Time of 15 minutes and you're alerted to the fact that your FRT is about to breach, and then it actually does. You won't be alerted to the Total Conversation Open Time possibly breaching until you fulfill the first metric by sending an outbound message.Determine how often you want to check if the metric is about to breach. The minimum frequency that can be set is 5 minutes.Set how close the metric is to breaching. The minimum time allowed is 1 minute and the maximum is 7 days. Select at least one individual user or team that gets notified with the alert. You can select a total of up to 50 users and/or teams.Select Save Changes.Once a conversation is close to breaching, users will receive in-app notifications both via a toast notification and the Notificationsmenu.Best practices for setting up alertsWhen setting up your alerts, keep in mind that the goal is to catch any conversations that are at-risk of breaching while giving your team members enough time to take action on them. You should take your individual SLA time commitments into consideration when setting up alerts to ensure that you do not overwhelm your users with notifications. Below are basic guidelines that we recommend you follow when setting up your SLA alerts:The Check Every interval will typically be less than the Breach in the next interval to ensure that the entire time defined for breaching is covered.The Breach in the next interval will typically be higher than the time commitment you entered for your SLA metrics to ensure that all conversations that are close to breaching are caught. For example, if the SLA is set to 20 minutes, this value can be set to 30 minutes. You should try to structure the Breach in the next configuration of your SLA alerts so that your alert recipients have the time they need to take action.For example, let's say you create an SLA policy for VIP customers contacting you specifically via email and you set the First Response Time for 10 minutes to ensure that they receive quick replies. You can set the Check Every internal to 5 minutes and the Breach in the next interval to 15 minutes. Using these intervals, your agents are notified of an upcoming breach with enough time to take action and respond to the customer before the countdown expires. Please note that intervals will vary based on your specific needs and these are just examples. Earlier, we gave an example of how to set up an alert for a policy with a 10 minute breach time. Let's say you have an SLA that is set for 5 hours, you may want to set the Breach in the next interval to 1 hour instead to avoid getting notified multiple times.Best practices to manage breached SLAs
A service level agreement (SLA) is a set of internal conversation metrics to ensure your team provides consistent support to your customers. After you've created an SLA policy, your metrics will be shown in conversations for your agents to consider as they prioritize their conversation tasks.Managers and administrators can manage conversations SLA at a higher level while using searches, workflows, reporting, and SLA notifications. This article will discuss a variety of methods available in Kustomer to search, report on, and manage breaching SLAs.Who can access this feature?User typesAdmins and users with permissions to access to searches, workflows, reports, or SLA settings.In this articleUse SLA alertsCreate a search for breaching conversationsUpdate breached conversations with workflowsCapture breached conversations in reportingUse SLA alertsOnce you have created customized SLA alerts for an SLA policy, you will receive in-app notifications to selected users and/or teams of conversations at risk of breaching their SLA metrics. Clicking on the notifications takes you to a search of at-risk conversations so you can re-prioritize team workload. Learn more in SLA alerts.Create a search for breaching conversationsYou can also create searches for conversations breaching their SLAs. Use the Next Breach At search filter to view conversations that are breaching within a specific period of time. In the below example, the search finds snoozed conversations that will breach within the next 24 hours.You can also use the SLA is Breached filter to view conversations that have breached a policy for a specific period of time. Here's an example of breached conversations that were created at least 1 day ago.Update breached conversations with workflowsYou can use the Kustomer > SLA Breached trigger in workflows to carry out automations once a conversation has breached an SLA policy. In the following example, this workflow routes conversations to a higher priority queue when the SLA has breached.Capture breached conversations in reportingThe Standard SLA Report provides important data on conversations matching your SLA policies. In addition to the total count of conversations that match your SLA policies, you can see the percentage of conversations that have satisfied your metrics, a breakdown of conversation statuses across all available metrics, as well as your breached, satisfied or pending SLA conversations.In custom reporting, you can use any of the following date attributes under the Conversation object to create SLA-based custom reports:SLA Matched AtFirst Breach AtNext Breach AtSatisfied AtFirst Response SLA Breach AtFirst Response SLA Satisfied AtLongest Unresponded Message SLA Breach AtLongest Unresponded Message SLA Satisfied AtTotal Convo Open Time SLA Breach AtTotal Convo Open Time SLA Satisfied AtTotal Customer Wait Time SLA Breach AtTotal Customer Wait Time SLA Satisfied AtHere's an example of a custom report that shows conversations that have breached their Open Time SLA metric and segmented per queue.
Still need help? Contact Us