vicidial.org

Our client would like to have the AC CID feature to work per list instead of for the whole campaign. We could do something like this: the Description field in the AC CID could hold the list ID the CID should apply to. So let's say that there are 100 records on the AC CID page. The Description field of 10 out of 100 fields is set to 1001 where 1001 is one of the lists in the campaign. Any time that this campaign places calls for list id 1001, it should use the caller id's where the description is set to 1001 in the same way that the campaign uses the AC CID function. Same way, if there are other records where Description is set to another list id, these caller IDs should be used for all calls placed to leads in the corresponding list id. And so on.

Please PM with bids.

We have quoted this before, it would have an AC-CID link for each list where they could be defined. We wouldn't recommend doing it the way you describe because lists can easily be changed to different campaigns, so we wouldn't want the AC-CID for a list to be tied to a campaign. Of course, that's just the admin web side of things, the dialing side is much more complex to program. The quote was 20 hours, or $4000 USD.

@mflorell
So you quoted this to someone else before but the client did not forward with it?

VoIPEssential wrote:@mflorell
So you quoted this to someone else before but the client did not forward with it?

At this level of decisionmaking, it's often easier to upload the CID for each lead specifically, which is already a feature. You can upload the CID with the leads as you load them, or alter them directly in the DB after they've been loaded (as often as you like) with a fairly simple mysql query. That sql query can be attached toa web page so an admin/T.O. or whoever can manage them at will based on however your web designer builds the page ... or you can just tell your IT guy what numbers to set for which area codes in which lists or campaigns or both.

So I'd doubt anyone would pay for this feature to be created, honestly, since it would be fixing only a tiny subset of the overall picture and not be particularly cost-effective.

I could see someone paying to have a custom CID feature added to the admin-utilities, but even that will still be fairly limited in usefulness compared to writing your own for whatever you need. It's just a mysql query with a limitation on list_id and area code.

Well the client requires the use of multiple caller id's so that they get better a connectivity ratio, basically the same advantages of the AC-CID feature. So single cid per lead won't work for them. I appreciate the inputs though.

It's not "single caller id per lead", that's just how you get them in the DB. You can put the same CID on all of them, or put the same CID on all the leads in any pattern you want. Up to and including all the calls in one area code on each list getting the same CID (which is the feature you requested).

No code changes, no cost, you use the feature to pull the CID from the special field (in the Vicidial Manager's Manual, look it up) and you're done. The fact that the CID is the same for all numbers with the same area code in a specific list is merely a decision you make before you upload the leads.

Optionally, you can run a mysql query to change them after upload. Pretty simple to write. I could write a SQL query to execute at the CLI for each area code/list in about 2 minutes (with testing). 30 seconds without testing.

I am aware of the feature you are talking about but in that feature, each lead will have only one caller id no matter how many times it is called. In AC-CID, you can define as many caller id's for a single areacode as you like. This is basically what we are trying to achieve per list. I hope this clarifies our requirement.

The SQL script idea is not bad but I will keep it as a last option.

In that case, you would put each list in its own campaign to piggyback the feature. Or have someone write a custom asterisk agi script to manage the CIDs during execution of the calls.

Yes, we quoted it for an existing client and they chose not to move forward with the project.