Vector ignored holiday table routing?

[Stinney]

We route calls from a couple of toll free numbers to the same VDN and the same vector. I built holiday tables into the vector to bypass 1 or both IVR systems that handle calls.

I recently made an entry into holiday table 99 to bypass both systems and when I called it, the call bypassed and routed properly. But we see a lot of calls that went through and were handled by the IVR.

The IVR ports are set up as AAS agents and only have 1 skill. I have listed usage and made sure that calls are not routed to these IVR ports by any other method than to the one vector shown below for processing.

Is there any reason a vector would ignore the holiday entry in a vector, or are there any known issues? I don't know of any other item that would effect holiday routing, such as COR, VDN settings, etc.


The holiday entry I made was:

______START_______ _______END________
Month Day Hour Min Month Day Hour Min Description
12 31 08 58 12 31 23 59
01 01 00 00 01 05 00 00


The vector is programmed as follows:


Number: 94 Name: IVR
Multimedia? n Attendant Vectoring? n Meet-me Conf? n Lock? n
Basic? y EAS? y G3V4 Enhanced? y ANI/II-Digits? y ASAI Routing? y
Prompting? y LAI? y G3V4 Adv Route? y CINFO? y BSR? y Holidays? y
Variables? y 3.0 Enhanced? y
01 wait-time 0 secs hearing silence
02 # Next line bypasses both IVRs
03 goto step 14 if holiday in table 99
04 # Next line bypasses IVR1
05 goto step 10 if holiday in table 97
06 goto step 10 if V1 = 1
07 queue-to skill 1st pri m
08 goto step 14 if V1 = 2
09 # Next line is to bypass IVR2
10 goto step 14 if holiday in table 98
11 queue-to skill 2nd pri m
12 goto step 14 if queue-fail
13 stop
14 goto vector 22 @step 1 if unconditionally
15 stop

- Stinney

Quoting only proves you know how to cut and paste.

 

[RTMCKEE]

I think you need to put a time in the 01.01 - 01.05 entry. Ie. 00:01 and 23:59. I'm just guessing here, but the 00 entry isn't specifying any time.

rtmckee

CM 4.0.4 (7 US locations)
CM 5.2 (India)
IP Office 5.0 (China)
Modular Messaging 3.1
CMS R3V11

 

[Stinney]

Interesting thought, but 00:00 should indicate midnight. I don't think it should be the issue. Calls were coming through on 12/31 as well as the 01/01-05 dates.

And when I made my first 2 test calls on 12/31 around 09:00 the calls did bypass the routers.

- Stinney

Quoting only proves you know how to cut and paste.

 

[DAVIDPAYNE]

I am sure you have, but to just check, have you check the time on the system.

 

[DAVIDPAYNE]

also, what does vector 22 look like?

 

[Stinney]

Date and time are correct.

Vector 22 is what the IVR will transfer to after determining the call should be routed to an agent. Or where it should route if the holiday table is active.

There's nothing fancy there and the system should have directly sent the call to Vector 22. This is where I confirmed my test calls were going. Nothing fancy there.

- Stinney

Quoting only proves you know how to cut and paste.

 

[rejackson]

You dont say when the calls got through but I think I found that the dates have to be in order in the table. Move the january entry to the front. Its a pain because you have to shift the whole table down.

 

[Stinney]

I think you're on to something. I'll test it out and let you know.

I just remembered that initially I only had the 12/31 date in the table and that's when I made my test calls. Then they called me to extend the time through the weekend, I added the 01/01 - 01/05 dates and didn't call to test again.


- Stinney

Quoting only proves you know how to cut and paste.

 

[Stinney]

Unfortunately, it doesn't seem to be the issue. I changed the 01/01 - 01/05 dates to 01/01 - 01/08 and left the 12/31 date in place and the test was working.

- Stinney

Quoting only proves you know how to cut and paste.

 

[EPalle]

Can you run a list trace on the vector??
This will show each step the call goes through when it hits the vector.

Open the terminal emulation and type the command:
LIST TRACE VECTOR 94

Then make a call.
Post the outcome.

 

[Foneranger]

I saw the vector starts with a wait time of 0 seconds, I have encounteed problems with high volume vectors using 0 sec wait, changing it to as little as 2 sec has helped.

 

[Stinney]

Unfortunately, because I can't recreate the issue, the list trace shows the calls routing properly if I put an entry in the holiday table.

- Stinney

Quoting only proves you know how to cut and paste.

 

[BIS]

What CM version is this? I remember having trouble with holiday tables spanning multiple days - that simply didn't work. I had to add an entry for each day.

 

[rejackson]

I know you did a test but I still think the order matters. When I had the problem it appeared the the table lookup stopped as soon as it hit a date/time greater than the current one.

 

[Stinney]

We're on CM 5.1

I'm still not sure that the order issue applies. When I only had the single entry of the 12 31 date it was failing before I added the 01 01 to 01 05 dates.


- Stinney

Quoting only proves you know how to cut and paste.

 

[letman2]

I always put the time in my holiday tables as start 00 00
and end as 23 59 and never have any problems. It would seem if you put start 00 00 and end 00 00 it would start and stop at the same time of day

 

[Stinney]

OK, Holiday Tables were not the issue. Not the dates or times, etc.

Can't believe we didn't find this earlier.

I didn't program the original vector and shame on me for not following it all the way through the call or all the way through with a list trace report. Once we were hitting vector 22, we stopped testing as that was where the bypass was supposed to go. Here's what was going on.

Vector 94 was sending the calls to Vector 22, which I don't like to do. I prefer it would route to a VDN, which allows for accurate reporting of how often the VDN is routed to. This also would have helped to discover the issue sooner if it had been set up this way. Or more likely, not caused the issue in the first place.

So vector 22 has a menu and when a caller chooses to speak to an agent then the call is sent to vector 23 (result of legacy of limit of 32 steps in vector).

Vector 23 then plays an announcement and queues to......1st Skill.

Since the original VDN to vector 94, never routes to any other VDN the original 1st Skill in the VDN is queued to which is the IVR skill.

So this is why the calls showed as being answered in the IVR skill report and in the VDN report.

But by looking at a Vector report for vector 94, we saw that no calls were queuing to the skill in vector 94, or being answered by the IVR in vector 94, but in vector 23 the calls were being answered by the IVR. The IVR then was routing calls to a new VDN out of the IVR to vector 22 and being answered by the agents.

I have since resolved this by changing the bypass step from a goto vector step to a route to VDN. The new VDN's 1st Skill is the agent skill, and I have made sure the VDN over-ride, doesn't prevent the necessary skill change.

Thank you all for your help.

- Stinney

Quoting only proves you know how to cut and paste.