Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Time Zone routing based on CLID

Status
Not open for further replies.

Ariadne

MIS
Jul 5, 2002
94
US
Hi there!

I have a team that wants to be able to take calls based on the different time zones. Here's my example.

The call centre, which is located in Toronto, Canada is in the Eastern time zone. It is staffed from 8 AM until 12:00 AM EST.

At 8 AM EST, they want to be able to answer calls from Newfoundland, (it is 9:30 AM in NFLD) but not accept calls from any other province or territory in which it is not 9:30 AM in their respective time zones, based on the CLID.

When it is 9:30 in each time zone, the call centre wants to open, and take their calls.

I know that I will be using VRT tables and the ANI command in the vector, I am just not sure how to cover off all the time zone routing...

Help!
 
Does anyone know if vector variables would work for this?
 
You might be able to use a variable for the TOD routing. I never really saw the purpose of that since you could already do that within a vector.

you will need to build as many VRTs as you have time zones.

Have each VRT point to a different Vector with the Open and closed time adjusted according to your open and closed hours.

Orignial vector might look like:

Goto vector 123 if ani in VRT 1
Goto Vector 234 if ani in VRT 2

Seems to be pretty straight forward.

RTMCKEE

CM 2.1.1
Prologix R9.05
Modular Messaging 1.1
 
I just wondered if there was an easier way. I had the same solution/idea, but it takes 7 vectors for each skill, and with 157 new skills to build, along with all the Business advocate stuff, it seemed fairly cumbersome.

Thanks!
 
I'm not sure how your customers call your center, but perhaps if you were to request different toll-free numbers for each time zone, with different DNIS digits, then your VRT tables would be a lot easier to implement. You also wouldn't have to keep track of changes in the area codes to maintain the VRT tables in the future.

Susan
"'I wish life was not so short,' he thought. 'Languages take such a time, and so do all the things one wants to know about.'"
- J. R. R. Tolkien, The Lost Road
 
Also not sure how you route calls today, but you wouldn't need 7 vectors per skill. At a max 1 vector per (timezone) and you could even double up on that. You'd have the one main vector that routed calls based on VRT then each "sub" vector would queue based on time. for example:

Goto vector 123 if ani in VRT 1
Goto Vector 123 if ani in VRT 2
goto vetor 234 if ani in VRT 3
goto vector 234 if ani in vrt4

Vector 123

1 wait o sec hear silence
2 Got to step 12 if ani in VRT 2
3 goto step 10 if time all 8pm to 8am
4 queue to skill 5
5 wait 3 min hear music
6 goto step 6 unconditionally

10 announce (we're closed)

12 wait o sec hear silence
13 goto step 18 if time all 9pm to 9am (time shifed for timezone)
14 queue to skill 5
15 wait 3 min hear music
16 goto step 6 unconditionally

18 announce (we're closed)


This is an example of how you could double or even triple up on vectors. They could all route to the same skill.

You could also do a variable based on the VRT, but the variable would be need to be set with each incomming call, and I dont know how fast that variable can be set\reset. ( was thinking of this on the way in today. If i come up with something, I'll post.


RTMCKEE

CM 2.1.1
Prologix R9.05
Modular Messaging 1.1
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top