Dropped call % percentage

[glenewhittenberg]

Why does the real-time campaign summary show:

DROPPED PERCENT: 12.39%
DROPPED / ANSWERED: 188 / 1517

While my Outbound Calling Report from the reports page show the following (for the day):

---------- DROPS
Total Outbound DROP Calls: 121 2.29%
Percent of DROP Calls taken out of Answers: 121 / 1435 8.43%
Average Length for DROP Calls in seconds: 6.95
Productivity Rating: 0.42

What is the correct number? What determines a dropped call? Do dispositions have anything to do with this?

Thanks!

[glenewhittenberg]

Ok some strange stuff on this one. With the campaign inactive all night and no agents logged in It now shows when activated dropped calls at 83%. inbound and outbound call reports say nothing has happened in this time. Why did this go up on the real time report?

[glenewhittenberg]

Anyone have anything?

[glenewhittenberg]

Well i discovered something. When i run the outbound call report starting with tomorrows date through the end of the month I have an over 80% dropped call rate. This is true predictive dialing. artificial intelligence if you will in reality I had the worng date in the system when I first started making calls. I think it put them in the database and the real time report must have a " from this date/time forward" query so its grabbing all the future calls. will look into call logs now.

[glenewhittenberg]

Well I did not get any assist on this thread but did enough digging to find a solution. It appears to be the calls that were made when the clock was set incorrectly. I am not sure what table(s) it was that fixed the problem but a removed all future calls from all the log tables in the asterisk database and the problem seems to be gone. Will be back in production in the morning for the real test but It looks good so far. If I don't respond back to this thread then i fixed it and will be moving on to the next issue (Don't have one yet but you know how it goes).

Is this thing on?

Thanks!

[mflorell]

Thanks for posting your solution, I haven't seen that problem before.

[glenewhittenberg]

FYI That fixed the problem. Stats started at zero today and finished with real numbers. Another lesson learned. Verify the date/time on your server before making calls.

[geoff3dmg]

PHP Timezone differences between servers can cause similar havoc.

[williamconley]

We've had that on a couple different scenarios: 1) Bad CMOS battery caused the time to be freaked out (future a couple times) and had all sorts of oddities until we got the battery changed. (2) hackers overloaded a couple client servers and managed to drive the time-sync completely out of whack, making calls about 9 months in the future by the end of the day. Took a while to get all the odd entries out of the logs (and we had to get them all as some of the logs were used in Client Billing!).