AutoAltDial Methods

[KDell]

These's a list of quite a few methods to auto alt dial. what do they mean? and is there a way to not dial the primary phone, and only dial the alt phones?

[williamconley]

Nope.

If you want to avoid dialing the phone_number field, but want to dial the alt_number field instead, swap the data before you import into Vicidial and then don't dial the alt_number field.

Perhaps you should explain why you are asking the question ...? (maybe there's a different way to get where you need to be)

[KDell]

We have home numbers and business numbers for many of our leads, we want to be able to switch back and forth. So far we've been just uploading two lists and have a script that procs off of the vendor lead code to remove "uncallable" leads, we were tryng to find a way to eliminate that script and have all leads for a campaign in one list. I guess it is ok to hit the home # then the bus # if there is no contact, but that's two dials per lead during business hours, which means we need to almost double our calls out, our contact rate drops, and phone bills cost a little more, and I have to train everyone to pay attention to another setting, because I wouldn't want us calling businesses at all on Saturday.

[williamconley]

you could keep the two list concept and write a linking app that removes human contacted leads from the OTHER list based on source_id (which would be shared between the two leads for each prospect).

set a dispo URL for the campaign that checks the human answer value of the dispo, if it's human set the status of the OTHER lead to a status that is not dialable (unnecessary to dial, something similar) or merely deletes it or perhaps moves it to an "unnecessary" List that would be inactive or in an inactive campaign.

This would then be a real time change with no input or effort from the agent while allowing the two lists to be in two campaigns dialed at different prospect times and always live (no shuffling or activating or deactivating of lists or modifying of filters during the day).

All that you'd have to do is be sure the source_id matches on all related numbers. (ok: and you'd have to be sure that they did NOT match on unrelated numbers in those campaigns! LOL)

[KDell]

That sounds good. We actually have a script similar for inboud calls that procs off of both vendor lead code and source id, so that shouldn't be too hard to add in. Since we use a seprate app on a webform for updates and sales, it would be pretty simple I think. Am I correct in thinking We could also eliminate a LOT of disposition codes for agents to select that way - just have the app automatically send that dispo over once the agent gets to the sale screen (we only want to update information and pitch someone once), so if a CC goes through = sale, if a CC is not entered = NS, and if a bill is sent = BILLME?

[williamconley]

Actually, that sounds about right. And if NOTHING ever generates, put the lead in a manager pile to listen to the recording and find out what happened (or "discuss" vigorously with the agent why they never hit submit on the Web Form when completing the call with the client).

[KDell]

And yet once again - a reaseon the card says solution artist

[mflorell]

We actually added the MULTI_LEAD option a couple months ago so you could call any combination of phone number types using the auto-alt dialing method. The way it works is:

"Using MULTI_LEAD allows you to use a separate lead for each number on a customer account that all share a common vendor_lead_code, and the type of phone number for each is defined with a label in the Owner field. This option will disable some options on the Modify Campaign screen and show a link to the Multi-Alt Settings page which allows you to set which phone number types, defined by the label of each lead, will be dialed and in what order. This will create a special lead filter and will alter the Rank field of all of the leads inside the lists set to this campaign in order to call them in the order you have specified."

You can use this in conjunction with the deactivate_lead.php script in the Dispo Call URL to ensure you deactivate the other leads after you have a contact with one of the leads assigned to an account.

[williamconley]

I've read that three times. It sounds exact, perfect for this application. But MOSTLY I'm happy I'm not the one who has to set it up for this client, cuz that part does not sound so fun (which is likely the result of the complexity of the requirement). LOL

[KDell]

I've read that three times. It sounds exact, perfect for this application. But MOSTLY I'm happy I'm not the one who has to set it up for this client, cuz that part does not sound so fun (which is likely the result of the complexity of the requirement). LOL

The set up doesn't scare me as much as trying to teach everyone else how to make it function.

[friendlysol]

Where can I set the MULTI_LEAD option ?

Thank you.

[mflorell]

In the Auto-Alt-Dial setting for Campaign Detail screen.

[friendlysol]

Thank you.
I was searching for the label, not the value, that's why I missed it.

Based on the description, I have to create a separate lead for each phone and vendor_lead_code has to be the same.

Do I specify the type of phone in asterisk.vicidial_lists.owner ?
What are the available values for that field?

[mflorell]

yes, the owner field is where you put the phone type, you can put whatever you want in there. One of our clients has up to 12 different ones I believe.

[friendlysol]

After adding the types in the owner field, where would utilize choosing which type of phone I want called?

[mflorell]

The multi-alt-lead setting page of course. The link shows up after you change the auto-alt-dial field to MULTI_LEAD

[friendlysol]

This works great, however, it created an issue.

If we have 5 leads with the same vendor_lead_code ( 5 different numbers ) and upon calling the first one, we no longer want to call that vendor_lead_code - we would have to go to each lead and change the status to DNC ( for example ).

