Final Disposition/Status

[tgalan]

Hello,

It is possible to have a Final Disposition/Status on Vicidial. After a disposition is selected Ex (sale) this disposition cannot be change to this lead.



Version: 2.12b0.5
SVN Version: 2590
DB Schema Version: 1468
BUILD: 160827-0917

[mflorell]

That is not currently a feature. Adding a feature like that would be quite complex given how many different places within VICIdial the status is changed.

[blackbird2306]

There is no way to dispose a lead with a unchangeable final status. But you can remove this final status from Dial status in all your campaigns so it is not dialable and won't get changed by agents in a normal way. Surely admins and agents with granted access (lead search, call log) can change it later. But it should be possible to export/move these leads to another list, which is restricted.

[tgalan]

That is not currently a feature. Adding a feature like that would be quite complex given how many different places within VICIdial the status is changed.

I was thinking of adding a query to the /agc/vicidial.php to ignore the status change. Just an idea that came to my mind.

[tgalan]

There is no way to dispose a lead with a unchangeable final status. But you can remove this final status from Dial status in all your campaigns so it is not dialable and won't get changed by agents in a normal way. Surely admins and agents with granted access (lead search, call log) can change it later. But it should be possible to export/move these leads to another list, which is restricted.

This avoids the leads to get into the hopper for ratio dialing, but don't stop an agent to do a manual dial on those leads.

[blackbird2306]

There are some ways to achieve this. It would be possible to use Dispo Call URL / No Agent Call URL pointing to a php script, which will look with a delay for previous "FINAL" statuses for this lead in vicidial_log and changes back to your FINAL status. But this would probably not work with some system internal statuses e.g. ADC in manual mode. Another easy way around this would be a simple sql query in crontab.

Put this in your crontab (if your mysql user has a password then use -u and -p option, default is without password):
Change "FINAL" to your desired final status:

Code: Select all

9 3 * * * mysql -D asterisk -e 'UPDATE `vicidial_list` SET status = "FINAL" WHERE `lead_id` IN (SELECT `lead_id` from `vicidial_log` WHERE `status` = "FINAL");'


This query will look nightly at 03:09 AM in vicidial_log and will update the lead status to your FINAL status but only if selected in the past with FINAL status. Depending on your server load and daily call volume it is certainly possible to change cron to start this query more frequently.

I would recommend to use a combination of both possible ways. First use Dispo Call URL / No Agent Call URL and then nightly purge the small percentage of calls which won't be captured by Dispo Call & No Agent.

[VFRDavid]

Three+ questions / thoughts about this:

1) Instead of using the Lead_ID - is it possible to use the Phone_Number - in the event that there are duplicates in the system (of course, there *shouldn't* be - but - just about every system I have worked on has had them)...this way - if ANY record with this phone number has a "FINAL" status - ALL of them will (at least in the same campaign - or however you want to do it).

2) Instead of hard-coding a Status (or list of them) - you could create a Status Category of "FINAL" and if ANY status in that category is selected - it will follow the same code you suggested - this way - if you decide on any changes to what equals a "FINAL" status = no code changes would be required - as long as you attach it to the correct Category.

2a) There may be other criteria involved other than just a "trusty" agent's decision to select a "FINAL" status - call duration, some other field's value, etc - but - I think that this is something that could be really useful...

3) It appears as though the DNC functionality kind of already provides this feature - of course - a FINAL status might not need to be as legally rigid as someone being added to your DNC list - but - if there were a way to create some other types of "suppression" lists - most of the existing DNC code seems that it would provide this functionality (the "DNCC/DNCL" statuses only get set when a lead is "loaded" into the hopper, and subsequently blocked from doing so due to the presence of the same phone number in the DNC list - correct?). Currently, there are two kinds of DNC lists - SYSTEM and Campaign - how difficult would it be to add a third - possibly StatusCategory - to the system?

I don't think you wouldn't need to create / maintain any additional cron jobs this way...any thoughts?

[williamconley]

