Rule sets for service level agreements

This topic provides examples of the types of rule sets that you can create for service levels agreements.

If service level agreement rules are not configured properly (for example, if you include an invalid work schedule name in a service level agreement rule), your support agents will receive an error while creating service requests. When you edit service level agreement rules, the First Response By and Resolution By metrics for existing service requests do not get updated automatically. If necessary, users with the ServiceRequestSLAOverride privilege can edit these metrics using the Edit Service Request dialog in NexJ CRM.

This topic assumes you have a basic understanding of Scheme expressions and have access to your business model.

First Response By rule set example

The following example describes a rule set that determines when first responses are due for service requests based on severity levels and, where applicable, the contact's tier.

In this example, the rule set is named SetServiceRequestFirstResponseBy and the rules are named as follows:

• Urgent severity - set First Response By based on client tier
• High severity - set First Response By to 8 hours
• Default - set First Response By to 2 days

This example uses the following fields:

Condition
When the severity level for a service request is the same as the severity level specified in the Condition field of a rule, the rule action is triggered and the appropriate First Response By date and time displays for the service request.

If a service request meets the condition associated with multiple rules in the rule set, the rule that applies the closest First Response By date and time prevails. If a rule does not have a condition, the rule action applies to all service requests regardless of the severity level.

The first two rules in this rule set require a condition because they consider severity. The third rule does not require a condition because this rule applies to all service requests. The condition for the first two rules uses the following Scheme code to retrieve service requests with the specified severity level:

(= (@ severity) (ServiceRequestSeverityEnum'get '<severityLevel>))

where severityLevel is URGENT for the first rule and HIGH for the second rule.

The severityLevel must be provided in upper-case letters.

Actions
When a service request meets the condition of a rule, NexJ CRM calculates the date and time when a first response is due for the request.

In this example, for service requests with urgent severity, the First Response By date and time varies for each tier and is also different for contacts with no tier specified. The action for this rule uses the following Scheme code to determine the First Response By date and time for service requests.

(this'firstResponseDueTime
   (cond
      ((= (@ primaryEntity tier) (ClientTierEnum'get '<tier>))
         (sla:date-add-business-hours "<workScheduleName>" (@ openTime) <numberOfHours>)
      )
      (else
         (sla:date-add-business-hours "<workScheduleName>" (@ openTime) <numberOfHours>)
      )
   )
)

where:

• firstResponseDueTime is an attribute that specifies the date by which a first response must be sent for the service request.

• tier is a string that represents the property assigned to a contact that determines the kind of service plan they receive.

  

  tier must be provided in upper-case letters. For example, TIERA.

• workScheduleName is a string that represents the name of the work schedule that specifies the business hours to be used for the rule. Work schedules are specified in the Work Schedules page in NexJ Admin Console.
• openTime is an attribute that specifies the date when the service request was created.
• numberOfHours can be any integer you provide. In this example, the line of code containing the first instance of numberOfHours is repeated three times with the values set to 2, 4, and 6 for tiers A, B, and C respectively. The last instance of numberOfHours, which applies to all other clients, is set to 8.
• sla:date-add-business-hours is a function that adds numberOfHours to openTime while taking into account the business hours specified in workScheduleName to calculate the date and time result.

The date and time result displays in the First Response By field for the service request.

For service requests where the severity level is not urgent, the tier is not taken into account. Therefore, the action for the rules High severity - set First Response By to 8 hours and Default - set First Response By to 2 days does not include the tier.

The action for the High severity - set First Response By to 8 hours rule uses the following Scheme code:

this'firstResponseDueTime (sla:date-add-business-hours "<workScheduleName>" (@ openTime) <numberOfHours>)) 

where numberOfHours is set to 8.


The action for the Default - set First Response By to 2 days rule uses the following Scheme code:

this'firstResponseDueTime (sla:date-add-business-days "<workScheduleName>" (@ openTime) <numberOfDays>))

where

• numberOfDays can be any integer you provide. In this example, numberOfDays is set to 2.
• sla:date-add-business-days is a function that adds numberOfDays to openTime while taking into account the business days specified in workScheduleName to calculate the date and time result.

Resolution By rule set example

The following example describes a rule set for a service level agreement that determines when a resolution is due for service requests based on severity levels and, where applicable, the contact's tier.

For this example, the rule set is named SetServiceRequestResolutionBy and the rules are named as follows:

• Urgent severity - set Resolution By based on client tier
• High severity - set Resolution By to 7 days
• Medium severity - set Resolution By to 10 days
• Default - set Resolution By to 15 days

This example uses the following fields:

Condition
When the severity level for a service request is the same as the severity level specified in the Condition field of a rule, the rule action is triggered and the appropriate Resolution By date and time displays for the service request.

If a service request meets the condition associated with multiple rules in the rule set, the rule that applies the closest Resolution By date and time prevails. If a rule does not have a condition, the rule action applies to all service requests regardless of the severity level.

The first three rules in this rule set require a condition because they consider severity. The fourth rule does not require a condition because this rule applies to all service requests. The condition for the first three rules uses the following Scheme code to retrieve service requests with the specified severity level:

(= (@ severity) (ServiceRequestSeverityEnum'get '<severityLevel>))

where severityLevel is URGENT for the first rule, HIGH for the second rule, and MEDIUM for the third rule.

The severityLevel must be provided in upper-case letters.

Actions
When a service request meets the condition of a rule, NexJ CRM calculates the date and time when a resolution is due for the request.

In this example, for service requests with urgent severity, the Resolution By date and time is different for service requests from tier A contacts compared to service requests from all other contacts. The action for this rule uses the following Scheme code to determine the Resolution By date and time for service requests:

(this'dueTime
   (if (= (@ primaryEntity tier) (ClientTierEnum'get 'TIERA))
      (sla:date-add-business-days "<workScheduleName>" (@ openTime) <numberOfDays>)
      (sla:date-add-business-days "<workScheduleName>" (@ openTime) <numberOfDays>)
   )
)

where

• dueTime is an attribute that specifies the date by which the service request must be closed.
• workScheduleName is a string that represents the name of the work schedule that specifies the business hours to be used for the rule. Work schedules are specified in the Work Schedules page in NexJ Admin Console.
• openTime is an attribute that specifies the date when the service request was created.
• numberOfDays can be any integer you provide. The first instance of numberOfDays in this example applies to tier A contacts and the second instance to all other contacts.
• sla:date-add-business-days is a function that adds numberOfDays to openTime while taking into account the business days specified in workScheduleName to calculate the date and time result.The date and time result displays in the Resolution By field for the service request.

If the date and time result falls outside of business hours, for service requests created before business hours on a business day, the due time is set to the end of the previous business day. For service requests created after business hours or on holidays, the due time is set to the start of the next business day.

If you enable the SLA End of Day feature on the Global Application Settings page in NexJ Admin Console, the system only uses the request creation date to calculate the date and time result and ignores the request creation time. The number of hours specified is added to the openTime and the due time is set to the end of the business day.

For service requests where the severity level is not urgent, the tier is not taken into account. Therefore, the action for the rules High severity - set Resolution By to 7 days, Medium severity - set Resolution By to 10 days and Default - set Resolution By to 15 days does not include the tier. The action for these rules uses the following Scheme code:

(this'dueTime (sla:date-add-business-days "<workScheduleName>" (@ openTime) <numberOfDays>))

Related tasks

Adding and deleting rule sets