Is there a way to update all entries (same vendor_lead_code ) from vicidial_list by dispositioning only one lead?

[williamconley]

I was under the impression that was automated. If you have a "Human Answer" in one, it should mark the others "called" or something.

[mflorell]

As of SVN/trunk from last week the auto-alt-dial-statuses will be used to determine if the other shared vendor_lead_code leads should be left alone to be called or be marked as INACTV so they won't be dialed.

[friendlysol]

If I'm running ViciBox Redux v.3.1.10 | | VicidialVERSION: 2.4-317a how can I do an svn update so it doesn't break things ? Any links to articles here on the forum ?

Thank you for all the help.

[mflorell]

cd /usr/src/astguiclient/trunk
svn update


READ THE UPGRADE DOC!!!!!!!!!!!!

Follow the steps for upgrading in the UPGRADE doc at the top.

Look at the changes in the UPGRADE doc to see what has changed.

[friendlysol]

The upgrade doc will be there AFTER I run svn update or should I be reading it before I run svn update?

[mflorell]

The UPGRADE doc will be updated after you run the "svn update" command

[friendlysol]

If I'm upgrading from VicidialVERSION: 2.4-317a, the UPGRADE document seems like it doesn't apply.

The highest version the document mentions is an upgrade from 2.2.0 to 2.4. I'm I'm running 2.4 already, it seems I don't need to do anything.

/usr/src/astguiclient/trunk # svn info
Path: .
URL: svn://svn.eflo.net:3690/agc_2-X/trunk
Repository Root: svn://svn.eflo.net:3690
Repository UUID: 3d104415-ff17-0410-8863-d5cf3c621b8a
Revision: 1707
Node Kind: directory
Schedule: normal
Last Changed Author: mattf
Last Changed Rev: 1707
Last Changed Date: 2011-08-02 12:19:49 -0500 (Tue, 02 Aug 2011)

[mflorell]

You are running the latest branch, not the latest version of the code. There have been 11 revisions to the admin.php since the version you are using.

[friendlysol]

Followed
http://www.vicidial.org/VICIDIALforum/v ... vn+upgrade


Now running:
VERSION: 2.4-327a
BUILD: 110801-0833

[friendlysol]

As of SVN/trunk from last week the auto-alt-dial-statuses will be used to determine if the other shared vendor_lead_code leads should be left alone to be called or be marked as INACTV so they won't be dialed.

Now that I'm on the latest version, where do I enable this option ?

[mflorell]

Which specific feature do you want to activate?

How do you want auto-alt-dial to work?

How are you loading leads?

[friendlysol]

I have multi-alt enabled.

I want to STOP calling call leads with the same vendor lead code if one of those leads gets marked with a status of DNC ( for example) .

[mflorell]

As long as DNC is not an Auto-Alt-Dial Status then it will do it automatically.

[friendlysol]

I'm guessing this is now working this way since that change on 8/2/2011.

Should I keep the hopper level low in order not to load leads into the hopper that have the same vendor_lead_code ?

[williamconley]

having them in the hopper should have no effect. that merely makes them available ... but they should not be dialed at the moment of truth if they have changed since loading into the hopper.

the hopper isn't a "we're gonna dial these dangit!" list. it's a smaller version of the vicidial_list to avoid parsing 3,000,000 leads for EVERY call.

[friendlysol]

Ok.... so If I 2 leads ( same vendor_lead_code ), with the status TO and the other with status NEW, campaign is setup with one dial status, NEW.

Will any of the two leads get called?

[mflorell]

Actually, you should keep your hopper to the number of calls you expect to make in 3 minutes. If a lead loads into the hopper and sits there for an hour, the auto-alt-dial check is not going to purge it and it is possible that it could be called.

Although this is probably something I could make an easy change for in MULTI_LEAD alt dialing...

[williamconley]

Egads, it IS a "we're gonna dial these dangit!"

But only for this type of case. I wonder if Friendlysol would sponsor that fix? (probably simpler than any other method, since it's SOOO close to what he needs ...) Dumping any related leads out of the hopper for matching vendor lead code ... or having auto-dial check status again before dialing ...

[mflorell]

It's a 2 minute fix actually, and I've already made it on my dev server, so you should expect it on svn/trunk tonight when I'm done with the current project that I am working on which is also tinkering with the AST_VDauto_dial.pl code.

[friendlysol]

I have no issues sponsoring stuff I need. Just tell me when and where

[mflorell]

already been committed, was working around that area for another client and just added it in. So you may want to svn update tonight.

[friendlysol]

Now I only have these remaining questions:

1. What status do I disposition the lead, in order to STOP that lead from being called but not other leads with the same vendor_lead_code ?

2. What status do I disposition the lead, in order to STOP ALL leads from being called with the same vendor_lead_code ?

Thank you !

[williamconley]

My guess: The status that does not have "Human Answer" will stop that lead from being redialed, the status that DOES have "Human Answer" will stop that lead and the linked leads.