Part III d: IVR / Question Box
IVR MODULE
requirements:
Microsoft Access 2000 (tm)
The IVR Module purchase will allow the Voice Service Program to access and speak database files that have been registered with ODBC and BDECFG (Borland Database Engine Configuration). For general application overview see IVR Box Overview below. For installation instructions continue here:
Database files MUST be registered with both ODBC and BDECFG in order for the Voice Service Bureau program to access them.
Note: All database fields MUST be of the type 'text'. The Borland Database Engine we use cannot read any other type of field. If you have field types of 'date', time, number, etc., as many databases will, you will need to change the field types to 'text'. If you are planning on using a database that another program will continue to write to, you will need to amend that program to redundantly enter the information into 'text' type fields. When choosing the fields in the IVR Box, you will then choose only the 'text' type fields. You may use any ODBC compliant database, as long as the fields are the type of 'text'. The information in the field can most likely remain the same. If the original field was 'date' and the information is in one of the 3 formats we can read (see 'action options' under the 'action' of date, then the data can remain the same. If the field was originally labeled 'number' and you want the information read as 'money', as long as the digits have a decimal point (if needed), then the data can remain the same and the voice program will read it as x dollars and x cents.
Install the ivr.exe from the CD rom AFTER all other .exe's (program.exe, 8bitprompts.exe, etc.) disks have been installed.
The IVR Module installation will provide a Microsoft Access 2000 .mdb file named \ivr\question.mdb. To use the file, you will need to register it with ODBC and BDECFG. Question.mdb is an empty Microsoft Access file with 15 fields (field type of character), each allowing for 50 characters. The file will be installed in the c:\IVR directory by default, along with a copy named empty.mdb. You will also need to register the question.mdb file using the IVR program folder and clicking on the BDECFG icon using the following instructions below for BDE file registration. You can copy the empty.mdb to any other file name and/or directory. You must then register your new file with BOTH ODBC and BDECFG.
1) register a database file in in ODBC:
click on My Computer
click on Control Panel
click on ODBC
click on User DSN
click on Add select Microsoft Access Driver (*.mdb)
enter data source name (this can be the name of your file minus the extension for ease of remembering) - for this example, file would be question.mdb, so data source name would be question. You must use the SAME name for all of these entries. Description can be the same name as under Data Source Name.
click on Select
choose your database file (\ivr\question.mdb)
click on OK
no other fields need to be used
click on OK and exit
2) register the same database file in BDECFG:
click on Start, Programs, IVR
click on the BDECFG icon to open
select "New ODBC Driver"
set SQL Link Driver to "ODBC_question" (filename as above)
select Default ODBC Driver "Microsoft Access Driver"
select Default Data Source "question" (filename as above) OK
Select Aliases Add New Alias New alias name "question" (filename as above) select Alias type "ODBC_question" (filename as above) OK
Be careful to choose the correct Alias type - if you choose "Standard", you will be able to see the database in the Voice Program, but no tables will be visible to choose.
In an IVR box, choose database "question" and the table will be "questions" (choose the table you want the program to use) ***************
There is no information in the question.mdb file. You can use your Microsoft Access 2000 program to enter information - or you can use a question box to enter information.
The IVR box will use a supplied database file to handle incoming or outgoing calls (when used in conjunction with an Outbound Box - see Chapter 14:The Outbound Box).
An example of an incoming application would be a salesperson calling to check on their sales volume as of a certain date. The company provides a database with the following information:
salesperson's account number password dollar amount date
555666777 123456 5000.00 06/20/99
The caller would be asked to enter their account number and their password. If correct, the system could say "Your sales volume is $5,000.00 as of June 20, 1999".
********************
You may have multiple IVR boxes.
*******************
QUESTION BOX - getting data into a database
If you do not have a database file, a question box can be used to enter data into a database file. Create an empty database file (using Microsoft's Access program for example) and register it with ODBC and BDECFG as explained above. The question box is also an easy way to test putting information into an IVR box to be read. On the main question box screen, choose the database file name and table.
Field # 1 in a database may be just a record number field and would NOT be a field we would use to either read or speak data. Choose your fields carefully. The database we provide (question.mdb) has the first field as record number.
This field shows as 'recno'. Question 1 will input data to field 2, question 2 to field 3, etc. Be sure your fields are set up accordingly. We provide an empty database file (c:\IVR\question.mdb and empty.mdb) with fields set for a maximum of 50 characters/numbers per field. You can have up to 15 questions, which would be a maximum of 16 fields.
Be sure you choose the correct database file and table. THE TABLE YOU CHOOSE WILL AUTOMATICALLY HAVE ANY INFORMATION IN IT BE OVERWRITTEN.
Note: Any database files you use must have the fields you want the program to use set as 'type=character, or 'text'.
The system can create a unique identifier number (if you check that field in the Question Box), after all the questions have been asked. This number will be spoken to the caller. This could assist you and the caller in finding the record. With a unique number, for each call if you are running a reminder service (Scheduled OutBound-CalenDialer), the caller can easily identify a birthday reminder for their Mother from a birthday reminder for their wife. The system will also use the number for record identification.
IVR BOX
You need to tell the program how to handle the call in an IVR box, what to say first, what to ask the caller for, and which field to compare that information to in the database file.
You will do this by setting up the 'steps' of the call. Step 1 - ask for account number, step 2 - ask for password, etc.
The first thing the program will do upon entering the IVR Box is to play the 'greeting', followed by the steps you set up.
Each step can have an initial prompt (please enter your account number), the field to use to try to find that account number, the action to take (account input) and, if the action selected was 'value prompt', then there will be recordings to accompany those values.
The 'actions' tell the program how to handle a particular field in the database file.
The program will only proceed to the next step upon matching. The first step reached that does not match will send the caller to the box you enter in the 'if validate fail' field.
You need to choose a database file and the correct table from within that file. Click on Database to choose the database file. Then, click on Table to choose the table. If you do not see any file listed, you have not correctly registered your database file. If you believe you have taken the correct steps, go back under Control Panel, then ODBC to see if your file is listed. Also, go back under BDECFG to see if it is listed under both Drivers and Aliases. If it is listed correctly in all places, try rebooting and looking for the file again.
If Validate Fail:
There are many possible ways to use the IVR Box. Some of them depend upon comparing information that has been entered by the caller to information in the file. For example, if you want a caller to enter an account number and a password in order to hear more information from the file such as a balance, you also need to have a path for that caller is they enter an incorrect account number and/or password. The box number you enter in this 'if validate field' is where the caller will be sent if they do not enter correct information upon request. This would also include information that is not actually entered by the caller in the IVR Box, but would have been entered in an access validate box or a user phantom, where they were asked to enter their mailbox number and password elsewhere in the program. That information is held by the program in memory and used when you enter a step like 'account validate box'. Other information is automatically gathered by the program, such as caller id. The caller-id number is gotten at the very beginning of the call and is held in memory throughout the entire call. So, if any of the items do not match information in the file, it is considered a 'validation failure' and the caller will be taken out of the IVR Box and sent to the box you listed in the 'if validate fail' field.
After Box:
If all the information matches (account and password correct, or the caller id number matches, etc.) and the caller can continue through the steps in the IVR Box, then the caller will be sent to the box you enter in this 'after box' field.
Sometimes callers abuse a system and the system operator would like a way to eject callers before they have the opportunity to do anything on the system. The Caller-ID add-on Module can accomplish this. The caller's phone number is available from the moment the program answers the call. You could have a list of phone numbers that you want to be immediately sent to a box that says "The phone number you are dialing from is no longer allowed to use this system". You would enter the phone numbers in a database file. Your initial box on each line would be an IVR Box using that list of numbers. When a match is found, the caller would be sent to the 'after box' field. If the match is not found, the caller would be sent to the 'if validate fail' box- that caller would be allowed into your system.
Record Handling:
The Record Handling screen tells the program how to manage the records it finds in your database and what options to play to the caller.
Search for Multiples:
Check this if you want the program to search for additional records in the database, after having found a first match. You might have a database containing social security numbers, check numbers and amounts. If this field is not checked, the program will find the first listing of a social security number, say the check number and amount for that record and search no more. When checked, it will read the first entry and look thru the database to see if there are additional records with that same social security number.
By default, the program will search for the presence of one look-up number for the first step, play the call flow items for that record and go to the 'after box' field. When 'search for multiples' is checked, the program will find the first entry, then continue to look through the entire file to see if there are any additional records with the same look-up number. It will put them all in memory and speak them one at a time.
Speak Total Records Found:
When checked the program will count the number of matching records found and speak the prompt you record here. 'There are 3 records found in the database'. 'There are' is a system prompt under Maintain, Prompts (\stplus\prompts\thereare.voi). '3' is the number of records found, and will changed. The last part of the statement you will record under "multiple prompt" - 'records found in the database' - or whatever is appropriate for you application. If not checked, the system will just begin playing the records.
If there is only one record, the program will say 'there is' '1' "record found in the database. You will record the singular prompt under 'single prompt.
Playback order:
If you have multiple records for any given entry, you may want to play them to the caller in a particular date order. This option can only be used if you have a valid date entered for each record. You need to choose the field where the date is located. If you want records sorted and played by date you MUST have set a Step of 'Date', and choose it in the field under Steps, Date, Action Options. See the 'Date' section under 'Steps'.
Play Prompt After Each Record:
If the records you are speaking to your caller are short, as in simply speaking a list of numbers, or dollar amounts, you may want to just speak them one after the other. As in, 'Check number 455 in the amount of $10.00, check number 456 in the amount of $15.27, etc.' However, if the information is lengthy ('the part number is 876cfg239487') or you know there will be a lot of records played to the caller, you may want to give the caller a break in between the records being played back. Checking to 'play prompt after each record' will tell the system to play the first record, then 'to repeat this record press 1, to repeat all the records found from the beginning press 2, to skip to the next record press 3'. The caller can press a key at any time during this message, so they can move along quickly if they want to.
Records in Sequential Order:
If your database has the look-up numbers out of order, that is, account number 555 could be listed at the top of the database, somewhere in the middle, and perhaps another could be at the end of the file, then the program must search through the entire database to find these multiple entries. This can take several seconds, depending upon the size of the database and the speed and memory in your computer. By default, the program will continue to look for more matching records in this manner. If, however, your account numbers are sequential, meaning all the records with account numbers 555 will be together after account number 554, the program can stop the search after finding 556 (not a match). This can add up to a lot of saved time. If your database is set up that way, you can check this field for greater efficiency and speed of look-up.
Delete Record After Lookup:
When checked, the program will delete a record from the database file after it has been accessed. This is generally only used if you are using the Privilege Reset feature in conjunction with calling cards. You would have a list of pin numbers and would have issued cards with those numbers imprinted. You could sell those cards to stores, who would in turn sell them to their customers. Each pin number would have a privilege associated. You would not want the pin number to be used more then once, so we will delete the record after we look it up and give the caller the appropriate privilege.
Send to Fax:
The program will ask the caller if they want the information faxed to them. If so, we will create a uniquenumber.txt file in the \stplus\faxes subdirectory. The information is not actually being faxed. We are simply entering enough information in this text file for another program to perform the faxing functions based on the account input entered by the caller.
The file is sent to the subdirectory you indicate in the \winnt\stplus.ini file [Fax] section:
[Fax]
IVRFaxPath=c:\stplus\faxes
The file is set up as follows:
date
time
fax phone number (entered by caller)
callers name or extension number (entered by caller - blank, letters, or numbers)
DNIS (blank line if not available)
IVR box number
account input number
second account input number
etc.
To allow the caller to hear this option, you must have the information correct in the \winnt\stplus.ini file, one of the 'send a fax' options, and the 'play prompt after each record' checked in the Record Handling screen. By checking 'send to fax after all records' checked, the caller will not be given the option to send to a fax until all the matching records have been played. If you check 'send to fax after each record', then the caller could choose not to listen to all matches, and just send the information to the text file after the firs record has been played.
The caller will be given the option to enter their fax phone number, followed by the option to enter either an extension number, or their name, using the touchtones on their phone. They will be prompted to enter the first letter followed by the # key, the next letter followed by the # key, etc. When they are finished they should enter the # key by itself. The letter 'a' is the 2 key pressed once, the letter 'b' is the 2 key pressed twice, etc.
Use BDE
Use Database Program
Choose one of the above options. The first option will use the internal Borland Database Enginge (BDE) to locate the record(s) reequested by the caller. The Use Database Program will only be available to you if you have also purchased the NetNotify add-on module. If you have this module, see NetNotify Add-on Module section. This will allow for very fast database lookups.
Call Flow:
Clicking on this button brings you to the section where you define the steps the caller goes through while in the IVR Box.
Double clicking on each (after adding it) will bring up the 'step information' window:
This window is where you define what happens to the caller in each step of the IVR Box. If you want the caller to enter an account number as an action, you would want to record "Please enter your account number now" after clicking on the "Prompt" button. Choose the field from your database file that contains the account number by clicking on 'Select Field'.
Your first step MUST be one which the program can use to identify which record to use to continue to the next steps. You must choose one the following 4 steps as your first step:
account input
account caller id
account validate box
account outbound key
You can choose any field number to be used, but you must choose one of the above as your first step.
Click on the scroll arrow next to the Action field to choose the action.
If items need to be matched, either by caller entry or from information held in memory, the IVR Box will proceed to the next step, or if no more steps, to the 'after box' on the main IVR Box screen. If there is not a match at any point, the IVR Box will ignore any further steps and take the caller directly to the box listed in the 'if validate fail' field in the main IVR Box screen.
Some actions have 'sub' information that must be entered or chosen in order for the action to operate correctly. Additional buttons on the main Step screen can be chosen for any action. Any action that requires touchtone input from the caller can utilize the 'confirm'. If 'confirm' is checked, the system will automatically repeat the number entered by the caller and ask if it is correct, or allows the caller to press a key and re-enter the number. That will done prior to actually looking up or entering the number in the database field.
Your steps must be in order - 1,2,3 etc. If you set up 3 steps in order, then decide to delete number 2, you must re-do your steps. They will not automatically re-order themselves and all IVR Box activity will stop after the first step. If the step 1 matched, caller will be sent to 'after box'. If step 1 did not match, caller will be sent to 'if validate fail'.
Some actions require additional information to work correctly. For example, if you choose 'date', you must also choose the correct date format under 'Action Options'. After you have chosen your 'action', if you have other possibilities, then the 'Action Options' will be available for you to click. When you click on it, you will see what options are available for the action you chose. If the action you chose requires no further clarification, the Action Options button will be grayed out.
ACTIONS:
ACCOUNT INPUT:
The field selected would contain an account number. The system needs to ask caller to enter account number (you will record the Prompt in this step as "Please enter your account number"). If used in conjunction with PASSWORD action, system also needs to ask for a password and be sure they match. If you would like the number the caller entered automatically played back for confirmation, also check the 'verify account input' under 'Action Options'.
ACCOUNT CALLER-ID:
Requires purchase of optional CallerID module.
This action expects the caller id to be in the selected field and will match to the caller id in memory (this could have gotten there via a question box which allows for data input to a database field). If there is a match, the program will go to the next step. If no more steps, the program will proceed to the 'after box' field on the main IVR Box screen. If it does not match, the program will ignore any further steps and go to the 'if validate fail' field on the main IVR Box screen. A special voice board is required and you must receive caller id information from the phone company.
ACCOUNT VALIDATE BOX :
Once a mailbox and password has been validated on the system, via the User Phantom or an access box with the tweaks set for validate, it is held in memory for the duration of the call. The IVR Box can match the box number and proceed to any other action.
ACCOUNT OUTBOUND KEY:
This is the unique number created from a question box.
PASSWORD1:
This field contains the account password. The prompt would be recorded "Please enter your password". This field is used in conjunction with the "account input' action. Ask for the account number first, then the password. It does not need to be an actual password, but could be an additional piece of information to identify the caller. If your first step was 'account input' and you were requesting a social security number to be entered, the your second step could be 'password1' and be asking for the caller's driver license number. PASSWORD2 , is yet one more item to verify the caller. It could be a birth date, for example.
PASSWORD2:
This field would contain a second password for additional identification. See Password 1 section above.
CONTENTS:
There can be numbers and/or letters in this selected field, and the system will speak them, using the program's default number and letter prompts (587abc = "five eight seven a b c"). The program will speak to a maximum of 256 characters in this field.
VALUE PROMPT:
This selected field will contain a number, such as 602, for an area code. A value prompt must be recorded for all numbers that could occur in this database field. For an area code of 602, you would record "Arizona". In the doctor appointment scenario, this field could either contain 1,2,3, for example. 1 could be recorded as "Dr. Jones", 2 as "Dr. Smith", etc. The idea is that program will see a number, yet speak a voice file that has been recorded to be associated with it. If Value Prompts is selected as an action, you will need to record the actual voice prompts to be played under 'Action Options', then "Value Prompts".
PLAY FILE:
A voice file and it's location (path) would be listed in this selected field and the system will play it.
DATE:
Numbers in this selected field will be spoken in date form (060499=Friday, June 4, 1999). You will need to choose the date format of the database information under the 'Action Options' button. For example if the date format is 6/4/99 or 06/04/99, you would choose MM/DD/YY as an Option for this Action. If you have multiple records with the same account input number in your database, you may want to sort them by date before playing them to the caller. If, you are playing back check number and amounts, it will make more sense to the caller to hear them either in chronological or reverse chronological order. If you are playing employment history information, you would most certainly be playing in one of those order. You need to have a step of 'Date' to accomplish this. This is the step you must choose in the record handling screen to sort. Check the 'sort only' if you do not want to play the date in this field to the caller. That means the program will sort the records in order of these dates, but will not actually speak the date.
TIME:
System requires military time to be in the field. If the number is 1730, the system will speak 'five thirty p.m.'.
CALLER-ID LOOKUP:
Requires purchase of optional CallerID module.
You must have a special voice board that can access the caller-id sent from the phone company. You need to request caller-id on your phone lines from the phone company for this function to operate. Choose which (or all) of the 10 numbers you want to match, by clicking on the Caller-ID button and checking off the numbers you want - area code, prefix, area code AND prefix, etc. Caller-id is sometimes called ANI when using T-1 lines.
EXPIRATION:
This field will have numbers in date form, such as 060499 (June 4, 1999). There must be six digits. When used in conjunction with an account input field, the program will check today's date, and if EARLIER then the date number in the field, will allow the caller to continue to the 'after box' field in the IVR box screen, or to another step. If today's date is LATER than the date entered, the caller will be sent to the 'if validate fail' box listed and no other steps will be performed. As an example, this could be used to allow customers access to your system to reach a tech support person. example:
step 1 account input - record prompt as "please enter your account number"
step 2 password - record prompt as "please enter your password"
step 3 expiration - no prompt would get recorded here; this just tells the software to see if the date entered in the field is today or later.
MONEY
This field can hold number in the following forms:
2 will be read as two dollars
.2 will be read as twenty cents
3.1 will be read as three dollars and ten cents
3.01 will be read as three dollars and one cent
1234.55 will be read as 1 thousand 2 hundred thirty four dollars and fifty five cents
PRIVILEGE RESET
This field can be used to automatically have a mailbox owners privilege reset. This must be used in conjunction with the 'account input' step. The concept is to allow caller to increment or reset their privilege based upon a special pin number code that they enter. You could sell a list of numbers that have been pre-printed on cards to a local store. The number could be of any length - generally 9 digit numbers. The store owner could re-sell those cards to customers of your that already have mailboxes on your system. Then the customer calls into your system, enters their mailbox number and password. You route them to an IVR box which uses a database that has those numbers listed one field and the privilege number in another field. The program will find the number and reset or increment the mailbox (which is held in memory) to the privilege number associated with the 9 digit number they entered.
This can also be used to promote your system. If you are using a dateline, for example, you could have first time callers who purchased a card, go through a capture box to have a mailbox created for them. Send them through an Access Box set to validate, then to the IVR box. They can enter the number on the card and automatically get the associated privilege. You should still approve their survey description, but other than that, they can continue to use your system by just purchasing additional cards.
The first step should be 'account input' and you should record a prompt such as 'please enter the number on your card'. Choose the field in the database that holds the 9 digit number. The second step would be 'privilege reset'. No prompt would be recorded. Choose the field that holds the privilege number.
Under the Record Handling button is the 'delete record' option. When checked, the record (9 digit number and privilege) will be deleted from the database file, so it cannot be entered again. BE SURE YOU CHECK THAT FIELD. Otherwise the caller can use the same number over and over without paying any more money.
GO T0 BOX
This field must contain a valid box number on your system.
GET DIGITS
This step takes touchtone digit input and inserts it into a field in your database. Be sure you have this set up as a blank field - any touchtone input from the caller will automatically be written into the field, overwriting anything that might already be there. Any information already in that field would be overwritten.
GENERATE NUMBER
This step will automatically create a unique 9 digit number and enter it into the field you choose in the database. The system will then speak the number to the caller and ask if they would like it repeated.
SET DATE
This step will automatically enter a date into a particular field in your database. You will specify under Options whether you want the program to enter today's date or a date x days from today. The date will not be spoken to the caller.
VALIDATE BOX
This step allows you to enter a valid mailbox number in a field in your database file. The program will automatically validate the box number and password, as though the caller manually entered them. The first step in an application such as this could be account input, or could be account CallerID. You would have entered the mailbox owner's home phone number in the first field (step 1 account caller id). The next field would be the mailbox number (step 2 validate box). The third field will contain a valid system box, such as an access box, or User Phantom box (step 3 go to box). So that will be the first thing the caller hears. If the caller is not calling from their home phone, the caller id will not match, so the caller will be sent to the 'if validate fail' on the main IVR box screen. They would need to manually enter their box number and password.
Load Database into Ram
As we are not accessing the database file directly, but rather via ODBC and the Borland Engine, large database files may take some time to search. If you find the time on hold excessive (this will depend on the size of the file and the speed and ram of your machine) you may find it more desirable to load the database file(s) into ram for speedier access. A maximum of 10 files can be loaded into ram. If you use this method, no changes can be made to the database file while the program is running - the voice program won't know about it, as it is only using the copy it originally loaded into ram when the program first opened.
If you will be making periodic changes to the file(s), you will need to close the voice program and re-open it, to load the new, changed file. If you have the voice program making changes and writing to the database file(s), the changes will be made both in ram and on the hard drive. The information needs to be setup in the \winnt\stplus.ini file as follows:
[DataSources]
datasource1=datasource name (not the filename, but the name listed with ODBC)
table1=table name within the database.
The file(s) still need to be registered in the same manner with both ODBC and BDECFG. Be sure you have enough ram to accommodate the file(s) and that the files are of the correct number of fields and field length. To be loaded in to ram, there can be no more than a total of 15 fields. Each field can hold no more than 30 characters. Each record will take up approximately 450 kb. To see how much ram will be occupied, multiply 450 kb by the number of records in your database file. The program executable itself requires approximately 8 mb.
When loaded with one 40,000 record database file, approximately 32 megabytes
of ram are taken. Remember, you still need more ram for Windows NT itself, etc.
When opening the program you will see the database file load. When the program
has opened you can use the task manager to see how much ram was taken by
stplus.exe. If you begin to run low when opening the program, you will get a
virtual memory error. You should use the task manager to stop the stplus.exe in
that case. Then, go back and re-do your arithmetic, so you can be sure you have
plenty of ram available. You should have at least 100 mb of ram available AFTER
the program has opened.
If, after allotting for the correct space, loading the file into ram, you are still experiencing a delay when the record is being searched for, check the trace log or the global log. After the initial account input step, you should see where the program is looking into ram and will show a comparison of the database and table it finds (if any) and the database and table listed in the IVR box. This is a simple way to see if you have made a typo somewhere. First it compares the databases, then the tables. The log will show the number of files found in ram (ram datasource cnt=x). If there are any, the next line will show the names verse the IVR box names. Then you will either see 'match found' or 'match not found'. If 'ram datasource cnt=0', or there is no match found, you will see the program 'open database' and 'open table', then begin the search for a matching record.
Sample Applications:
Using CallerID:
As an example, with the optional CallerID module, you can speak a particular prompt to callers depending upon their area code. Your callers will be thrilled to hear "Thanks for calling us all the way from Florida, the Sunshine State!" You need to create an Access (or other ODBC compatible database) file that contains all area codes listed in one field and another field to contain the path to voice files you have recorded. The voice file will contain the "Thanks for calling all the way from Florida, the Sunshine State!".
The greeting in the IVR Box will be recorded as a blank file - or some other generic salutation. You do not want to record the greeting as 'Thanks for calling from...." and put the state in the other prompt, because some callers may have their caller id blocked. In that case, the caller will be sent to the 'if validate fail' box you have entered on the main IVR Box screen. If there is a match with the caller's area code, then the caller will be sent to the box you enter in the 'after box' field on the main IVR screen.
The IVR Box should be set up with 2 steps. Step one should be set with the Action 'Account CallerID'. Choose the field in your database that contains the area codes. Step 2 should be 'playfile'. Choose the field that contains the filename and path for the appropriate voice file. The voice files can be recorded using the voice file editor, VFEdit, which is available for purchase.
It is also possible to enter the numbers yourself using the 'value prompt'. Step 1 becomes 'CallerID lookup'. In the same step, you will also click on 'value prompts'. Enter the area code, and record the prompt - "Thanks for calling all the way from xxxxxx".
Troubleshooting:
If the database is listed properly, but on the call you hear 'the date is' then you hear 'blank', and you know you have a proper date entry and all is set up correctly, the field length may not be correct. Please see above structures and double check the settings in your database. There is no need to re-register if you make changes to the database file.