Vector Overview and CMS Reports

[Realign]

Site Info: G3SI V11 Intuity MAP5 CMS V6
Good Morning, I have a couple of quick questions. I have calls routing via the below vector. In reviewing CMS reports on the Split Call Profile, It reports no abandoned calls, average speed of answer is 01 seconds however it is reporting that only 90% of calls were answered. Shouldn’t this number be 100% if the call is forced to be answered or routed out? On a second note, is there any report which would show the total number of agents logged in during a particular time? I am looking for an Interval (or similar) report which shows a total as opposed to an average. Any suggestions would be greatly appreciated.

01 goto step 13 if time-of-day is all 17:55 to all 08:30
02 goto step 13 if time-of-day is fri 16:55 to mon 08:30
03 goto step 23 if staffed-agents in split 5 > 0
04 wait-time 5 secs hearing music
05 goto step 13 if available-agents in split 1 = 0
06 wait-time 5 secs hearing music
07 queue-to split 1 pri t
08 wait-time 10 secs hearing music
09 announcement 6607
10 goto step 13 if available-agents in split 1 = 0
11 wait-time 10 secs hearing music
12 goto step 10 if unconditionally
13 route-to number 5003 with cov n if unconditionally
14 stop
15

 

[cyberjamos]

So you're running a split/skill report for skill 1 and it's showing less ACDCalls than CallsOffered?

Cheers,
NJ

PS: Please let me know if my advice has been of any use.

 

[Stinney]

Calls flowed out after queuing (as in line 13) are considered not answered.

If you actiavte a trace on the agent(s) that can log into split 1 you can see exact days and times the agent was logged in and out of a skill.

 

[Stinney]

Sorry for the multiple posts.

You can also run a Historical Agent Login/Logout report on the skill.

Favorite all to common vendor response: "We've never seen this issue before.

 

[Realign]

Good Afternoon, I think I see where you going with this. So if a call is abandoned before the queue and I am reporting from the queue why is that counted against percent answered? Do you think it is because I have step 13 after the queuing step? And nothing for the actual count of Agents? I will need to run each individual separately?

 

[Stinney]

If any call is abandoned before it is queued to a split/skill it is not counted against percent answered. Only calls that are actually queued to the split/skill are counted. Once it is queued, calls abandoned or redirected out of the queue will change the % of calls answered.

Since step 13 redirects a call after it has queued it will effect the % calls answered stats.

Using agents-available on line 10 may not be the best way to handle your calls depending on what you are doing. Agents-available will only look for agents that are in available state and not on a call, in aux, acw, or any other state than available. It doesn't consider if agents are staffed and just handling calls or in an unavailable state. So technically your "queue" of playing music and annonucements should never play. If an agent is available, the call will route to them immediately. If agents are staffed but busy on calls or other tasks, the call will immediately route out on step 13. This would also be why your average answer speed is 1 sec. I would bet money that if you monitor a real-time report of the skill you never have any calls waiting in queue.

Assuming your intention is to actually look to see if there are agents logged in to take calls you should change lines 5 and 10 to:

Goto step xx if staffed-agents in skill 1 < 1



Favorite all to common vendor response: "We've never seen this issue before.

 

[Realign]

I like that idea much better. So if there are NO agents available, the staffed will pass the calls like I would like. Therefore the queue time should always be 0 seconds speed of answer and everything should be under the SLA. Now since you had a great idea, let me toss something another one at you. On another vector I have calls-queued:

01 goto vector 151 if holiday in table 1
02 goto vector 200 if time-of-day is all 18:00 to all 08:30
03 goto vector 200 if time-of-day is fri 17:00 to mon 08:30
04 goto step 23 if staffed-agents in split 4 > 0
05 wait-time 5 secs hearing music
06 goto step 25 if calls-queued in split 1 pri h > 2
07 wait-time 5 secs hearing music
08 queue-to split 1 pri h
09 announcement 4801
10 wait-time 10 secs hearing music
11 collect 1 digits after announcement 4849
12 goto step 14 if digits = 1
13 goto step 15 if unconditionally
14 messaging split 32 for extension 3022
15 wait-time 10 secs hearing music
16 announcement 4847
17 goto step 25 if calls-queued in split 1 pri h > 2
18 wait-time 20 secs hearing music
19 goto step 11 if unconditionally
20 stop
21

Do you think this is the optimal way of transferring anything after 3 calls waiting?

 

[Stinney]

This statement appears unclear/incorrect: "So if there are NO agents available, the staffed will pass the calls like I would like. Therefore the queue time should always be 0 seconds speed of answer and everything should be under the SLA."

Sorry if you understand this but I want to make sure I was clear.

