Tips for writing BSR vectors

Last Updated : Feb 01, 2013 |

Before you write vectors using BSR, see the sample vectors provided and familiarize yourself with the new commands and command elements. Sample vectors are provided in singlesite BSR and multisite BSR. The new commands and command elements are explained in the Call Vectoring commands.

As you write BSR vectors, follow the guidelines:

  • Arrange the consider steps in the order of preference.

    The consider step that tests the main or preferred, resource must be the first in the series. The second consider step must test the resource, that is, your second preference for handling the given call type. To prevent unnecessary interflows, use consider steps for local resources before steps for remote resources. This arrangement also provides a local best as a backup in case the interflow fails.

    Arranging consider steps in the order of preference for all BSR vectors. This arrangement is especially important when the active VDN for the call is using the 1st-found agent strategy since the server delivers the call to the first available agent found, arranging consider steps in the order of preference ensures that calls are delivered to the best available resources.

  • Do not put any commands between the steps of a consider series that can cause a delay. Goto commands are ok.

  • Do not put a consider series in vector loops.

  • Confirm that calls queue successfully.

    Since EWT is infinite for a call that is queued, a step that checks EWT after a queue attempt is a good confirmation method. After a queue-to best step, for example a command such as goto step X if expected-wait for call < 9999 must be included.

  • Do not use the wait-improved conditional in a vector before you have queued the call once.

    The wait-improved conditional compares the EWT of the call in the current queue to the best resource found by a consider series. If a call is not queued and a vector step such as check best if wait-improved > 30 is executed, the server interprets the current EWT of the call as infinite and the check best step always routes the call to the best resource. In other words, in this situation the check best step functions like an unconditional goto or route-to command.