vicidial.org

VERSION: 2.8-403a
BUILD: 130510-1350
Install VIcibox Server
Originally Installed with ViciBox.i686-4.0.1.iso
Asterisk 1.4.44-vici

I have exhausted my efforts trying to find this online the last few days; so have come to my last resort.

I am trying to find a way to have the DID description displayed to the agent.

Main reason is we have over 1000 DIDS, and groups of 200+ are pointed to an IVR. The IVR throws it into a few different in-groups (for tracking) then these drop to one main in-group for the floor. So in other words, we can't use in-groups to track the source. Plus we constantly change queue times, holdto, waito, etc throughout the day, so we don't want to be in a position where we have to change 200 in-groups every time we want the drop rate 1 second lower

If this was passed the Description can also have more specific information. Like Florida, CA, NY times, etc. That can be adjusted on the fly when a campaign launches with that number. If this doesn't exist. I think it would be a great feature as it is a very valuable piece of data that I feel is as, if not more, important than displaying the recording ID or list ID to a rep.

I tried to play around with the view settings but that didn't do much other than show the same info differently.

I saw it displays recording ID so I was hoping to put in DID DESCRIPTION as the first recording field, but it doesn't appear that is an allowed variable...?

Lastly my workaround for this, should someone else have a similar issue. Is to make a Webform URL that passes the DID Description. This way they can click the webform link and on the dead page it will show the DID Description in the URL. Obviously this creates a lot of human error and slows them down so would definitely prefer it in front of them when the call connects. Any ideas are welcome.

You should be able to display the did_description as a Script variable in the SCRIPT tab.

Good call. That is even better!

One final issue. It seems that it won't pass the DID description properly if you go from in-group to in-group.

The flow is:
DID
Call Menu
In-group (immediate drop)
Final In-group.

The IVR sorts my callers out then throws them to the in-group they "choose" for easy tracking, exporting and separation. Then they all immediately drop back to one main in-group for the call center.

I can retain the description from the DID > Call Menu > In-group. But Lose it from In-group to in-group. I have tried all variations of Closer, Campaign, Customer, etc. Nothing so far. Also it seems to pass other info like phone number and in-group, but won't do description. I also was unable to make it work with my stated workaround in my first post. I am having the exact same issue. The web form won't pull it. So it appears to have breakage between the two in-groups. I also tried DID > In-group > In-group and same issue.

Anyone able to help on this? Is there a work around?

I have to have the two in-groups since my agents choose their in-groups based on their call assignments that day. If I didn't drop to 10 condensed in-groups there would be hundreds to choose from when they log in. Which obviously couldn't work. I have tried in-group to call menu back to in-group, with no success.

Just bumping this.

Anyone able to come up with something? Would it be possible to write a script that writes the DID Description to the comments or any available field?

Thanks in Advance.

With complex call routing it becomes more difficult to maintain where the call came from, especially if the uniqueid and/or the callid changes. For one client in the past we created a custom script that would look up a similar value, and it was not a simple process.

if you're looking to retain a piece of information that gets lost ... you'll need to find the process that loses it to see if this is a "bug" or a "feature" (ie: is this something that happens on purpose?). Each case has a slightly different path. A bug would be posted to the Vicidial Issue Tracker and could get resolved easily in future releases if the DIFF you provide actually fixes a flaw. If, however, there is a reason it happens that cannot be sidestepped, a new feature may need to be created.

If it's not something you want to beat yourself against, consider upgrading to the latest SVN if you have not done so in the last couple weeks and test again. The pay someone to dig in and find the flaw if the result is not good.

To debug yourself: Decision-making processes can be convinced to log their output to the console (screen -r asterisk, with ctrlA/ctrlD to exit, or asterisk -R, with "exit" to exit) or file (/var/log/astguiclient) by changing the agi logging option on each server in admin->servers.

Happy Hunting!