Defining OLA policies using internal SLAs and child ticket side conversations

Fastpath: Admin Center > Objects and rules > Business rules > Service level agreements

You can use SLAs and child ticket side conversations to create operational-level agreements (OLAs), internal to your company, between two groups of agents about how quickly one group responds to and resolves tickets from another group. For example, let’s say you want to create an OLA between your support team and shipping team that legal questions will be answered within 6 hours and solved within 48 hours.

Note: On Enterprise plans, you can also define group SLAs to create OLA policies. See Defining group SLA policies for internal teams.

This article contains the following sections:

• Creating OLAs with child ticket side conversations
• Metrics activated by OLAs for child ticket side conversations

Related articles:

• About SLA policies and how they work
• Understanding ticket reply time
• About side conversation child tickets

Creating OLAs with child ticket side conversations

While SLAs are intended to be a policy between the company and the customers, companies with complex workflows that involve multiple teams in the solving of tickets need SLA-like functionality to create and enforce agreements between them. These agreements between teams are commonly referred to as operational level agreements, or OLAs. OLAs make it possible to more easily enforce an agreement between two internal teams.

Child tickets are created with a new “side conversation” channel type, which provides a condition that SLAs can use to ensure that the policy is only applied to internal tickets created from a parent ticket. This condition, in addition to a group condition, makes it possible to create workflows where one team creates tickets assigned to another team with agreed upon response times, wait times, update times, etc.

To create an OLA with child ticket side conversations

1. Enable child ticket side conversations.
2. Create or update an SLA policy to include these conditions:

   • (Optional) Group + Is + (specify a group) If the SLA policy doesn’t include a group condition, it’s not really an OLA since an OLA is an agreement between two groups. Without it, all agents in your Support account are equally responsible for fulfilling the agreement.

   • Channel + Is + Side conversation

     

3. (Optional) Include the term OLA in the SLA policy’s name, so that it’s easier to identify your OLAs at a glance.

   

When a child ticket side conversation is created that meets the conditions in an SLA policy, the SLA policy is applied to the ticket. The ticket interface tells the assigned agent what stage the SLA policy is in and how much time they have left to fulfill the agreement.

For information creating a view so you more easily find tickets with your OLA, see Seeing SLA statuses in views.

Metrics activated by OLAs for child ticket side conversations

When a child ticket side conversation is created or updated via a public comment, and an SLA policy is applied to it, the First reply time metric is activated, but only if the creator and requester of the child ticket are the same agent.

After First reply time is fulfilled and the requester adds a new public comment to the child ticket, the Next reply time metric is activated. First reply time and Next reply time are fulfilled when an agent who isn’t the requester adds a public comment to the child ticket, or the ticket is submitted as Solved (see Understanding how SLA policies are applied to tickets).

It’s also important to note that marking the side conversation as Done in the parent ticket doesn’t fulfill First time reply and Next time reply metrics when an SLA is applied to a child ticket. This is because the SLA is applied to the child ticket, not the parent ticket. For more information about the inheritance pattern between parent and child ticket side conversations, see About side conversation child tickets.

Note: When using SLAs with child ticket side conversations, we strongly recommend that you train your agents to not change the requester on child tickets. In some situations, doing so can result in differences in metric activation and fulfillment that agents may find confusing.