Rules for Routing Customer Support Questions

One of the more common uses of business rules is to route incidents to the most appropriate staff member, group, or queue based on the criteria you define.

These conditions can be related to the incident itself or to a field in the contact or organization record associated with the incident.

It might make sense to route certain types of incidents to a specific staff member. But the rules engine cannot determine which staff members are logged in, so you risk having the incident assigned to a staff member who is not at work when the incident is routed. To ensure a timely response for your customers, a better practice is to assign incidents to queues from which all logged-in agents can pull.

In the following examples, each rule has two actions: to route the incidents that match the criteria to the queue for Team A, and then to move the incidents to a different state called “To be Processed.” (Best practice recommends you move incidents out of the initial state after the rules engine has routed them so the rules engine does not continue to process an incident using the rules of the initial state whenever it is updated.) In reality, you might have additional actions in any given rule. For example, after assigning an incident to a queue, you might want to append SmartAssistant-suggested answers to the incident before you transition it to a different rule state.

• Example of Routing Incidents by Source
• Example of Routing Incidents by Products or Categories
• Example of Routing Incidents by Time Created
• Other Incident Routing Conditions
• Example of Building on Basic Incident Routing Rules
• How the Else Clause Can Simplify Business Rules