We run a mail order call center on FreePBX, and even with the paid reporting module, have always found the reporting to be mostly useless. Even simple things like getting the total number of calls into a particular DID are impossible.
We actually hand logged the calls (on paper) for two separate days to verify the reports. Our hand written logs didn’t even come close the totals reported by FreePBX. In some cases, the reports showed 2 1/2 times the actual number of calls.
In the end, we set up MySQL to allow connections from two PCs on our network, and we wrote some code to generate our own reports. They now report realistic call statistics.
Over all, we are very happy with FreePBX and the great support from Sangoma. The only real disappointment has been with call reporting. We had a Mitel system before moving to FreePBX, and really do appreciate the flexibility and freedom we have with an open project like FreePBX. The one thing that Mitel really had figured out however, was reporting for call centers. The only negative feedback we got from management/ownership after the migration to FreePBX was call reporting. The comments from management were along the lines of “they really don’t understand call center reporting, do they?”
That’s why we had to build an internal solution. I wish I were a better PHP/Web developer, I would like to be able to contribute back to the project. Our solution is very specific to our needs, and I also would swear that there is duck-tape involved somewhere!
I agree that the CDR reports are difficult to read if not almost useless sometimes. We made some changes yesterday so I wanted to look at the CDR if anything jumps out i.e. disconnected calls, lower volume, etc…
I search for 11/19 and get "Call Detail Record - Search Returned 100 Calls"
but on closer inspection it’s NOT 100 calls. The screen is full of CEL events for the same call.
The data below is 1 single call. How is this usefull?
I am not saying CEL is not useful. It is. Clicking on 1479593049.795 opens the CEL window which is quite informative. It’s just very confusing in the CDR report to have 10 lines for one single call.
2016-11-19 17:05:26 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:05
2016-11-19 17:05:21 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:04
2016-11-19 17:05:20 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:01
2016-11-19 17:05:18 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:02
2016-11-19 17:05:14 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:03
2016-11-19 17:05:11 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:02
2016-11-19 17:05:09 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:01
2016-11-19 17:05:05 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:04
2016-11-19 17:05:03 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:01
2016-11-19 17:05:01 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:01
2016-11-19 17:04:59 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:02
2016-11-19 17:04:56 1479593049.795 1514yyyyyyy 514xxxxxxx Dial 514xxxxxxx NO ANSWER 00:02
I am using the lastest Distro and nothing is really broken but you are partially right. Thanks for making me look.
I am feeding the call into a2billing and the user was dialing an invalid number string which made a2billing try different trunks. Each time it tried a new trunk it generates a new CDR record and there seems to be a bug in that a2billing doesn’t stop after the 2 defined failovers but continues looping from trunk A -> B -> C -> A -> B -> C etc… (It’s supposed to stop at C)
Each time it does that a CDR record is generated which is wrong. In my case it’s a bit extreme and I will fix it but the CDR module should know it’s the same call and generate only 1 single record with the trunk failover mess showing in the CEL.
I could be wrong but I always thought it was Asterisk itself that was writing in the CDR table and not the CDR module which only queries that table…
If so, the multiple entries you see (caused by a2billing) are actually in the table and I guess the best the CDR report could do is offer a way to remove duplicate System UniqueID.
Should it do that by default, I am not so sure… For someone like me which doesn’t use a2billing I would like to know if there were such a weird thing going on my system…
I think your best bet would be to contact the a2billing people to see if there is anything that can be done on that side and if not maybe you could do a feature request to the FreePBX people to have a checkbox that remove duplicate System UniqueID…
I think our problems with multiple entries for a single call centered around how the calls were handled in the queues. Sometimes our call center staff will get presented with a call, but are busy with something like web chat for example, and let the call “roll over” to the next agent. Each time the call goes back to the queue, ti generates another CDR record.
The paid queue reporting module doesn’t know how to handle this either. We have always had inaccurate data in the reports.
Why would a call go back into queue. Are you saying you are failing over a timeout back to the queue? If so then that is a new call into the queue and not sure why would would do that. Just set your wait time to be higher.
In our case (with a2billing) it’s the same identical System UniqueID.
It’s caused by a2billing going back to the dialtone after a failed call attempt and the user can enter the destination number again. That seems to be considered a new call but with the same identical System UniqueID.
In my opinion the CDR module should not print duplicate entries (no matter the reason) as there are a million ways to use FreePBX. I am not a programmer but the CDR query could filter for unique System ID when generating the report.
Unfortunately the old CDR especially if wrapped up with a2billing was never very good, that’s why CEL, but a decent very specific sql query will always get what you want (think order by X LIMIT 1) , just not from the GUI.
So this isn’t only my problem and others faced too.
I should add two points:
In some cases, I see the log of calls in console, but I can’t find any CDR for that. It isn’t for specific case (I couldn’t find a specific case for that yet)
In some cases when calls are transferred, I see two calls with different caller-id for that. So it’s very confusing.
So we decide to make a CDR with using the AMI and based on events.