Introduction

A Service Level Agreement (SLA) is a formal contract that defines a server provider's performance obligations to a customer. For example, customers who pay for priority support through email are generally guaranteed a response within a certain timeframe, such as "within 2 hours" or "before the close of the next business day".

With Cerb5, you can configure Virtual Attendant behavior to enforce your SLA commitments.

NOTE: This functionality requires Cerb5 version 5.5 or later.

Defining Service Levels on organization records

The first step is to grant service levels to the appropriate contacts. You have plenty of leeway using Cerb5 to model this according to your particular business practices.

Our usual recommendation is to create a picklist custom field on organization records called "Service Level". Even if you only have a single service level like "Priority Support" this will give you room for future expansion compared to using a checkbox. We recommend that you add this field to organization records so it covers all the contacts that you assign to the organization, which saves you the hassle of assigning service levels to each individual contact. However, if you limit the number of authorized contacts then everything in this article is still applicable if you put the custom field on individual address records.

For simplicity our examples will use the organization-based approach.

Creating the Service Level custom field

1. Click Setup in the top right of the navigation menu.
2. Select Settings->Custom Fields from the Setup menu.
3. Select the Organization record type.
4. Create a new picklist called "Service Level" and add "Priority Support" as a field option.
   
5. Click the Save Changes button.

Automating the process with Virtual Attendants

Now that we have a custom field for granting priority support to specific organizations, we need to instruct our group Virtual Attendant to give their messages special consideration.

Creating the SLA Escalation custom behavior

We're going to enforce our SLA by attaching custom behavior to a ticket when one of our priority contacts writes in. This behavior will make a decision based on whether or not our workers have provided a response within the desired timeframe. For the purpose of this example we're going to enforce 2 hour response times.

Let's create the custom behavior.

1. Click Groups in the top right of the navigation menu.
2. Choose the group you want to enforce an SLA for. In this example we'll be using a group called Support.
3. Select the Virtual Attendant tab.
4. Click the Create Behavior button and enter the following details:
   
5. Click the Save Changes button.

You should now see a brand new decision tree on the Custom ticket behavior event. This is where we define decisions, outcomes, and actions to instruct the Virtual Attendant how to perform our desired behavior. It's called a decision tree because each decision can have various outcomes, and each of those can have various actions. An outcome can also have start the whole process over with a new decision that continues branching. A decision tree is built using simple building blocks, but the behavior you can create can be very complex depending on your needs. Each of the clickable bubbles in the decision tree is referred to as a node.

Our objective is to have a place where we can react accordingly if the current ticket has not had a worker reply within the past 2 hours. We will verify that a message was sent by an SLA-covered organization later. Let's create the new behavior.

1. Click on the event node and select Add Decision from the menu.
   
2. Title the new decision: "Has a worker replied within 2 hours?" and click the Save Changes button.
3. Now click on the decision node and select Add Outcome from the menu. Enter the following details and click the Save Changes button. This will give us an outcome where a ticket is open and is lacking a worker reply for the past 2 hours. Note that we're filtering out the waiting for reply status because if we are waiting on the customer then the clock is not running.
   

At this point you could do a number of things on a ticket where a paying customer is anxiously waiting for an answer and a worker has not replied recently:

• If there are watchers, notify them.
• If there aren't watchers, notify the group manager(s) or a designated dispatcher.
• Force assign the issue to someone.
• Send a series of SMS text messages, email messages, post to a Campfire support team chat room, etc. With plugins there is really no limit to the kinds of things you can instruct Virtual Attendants to do.

For the sake of a simple demonstration, we're going to have our Virtual Attendant check if the ticket has watchers or not and react appropriately in either situation. If there are watchers we're going to send them a notification. If there aren't watchers we're going to notify the group managers.

In our official helpdesk environment at WebGroup Media, our team is always connected to a Campfire group chat room. We use the Cerb5 Campfire Integration plugin to send automated status updates from our Virtual Attendants to chat where we can quickly decide in real-time who will take care of any issues. For us, this is the ideal place to send notifications about SLA obligations. We'll assume that you don't do that (perhaps you should), and instead we'll just send a simple notification to a specific worker that we'll assume is our group's manager or dispatcher. If your team stays in touch in a different way (e.g. IRC chat, Skype, scrolling LED marquee on the office wall, office loudspeaker with text-to-speech orders droned out 1984-style) then consider hiring us to build a Virtual Attendant plugin for integration with your existing infrastructure.

Let's continue our decision tree.

1. Click on the new outcome node and select Add Decision from the menu. Title the decision "Are there watchers?" and click the Save Changes button.
2. Click on the new decision node and select Add Outcome from the menu. Enter the following details and then click the Save Changes button.
   
3. Click on the new outcome node and select Add Actions from the menu. Enter the following details and then click the Save Changes button.
   
4. Now we also want to react if there aren't watchers. Click on the "Are there watchers?" decision node and select Add Outcome from the menu. Title the outcome "No" and click the Save Changes button. We don't need to provide any conditions because if the "Yes" condition doesn't match then we can safely assume "No" is the correct outcome.
5. Click on the new "No" outcome node and select Add Actions from the menu. Enter the following details and then click the Save Changes button. Notice that we are notifying specific workers (our managers or dispatchers) instead of the non-existent watchers.
   

Understanding behavior loops

