Migrating Avaya Call center to another country

[bankingguy]

Hi guys,

I'm currently working on a CM project that requires me to migrate a small group of call center team in Country A to be migrated to Country B. Calls are very minimal per day. IP trunks will be built between 2 CMs. There are only 2 channels on the trunk.

My solution:

1. Perform IP trunk
2. make a simple route to IP trunk If there is no available agents locally.

Challenges:

Since there are 2 channels only on the IP trunk, the 3rd call might get busy tone or may queue to the local skill which i dont want to happen. it will only queue if the trunk is down. any suggestions?

 

[kyle555]

So, CMA in Country A gets calls and you're trying to migrate the calls to CMB in Country B but only actually route the calls from A to B if there are no agents available locally? Why would agents be available locally anymore?

There's 101 ways in vectoring to accomplish something like that.
In vectoring you can go to step X that routes to CM B if available or logged in agents in skill 1 =0.

There's a conditional of "gateway registered or not" so you can "route to queue 5 which only has agents at site 5" but right before that step have "queue to skill 6 if gateway 5 isn't registered"

There's also a "counted calls" conditional that lets you route based on how many calls are active in a VDN.

https://downloads.avaya.com/css/P8/documents/100059285

Think like:

1. go to step 10 if staffed-agents   in skill 1 = 0
2. go to step 10 if available-agents in skill 1 = 0
3. queue to skill 1
10.queue to skill 1 if counted calls route to vdn 202 >=2
11.route to vdn 202 that ultimately routes to CM B

That would make calls queue to skill 1 on CM A if 1 agent were available, and if none were available, then let the next 2 calls route to CM B and the 3rd would stay on CM A.

If you're looking at further consolidation, instead of making the trunk only 2 channels, you can have as many as you like and administer a bandwidth limit between those network regions.
You can also make that CM A to B trunk a QSIG trunk with path replacement. That would let you indiscriminately kick all PSTN calls received on CM A to CM B and leave all logic and programming in CM B. If CM B decided it wanted to route the call to VDN/skill on CM A, it would route back over the same trunk. Path replacement would kick in and CM A would realize it can keep the audio locally. What you would see on a trunk status is 2 channels with 0 bandwidth used. CM A just borrowed some brains from CM B to learn to route a call on it's PRI to an agent on it's system.

 

[bankingguy]

Thanks Kyle.

The business only requires to migrate the call center to cut cost. It will queue locally during BCP scenario and most of the time all calls will route to CM B. My trunk is only limited to 2 channels with 64 kbps bandwidth reserve. Business expenses is too tight so this is the best that they can do for now. Also CM B is in India, Voip call is not allowed, due to some regulatory approval. I want to try the counted calls. Any other tips I can do?

 

[DAVIDPAYNE]

As long as the call to or from India stay on company equipment you should be fine.as long as it over company MPLS, Network, even over VPN. You could not route two a cell phone in india, and route a call from a cell phone, land line, etc. in India to device that was not in India, unless it went out over India International cicuits. Or that was my understanding 4 years ago. VoIP (internet) is not allowed, the India Telco most get it money.

 

[DAVIDPAYNE]

But I am no lawyer, and India has some of the strictest Telecom Laws I worked with.

 

[bankingguy]

Hi Kyle,

On the vectoring you mentioned on counted calls:

queue to skill 1 if counted calls route to vdn 202 >=2

what I want to do is to perform a "goto step 10 if counted-calls to vdn xxxx = x"

but its not happening. This step is being skipped.

My aim is to make sure that if the trunk is full, I will let the caller hear MOH, then if the trunk is clear it will route automatically.

Any tips?

 

[kyle555]

Maybe its because the call left vdn processing on the route out. I suppose if the vdn had a vector queuing to a skill, then 202 would have those 2 calls tied up.

It sounds like there's a better way to do this...You're not going to have much fun consolidating the logic of two disparate call centers together.

Maybe something like a station with EC500 and 2 call-appr and not restricting the last call-appr for conference/xfer and just EC500 the station to India's queue number? Then a coverage path for that station to a vdn back to the queue on CM A? Not sure how EC500 plays with multiple calls or if it'll let you have two calls up to the same "station" but that might be easier than vectoring.

The feature I think you're looking for is look ahead interflow. But that's for doing this at a large scale with business logic. Not just routing 2 and never more overflow calls to another CM.