Question: CallBK

[VIIseven]

Why is that even if we set the time and date for the CALLBK the call back will return after a few minutes after setting up a specific time. Sometimes after disposing it, it return right away to anther agent. And the call back are all active(Campaign/User). Anyone who can help me..?

[mflorell]

admin.php version and build?

How did you install your system?

Are the scheduled callbacks settings enabled for both the users and campaigns?

What are your dial statuses in the campaign in question?

[VIIseven]

server, campaign, phone are the have the same time and for the dial status its only A, B, AFAX, N

[williamconley]

admin.php version and build?

How did you install your system?

Are the scheduled callbacks settings enabled for both the users and campaigns?

keep going! we need answers to all of these, not just the last one! (if MATT asks you something answer ALL of it even if you ignore my stuff!!)

since we're here:

when you post, please post your entire configuration including (but not limited to) your installation method and OS with kernel or version, vicidial version and build, asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box.

Similar to This:
Vicibox X.X from .iso | Vicidial X.X.X Build XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation

this IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)

[ruben23]

VERSION: 2.4-297
BUILD: 110124-1134
© 2011 ViciDial Group
asterisk-1.4.39.1-vici
Dahdi-Current
vtigercrm-5.1.0
Ubuntu-Server-10.04.1 LTS
Single Server

Hi guys i have the same issue "VIIseven" Agent callbacks return after a few minutes even it is set to one days and week, any work around on this please? suggestion

- the callback is not added on the Dial Satus, Agent only call back and schedule calls back s are set also.

[williamconley]

How did you install your system?

keep going! we need answers to all of these ...(if MATT asks you something answer ALL of it even if you ignore my stuff!!)

if you don't list your installation method (or if your install is "scratch") we have to assume it's a flaw in your installation method.

can you reproduce your error in a vicibox installation?

can you trace the path of the call that should NOT have been made? (ie: logs from each stage of the call ... post them)

[ruben23]

@williamconley

Yes its a single server setup scratch install..

[williamconley]

to get it solved then ...

can you reproduce your error in a vicibox installation?

or

can you trace the path of the call that should NOT have been made? (ie: logs from each stage of the call ... post them)

also: you are working with a fairly old version ... try updating to the latest for your branch at least

[ruben23]

@williamconley

Im using the latest SVN trunk version:

VERSION: 2.4-297
BUILD: 110124-1134

yes i will try to trace but i dont have any box for vicibox to reproduce the error.

Thanks for the comments.

[williamconley]

use a VMWare install for testing. it's free.

but start with tracing the last call you believe should not have happened. see if you can find it in the logs and verify that the "situation" should have called for it not to happen. then we can work on finding out why it DID happen.

so far when i've done this, i've found that actually the call SHOULD have happened, because (for instance) the client called back, became an inbound call .. and was dispositioned as "answering machine"! by an ID10T agent (who later complained because the client was called back by another agent and the sale was blown). Of course, Answering machine is a "callable" status ... so ... his system now has a "do not call a lead if it was EVER a sale" method resulting from MOVING all sales to a completely different campaign. (which never calls out except by manual dial from managers tracking cancels).

[ruben23]

@williamconley

Thanks ill do as what you advice, actualyl as present agents are complaining that callbacks are coming early- i guess i need to trace and investigate if they did properly done the process of setting up callback.

[williamconley]

concept: forget "the agents" and "the callbacks" ...

focus on ONE. trace ONE (the last one?) complaint through its paces and find out if/where it went wrong. when it was last dialed, should it have been (according to the rules in the system ...). or when it "appeared" in the callbacks, should it have.

take NOTHING for granted. look at the screen yourself. (technicians take notice from users, but always verify the complaint independently before beginning the troubleshooting, right?)

log files and log tables will give status changes ... most of the time it turns into a training seminar instead of a bug fix IF you are using the latest code.