Using agents-available after a call is queued to the skill will redirect the calls immediately out of the vector if there are agents staffed but no agents availabe to take a call because they are on a call, in aux, in acw, other, etc. Which obvously will leave your stats the same as they are now.

Using staffed-agents after a call is queue will leave the call in queue (looping through music and announcements) if there are agents logged in, but not available to take a call because they are on a call, in aux, in acw other, etc. This will change your stats, making the % of calls answered better, but increasing the average answer speed.

The way your newly posted vector works, it will redirect a call if there are already 2 calls in queue at line 6. But line 17 technically should never work. You can't get more than 2 calls in queue at one time. Line 6 won't allow it, assuming you aren't using a goto vector xxx @ line 7 or greater somewhere else. You would need to explain in more detail what you are trying to do here.


Favorite all to common vendor response: "We've never seen this issue before.

 

[Realign]

My sincerest apologies, apparently I thought it made sense when I was typing it. Sometimes we all get a little carried away and type too fast. Anyways, I completely agree with you that line 6 should not allow any call over 2 but honestly we have been seeing some pretty interesting things such as the queue raise up to 4 or 5. So I put a secondary step to double check if you will just incase the queue wasn’t reviewed initially. Any thoughts? I really appreciate all of your responses.

 

[Stinney]

Are you using split 1 as an example or is this the real spilt you are using? It appears that you are using it in this vector and the original one you posted earlier.

If you are queuing to the skill in more than one vector then the calls queued can easily climb to more than 2. It doesn't necessarily mean that the number of callers waiting are all within that vector. It would seem to make more sense to use a different skill to keep the call handling seperate in these 2 vectors.


- Stinney

Favorite all too common vendor response: "We've never seen this issue before.

 

[Realign]

I should have clarified that. These vectors are for 2 different locations both with split 1 for consistency. The original is transferred out if no one is available and the second posted one is if calls are queued then transfer.

 

[langl3y]

Realign,

I would ask why a caller has to wait 10 secs before queuing in the vectors above? You have two lots of 5 secs of music that you may not need.

Cheers
Langl3y

 

[Stinney]

I agree with langl3y as well. Line 7 is probably your source of problem with more than 2 calls in queue.

Because line 7 makes the caller wait 5 seconds before queuing the call, you can have multiple calls come into the vector during that 5 second wait before the call queues in line 8. Then all of the calls that came in and are waiting 5 seconds have already passed the test on line 6 and queue as well. I don't see any reason for lines 5 or 7, your just making the caller wait for no reason.

- Stinney

Favorite all too common vendor response: "We've never seen this issue before.

 

[Realign]

I agree, those times need to be removed. How about this one:

01 goto step 25 if staffed-agents in split 5 > 0
02 goto step 12 if time-of-day is all 17:00 to all 08:30
03 goto step 12 if time-of-day is fri 17:00 to mon 08:30
04 goto step 12 if available-agents in split 1 = 0
05 queue-to split 1 pri t
06 wait-time 25 secs hearing music
07 goto step 6 if unconditionally
08 stop
09
10
11

Technically the call should never hit step 6 correct? Should I have the available-agents step after the queue step?

 

[Stinney]

Technically, no it should never hit step 6.

What does step 12 do? You really should post all of the steps.

Don't forget, if you flow a call out after it's been queued, then your % of calls answered will be lower.

- Stinney

Favorite all too common vendor response: "We've never seen this issue before.

 

[Realign]

Below is just the same route-out step which is on the previous vector.

12 route-to number 5003 with cov n if unconditionally
13 stop
14

25 is the site emergency message. Do you think I should remove step 6 completely? Just have the available-agents, then the queue step and that’s it?

 

[Stinney]

I wouldn't remove line 6, just in case something weird happens and line 4 is ignored. Don't want the caller hearing dead air.

- Stinney

Favorite all too common vendor response: "We've never seen this issue before.

 

[Realign]

I took your advice and removed the 2 additional 5 second intervals. The new vector looks like this:

01 goto step 12 if time-of-day is all 16:55 to all 08:30
02 goto step 12 if time-of-day is fri 16:55 to mon 08:30
03 goto step 23 if staffed-agents in split 5 > 0
04 goto step 12 if available-agents in split 1 = 0
05 queue-to split 1 pri t
06 wait-time 15 secs hearing music
07 goto step 6 if unconditionally
08

So far this morning the calls within SLA are at 100% which cures the Call-Profiling issue which was reported earlier. I sincerely would like to thank you all for your help. I will post the days final results to ensure they have remained at the 100% mark. I think now I should take out all the 5 second delays I have on other vectors.