I've been looking at the various callback and voicemail queuing applications out there, and I'm convinced that there should be a better way to pull off a caller requested call back from queue. I'm not worried about queuing a voice mail, I simply want the caller to have an option to get a return call, and it seems to me that the Outbound Subsystem is well positioned to pull this off. I can dynamically write XML documents and prompts to the database, so it seems like there should be a way write a single row to an ongoing campaign to add a call to it or to somehow automatically re-import contacts to an existing campaign. Has anybody faced the outbound problem in this way, or is there something that prevents pulling this off that I don't know about? Thanks for your thoughts on this.
There is a sample script for this already. It is in the script repository via Cisco site I have modified it and have it working. search for script_repository_701.zip. It is called BaseLineMessageCallback.aef. I have attached it here but if you want. It includes docuementation etc. This is all available on the cisco site, it is just a bear to actually locate it. Here is the link from the uccx70 scripts vol1 pdf. Sometimes I think it is someones job to bury good information in PDF documents. ;-)
Thanks for the reply. I am familiar w/ the call back scripts, and understand that they do pose a solution; however, I am looking for a different solution which utilizes the Outbound Subsystem. The Outbound Subystem has a number of advantages, because the contact is actually written to a database and will only be active during business hours and can be marked w/ the proper handling. One problem I see in the call back scripts in the repository is that there is no mechanism to report upon successful contact. If a call were to queue for call back late in the day before a holiday weekend, it would be lost once the max steps are hit in the script. If the server were to go down or have a problem, the contact would be lost. I understand that there are ways to kluge together some kind of accounting on calls (and even preserve contact information in an email) and rectify that what was called back and what was supposed to be called back add up, but this would be re-inventing the wheel.
I will say that it looks like those scripts have improved since the last version I have seen, but I think there are some underlying problems. All of the shortcomings could be addressed with the Outbound Subsystem. That is why I am curious if anybody has dealt w/ it in this way.
Have you got any further with this? I'm trying to do something similar.
I've tried manually inserting entries into the DialingList table, however this doesn't work for me. When I do this, the outbound subsystem seems to stop working. I had to delete the manually inserted entries and restart the outbound subsystem to get things back up and running.
No, I think I'm about 90% of the way there, but I have not tested yet. It sounds like I could run into the same problem as you. Did the Outbound system go into partial service, or just stop working? I have figured out that there are some other tables in the mix, particularly, ConfigSeed which provides a couple of the keys: DialingList (recordID in the dialingList table) and NextDialingListID (dialingListID in the dialingList table) both should increment and match the IDs provided in your dialingList table. There appear to be some other presents hiding in some stored procedures that I'm trying to figure out right now, so I don't trash the DB. It's definitely worth having a nice snapshot backup in place. I'm still convinced that the scripting portion of this is pretty trivial, just a few DB queries and writes, but I'm really hoping someone from TAC chimes in to at least tell me what I'm risking breaking due to table dependencies that I haven't yet found.
OK, I got it, but I went way in over my head to get there. I'm not going to share my scripts on this, as I'd rather you were the architect of your own DB's demise. Be sure you have good backups before you do this. I'm sure TAC will chime in that this is a very bad idea, and I'm positively sure it will be hosed in the 8.0 upgrade...
A couple of the fields pull from and in turn increment in the ConfigSeed table. There are a couple of stored procedures (and a bunch of sub-procedures) that do a lot of the intelligence and validation for you. Adding records using the stored procedures seem to take care of some backend stuff that breaks when you do it manually. Note that the only way to execute a stored procedure in a script, even when it updates the database, is through a read step.
Here is a rough sketch of the steps:
1. Create a new system DSN to the db_CRA and connect to it through the DB subsystem
2. Config up your Outbound subsystem and setup your Call Back campaign, skills, etc
3. Import a contact and go look at the DialingList table to get your campaignID
4. Make sure your Outbound campaign works properly and previews the call to your agent
5. You'll create a script to gather the number from your caller and validate it however you want (look for other posts from me, somebody shared some nice Java w/ me to pull this off recently)
6. Create your callback script
a. First query the ConfigSeed table to find out the NextDialingListID (actually tells you the last contact)
b. Increment this NextDialingListID by one, you'll use it as the dialingListID in the DialingList table and write back the incremented value to your ConfigSeed
c. Pull the current time and date and put it into the same format you see in your DialingList table
d. Put in a read step and execute the following SQL, you will of course fill in values w/ variables, where I have done it manually to execute the SQL: EXEC wrapperCreateDialingList '', '12', '1', '5', '', '', 'James', 'Bond', '2085551212', '', '', '102', '0', '102', '0', '102', '0', '', '', '1', '', '', '', '', '', '', '', '', '', '1' (You can look at the stored procedure to get an understanding of these variables, I'll paste them w/ my comments below.)
e. Put in a read step and execute the updateConfigSeed wrapper to update the NextDialingListID to your updated value (UPDATE ConfigSeed ID = $dialingListID WHERE tableName = 'NextDialingListID')
7. Outbound call should preview to your agent, assuming your campaign is enabled and your stars are aligned
Here is the first part of the main stored procedure and my comments on the variables to pass.
CREATE PROC wrapperCreateDialingList(
@recordID int OUT, /*Automatically filled from ConfigSeed w/ Wrapper call below */
@dialingListID int , /*????You have to increment this from the last record somehow, don't see how it's done in SQL, can easily do w/ a query of last record and increment, but want to know how this is done*/
@profileID int , /* 1 */
@campaignID int , /* 5 for my test, but this will statically map to your campaign of choice, create your campaign, add a contact, then look at the table to get this value*/
@createDateTime datetime OUT, /* Automatically filled in procedure */
@accountNumber nvarchar (25) , /* null */
@firstName nvarchar (50) , /* SEND IT IN A VAR*/
@lastName nvarchar (50) , /* SEND IT IN A VAR*/
@phone01 varchar (28) , /* SEND IT IN A VAR */
@phone02 varchar (28) , /* null */
@phone03 varchar (28) , /* null */
@gmtZonePhone01 smallint , /* 102 for MST */
@dstPhone01 bit , /* 0 = dst*/
@gmtZonePhone02 smallint , /* 102 for MST*/
@dstPhone02 bit , /* 0 = dst*/
@gmtZonePhone03 smallint , /* 102 for MST*/
@dstPhone03 bit , /* 0 = dst*/
@callbackNumber varchar (28) , /* null */
@callbackDateTime datetime , /*manually populate this w/ current date/time */
@callStatus smallint , /* 1 Always */
@callResult smallint , /* null */
@callResult01 smallint , /* null */
@callResult02 smallint , /* null */
@callResult03 smallint , /* null */
@lastNumberDialed smallint , /* null */
@callsMadeToPhone01 smallint , /* null */
@callsMadeToPhone02 smallint , /* null */
@callsMadeToPhone03 smallint , /* null */
@privateData image , /* null */
@numcds int /*Always 1 on single server environ. I think this is in place for DB replication in a cluster?*/
Good luck. And don't blame me if your server starts smoking.
Please rate this if it helps you.
Almost there, but not quite. I'm getting a SQL or Java error when I run my read step. On the Java (Java Null Pointer I think) error the record actually does update to the table, but my script bombs. The dialing list gets activated w/ the new contact.
EXEC wrapperCreateDialingList '', $dialingListID , '1', $campaignID , '', '', $firstName , $lastName , $phone01 , '', '', $gmtZonePhone01 , '0', $gmtZonePhone01 , '0', $gmtZonePhone01 , '0', '', $callbackDateTime , $callStatus , '', '', '', '', '', '', '', '', '', '1'
This works. Thanks to other Netpros and the archives.
DECLARE @return_status int
EXECUTE @return_status = wrapperCreateDialingList '', $dialingListID , '1', $campaignID , '', '', $firstName , $lastName , $phone01 , '', '', $gmtZonePhone01 , '0', $gmtZonePhone01 , '0', $gmtZonePhone01 , '0', '', $callbackDateTime , $callStatus , '', '', '', '', '', '', '', '', '', '1'; SELECT 'Return_Status' = @return_status
Outbound Call during work, I encounter a difficulty: When we have a * txt file containing the customer's phone number to call, we must update the file UCCX up manually, so will be very slow gian.Khong know Cisco has no solution for this is done automatically or not.? I am the Contact Center Express 7.0 version.
Have you managed to create Automated Callback Utilizing Outbond subsystem? I'm trying to do same thing but without sucesss. Could you share your Script?
Yep, glad to, but will talk w/ you off the forums, as I don't think this is advisable for the general public, due to above-mentioned reasons.
The idea I outlined above worked, but it didn't work well. Spanlink is now selling a custom application which will perform automated call back much like UCCE. Their website has details. I've seen the pricing, and it appears reasonable.
I am trying to create a system DNS but I do not have idea of how to do it in a linux server, do you know how to so it, can you help me please ?