1) Instead of using the Lead_ID - is it possible to use the Phone_Number - in the event that there are duplicates in the system (of course, there *shouldn't* be - but - just about every system I have worked on has had them)...this way - if ANY record with this phone number has a "FINAL" status - ALL of them will (at least in the same campaign - or however you want to do it).

Certainly. In fact, it may be useful for an option to be available for vendor lead code as well, since that's often used to link multiple numbers together for a single contact. This may require a bit more complex query or some looping in the script running the process.

2) Instead of hard-coding a Status (or list of them) - you could create a Status Category of "FINAL" and if ANY status in that category is selected - it will follow the same code you suggested - this way - if you decide on any changes to what equals a "FINAL" status = no code changes would be required - as long as you attach it to the correct Category.

Very good idea. However: It may be better to use a Status Flag instead, thus reserving the status categories for other use. EG: "Completed" or "Unworkable". If the feature were robust, it would allow choosing either a category or a flag, thus allowing many more users to avoid collision with existing configuration.

2a) There may be other criteria involved other than just a "trusty" agent's decision to select a "FINAL" status - call duration, some other field's value, etc - but - I think that this is something that could be really useful...[/quote]
Now it'll be even more useful for everyone, getting very robust, and becoming a full-fledged "Feature".

3) It appears as though the DNC functionality kind of already provides this feature - of course - a FINAL status might not need to be as legally rigid as someone being added to your DNC list - but - if there were a way to create some other types of "suppression" lists - most of the existing DNC code seems that it would provide this functionality (the "DNCC/DNCL" statuses only get set when a lead is "loaded" into the hopper, and subsequently blocked from doing so due to the presence of the same phone number in the DNC list - correct?). Currently, there are two kinds of DNC lists - SYSTEM and Campaign - how difficult would it be to add a third - possibly StatusCategory - to the system?

Adding it throughout the entire system so this feature is fully integrated would be fairly hefty. The Vicidial Group would be able to provide a quotation, of course. It may be a good idea to create an "outside of Vicidial" version at first that uses external scripts to "fix" the broken statuses nightly (3:09AM?) possibly combined with a dispo_url. After the system is up and running, it would be possibly to merge it into the variouis Vicidial modules in an orderly fashion while the "fixer" scripts continue to run and clean up anything that gets missed nightly.

I don't think you wouldn't need to create / maintain any additional cron jobs this way...any thoughts?

cron jobs are free. A fully-integrated Vicidial Feature is quite the opposite. Using the cron jobs to "catch and kill" any overlooked changes (near the end) and as the primary method of completion (at the start) would be one way to avoid spending a large sum. But if you want the feature fully-integrated without the cron job, having it coded all at once is certainly the way to go.

We did code this type of feature for a client many years ago. It was not fully integrated, just active during generic "dispo" screen, and was based on dispo categories. To get it fully functional it may be useful to have several preference options in the admin.php interface to allow overrides for users, campaigns, lists, and of course the main system method to set the statuses (status, flag, category?) and how to choose them.

[dspaan]

I didn't read all the comments but what you can do is use the dispo move script to move the sales to a different list/campaign that falls outside all inbound CID lookups and manual search scopes.

[williamconley]

I didn't read all the comments but what you can do is use the dispo move script to move the sales to a different list/campaign that falls outside all inbound CID lookups and manual search scopes.

That means the next inbound call will be 'blind' and not linked to the data. Not the necessary outcome. Just sayin' ...

[dspaan]

That's true but at least you won't lose the sale status which is more important.

[williamconley]

Yes you will. You'll have to find that record to have that discussion with that client, or you have NO data during the call. If it was a sale, it may not be by the end of the call otherwise. lol

("What the heck do you mean you can't find my record? I'm gonna need to talk to a manager ..." then comes the chargeback).

[dspaan]

Maybe then use a script that copies the lead to a new list (generates a new lead with the same data) instead of moving it?

You could also use the QC features to keep track of sales but i've never tested if a sale gets removed from the QC queue after the lead changes states because of an inbound call.

[williamconley]

Maybe then use a script that copies the lead to a new list (generates a new lead with the same data) instead of moving it?

that would involve more work than "locking" a dispo. there are a lot of linked tables and it would take a decent amount of work to duplicate all the linked records in all of them.

then the next question: what happens when they are out of sync? one gets updated but the other doesn't? what if the new one gets marked as sale and screws up your stats.

