Taking bids for agent agc integration in PHP collect systtem

[mstopkey]

Greetings all!
We are currently taking bids for integration of the agent functions into our PHP/MySQL based debt collection system. This new debt collection system is currently being built.
Functionality requirements are as follows.
All the development is going to be in PHP using the same database of the Debt Collector System.
RQMT001-Dialer Interface for Debt Collector System
The Dialer Interface will be a control to manage all the dialer operations from the Debt Collector
System to the VCDial and Asterisk telephone plant. This interface is going to be implemented and
used in the “CWS Debtor” option of the Debt Collector System.
The functions needed on this control are:
 Call: Make a call to the phone number selected in the web page or entered by the user.
Agent must be paused on dialer and select MD for manual dial from existing pause codes
on dialer.
 Auto dialing: will send a connected call to available agent that is logged into dialer and not
in pause or disposition condition.

 Hang up: Hang up the active call.
 Pause: Prevents dialer from sending any connected calls to agent. This is not for active,
connected calls. If campaign is set to force selection of pause code when agent clicks
pause, then display the list of pause codes for the campaign to select from.
 Resume: is to un-pause agent to be able to receive connected calls from the dialer. This is
not to resume an active, connected call.
 Dial Next: Get the next automatic call and dial, only if, agent is logged into a campaign that
is set up for auto dial next number that is loaded into an active dialer list.
 Call Park: allows call to be parked and any agent that is allowed by dialer settings can grab
that parked call. Parked calls are viewed in agent dialer screen.
 Transfer: This is accomplished by selecting the agent from logged in agent list and it sends
the call to queue in dialer for agent-direct. It waits until that agent is available and has
priority over other calls for the receiving agent according to dialer settings. Also can blind
transfer or 3-wau transfer (conference) to outside 3rd party phone number.
 Hot keys in existing ViciDial agent app must also work in dialer control.
Important. Screen popup the dialed debt account/debtor in the collection systems CWS form when
the dialer passes a call to an agent. This will happen when agent is waiting for call and dialer is
auto dialing.
Talk timer alert. ViCiDial can popup admin configurable alert to agent. Bring in that alert URL.
The Debt Collector System is going to use this interface to login into the VCDial system, so the user
would be able to use the Dialer Interface Control as part of the Debt Collector System.
This interface is going to be a web service in XML format that Debt Collector System is going to
consume at the login page.
The fields used in this interface are going to be:
 Login phone
 Phone password
 User login
 User Password login
 Campaign – Dialer login must check user allowed campaigns list in one of the dialer’s
tables and only allow those list of campaigns.
Note: This interface does not include the administration of the campaign, phone’s login and user
login, this is controlled by existing ViCiDial admin interface.
The Dialer Control is going to have an interface in the data base with the tables related to the
phones and call results in the Debt Collector System scheme, all the dialer database tables are
going to be part of the same schema as the Debt Collector System database.
The results that are going to be saved in the data base are:
 Call log: ViCiDial has two tables to grab this information (vicidial_list and vicidial_log). The
daily loaded leads in table vicidial_list is cleared out nightly and is the only location where
the debtaccountid (field is vendor_lead_code) can be matched to the call records in the
table vicidial_log. So we need a process to assure that all the call records are logged to the
collection table of debtor_phones before the nightly routine of dumping the list contents
and repopulating lists.
 Debtor phones
o Last answer
o Times dialed
o Last Call Stat
o Last call date time
o Call status must be matched to dialers DNC list, update the phone number record
field of ‘restricted’ to ‘1’ for yes and include status.

UPDATE: Well, while we are it, let's go ahead and throw in modification to add chanspy 'whisper' in the reatime report screen.

The dialer's database tables will be consumed into the debt collection system's database. (This is already done)

Contact Mark Stopkey @ mstopkey@tamcu.com

[williamconley]

Is the debt collection system itself going to be open source (which would make this interface extremely useful for the open source community and possibly share costs ...)?

[mstopkey]

Hello William,
The collection system will be a commercial system that would be fully compatible with ViciDial so that any one currently using ViciDial would have nice interface and communication between the two. Anyone not using ViciDial would be counseled on ViciDial's many benefits and if they wish, 'Be welcomed to the party!' But as stated, the collection system will be commercial although 'very' reasonably priced.
As for costs, we are absorbing all costs.
Of course the chanspy 'whipser' addition would be shared with the community. So in other words, we are footing the bill on this feature.

[williamconley]

Have you tested this

http://www.compasscollections.com/

[mstopkey]

No I have not, but, what we are almost done building is available in multiple languages, and is much more than just a debt collection system. (Can't say what else at this point) Is top secret, first to market.

[williamconley]

We're always interested, of course. We've found that if the base product is open source, shared costing allows for much better bang for the buck for individual call centers. Doesn't mean we don't work with proprietary (do it all the time in fact), we just love open source solutions, and to date Compass is the only one we've found for collections (and we don't even know if anyone uses it!).

[mstopkey]

I am very much pro-open source myself, but one of our products has to pay the bills! Therefore, taking bids.

[williamconley]

Understood. Unfortunately, it would take a couple hours at least to generate an accurate bid. Mostly, the bid itself would create the framework that the developer would be working with to integrate (which is why it would take so long), in addition to validating all the necessary api functions ... and then estimating the creation of new functions (if necessary) along with implementation of the existing functions which means it would need to be a paid bid. And we don't do "toss out a huge number and see if they're gullible" (which is actually a very popular tactic, we only do so upon direct demand, LOL), nor do we do "toss out a tiny number because we're desperate and incompetent" (LOL).

I think we're going to adopt the Compass Collections Open Source Collections software and update it to the latest PHP and see if it helps anyone. There are a lot of collections people on this site, and someone may actually benefit. It seems to install well as long as the server is over 7 years old! (and never been updated! LOL)

[mstopkey]

Might want to reconsider that 'Compass' solution. We installed it and checked it out and it is 'Very' limited function.
Ok, so how much for the bid? We are going to have someone do this.

[williamconley]

Very limited beats "no such thing". Gotta start somewhere! LOL (Since we can't start with the proprietary one you have ... right?)

If you read my prior post, you'll see my comments regarding a bid. Still very willing to give one based on those terms.