vicidial.org

On one of our systems we noticed there is a big discrepancy between received and answered inbound calls even though there were enough available agents.

After some research we found:

1.A call arrives at a DID
2.The DID routes to an ingroup
3.The ingroup plays a welcome message
4.The caller hangs up during the welcome message

In case of the scenario above when you check the inbound DID report you will see 1 call has been added but when you check the inbound (ingroup) report you will see NO call came into that ingroup.

Problem: Now when a callcenter manager looks at the reports they will see a discrepancy between the two reports without a clear explanation. I believe the same thing happens when callers abandon during their time in the callmenu/IVR.

Technichally i would say:
When a DID routes to an ingroup and caller abandons during the welcome message this should count as a DROP.
When a DID routes to a callmenu and caller abandons in the menu this also is a DROP but to which ingroup do you attribute this DROP?

From a management/agent perspective i would way:

When a caller abandons during a welcome message or callmenu we can't be blamed for not answering the call so why count it as a DROP?

Conclusion:
I think it is important to keep track of these pre-queue drops so you can take action (for instance set the welcome message to IF_WAIT_ONLY) to improve these abandons. Perhaps it would be an idea to create a new system dispo status for this and a system ingroup which can't be deleted?

This subject has been brought up several times over the years, and the general consensus is that until the system attempts to find an agent to send the call to, it is not "in-queue", and it absolutely cannot be treated as a "DROP" in any way. This is how QueueMetrics handles it as well.

I have no problem creating some kind of additional logging to somehow catch when a call hangs up while the welcome message is playing(or while being asked pre-queue about a post-call survey), but it must exist outside of the dropped-call category(maybe a status of 'PQHU'). We can then add this as an additional statistic to display in the inbound reports.

As for how to track it, since the call might not have a vicidial_auto_calls entry until after the welcome-message(and/or post-call-survey-question) finishes, we would have to add some kind of record somewhere that would denote that the call was sent to an in-group, but had not made it to queue or been kicked out for some other reason(after-hours, max-calls, no-agent-no-queue, etc...), and that record could be used by the FastAGI_log.pl script when it detects a channel hangup to log it properly.

As for how much work all of this would be, the bulk of the programming of it would be fairly simple, probably only 6 hours, but the testing and fine-tuning would probably be double that, trying to cover every scenario imaginable and make sure it won't mess up any other logging going on, so probably an additional 12 hours for a total project time of 18 dev hours.

Hi Matt, i understand now thanks. I think it would be really useful to log these kinds of calls. What we see is that this quite a large amount of calls, of course it depends on the type of project. Another possible way to go would be to create a DID<>Ingroup comparison report which simply looks at the calls that came in through a selected group of DID's and compares that to the calls logged for ingroups and shows the difference.