Routing Best Practices

[mdewhurstuk@gmail.com]

Hi i have been asked by my current employer to review the routing setup as they suspect that the previous integrator didnt design the flow in the best way.

I can design routing strategies etc but i am not a expert. I just wanted to know if there was anything to avoid in routing when it comes to Best Practices or anything that would help with performance?

Any help or tips welcome

Mike

[Adam G.]

Hi Mike,

That's a really open question. It all depends on the requirements. As for ideas, unless the strategies are really basic I like to use subroutines.

Pavel

[mdewhurstuk@gmail.com]

well at the moment they have 50 + strategies 100 VQs for Email routing only. Seems to be to be over-engineered.

[Adam G.]

Mike,

Or under-engineered depending on how you look at it.

The other thing to think about is how long the implementation has been operational. The longer it's been used, the greater the 'spaghetti' level.

Give me a bell if you want.

Pavel

[KBS]

Mike -
Many of the same principles used in programming can be used here. A few things to consider:
- Do some of the existing strategies use the same (or almost the same) routines/block of steps in certain places? If so, you might be able to move this block to a subroutine

- Do some of the strategies use essentially the same routing, but the only difference is the targets and/or treatments? If so, combine the strategies and do the customization with database lookups or list objects

- Is there a standard for variable /target naming conventions?

- Is there a lot of hard coding for targets, treatments, etc? Can this be modified so the strategy uses more data lookups than explicit declaration?

- What is the reason for the 100+ VQs? If some of them have similar attributes, could they be combined, and filters used to provide additional reporting?
For example, if you had VQ_QUEUE, VQ_QUEUE_RED, and VQ_QUEUE_GREEN, could you whittle it down to just VQ_QUEUE, and apply Filters to gather Red and Green statistics?

Good luck. Our original integrator did the same thing - created a bunch of similar strategies where the only things that changed was the target and the Virtual queue. Over the years, we've reworked our routing, to where we have a single core routing strategy (with about 60 supporting subroutines) that is data driven and supports 95% of our routing.

Kevin

[René]

Hi Mike,

I can undersign all recommendations in previous posts but these are focused mainly on voice routing. If we're talking about email routing then I would focus on the main point and that is workflow. Many people (routing designers) underestimate that when designing routing of emails and to be honest I did the same mistake when doing it for first time few years ago. So being in your role I would analyse/describe implemented workflow in the first step, compare it with required one in second step and propose some optimization afterwards.

About number of VQs - it's hard to say without knowledge of reporting requirements. Personally, I prefer using filters but it could have some "negative" impact to required time for development/modification of historical reports especially when using CCA.

R.

[mdewhurstuk@gmail.com]

ok thanks for your help..

Last question (s), i notice a lot that companies have more implementations using Filters / Attached Data rather than lots of VQs.

Is there a business / technical reason for this?
Is one a newer technology ?

Mike

[cavagnaro]

All will depend on your customer requests, with attach data you will be able to create custom stats too