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 IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Reporting Question

Status
Not open for further replies.
Nov 17, 2004
17
GB
Please can someone help me understand what we are missing in the following calculation. We are using Crystal Reports to design a new report using Symposium V3.0 Database fields.

Logged in Time = 08:37:32

Talk Time = 05:39:51
Not Ready Time = 01:39:56
Wait Time = 01:02:20
DN INT Time = 00:00:00
DN OUT Time = 00:37:05

The total of the above 5 times = 8:59:12 does not match the logged in time of 08:37:32. What are we doing wrong?? In order to reconcile the logged in time, what other factors should be in or taken out of the report.

Ideal Result would be:

eg. Logged in time = 5hrs
Talk Time = 4hrs
Not Ready Time = 30 mins
Wait Time = 30 mins

Total = 5 hrs and matches Logged in Time.
 
From NTP:
All agent state timers are maintained independently. For example, the following events occur:

9:00:00 The agent logs on.
9:00:10 The agent answers an DN call from an internal number.
9:00:20 The agent places the DN call on hold and answers a Symposium Call Center Server call.
9:01:20 The agent releases the Symposium Call Center Server call and resumes the DN call.
9:01:30 The agent releases the DN call and logs off.

At the end of this period, the agent timers have the following values:

LoggedInTime 90 seconds
WaitingTime 10 seconds
DNIntInCallsTalkTime 80 seconds
TalkTime 60 seconds

The total activity time for the agent, as calculated below, exceeds the agent logon time of 90 seconds.
WaitingTime + DNInCallsTalkTime or DnIntInCallsTalkTime + TalkTime = 10 + 80 + 60 = 120 seconds.

Similarly, on the Meridian 1/Succession 1000 switch, a phoneset may contain multiple DN keys. If an agent answers a DN call, places it on hold, and makes another DN call, both DN hold time and DN talk time are pegged for the same
period.
 
I think we have already seen this in the Symposium Dictionary some where, and word for word. But this does not help us at all.

I have never seen a telephony system that does not add up. Surely it makes sense that all the components add up to the logged in time. Otherwise, how does a Call Centre Team Manager work out what proportion of time advisors have spent in the various activites. They are never going to be able to get this accurately.
 
Try doing some scenario testing such as receiving an inbound queue or skillset call, talk for 1 minute, then put the caller on hold and make an outbound DN call, talk for 2 minutes, then hang up the DN call and return to the queue call, talk for a further 2 minutes and hang up.

This may be where the problem is, that Talk Time includes hold time, which means if your agents are putting a caller on hold and talking to another agent or external caller it is double counting as DN talk time and hold time.

Hence in this situation the following might appear:

Talk Time (incl hold) 5 mins
DN Out Talk Time 2 mins

whereas the actual call was only 5 mins, it has recorded 7 mins of activity. Not sure whether this is the case but testing will show you.

The other thing to check is the call presentation class where if an agent has the placement of DN Calls on hold when answering a Queue related call set to true, this will cause problems with marrying up your statistics. Try this first and see if it fixes your issue and then do some testing.

Good Luck!

 
Yea the problem with the reports are that you can be in Not Ready and on a DN-OUT/DN-IN.

I would assume by your numbers that you have some crossover with that and you are basically going to have to assume the "difference" to know how much was while on Not Ready and how much was straight DN time.

In the above example you are about 20 minutes over your login time so I would assume that @20 minutes of your Not Ready was actually spent on DN Out Calling. The remaining DN out was made while not in the Not Ready state. In other words they just picked up their DN to make an outgoing call while they were waiting and thus it was logged solely as DN time.

 
Richard,
We share your aggrevation. We've worked on this for months and finally gave up. You will not be able to add certain agent call states together to match the exact login time. I couldn't believe it either.
In my opionion, The Symposium data dictionary doesn't offer much help in terms of reporting. We actually worked with Nortel professional services on this and they couldn't offer much help.
I do agree in the 5 agent states that you mention above, there could be some double pegging going on such as DN talk and Not Ready. We tried to take out all call states that were double pegging and still couldn't match exactly...even in a controlled testing environment. Soemtimes the login time would be a little higher, sometimes a little lower. I think that part of the problem is that the system "rounds off" the time. For example, if you press your not ready key really fast, sometimes it will peg as 1 second of NR time, sometimes it will not.
Just a sidenote: Couple of other independent call states to mention are walkaway and consultation to throw in the mix.
Good luck with this. I would be very excited and surprised to see this actually work out.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top