I think locking the dispo is simpler. even if it's not truly "locked" but involves a dispo_url that checks to see if the lead was EVER a sale and changes it back to sale if it was (with notable exceptions such as chargeback). this allows the system to "heal" after each call without altering the vicidial code.

[dspaan]

But this could also have disadvantages because what if you want to do a CBHOLD for a lead that was a SALE or what if your policy is to callback leads that have AFTHRS status?

The thing is that the original poster did not motivate why he needs the SALE status unchanged. Because based on history you can still see the sales in reports. For instance the export calls report will always show your sales.

[williamconley]

that's what scripting is for. if you have an exception, build it into the script. if it's a callback, don't reset it until after the callback (which will invoke another dispo_url to get it resolved).

i've always been opposed to duplicating or modifying something to NOT show true reality, it always creates more problems than it's worth ... in the end.

lol: Oh what a tangled web we weave when first we practice to deceive.

Put in the work to make it reflect reality. Which, in this case, is "after the call has ended, and the disposition from THIS call is recorded in the log, should the lead itself retain the dispo from this call or should it revert to a previous dispo that's more important?"

Obviously having a feature that just locks the dispo would be cool. Especially if the feature had exceptions (like callbacks) built in. But without altering Vicidial code, dispo_url is the best solution i can think of.

And it does say Solution Artist on my business card, so ... lol

[VFRDavid]

I was thinking a bit more about this - not only do I want to not call the occasional duplicate lead/phone number that was "recently" sold - I also want to make sure that if / when the customer calls back via the caller ID they received from us, I would like to redirect those calls to the same department / office they would have reached if they had instead called the toll-free number they were given during their sales calls, or that was included in their confirmation email / letter / etc. We have multiple (about a dozen) offices, all connected to the same system - specifically to avoid duplicate sales / calls - and when the customer calls in to a DID that otherwise would just route back to the same department that the outbound call came from, we have started to have more and more issues with "he stole / blew up my sale" and the like...not to mention the fact that if the rep re-dispositions the sale as "Ansering Machine" or some other dialable status - we start calling it again, annoying someone who just purchased from us.

Anyway - to avoid this - I was thinking of two possibilities...

First - I was thinking of using the FFG (or maybe the Pre-FFG) - creating a special group that, once a sale occurs, and meets certain requirements (maybe length of call, confirmation number filled in, etc) - I could create a stored procedure / cron job that would copy those phone numbers to this FFG - and then once the sale aged enough to be ok for another sale - have the same task also remove it from the FFG (or maybe the first time the number is dialed predictively from the same campaign AFTER the re-sale age is reached).

Second - and less desired, I think - would be to see if there was a way to route calls from recently sold phone numbers back to the rep / office they were sold from. This doesn't stop reps from screwing up the dispositions - but - it at least helps with cross-office "unintentional" poaching...

Is there anything already built into VICI that does something like either of these? The code to move phone numbers for vicidial_list records with SALE Statuses / Status Category with a recent last_local_call_time isn't all that complicated - but - if there is already something in place that does this or something close - I would rather not create / maintain separate code.

I did the stored procedure / cron job thing for the outbound duplicates - flagging the same phone number in other lists as "OLSALE" from whatever status it was - and (of course) ensuring that OLSALE is not included in the campaign's dialable statuses - works well enough - but - I need to extend it from leads in the same campaign to leads in campaigns connected to the same user group, using the same DNC list, DROP group, or some other campaign grouping method - because - it's now missing leads in lists moved to "Archive" (or similar) campaigns - and if / when they are moved back, the duplicates still have their original status - which could be dialable...up until now, this hasn't happened close enough to the sale date to be an issue - but - one day, I'll have to tackle it...

If anyone has any ideas for something internal - I would appreciate their reply...David

If anyone wants to code to the "OLSALE" stored procedure - i'll gladly post it - as long as no one makes fun of my in-elegant coding style...

[williamconley]

Inbound DIDs can be configured to redirect calls based on the outcome of a URL. "Filter URL" and "Filter URL DID Redirect" and the other related settings. This would allow you to catch and redirect those who call back using CIDs your system recognizes as requiring special treatment.