At this point, when our new behavior runs it will notify either the watchers or the group managers if an open ticket from a priority customer has not been replied to within the agreed-upon timeframe. After that, though, it won't provide any subsequent notifications if nobody does anything and the conversation continues to rot. That's where behavior loops come to the rescue. Custom behavior is capable of scheduling other behavior, including itself, to run in the future when certain conditions are met. In our case, we want the SLA Escalation behavior to continue to notify us every hour while a ticket remains overdue -- in other words, we want it to schedule itself to run again.

The proper place to schedule the behavior loop is after the first decision ("Has a worker replied within 2 hours?") because we want the behavior to loop whether or not there are watchers. This saves us from having to schedule future behavior individually for each subsequent outcome.

1. Click on the first "No" outcome node and select "Add Action" from the menu. Enter the following details and click the Save Changes button.
   
2. We want our behavior to be rescheduled as the first thing that happens on the "No" outcome, so click the new "Reschedule SLA Escalation" action node and drag it to the first "No" outcome.
   

This reschedules our behavior to run again in one hour. The "If duplicate behavior is scheduled:" option instructs the Virtual Attendant on what to do in the event we ever end up with multiple SLA Escalation behaviors on a single ticket conversation.

We're selecting the "Only schedule earliest occurrence" option because if there is already an SLA reminder scheduled for 5 minutes from now, we want it to run it then instead of resetting it to an hour from now. For example, if a customer is waiting on our response and an SLA response is due in 10 minutes, a customer may happen to write in with the message "Hello? Is anybody home?". If we reset the SLA timer to an hour in the future due to their activity then it would take another hour before our custom behavior attempted to get the attention of the watchers or managers. When a customer is waiting on us, we always want to respect the SLA timer with the least amount of time left on it. That means if a customer writes in several times in rapid succession, we are not attaching new SLA behavior to the conversation if it already exists. Once the original behavior runs, it will reschedule itself for an hour in the future anyway. We've found this to be a very elegant solution to the potential problem of "stacking" the same behavior on a particular record too many times.

Scheduling custom behavior for new messages

If you're particularly astute, you may be wondering how our custom behavior is added to conversations in the first place.

Now that we have our custom SLA Escalation behavior that tries to get our attention when we're not responding to customers fast enough, and it's capable of rescheduling itself until our SLA commitments are met, we need to schedule it when someone writes in who has an SLA.

You should still be on the group's Virtual Attendant tab. If not, navigate back there.

1. Click the Create Behavior button. Enter the following details and then click the Save Changes button.
   
2. Click on the new event node and select Add Decision from the menu. Title it "Is it an incoming message with an SLA?" and click the Save Changes button.
3. Click on the new decision node and select Add Outcome from the menu. Enter the following details and then click the Save Changes button.
   
4. Click on the new "Yes" outcome node and select Add Actions from the menu. Enter the following details and then click Save Changes.
   

Our custom SLA Escalation behavior will now be scheduled 2 hours in the future on a ticket conversation every time a customer writes in who has a priority SLA. If the customer writes in multiple times before a worker replies, the SLA Escalation behavior with the shortest timer remaining is used and the others are discarded. If a worker doesn't reply within 2 hours then our behavior will send out notifications and reschedule itself every hour until the customer receives a response or the ticket is closed.

Assign a priority service level to some organizations

You probably want to assign a service level to a couple organizations to take advantage of this SLA Escalation behavior.

• If you have a few V.I.P. customers that you want to pay extremely close attention to, ensuring they have the best customer support experience, then this is a great way to do it.
• If you offer corporate support for a fee in exchange for guaranteed response times, this approach should be flexible enough to accomodate your needs.
• Or perhaps you may want to do this for every customer contact, because that's just the kind of customer-focused company that you are. Kudos! We hope it helps you remain accountable to that commitment.

If you need any help, just ask.

We recognize how important SLA functionality is, and that's why we didn't want to provide it as an inflexible, presumptive feature that forces you into changing how you do everything. This may seem a little complicated to you the first few times you set up new Virtual Attendant behavior, but as you become comfortable with it you'll likely realize countless uses for it. These skills are widely reusable for configuring business automation and workflow in Cerb5.

Feel free to contact us if you need help fine-tuning your Virtual Attendant behavior. We're available for hire to build custom integration, as well as to provide training or consulting on moving more of your online processes to the Cerb5/Devblocks platform.

Where to go from here

Business hours

You could modify your Virtual Attendant to schedule behavior based on business hours. For example, if it's currently a weekend then it could be scheduled for "Monday 8am". If it's currently after-hours on a weekday it could be scheduled for 8am the next day. It's a safe bet that we'll be adding new conditions to make calendar and work hour based processes even easier.

Additional service levels

If you have several tiers of service level agreements you could create a behavior for each one "SLA Platinum Escalation", or you could add another decision with a series of outcomes to the decision tree that would set target response times accordingly.

True escalation

Currently we're checking to see if an open conversation from a priority contact has the last worker contact more than 2 hours ago. You could gradually escalate to more aggressive forms of attention-grabbing reminders after 2 hours, 4 hours, and 8 hours. This could be accomplished by scheduling a different custom behavior if the worker reply is extremely late. An ideal place to do that is at the top of a decision tree by scheduling a new behavior to occur "now" and then abandoning the current behavior.

That's easy to do if you nest decisions from the oldest period first. For example:

• Is 8 hours late?
  • Yes
  • No
    • Is 4 hours late?
      • Yes
      • No
        • Is 2 hours late?
          • ...