Need Vector with VRT and VOA for all 50 States!

[adminman3]

We have our VDN Announcement working, but we need to somehow keep one toll-free number as the public access, and one vector to handle area codes for each of the 50 states. In other words, we want to route calls based on NPA of origin, and to do so with a 'state-specific' announcement to the agent...all from one main VDN. Can it be done? ...by this Thursday?

 

[testLED]

you could in theory possibly use incoming ANI routing albeit long winded. If you have ANI as a feature within your vector programming. you could rout to specific VDN's from the main VDN based on the state area code using the route to VDN to control your VOA..

I am UK so do not know US telephone numbering plan!

probably your best chance of achieving this.

 

[matthartt]

When I look at my vectors...I see 99 possible steps. There is no way you could account for all the different possible area codes with just those amount of steps. At least that I can think of.

Maybe someone else has a creative way. But limiting it to just one incoming VDN...that is the limiting part.

 

[matthartt]

Thinking it over you could do it this way...

First announcment says press one if you live in "State 1, State 2, State 3 or State 4 press1, If you live in State 5, 6, or 7 press 7."

Then if they press 1, the message would be "Press 1 for state 1, press 2 for state 2"

It would be a long menu for the caller to wade through but could send the calls to agents saying what "State" they are coming from.

 

[98Converter]

Just a thought - been out of the call-center space for quite a while:

Give it to AT&T... They can do area code routing in the cloud a lot easier, and then have them send you a 4-digit DNIS based on state.

They'll decide where the call is originating from, and let's say it's from Arizona - AT&T will send it to your 800# with 5004 which would be 1 your new 'State' VDN's...

An example:
STATE DNIS
Alabama 5001
Alaska 5002
American Samoa 5003
Arizona 5004
Arkansas 5005
California 5006
Colorado 5007
Connecticut 5008
Delaware 5009
District of Columbia 5010
Florida 5011
Georgia 5012
Guam 5013
Hawaii 5014
Idaho 5015
Illinois 5016
Indiana 5017
Iowa 5018
Kansas 5019
Kentucky 5020
Louisiana 5021
Maine 5022
Maryland 5023
Massachusetts 5024
Michigan 5025
Minnesota 5026
Mississippi 5027
Missouri 5028
Montana 5029
Nebraska 5030
Nevada 5031
New Hampshire 5032
New Jersey 5033
New Mexico 5034
New York 5035
North Carolina 5036
North Dakota 5037
Northern Marianas Islands 5038
Ohio 5039
Oklahoma 5040
Oregon 5041
Pennsylvania 5042
Puerto Rico 5043
Rhode Island 5044
South Carolina 5045
South Dakota 5046
Tennessee 5047
Texas 5048
Utah 5049
Vermont 5050
Virginia 5051
Virgin Islands 5052
Washington 5053
West Virginia 5054
Wisconsin 5055
Wyoming 5056

Then from there, put in your VOA...


Thanks,
CJH

We are what we repeatedly do. Excellence, then, is not an act but a habit. ARISTOTLE 384-322 B.C.

 

[adminman3]

I see from your responses that I was not too far off with my own thoughts about the system capabilities and limitations, as well as the major task of gathering all the area codes for each state in to a single vector. My BP will have to consider the at&t or Sprint option in order to make this happen, and that's not going to please him $$$$$. Life is tough, but this is the direction he will probably have to go.

Thanks for your time and generous help.

Paul

 

[testLED]

It makes no odds if you only have 99 steps or on earlier versions 32 as you can link vectors together. So you have one main VDN that takes the first call control based on ANI routing for example if ANI = xxxx route to. when you get too full route to vdn/vector. However you will still have multiple VDN's to control your individual VOA but only one main one to control incoming calls

Admittedly it is alot of administration but not impossible really... unless you have some feature limitations.

 

[adminman3]

I have taken an approach similar to what you are describing, by taking a look at sorting inbound VRT by NPA such as 200+, 300+, on the original vector. From there, I am looking at sending to a second vector to treat the 200+ series, and a third vector for the 300+ series, and so on. I may come to a road block, but that is where my head is taking me.

I appreciate the suggestion. Still need this to work somehow without IXC intervention if possible.

Paul

 

[nohuhu]

adminman3,

we did the same thing for one of our customers using aes + cce call routing server + ms sql database. in the entry vector use adjunct-route step to call routing server, it does a simple lookup on ani-vdn matrix stored in the db and returns the expected second level (state, that is) vdn. cheap, easy and works a helluva lot faster than multiple vrt lookups - we were able to cut 4-second vrt lookup delay to less than half a second with cce call routing. robust, too, however it won't hurt to implement some backup scheme just in case.

 

[thejkro]

I have to agree with adminman3. Given your time constraint of -today- I would say your best bet is to use vrt lists with area codes. Here is a site with area codes by state.

http://www.50states.com/areacodes/

Sorry if it's not the best... it was the first result for a Google of area codes by state. I'd say if you want to do it by state make a different vrt for each state and then a goto step __ if ani in table ___ . Just correspond the right extenion to the right state vrt number and you should be set. Shouldn't take more than an hour to implement really.