User adjustments in multisite BSR

Last Updated : Feb 01, 2013 |

User adjustments are especially important in multisite applications, where unnecessary interflows are costly and use trunk capacity inefficiently.

User adjustments in multisite applications function in the same way as in singlesite BSR with one important difference: user adjustments is applied at the remote servers in an application as well as at the origin server. Since a status poll vector uses consider steps to evaluate resources on the server where the vector resides, with the adjust-by portion of each consider command, the administrator at each server can set preferences for the splits or skills at the server. In BSR applications, the status poll vector checks any such adjustment for a split or skill when selecting the best resource. The adjustment is then returned to the origin server along with the other data for that resource. When the server receives the adjustment from the remote server, the server adds the adjustment to any adjustment that was assigned to that location in the consider location step. In the following example, no agents become available during the time the vectors are processing the call.

The following example shows a primary vector that checks one remote location to which the vector assigns an adjustment of 30.

Vector with consider step for one location

1. wait time 0 secs hearing ringback
2. consider split     pri m  adjust-by  0
3. consider location 2 adjust-by 30
4. queue-to-best

The following example shows the status poll vector at location 2.

Status poll vector

1. consider split  2    pri m   adjust-by 0
2. consider split 11    pri m   adjust-by 20
3. reply-best

Consider split/skill commands in the status poll vectors work the same as in singlesite BSR vectors. User adjustments are applied to a single split or skill and not to the entire location. In this case, the two splits are assigned different adjustments. Say that split 11, despite having the larger adjustment, returns the lower adjusted EWT for a call. The reply-best command in step 3 returns the user adjustment of 20 to the primary vector on the origin server, along with the rest of the data for split 11.

In saving the data that is returned by location 2, the origin server adds the remote adjustment of 20 to the adjustment of 30 that is specified in step 3 of the primary vector. As a result, the call does not interflow to location 2 in this example unless the EWT for location 2 is more than 50 seconds better than the EWT in split 1 on the origin server.