In my previous blog post, Part 1, I provided an overview of the Service Entitlements front end—how milestones are used on Service Requests (SRs) to monitor SLA compliance. In this post, we will go behind the scenes and look at how the Oracle CX Service Cloud Entitlements architecture functions and can be leveraged to support your SLA business requirements.
Service Entitlements Architecture
Let’s start off by introducing the key components of the Service Entitlements architecture and then we’ll drill-down on each area in more detail. I’ve created the diagram below to summarize the key components and how they connect to ultimately assign specific milestones to SRs.
The heart of the entitlements architecture is the standard coverage template with the entitlement rules table. A rule is built with conditions, a calendar schedule selection, milestone thresholds, and effectivity dates.
The matrix class configuration is what determines which condition columns and milestone result columns display in the entitlement rules table. Matrix classes can be configured by administrators to define new condition and result columns (milestone types) if needed.
Once standard coverage templates are created, they are used to define the default coverages. If Subscription Management is implemented, then subscription coverages for customer products and assets can also be defined. These coverages function as rules that determine which coverage template is used to apply entitlement milestones to an SR based on product, customer, or the global default.
Once specific milestones are applied to an SR, the monitoring process checks for threshold violations throughout the SR lifecycle.
Now let’s take a more detailed look at each service entitlement component.
Milestones and Matrix Classes
Milestones have properties that can be configured to determine the start, pause, and complete conditions. For example, the First Response metric is predefined to complete when a user sends a response to the customer. We can add a condition that also requires the SR status be “In Progress” or “Waiting on Customer” before the first response milestone is complete. Milestones can also be configured to allow agents to manually complete and override the milestone due date on the SR.
If your implementation will leverage multiple business units (BUs), then milestones will need to be configured for each business unit used by CX Service Cloud. These milestones can have the same properties across all BUs or be altered to meet unique requirements for each.
If the seeded First Response and Resolution milestones cannot be configured to meet all your SLA requirements, we can define entirely new milestone types. For example, a Service Restored milestone can be created to track the time the customer’s system is down. Getting the system back online is often on a tighter SLA and may be completed before the SR is ultimately resolved.
Defining new milestone types is somewhat involved and beyond the scope of this article. But ultimately a new milestone type will add result columns to the matrix class that is used on the coverage template entitlements table.
Matrix classes are also used to define new condition columns for coverage template entitlement rules. Again, the details are beyond the scope of this article, but know that if you need to assign different entitlements based on SR attributes other than Severity and Channel, Oracle can be configured to handle it.
Schedules: Define Service Working Hours
Oracle is preconfigured to track milestones on a 24 by 7 basis. But if your support center closes at 6 PM, you probably don’t want milestones expiring in the middle of the night. Fortunately, Service Cloud can be configured to track time only during specified hours by setting up schedules. Schedules are configured in the Subscription Management Availability page.
A schedule is typically configured with standard support center availability hours as the baseline date intervals and then exceptions that override normal availability for holidays. But you can also define exceptions for working hours or days; for instance, if your support team works weekends during peak seasons.
If your organization has multiple support centers with different hours and in different time zones you can define a schedule for each center. You can also define schedules for special entitlements such as providing extended hours for customers who have purchased a premium support contract.
Standard Coverage Templates and Entitlements
Once milestones and schedules are configured, it’s time to define the standard coverage templates and entitlements. Standard coverage templates are the heart of service entitlements. Templates consist of a header and the entitlement rules table. The header defines the entitlement type (always “Subscription Entitlements” for standard SRs), template name, and effectivity dates. The bulk of the action is in the entitlement rules.
An entitlement rule consists of conditions, schedule (Calendar column), milestone thresholds, and effectivity dates. While a coverage template can have any number of rules, they need to be defined so that only one rule would qualify for a given service request. Let’s walk-through the example below, to see how entitlement rules function, assuming this coverage template is the global default.
I’ve configured this coverage template to use just one condition: SR Severity. When a medium severity SR is created, Oracle will match the first entitlement row and assign a first response milestone of 120 minutes and a resolution milestone of 480 minutes. If the next SR has as a high severity, Oracle will assign 60-minute first response and 240-minute resolution milestones. Both cases will use the US Service Hours schedule to track time elapsed on the milestones.
Recall that the matrix class configuration determines which condition and result columns are available within the rules table. While the above example uses only severity as the condition, I could have included the channel condition or any other condition column defined for the matrix class. These conditions needn’t be the same across coverage templates—we could use severity for one coverage template and channel plus severity on the next template. The same degree of flexibility applies to the result column milestone thresholds.
The calendar is another important attribute of entitlement rules. This is where we assign a schedule created in the previous configuration step to specific entitlement rules. The calendar controls how time is tracked on the milestones. Let’s expand our example and create a new standard coverage for VIP Customers who qualify for extended support hours.
You’ll notice that the conditions and thresholds are the same, but the calendar is using the Extended Service schedule. This coverage template will assign the same first response and resolution milestones to SRs as the first coverage template, but the milestone timing will use extended service hours (nights and Saturdays).
How does Oracle know which coverage template to use? That’s the purpose of our next topic.
Default Coverages and Subscriptions: Selecting the Coverage Template
When an SR is created, CX Service Cloud evaluates available coverages to determine which set of entitlement rules to use.
First, if Subscription Management is implemented and the SR is tied to a covered customer asset, Oracle will select from that set of entitlement rules. Next, Oracle will check for a matching customer default coverage. Finally, Oracle will use the global default coverage.
Continuing with our example, we can define a global default coverage to use the standard support SLA coverage template and define customer defaults only to customers who should get the VIP extended hours coverage.
This template and default coverage configuration will ensure only select customers have SLAs calculated based on extended service hours while everyone else is based on normal support hours.
Monitoring and Notifications
B2B Service requires the Monitor Service Request Milestones job to be scheduled to run frequently. This process checks SR milestones to determine if warning and compliance threshold violations. When a threshold is reached, the process will update status flags and send any notifications.
Email notifications are defined using the email template and object workflow tools in CX Cloud’s Application Composer. The object workflow tool is very flexible, providing robust condition logic and the ability to perform additional actions such as updating SR fields or running scripts. The milestone email template is a bit limited in the fields that can be added to the email. Fortunately, we can define custom formula fields for the milestone object to workaround these limitations when needed.
This wraps up my two-part post on how Oracle CX Service Cloud provides SLA support through service entitlements. If your business has very simple SLA requirements, the service entitlement architecture may seem overly complex. But know that configuring entitlements can be as simple as defining a single entitlement rule on a standard coverage template that is mapped as the global default. On the other hand, if your company has service centers around the globe that support multiple product lines with different coverages and customer-negotiated SLAs, Service Cloud’s architecture can accommodate your needs.