According to Wikipedia, skill-based routing (SBR) is a call-assignment strategy used in call centers to assign incoming calls to the most suitable agent, instead of simply choosing the next available agent. However, many types of systems have aspects where skill-based routing should be considered – retail, quick service restaurant, and even manufacturing and maintenance systems can utilize the technique. Skill-based routing occurs anytime an entity needs to be directed to a resource with the most applicable skill sets or capabilities. In this fashion, entities can be processed by resources that can provide better service or faster completion of the task.
The use of Sets is a key factor in the design of a skill-based routing system. By defining your resources as members of a Set and in the preferential order in which you want them selected, you can implement skill-based routing logic.
As a simple example, let’s say your system has a single entity type. Three different resources can service the entity, but we prefer that entities be serviced by Resource 1, then Resource 2, and lastly Resource 3, when a choice must be made between available resources. By placing these resources into a Set in the order in which we prefer to use them, and then seizing a member of the set using the Preferred Order selection rule, we will always use the resource in the first row of the set first (Resource 1), then the resource in the second row (Resource 2), and then the resource in the last row of the set (Resource 3). There are two caveats to this though: the resource must be available (i.e., scheduled and not busy) and there must be a choice to be made (i.e., more than one resource available). Obviously, if the resource is scheduled away on break or processing another entity, it is not available for selection. Likewise, if only one resource in the set is available, it is the resource selected to serve the entity and there is no choice to be made since it is the only resource available.
We can now introduce a skills factor into the problem by defining our processing time as dependent upon the resource seized. When delaying for processing, we can use an arrayed variable or expression to hold the processing time for each resource. In this example, the processing times will be held in an expression e Processing Times with 3 rows. Ordering the information is important at this step. Define your arrayed variable or expression so the first row holds the processing time for Resource 1, the second row holds the processing time for Resource 2, and the third row holds the processing time for Resource 3. Note that this is the same order in which the resources were defined in the Resource Set.
When seizing a resource from the set using the Preferred Order selection rule, also define an attribute to hold the set position of the resource seized. Let’s call that attribute a Selection and define it in the Save Attribute prompt.
The attribute a Selection will have a value of 1 if Resource 1 is seized, a value of 2 if Resource 2 is seized, and so on. Now we will know the position in the resource set of the resource seized. Since the arrayed variable or expression holds the processing times for each resource in the same order as they are defined in the resource set, we can use it in our processing delay as the index into the correct row of information (i.e., e Processing Times(a Selection)).
To expand further upon this example, let’s say the system now has 5 different entity types and 11 resources. We’ll use the Assign module to assign a value to each entity for its type (using attribute a Type with values of 1, 2, 3, 4, and 5). Using the same methodology as the previous example, we define sets of resources according to the preferences of each type of entity where Set 1 will service Type 1 entities, Set 2 will service Type 2 entities, and so forth.
| Set Name | Member 1 | Member 2 | Member 3 |
|---|---|---|---|
| Set 1 | Resource 1 | Resource 2 | Resource 3 |
| Set 2 | Resource 3 | Rescource 4 | Resource 5 |
| Set 3 | Resource 5 | Resource 6 | Resource 7 |
| Set 4 | Resource 7 | Resource 8 | Resource 9 |
| Set 5 | Resource 9 | Resource 10 | Resource 11 |
Notice that some resources belong to more than one set. For example, Resource 3 can service Type 1 entities (Set 1) with a low preference (last position in the set), but it can also service Type 2 entities (Set 2) as the first preference (first position in the set).
Using a Decide module to connect to different logic based upon the a Type attribute value, you can send Type 1 entities to logic that seizes a member of Set 1 in preferred order, you can send Type 2 entities to logic that seizes a member of Set 2 in preferred order, and so on. Combining this with arrayed variables or expressions representing the processing times continues the theme of skill-based routing.
For an added challenge and to streamline your logic even further, you can define Set 1 through Set 5 as rows in an arrayed expression (i.e., e All Sets), eliminate the Decide module discussed in the previous paragraph, and use the EXPR Arena variable discussed in the February 2016 issue of this newsletter to point to the correct resource set to seize from based upon the a Type attribute value of the entity.