Setting up the script

There are some CallWeb script requirements that are specific to the CATI environment. They are explained below.

1. add a PRESTRATE question
2. add a CALCTESTQUOTAS question
3. add a TESTQUOTAS question
4. document possible call results

PRESTRATE question

Very early in the questionnaire there must be a question named PRESTRATE which stores the stratum membership of every case in the data base; every case must be assigned a value for this question via prepopulation. If the project does not use strata, PRESTRATE must still be present and contain a single category.

The text of the PRESTRATE question must document the maximum number of cases which will be allowed to be used in each stratum. The syntax is as follows:

1 = 100, 2 = 50, 3 = 90

This limits stratum 1 to 100 cases drawn from the entire data base into the list of active telephone numbers, 50 for stratum 2 and 90 for stratum 3. Using this mechanism, one can prepopulate the data base with a large number of telephone numbers and "open the tap" as required without having to perform additional prepopulation.

Strata are defined using response categories; there shall be as many response categories as there are strata.

The PRESTRATE question should be given the NEVERUPDATE characteristic so that it is never displayed to the interviewers and that it cannot be modified once prepopulated. A typical PRESTRATE definition would look as follows:

PRESTRATE NEVERUPDATE
% text
    1 = 100, 2 = 50, 3 = 90
% note
% categories
    Montreal
    Toronto
    Vancouver
% skips
% display condition
% open end
! end ==============================

CALCTESTQUOTAS question

CallWeb CATI demands that quotas be defined. The basis for quota definition can simply be membership to the original strata defined in PRESTRATE but quotas can also be based on any other criterion or combination of criteria. CallWeb supports quotas for groups that are defined on-the-fly during the interview and based on responses to the questionnaire as well as prepopulated or calculated data. Refer to the CallWeb base documentation for a description of quota management.

The simplest CALCTESTQUOTAS question simply transfers PRESTRATE stratum membership over to the TESTQUOTAS as follows:

CALCTESTQUOTAS CALCUL
% text
    TESTQUOTAS = $PRESTRATE
% note
% categories
% skips
% display condition
% open end
! end ==============================

TESTQUOTAS question

As early as possible into the questionnaire, a question named TESTQUOTAS (of type QUOTA) must be inserted to test whether required completions have been reached for the stratum to which the current case belongs. Refer to the CallWeb base documentation for a description of quota management.

Actual quota groups must be defined as categories of this question.

In the following typical example, the project manager is striving for 40 completions in stratum 1, 25 in stratum 2 and 60 in stratum 3. Once a stratum has reached its quota, based on the presence of data in a sufficient number of cases in question QCOMPLETE, interviews are routed to question QUOTAFILLED and terminated.

TESTQUOTAS QUOTA
% text
    complete = QCOMPLETE, skip = QUOTAFILLED, 1 = 40, 2 = 25, 3 = 60
% note
% categories
    Montreal
    Toronto
    Vancouver
% skips
% display condition
% open end
! end ==============================

Call results

Call results that will be offered to interviewers are defined using the cwcodescati.cgi utility which is accessible from the integrated module. Call results can also be copied from one project to the next by copy the file named project1.ccw to project2.ccw (make sure to give write access permissions to the world si that cwcodescati.cgi can modify this file).

There can be any number of result codes; each is defined, in cwcodescati.cgi, on the basis of the following characteristics:

• a code name which is displayed to interviewers and in field reports;
• whether or not the result code corresponds to a completed interview; only one result code can bear that characteristic;
• whether a callback date is required for the code
• whether a callback time is required for the code; if a time is required, a date is automatically mandatory. Result codes requiring a date but not a time correspond to general day-based appointments or "not available until" such a date situations;
• whether or not the result code corresponds to a refusal situation;
• whether or not the result code is allowed to replace a previous refusal code; for example, this gives the project manager the ability to allow refusals to be transformed into completions, but not into busy signals;
• whether or not the result code is usable only once; using this characteristic, the project manager can control that a code, say Refusal, cannot be entered a second time; in this example, a second refusal would have to be coded as Second Refusal;
• whether or not the result code is invisible to interviewers; it is sometimes useful to deactivate a result code (say, after a pretest) but it must be maintained in the result code list if a single case uses that code in the data base;
• the number of times a result code can be used before a case is retired from the project; for example, a single use of a "Definite refusal, don't ever call again" code could retire a case; a value of 0 indicates that the code may be used without incidence on case retirement;
• whether an interviewer comment is allowed or is mandatory if the result code is selected;
• whether the result code represents a human contact (e.g., the interviewer talked to someone); this information is used by cwoutcomes.cgi to calculate the adjusted response rate;
• the response rate analysis group to which the result code belongs; response rate categories are defined below the list of result codes; they are used by cwoutcomes.cgi to calculate the adjusted response rate.