Vicidial modification for answering service

[yeshuawatso]

Hello Matt,

I've been searching up and down for Answering Service software that is open source for use with the * boxes and have come up null. There are systems that have similar function that are open source, but they require manager access for every user, most of which would leave the server open to all kinds of security holes.

Then I started to think, what if I just developed my own? Generate a couple of FastAGI scripts (in PHP for me as I'm horrible at Perl), some ajax/javascript/PHP web fronts, and some fancy config files for queues.

But then I thought about it, and realized that Vicidial and astGUIclient do all the same functions, but just from a different perspective.

Vicidal can be used for blended operations but only on a per campaign basis. astGUIclient does...well I'm not sure for it's actual purpose other than conference bridging and monitoring lines. It seems simple enough, just modify the inbound groups to be active by an assignment of multiplr campaigns. Each campaign representing a different customer, with variable scripts and web forms.

There is some thought to this though. Instead of matching caller ID with customer information in the database, one would have to match the DID number called and match it with the appropriate campaign, script, and web form in real time. And of course, the vicidial dialer page would have to be modified as well to accommodate the change in use.

So, What's you guys opinion on this? What ways do you think Vicidial could be used for the TAS industry?

Thanks,
Yeshua

[williamconley]

I think if you investigated Vicidial 2.0.5 you might find out it can already do everything you are talking about without any changes.

Do you have the manager's manual? Have you looked in-depth into InGroups and DIDs?

[mflorell]

We already have several Answering Service clients that only do inbound. We have added a lot of functionality for inbound applications and of course you can do custom scripts, web forms and agent variables per in-group, and you can configure DIDs right in the web interface.

[yeshuawatso]

Yes I know, but the process of setting up these service is tedious for large scale or rapid growth centers.

From what I can tell, here is just the Admin portion for setting up inbound only answering service, assuming the users have already been created.

Create Campaign-->Set to blended (Needed only one time really)
|
\/
Create Script for each customer
|
\/
Create In-Group for each customer with custom script for greeting, and web form for taking messages. (I haven't found the variable for detecting DID number called but this could be supplemented with another internal reference number as DIDs are bound to the In-Group anyway)
|
\/
Create DID(s) and assign to In-Group-->Give to customer for forwarding
|
\/
Modify each user to allow joining the in-group for the new customer.

The good news is that that's all the work needed once the customer has been created. But when deploying 100-200 customers for vicidial to utilize, the management of in-groups and scripts become annoying, albeit creating job security for Admins.

To simplify things, one could leave the defaults of Vicidial alone but combine some of the steps. For instance, the campaign creation/editing could hold a setting identifying whether this would be Outbound, Inbound, Blended, or Answering type of service. Based on the choice, unnecessary options wouldn't be presented to the admin. You could also combine the In-Group, DID(s), and scripting options with the campaign settings in the event one chooses Answering as the campaign type. This way, there is only one page for modifying an answering service client (these records could also be separated and grouped from the other campaigns). These scripts, In-Groups, and DIDs for Answering campaigns wouldn't appear in their current settings pages nor in other areas of vicidial admin (other than what's listed below) to prevent confusion and/or mistakes with other campaigns and services provided.

Now, as for agents, instead of having to manually choose which In-Groups an agent can have access to or leaving that up to the agent, the User Groups can be used to assign In-Groups to the agents. This way an admin/production manager could plan how many customers will be assigned to each group rather than having to assign the agents manually, maximizing billable minutes. Of course the vicidial page could be modified to accommodate the TAS industry but the Web Form could do the same.

All of these suggestion could be done with little modification to the system and create a systematic approach to system management.

These are just my opinions of what would make the process easier for me and not necessarily easier for the industry as a whole. This is why I'm seeking opinions.

What are your thoughts?

[mflorell]

What you suggest sounds good and could certainly be done, but it will take a bit of work to combine all of those steps into a common interface. Is this something you are looking ot do yourself or would you be able to sponsor this development?

[williamconley]

Somewhat like how QuickBooks has various deployment choices (during install you can choose "Construction Company" or "Web Design Company" or others), there could be an "Answering Service" deployment or "Client Setup" that would script all the necessary steps.

Next version, a scripting interface that would allow multiple steps to be executed automatically, based on a preference context of some sort, that would allow the creation of "custom business types" to allow for any type of business installation.

This would be a fine first step towards such development. And if you, indeed, have 100-200 clients to set up and don't want to pay your "Admin" to do it all those times, it would be an excellent investment to have an automated setup system built just for your business model.

[yeshuawatso]

Sort of like Quickbooks. Quickbooks is a front end to make accounting records management easier. Instead of making entries to your journal and posting them to the ledger, you input a bill, write a check, or generate an invoice. Even though in reality you are Posting a credit to Accounts Payable, Crediting Cash, and debiting Accounts Receivables respectively. The "deployment choices" are merely different Chart of Accounts for various industries so you don't have to generate them yourself. If all this accounting stuff is Greek to you, then Quickbooks has done their job by making a non-accountant, an accountant.

If Vicidial were to mimic this functionality and become more easier to use, then Vicidial developers would have to take a survey and generate some statistical analysis to discover how Vicidial users are using Vicidial. This is easier said than done, as I'm sure most experience call centers have ran telephone survey campaigns (which is actually a feature of vicidial).

Right now, the system is confusing at first and requires a lot of work to get it going. VicidialNOW has taken some sting out of this process, but a systematic approach would require immense resources. One of the ideas I've seen before on other OpenSource projects, is to conduct an online poll for the most requested features that accepts donations from the the project's users to support the most popular feature/fix. This would allow the Vicidial devs to support their work, allow the market to define what features are worth paying for support, and spreads the sponsorship load across multiple users. Sure there will always be freeloaders, but it would allow even the smallest user to contribute something back to the project, regardless of how small the donation.

From my experience with a wide array of Open Source projects, personal user contributions are rarely included in the final released code unless it is a feature that the devs would want and didn't have time to code it themselves. Most projects are simply becoming modular in function and features and the devs simply work on core functions and APIs. In order for this to happen to Vicidial, a severe rewrite of the code is necessary. And without a massive amount of support from users to develop code and scripts, its too much work to ask the devs to change everything and receive nothing in return other than gratification posts on a forum. Sponsored code contributions are fine, but the extra features are usually for that sponsor and may not benefit the masses; especially if the sponsor is a niche call center.

The changes that I proposed earlier are quite doable with just the modification of the admin.php script. The functions would still be the same, but the content presented would be different. I've already started on changing this code now and plan to submit my changes to the SVN/CVS once completed. I ran into a little problem though so now I'm going to post my errors in the Support section (damn Zaptel timer).

Once I finish the changes I'll use this same thread to indicate any additional features or changes in the process.

BTW, I'm testing a statistical analysis script for interaction with Vicidial and other various Open Source projects. The scripts run independent of Vicidial but offer customers a better insight of their campaign in near real time. If you're interested in testing the scripts out for your call center send me a private message. I don't plan on selling the software but I am looking for feedback about it. I can also give you a demonstration if you don't want to install anything on your servers.