No more leads in the hopper campaign!!

[eskali]

Hi,

Im getting somes alert messages while trying to make some calls. The alert message say something like "No more leads in the hopper campaign", so i started to monitoring the vicidial_hopper table, and i found that ones you make a call, the next assigned call will be shown in that table with status = READY. But the thing is, its take a time to assign the next call to an agent. Sometimes 5 seconds, 10, 30, or even 45 seconds. So, if you click "Make next call" from the vicidial gui and you got no "next call" assigned in vicidial_hopper table, you get the alert message. BUT if you wait that time (5, 10, 30, 45, etc randomly), you can make the call successfuly.

Im not sure if vicidial works with some internal cron or why the time between the call and the next assignment take so long.
Can anybody give me some tips about it ? I need to know how to change that value (if its possible).

Thanks in advance and im really sorry about my bad english, hope you guys can understand me.

Regards,

Eskali

[mflorell]

What is your campaign's hopper_level set to?

[eskali]

the campaign's hopper level is seted to 1 (i assume is in minutes)

[Op3r]

hopper level is where how many leads you want to dial with the number of active agents. You also have to take considerations on how many agents you have and the callbacks.

Please download the manager's manual at www.eflo.net , It will seriously help with your VICIDIAL experience.

[eskali]

Thank you both for quickly response. I'll read the manager's manual.

About the number of how many agents will operate simultaneously, its 20. Its not that much, at least in the beginning.

What i really can't understand is: Why if i try with a single agent, i get the same issue that testing with more than 5 at the same time. I mean, these level should at least work fine with a single agent (i guess). Like i said, i will read the manual, i hope can i find what i need to make it stable.

Thanks again guys

Regards!

[peacy]

Think of the hopper level as a temporary list where you store the phone numbers that you want to dial (it's a small subset of all of your diallable leads).
This list is topped up every minute, so it has to hold enough items for a 1-minute run of the call centre.

If you're running the call centre with 1 agent and your hopper level is set to 1 (i.e. keep at least 1 and max 2 leads in the hopper), then you can see what's the problem. (When I'm testing with a single agent I usually set the hopper level to 10.)

[eskali]

Yeah, i already figure it out, thanks.

Now i seted up the hopper level to 5 and i tryed to change the auto dial to 1, but i could'nt make it (i will check this out later).
What i would like to know is, what happens with the stored calls (unused (yet) calls stored in the hopper) If the agent takes a long time for each call, then he will be storing a large amount of "next calls" in the hopper table, right ? Its that a problem ?

Another thing that i found: When you make a call, you're executing this action "manDiaLlookCaLL" and in vdc_db_query.php you make a query that should return the uniqueid and channel for the given callerid (MDnextCID) ... the thing is, everything that i have in the vicidial_manager table, matching with this callerid got no uniqueid or channel defined (00000.00,), and the status for that record is "SENT", while in your query filter you're asking by status = UPDATED.
The are few records with status UPDATED, and they are related directly with the agent's softphone, not by the last call inself.

What is the big issue about all this ? ... Well, when i make a call ... it shows me "Waiting for RING" and no matter if the call was rejected or even answered, the seconds still running like nobody answered the call and when it gets 50 seconds it shows an alert message saying something about timeout and stuff.

I debuged all this, and the thing is that the action "manDiaLlookCaLL" in vdc_db_query.php, return "NO", because its not matching the given callerid with a status = UPDATED.

Im not sure if i was that clear, if not, so sorry and forget it ... if yes, this will be interesting to resolv.

Best regards,

Eskali