CMS - Call Records vs Split Data

[dialtone]

Finding significant discrepancy between data in Split tables (dsplit), and query on call records (call-rec). Avaya wants $260/hr to tell me why...anyone got a clue?

For example:

I'm looking at data for a single day for a single split, and dsplit shows 124 answered, while query on call-rec for same day, same dispsplit, with disposition = 2, shows 106.

Thanks in advance...

 

[ukcomms]

Check the error log.
If you're using internal call records, there may be intervals in the day where the call records limit is being exceeded. If that is the case the calls will be stored in the hsplit and dsplit tables but will not be written to the call records table.

 

[telcoguy]

Very simple answer, (it's in the books);
all tables are seperate measurements, so for various reasons they can differ from for example call-rec.
You are looking at diffrent data actually.
Call-rec is a special case
any record over 5000 will be truncated,like UKCOMMS said.
There is no solution to this unless you implement ECH(External Call History)which logs the data to an extra external server.
If you look in your cms error log it will probably tell you it is exeeding capacity.

Hope this helps

 

[dialtone]

Thanks to both of you - let me add some additional info, and hope that you'll do the same:

[li]I'm using ODBC to pull the call_rec and dsplit tables.
[li]Since I've upgraded to Multivantage, the call_rec table size has increased significantly.

For example, the latest import of call_rec has 194,862 rows. While the table does get truncated, and the error log indicates this, like it always has, the date that I'm querying is well within the oldest call date boundary, and so truncation doesn't look like a possible culprit here.

I'm looking at totals (i.e. calls offered) for a single day, for a single split, using call_rec and dsplit. Given the fact that aggregate CMS tables like dsplit are the result of call events that are captured in call_rec (or rather are supposed to be), there should be no disagreement between the two.

Here are my queries, this may also help clarify the situation (maybe there's something wrong with them?):

[li]dsplit query "select callsoffered from dsplit where row_date = 11/4/02 and split = 2"

[li]call_rec query "select count(*) from call_rec where row_date = 11/4/02 and dispsplit = 2 and disposition in (2,3)"

The result is that the call_rec query shows 20% fewer calls.

Thanks for any help anyone can offer.

 

[SF0751]

Your call_rec query isn't looking at as many records as the dsplit query. Need to include the inflow calls and othercalls. Here are the database definations:

CALLSOFFERED: The number of calls that queued to the split/skill and that completed during the interval. This does NOT include calls on the Generic 3 switch that could not queue to the split/skill because the queue was full or there was no queue.
CALLSOFFERED includes ABNCALLS, RINGCALLS, OTHERCALLS, and INFLOWCALLS.


DISPOSITION This item represents the call disposition and indicates whether the call in the segment was:
1=connected (CONN, non-ACD call to a measured agent)
2=answered (ANS, split/skill or direct agent call answered by an agent)
3=abandoned (ABAN)
4=interflowed (IFLOW)
5=forced busy (FBUSY)
6=forced disconnect (FDISC)
7=other (OTHER)

Try modifying the call_rec query as follows:
"select count(*) from call_rec where row_date = 11/4/02 and dispsplit = 2 and disposition in (2,3,4,7)"

Good luck!
Susan
Under certain circumstances, profanity provides a relief denied even to prayer. - Mark Twain

 

[dialtone]

Thanks SF0751, but that's not quite accurate:

The field definition you gave is correct - but it only applies to fields in the split tables. "OTHERCALLS" and "INFLOWCALLS" are fields in the aggregate dsplit table, and if you look at their definitions, having them in the "CALLSOFFERED" derivation makes sense - but not so for the call_rec table.

While "Disposition=7" in the call_rec table is labeled "other" it's not the same as "OTHERCALLS" in the split tables. "Disposition = 7" is for the most part, made up of outbound calls, which you absolutely wouldn't want to include in a "Calls Offered" calculation. Additionally, we don't have any interflowed, forced busy, or forced disconnect calls (dispositions 4,5, & 6).

Got any other ideas?

Thanks, & keep 'em comin...

 

[Coineandude]

the cms call record report documentation also notes that call record data will not be collected if call traffic is greater than 400 calls in 20 minutes to protect realtime processing on the cms. could explain the exceeded capacity error if in a given period call traffic exceeded that threshold.

cms generates maintenance error log entries when this occurs.

1902 11/14/2002 9:30AM 4 1 INFO CALL RECORD ERROR: Call rate exceeded capacity: 757 calls not transmitted

if this is your issue, you may need to do external capturing of call record data, or if you are just doing validation, compare data for specific periods where call record data was complete.

 

[dialtone]

Thanks Shaneymc, interesting note and good to know, however we're not doing anywhere near that volume, and the Error Log gives no indication of any problem.

All indications are that the call_rec data is complete (but it's not, of course - or the aggregates are wrong, who knows at this point).

Next?

 

[BHodgins]

Are you possibly overflowing to other (backup) splits if split 2 does not answer the call within a certain amount of time? If so, the call would certainly show up as an offered in dsplit, but not be tracked as having a DISPOSITION split 2 in call_rec (meaning that the call was actually answered by an agent having skill 2).

Try changing your call_rec query to look for those records where split1, split2, or split3 contains 2. Split1 is the first queue the call hit, Split2 the second, and Split3 the third.

Bill

 

[dialtone]

Thanks Bill, but no - I'm not doing any interflowing, overflowing, outflowing, or inflowing. Calls are queued to one and only one split each.

Next?

Thanks!

 

[BHodgins]

Have you tried changing your call_rec query where split1 or split2 or split3 = 2? You might find the reason why your disposition split = 2.

If memory strikes me correctly, I would think disposition split would only contain 2 if the call was answered. I don't think an abandoned call would show 2 in disposition split because it was not actually answered by an agent in split 2.

 

[netcon1]

Not a CMS expert, however, I would go back to the switch command line and start looking at perhaps muliple VDNs pointing to the same queue. eg VDN or queue switchboard transfers caller to for the queue, VDN or queue number the 800 number points to, or VDN/queue number RONA points back to. or VDN/queue number that staff point the caller to etc.

RONA values in your ACD/hunt groups may outflow calls back to the queue and skew your results in CMS.

In short, it may be correct in CMS but wrong on the switch programming of callflow.

Netcon1

 

[dialtone]

Thanks BHodgins & Netcon:

[li]Bhodgins: The call_rec field "dispsplit" is defined as the split number for the call at the time of the disposition - not the disposition of the call; so, dispsplit is the split of the call, not the disposition. As stated above, we're not multi-queueing calls, so opening up the query to additional splits would not make any sense.

[li]Netcon1: It doesn't matter how many VDNs may be sending calls to a specific split, since I'm not looking at any VDN data - I'm looking only at split data. RONA calls re-queue to the same split they came from, not a VDN, and even so, RONA calls don't result in a new call detail record being created. If they did, that still wouldn't make a difference, because the split data and call_rec data should still agree, since one is derived from the other.

I guess it's time to bite the bullet and shell out the cash.

Thanks to all for your help, this website is fantastic, keep supporting and using it!