Files
agc_1-X/docs/PROCESS_IDEA_CALLBACKS.txt
T
root 9c9de75826 1.1.10 release
git-svn-id: svn://192.168.202.10@1 3d104415-ff17-0410-8863-d5cf3c621b8a
2006-07-07 14:57:59 +00:00

88 lines
3.9 KiB
Plaintext

CALLBACK proces flow 2006-01-05
This will outline the process I have thought through in my head for a call-back
process in VICIDIAL. I have received suggestions for methodologies of how many
people think that call-backs should work and I think I've finally come to a
conclusion of how I may build it into VICIDIAL that incorporates most of these
suggestions.
The Agent Side:
When an Agent dispositions a call as CALLBK, a popup frame will appear that will
allow selecting a date from a calendar window(with option to go forward by month
up to 1 year) and a pull-down list that will show hours(in 30 minute increments
defaulting to current half hour). After the agent selects a day and time, they
must check a box to denote that only they should be able to get this Callback.
If the box is unchecked, anyone will be able to call this lead after it's
callback_time elapses. The lead will be entered as vicidial_list.status CBHOLD
in the system and will not be able to be dialed or selected as a dial status in
the admin screen.
If the agent checks the box that they will be the only one that can callback the
lead and it is time to call that lead again(vicidial.php will check at login and
every 30 minutes to see if there are any agent-specific leads that need to be
called back by that agent) then when the agent is paused they will be able to
click on the "CALLBACK" button on the bottom of the screen and select which lead
that they want to callback. The call will proceed as a normal call and will be
dispositioned as normal. The callback button will probably be able to flash or
gently strobe like the astguiclient.php voicemail button does when callbacks are
available to be called for that logged-in agent.
If the agent does not check that they are the only ones to be able to call that
specific lead back, then it will be updated by the AST_VDhopper.pl script once
it's callback date/time has been reached the status will be changed to CALLBK
and will be available for calling if that status is selected in the dial
statuses for the campaign and if the list is active.
The Admin Side:
In the admin.php web page will be a callback viewer. Admin users will be able to
search and sort by campaign, list, user, status and time-range to see summary
lists of the Callbacks in the vicidial_callbacks table. A new permission field
for altering callback records will be added to vicidial_users and those with the
proper permissions will be able to alter various properties of
vicidial_callbacks records.
The Server Side:
The vicidial_callbacks table will look like this:
CREATE TABLE vicidial_callbacks (
callback_id INT(9) UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
lead_id INT(9) UNSIGNED,
list_id INT(8) UNSIGNED,
campaign_id VARCHAR(8),
status VARCHAR(10),
entry_time DATETIME,
callback_time DATETIME,
modify_date TIMESTAMP,
user VARCHAR(20),
recipient ENUM('USERONLY','ANYONE'),
comments VARCHAR(255),
index (lead_id),
index (status),
index (callback_time)
);
The status field will probably have the following possible values: ACTIVE, LIVE,
ARCHIVE and all old callback entries will be kept for archival purposes,
anthough not viewable by the agent.
The AST_VDhopper.pl script will do a select every minute(before it does it's
hopper filling run) for callbacks that need to be placed back in CALLBK status.
Something like this query:
SELECT lead_id from vicidial_callbacks where callback_time < '2006-01-06
10:02:03' and status='ACTIVE' and recepient = 'ANYONE';
AST_VDhopper.pl will then set these leads to vicidial_list.status of CALLBK and
will change the vicidial_callbacks.status to LIVE. At the time of a hangup of a
callback call, the vicidial.php script will set the vicidial_callbacks.status to
ARCHIVE. The leads that designate the recipient as USERONLY will not be altered
in any way by AST_VDhopper.pl.