Architecture assistance

[cmcshane]

Hi,

We currently have a multi-site deployment. We have a central site where main configuration server is located and 2 other remote sites with cs_proxies and local t-servers, stat servers, urs etc. Calls for each site originate and terminate on the one pbx so there is very little intelligent inter-site traffic apart from some t-routing.

The business now want to virtualize the call-center so calls originating on any switch/IVR can route to the longest available agent with relevant skill on any of the 3 sites.

What I think needs to be done is for the ISCC parameters to be configured on each switch/t-server ( this is ok ) and the routing stat_server on each site needs to be connected to all 3 t-servers to monitor resource availability across the enterprise. Will this work ok or will the fact that each t-server will be broadcasting to 3 stat servers cause any issues ? I'm also a little concerned about agent reservation. Will there be a situation where the URS's could attempt to reserve the same DN's ?

Also, Is there any documents available that assist with multi-site routing apart from the one available in the t-server guide ?

Any feedback welcome. I'm also comtemplating re-designing the architecture and having one central Genesys environment and only have local t-servers on each site. This would simplify things as only 1 URS, routing stat server etc would be required, but we'd lose the site survivability in case of network outage as each site can work independently now using proxy. Any views on this again would be appreciated :-)



Thanks

Colin

[victor]

My gosh,

judging from your post, it seems like you pretty much can do anything there.

One extreme: everything on each site
Another extreme: one main site

Here is how I would go about this:

[b]1. do I have a lot of phone calls?
[/b]If I have a lot of phone calls that need URS handling, I would try to identify which site requires the most of URS routing. I would then place my URS there. I would also have ONE StatServer overlooking all the sites. It would be dedicated to routing and routing only. I would also place that routing StatServer as close to my URS as possible.

[b]2. how reliable is my network?[/b]
If I can get some sort of SLA for my network, I would concentrate most of my machinery in one place and let them handle everything except for pop-up: T-Server should be placed close to your PBXs, thus, I would have t-server on each site, connected DIRECTLY to main configuration server. I would force CCPs, Softphones or anything else that operators might use connect to configuration proxy that I would place on each site.

if my network is one of those that usually work but once in a blue moon decides to see for how long it can keep its breadth under water, I would identify what I can get away with, such as: default routing, inability to see stats, etc. The idea is very simple: having redundant systems at every site will increase the site usability but will also cause a lot of headaches in reporting department. The main problem I had to encounter when people use multiple statservers, is that from time to time stats on one statserver do not match stats shown on the other, and then I need to explain people which statserver is the "right" one (usually, both of them).

If I have an iffy connection (defined as five-second disconnect once a month), I would:

1. one global reporting statserver for CCA and for CCP used by SVs that need to see overall picture
2. statserver on each site, used by CCPs AND acting as BACKUP routing statservers
3. one routing statserver used by all URS, regardless where those URS are to ensure that stats are the same across all URS
4. several URS put behind an LDS, each using the same routing statserver. I would place those URS at every site, but would only use one main URS/LDS and the rest in case network failure

If I do not have LDS, I would place URS at every site and designate them for local routing only. This means that they would no longer use global routing statserver, but local statservers. All inter-site routing would be done through "transfer" queues, where URS@SITE1 would transfer the call to URS@SITE2 to be forwarded to operator@SITE2.

Agent reservation is good, but I simply do not want to waste those precious seconds and worry whether URS query interval is longer or shorter than network delay (nor that most people would, but I like to fine-tune things)

[b]3. DR and backup : how much do I care about it?[/b]
What is to be done when one of our sites go down? Do we switch all the traffic on the carrier level or do we do it locally? Even though I am a strong advocate of carrier switching, there are some scenarios where this is not possible, and you are stuck with fielding calls when your system is down. You can:
1. set your PBX to forward the calls to another PBX
2. have a completely redundant Genesys, thus URS1@SITE1 failure would not have an effect on SITE1 routin, by adding a hot-standby URS2@SITE1
3. have URS on SITE2 act as a backup server for URS1@SITE1
4. rely strictly on PBX routing
5. have a beta site to where operators would switch to

[b]4. Licenses[/b]
Needless to say, what is my overall budget for this year and how much can I afford to spend on HA licenses, redundant lines and SLA? If you can, go all the way. If not, identify what is critical, what is not, and then start cutting the redundancy. Is CCA reporting really criticial when your primary site is down? Do you need SV's to see SITE2 when network goes down between two sites? Do you really need HA URS, given that Avaya can deliver defaulted calls anyway?

At the end of the day, you can come up with at least 10 scenarios and all of them have something good and bad about them. But, from my experience, your multi-site is only as good as your strategy is. The rest usually is based on routing. So, as long as you got your routing dynamic and independent of any single statserver, you should be fine.

Best regards,
Vic

[cmcshane]

Thanks Vic. I wasn't expecting such a quick and thorough response, so much appreciated. For a number of reasons I'm edging more towards a central solution with only a remote t-server active on each of the other sites.

1.) Firstly we have one central datamart on our main site but local ODS Db's ( data_sourcers, stat servers etc ) on the others. All the data from each site is feeding back via the ETL processes. The administration on this is quite considerable. If we went with one stat server for reporting this would simplify the solution as all the data would be in the one ODS on the main site.
2.) The Genesys technical skills are all on the main site so it makes sense to have the servers and applications located in the one data-centre for administration.
3.) In order to have a consistent routing strategy for the virtual call-center it makes sense to have one central site where stat server and router are located. This ensures consistency of SL calculations etc and that all calls are treated by the same strategy ( ies ).
4. ) Correct me if I'm wrong but I can still keep all the existing applciations on the local sites (i.e proxy, stat, URS etc ) in a disabled state and manually swap over in the case of a sever network outage ( network is very stable so not much chance ). We also have HA for the applications so there's that redundancy there for genesys related issues rather than network.
5 ) We're a Nortel site(s) but can still configure default routing to ACD queues in case of outages. As part of this we'll need to work with the business to develop a robust default routing scenario.

Obviously I need to do a lot of planning on this, but we'll have a more stable and manageable environment utilizing the central solution. The multi-site remote survivability model worked well when the sites were pretty much standalone ( bar some time based t-routing ), but to move towards a virtual call-center I think the central model is definitely the route to take.

Thanks again for your assistance Vic, your input has been very helpful.



Colin

[victor]

Hi,

I think you have it right. Nortel's NACD is pretty good and can do everything you need should Genesys go down.
You are also right about keeping some of yoru products shutdown until the need arrives to use them. I wonder how you would be able to start al of your applications if it cannot access your configserver (cs proxy should be up all the time for you to do that).

Overall, I think centralized layout is the best way, especially if you can take care of network-related outages (at one of our sites, we are plagued by them no matter what we do)

Best regards,
Vic