What are the best practices when setting up incident rules?

Environment:

Business (Workflow/Escalation) Rules in your Oracle B2C Service application

Resolution:

Incident rulesets can become quite intricate and complex. However, the best practices listed below will help you set up a solid foundation for your ruleset that allows you to both organize your rules and take advantage of useful actions that can be accomplished using rules.

General Rule Setup and Structure

Some best practices are focused on the overall setup of the rulebase and how it is structured:

1. Plot and draw out your workflow process on paper before building rules. This allows you to not only understand your routing and handling process, but also identifies inefficiencies in your current process. 
    
2. Have queues, staff accounts, custom fields and profiles in place and functioning before building rules. Incident rules are commonly used to route incidents or set fields. Make sure the necessary items exist in your application before you try to create your rules. 
    
3. Create at least two rule states. One rule state must be set as the Initial state. The initial rule state contains the rules for initial routing of new incidents created in the application. You should have at least one non-initial state that is used for acting on and handling updates to existing incidents. 
    
4. Transition all incidents from the initial state. Make sure the rules in your initial rule state include adequate actions to transition incidents to another state after the initial action or actions have been performed, such as assigning the incident to a specific person or to a queue. 
    
   Each incident should only hit the rules in the initial state once and then be transitioned to another state. If an incident remains in the initial state, the next time it is updated, it will hit the same rules and get routed again as though it were a new incident. This causes a looping effect and agents may not be able to reassign incidents to another person or group. 
    
5. Include the most important and specific rules toward the top of the list. Frequently, an incident is able to match several rules that are set up. Order your rules so that the most restrictive and most important rules and actions are listed at the top of the rule list. This ensures that those rules act upon the incidents correctly.
   
   Then, make sure the rule either transitions the incident to another state or make sure that follow on rules will not act on the incident unexpectedly and "overwrite" the initial action. For example, if incidents from a specific company are supposed to be routed to a certain agent, include that rule towards the top of the list and then make sure that incident will not be acted on and reassigned based on rules further down in the list. 
    
6. Include a catch-all rule. Create a catch-all incident rule at the bottom of the rules listed in the initial state so that no new incident goes unassigned and unresolved and gets lost in the system. Typically, this rule will read:
   
   IF Incident.Status Type = Unresolved
   THEN Assign incident (to queue or staff member) AND
   Transition state to (existing state). 
    
7. Include a catch-all escalation action. As the rules are transitioned to a non-initial state, have your incidents match a general escalation-chain rule so that an escalation is triggered so that someone in your organization is notified if an unresolved incident is not updated for an extended period of time. This draws attention to older incidents that need to be handled and resolved. 
    
8. Determine whether functions should be used. You do not have to use functions within your rulebase. Functions are designed to group sets of rules that you need to apply several times throughout the life of the incident. That way, you don’t have to recreate the same set of rules many times in your rulebase. If you find that you do need to run the same set of rules several times (such as with escalation rules), place those rules in a function and then call that function from a specific rule. 
    
9. Use the Notes field to describe each rule. When adding or editing a rule, include a brief description of the rule in the Notes field. Include the date that it was added and by whom so that other administrators at a later time can better understand the purpose of the rule within the overall setup. When you hover over a rule in the left frame, the Notes field displays as a pop-up so that you can easily review the purpose of the rule.

Set up and Order Escalation Actions

1. Include two rules for each escalation. When configuring escalations, two rules are used for each escalation action. You must use a Chain Rule (which sets the timeframe and conditions for escalating an incident) and an Action Rule (which specifies the actions to execute when the escalation occurs, such as sending an email to a manager). For more information on escalation rules, refer to Answer ID 2181: Setting up Escalation Rules. 
    
2. List Action rules before Chain rules. With the pair of escalation rules, place the Action rule above the Chain rule. If you have several pairs of escalation rules, list the group of Action rules first, followed by the group of Chain rules. That way, incidents that have already matched a chain rule from a previous update will match the Action rule and then have the opportunity to match a different escalation criteria. 
    
3. Create an Escalation function. Even if you have just a couple pairs of escalation rules, consider placing them in a function so that all escalation rules are grouped together. Then call the escalation function from a rule. This allows you to easily review your overall escalation process and verify the pairs of rules that are configured.

Utilize Specific Actions

The Add Action menu in the THEN section of a rule includes several options that can reduce the number of incidents from being submitted or automatically provide information for specific types of incidents. Understanding these options can help you automate processes even more.

1. Suggest answers to users when they submit their incident. Use the SmartAssistant suggested solutions feature to automatically suggest answers from your knowledge base when an end-user submits a question. Before the incident is created, users will see a list of answers and then have the option to continue submitting their question. For more information as to how to configure this, refer to Answer ID 453: Automatically suggesting solutions for Ask a Question requests. 
    
2. Restrict SmartAssistant solutions by product or category value. The SA_SUGGEST_LIMIT_PROD_LVL and SA_SUGGEST_CAT_LVL configuration settings allow you to configure the application to restrict suggested solution by the product or category value of the incident being submitted. Setting the Product level to a value of 1 restricts the SmartAssistant solution to the same product value. If products are not used on the end-user pages, you can set the Category level to 1 to restrict solutions by the category value.
   
   Note: In general, we do not recommend setting either of these values to a value greater than 1 unless you have a very large set of published answers (over 1000 answers, for example) AND if you have determined that your end-users are very good at selecting the sub-product or sub-category values when they submit an incident.
   
   In addition, if you have both products and categories enabled, it is best to only restrict suggested solutions by the product unless your end-users are very good at selecting the correct product AND category when they submit their request. Frequently, end-users will do a good job selecting one value, but may not be as good at selecting the other field. 
    
3. Append an existing Answer ID to specific requests. Determine the types of incidents where specific answer IDs should be recommended to your users. Create a rule that uses the action Append Thread > Append Existing Solution by Answer ID to Response Field to display the specific answer to these incoming incidents. This helps to resolve the issue BEFORE the incident is created. 
    
4. Append a specific response to requests. As appropriate, determine the type of incidents where a standard text response can be automatically displayed with the incoming request. Then, create a rule that includes the action Append Thread > Append Response Template to Response Field. This allows you to display standard text responses to the end user to help resolve their issue BEFORE the incident is created.
   
   In these cases, if the incident came in, the agent would be using the standard text anyway to send back to the end user immediately. Setting up an incident rule to automatically display the text response involves no human intervention, yet gives the end-user the same information they would have received from an agent. This cuts down agent work time, and handles redundant questions automatically. 

5. Automatic response actions should be limited by rule design.  Although automatic responses can reduce agent input, unlimited automatic responses can cause customer frustration and in extreme cases impact performance.  An unmetered automatic response in any rule state should be avoided.  Only one automatic response should be sent in any business process flow. An example business process could be a confirmation response to a customer email.  If a customer sends three seperate emails only one response confirming the communication should be sent.

   Before sending any automatic response a check should be made to see if a response has been sent.  A check requires a stored value in a custom field, custom object, or a seperate rule state in sequence with the current state. 

   Flow with a custom field or attribute: 
   If not ClosedResponseSent then send response, set ClosedResponseSent.

   Flow with a rule state: 
   Transition to Send Response state, send response, transition to Closed state, stop processing.

6. Use Matches Regular Expression as IF criteria. To identify specific types of redundant incidents, use the IF condition: Incident.Customer Thread matches regular expression. Then use the pipe ( | ) to specify words or phrases within the incoming incident that should trigger the rule. For more information on regular expressions, refer to Answer ID 486: Regular expressions and how they apply to rules or search on "regular expression" in the Oracle B2C Service knowledge base. In the THEN part of the rule, you can append a specific answer ID or a standard response.

And finally:  After you finish writing your rules, review them to make sure that you haven't left any loopholes. Try to make sure that every scenario is covered. Create a few test records and use the rule log to make sure that all the rules fired correctly.

For additional information, refer to the 'Best practices: Planning business rules' section in the Online Help User Guide documentation. To access Oracle B2C Service manuals and documentation online, refer to the Documentation for Oracle B2C Service Products.