Table of contents

COMPLETE CATI DOCUMENTATION ON A SINGLE PAGE
QUICK START
GENERAL INTRODUCTION
SUPERVISION
Introduction
Define active projects
Describe interviewers
Set up the script
Populate the data set
Control data collection
Manage telephone numbers
Attribution of telephone numbers
Analyse productivity 		INTERVIEWING
Introduction
Log-in procedure
Selecting a project, strata and types of calls
Selecting cases according to a third criterion
Automatic number, particular number or terminate
Managing a call
Time keeping
APPENDIX A CATI Project initiation checklist
APPENDIX B Recent changes and additions
APPENDIX C Time data in CallWeb
APPENDIX D Audio-visual supervision
APPENDIX E Playing sound files during an interview
APPENDIX F Batch dialer installation

Table of contents

COMPLETE CATI DOCUMENTATION ON A SINGLE PAGE
QUICK START
GENERAL INTRODUCTION
SUPERVISION
Introduction
Define active projects
Describe interviewers
Set up the script
Populate the data set
Control data collection
Manage telephone numbers
Attribution of telephone numbers
Analyse productivity 		INTERVIEWING
Introduction
Log-in procedure
Selecting a project, strata and types of calls
Selecting cases according to a third criterion
Automatic number, particular number or terminate
Managing a call
Time keeping
APPENDIX A CATI Project initiation checklist
APPENDIX B Recent changes and additions
APPENDIX C Time data in CallWeb
APPENDIX D Audio-visual supervision
APPENDIX E Playing sound files during an interview
APPENDIX F Batch dialer installation


Quick start

This page provides brief instructions on how to set up your first CallWeb CATI project. It is assumed that you have access to a Web server equipped with CallWeb and to an FTP program to transfer files to the server.

  1. edit the BASEprojets project to document your new project;
  2. edit the BASEpasse project to make sure interviewers can log in;
  3. add the following questions to the script: PRESTRATE, CALCTESTQUOTAS, TESTQUOTAS;
  4. add call result codes to the project;
  5. populate the data base with the telephone numbers to call and the stratum to which each number belongs;
  6. add telephone numbers to the call queue;
  7. unleash interviewers.

Quick start

This page provides brief instructions on how to set up your first CallWeb CATI project. It is assumed that you have access to a Web server equipped with CallWeb and to an FTP program to transfer files to the server.

  1. edit the BASEprojets project to document your new project;
  2. edit the BASEpasse project to make sure interviewers can log in;
  3. add the following questions to the script: PRESTRATE, CALCTESTQUOTAS, TESTQUOTAS;
  4. add call result codes to the project;
  5. populate the data base with the telephone numbers to call and the stratum to which each number belongs;
  6. add telephone numbers to the call queue;
  7. unleash interviewers.

   

General introduction

CallWeb CATI comprises a series of computer programs which add structured control and access to CallWeb questionnaires in the context of telephone interviewing.

CallWeb CATI includes a set of supervision modules to define active projects and their behaviour, to describe active interviewers and manage their time, to feed telephone numbers to the call queue and to control the state of the data collection.

CallWeb CATI also includes a set of interviewing modules which control the attribution of telephone numbers to interviewers, dial the numbers on behalf of interviewers and manage the collection of information on call results.

This documentation is organized accordingly.

General introduction

CallWeb CATI comprises a series of computer programs which add structured control and access to CallWeb questionnaires in the context of telephone interviewing.

CallWeb CATI includes a set of supervision modules to define active projects and their behaviour, to describe active interviewers and manage their time, to feed telephone numbers to the call queue and to control the state of the data collection.

CallWeb CATI also includes a set of interviewing modules which control the attribution of telephone numbers to interviewers, dial the numbers on behalf of interviewers and manage the collection of information on call results.

This documentation is organized accordingly.

   

Supervision — Introduction

CallWeb CATI includes a set of supervision modules for the following functions:

  • to define active projects and their behaviour
  • to describe active interviewers and manage their time
  • to set up the CallWeb script for CATI use
  • to populate the data set
  • to feed telephone numbers to the active number set and
  • to control the state of the data collection.

Supervision — Introduction

CallWeb CATI includes a set of supervision modules for the following functions:

  • to define active projects and their behaviour
  • to describe active interviewers and manage their time
  • to set up the CallWeb script for CATI use
  • to populate the data set
  • to feed telephone numbers to the active number set and
  • to control the state of the data collection.

   

Defining active projects

All CallWeb CATI projects must be defined and activated in the BASEprojets CallWeb project. Projects that are not declared or activated in the BASEprojets CallWeb project are not available to supervisors and interviewers — this way Web-only projects can be managed along with CATI projects, without interference.

Defining a project simply requires

  • stating a name,
  • possibly a title, and
  • a telephone suffix code (for billing purposes).

Also, projects

  • can be made to use the auto-dialer and the predictive/batch dialer,
  • can allow interviewers to change telephone numbers of individual cases,
  • can be temporarily switched on or off without deleting the entry from the list and
  • can be associated with a "do not call before" time and a "do not call after" time which are expressed in local respondent time.

The BASEprojets CallWeb project is most easily viewed and edited from the cwnav.cgi utility which is accessible from the integrated module.

Defining active projects

All CallWeb CATI projects must be defined and activated in the BASEprojets CallWeb project. Projects that are not declared or activated in the BASEprojets CallWeb project are not available to supervisors and interviewers — this way Web-only projects can be managed along with CATI projects, without interference.

Defining a project simply requires

  • stating a name,
  • possibly a title, and
  • a telephone suffix code (for billing purposes).

Also, projects

  • can be made to use the auto-dialer and the predictive/batch dialer,
  • can allow interviewers to change telephone numbers of individual cases,
  • can be temporarily switched on or off without deleting the entry from the list and
  • can be associated with a "do not call before" time and a "do not call after" time which are expressed in local respondent time.

The BASEprojets CallWeb project is most easily viewed and edited from the cwnav.cgi utility which is accessible from the integrated module.

   

Describing interviewers

Before they are admitted into the CallWeb CATI system, interviewers must be granted permission. This is done in the BASEpasse CallWeb project.

Describing an interviewer simply requires

  • stating a name and
  • providing a password

The BASEpasse CallWeb project is most easily viewed and edited from the cwnav.cgi utility which is accessible from the integrated module.

If the auto-dialer is used, each connected work station must be defined in the BASEposte CallWeb project — which is most easily edited in the cwnav.cgi utility.

Finally, the CallWeb CATI project automatically cumulates interviewer time spent on each project. The time data are stored in the BASEtemps CallWeb project. If an interviewer does not properly exit the system, an error is displayed next time they attempt to re-enter the system and a supervisor has to locate the time slip in the BASEtemps CallWeb project using cwnav.cgi and edit the transaction to correct it.

Describing interviewers

Before they are admitted into the CallWeb CATI system, interviewers must be granted permission. This is done in the BASEpasse CallWeb project.

Describing an interviewer simply requires

  • stating a name and
  • providing a password

The BASEpasse CallWeb project is most easily viewed and edited from the cwnav.cgi utility which is accessible from the integrated module.

If the auto-dialer is used, each connected work station must be defined in the BASEposte CallWeb project — which is most easily edited in the cwnav.cgi utility.

Finally, the CallWeb CATI project automatically cumulates interviewer time spent on each project. The time data are stored in the BASEtemps CallWeb project. If an interviewer does not properly exit the system, an error is displayed next time they attempt to re-enter the system and a supervisor has to locate the time slip in the BASEtemps CallWeb project using cwnav.cgi and edit the transaction to correct it.

   

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.

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.

   

Populate the data set

Before telephone interviewing can take place, the project data set must be prepopulated with at least the following information for each case:

  • a unique ID must be used as _telkey;
  • a telephone number (including area code) must be used as _telephone; if the telephone number field is empty, the _telkey field is used instead;
  • a stratum must be imported into the question PRESTRATE for each case.

During prepopulation, the offset between the time zone of each number (based on area code) and GMT is calculated and stored in the data file. Therefore, the GMT offset of each area code used in a project must be defined in the CallWeb installation file.

Additional fields may be required on a project by project basis, such as a contact name or a substitute telephone number. Such additional information would be prepopulated into separate questions which would be given the INFOCATI characteristic so that they are displayed to the interviewer in the case management interface.

Data prepopulation is documented in the main CallWeb documentation.

Populate the data set

Before telephone interviewing can take place, the project data set must be prepopulated with at least the following information for each case:

  • a unique ID must be used as _telkey;
  • a telephone number (including area code) must be used as _telephone; if the telephone number field is empty, the _telkey field is used instead;
  • a stratum must be imported into the question PRESTRATE for each case.

During prepopulation, the offset between the time zone of each number (based on area code) and GMT is calculated and stored in the data file. Therefore, the GMT offset of each area code used in a project must be defined in the CallWeb installation file.

Additional fields may be required on a project by project basis, such as a contact name or a substitute telephone number. Such additional information would be prepopulated into separate questions which would be given the INFOCATI characteristic so that they are displayed to the interviewer in the case management interface.

Data prepopulation is documented in the main CallWeb documentation.

   

Control data collection

The cwsuper.cgi interface gives access to field management actions for each project that is defined as "active" in BASEprojets. The following paragraphs describe each column of cwsuper.cgi interface.

Define or stop updates
This column may contain an open folder icon or a skull icon. The open folder icon indicates that there is no update planned for the project; clicking on this icon brings up the update planning interface (cwsuperpro.cgi). The skull icon indicates that there is an update planned for the project; clicking on this icon stops the automatic update and brings up the update planning interface.

Most recent update
This column indicates when then most recent project update has taken place — as long as a call queue exists for the project.

Next update
This column documents in how many minutes the next project update will take place.

Additions with the most recent update
This column informs about the number of telephone numbers which were added to the call queue at the last project update (e.g., new numbers, appointments, numbers brought back after a pause).

Numbers available to interviewers
This column contains the number of telephone numbers currently available for interviewers to use (the call queue). Note that numbers in time zones which are currently closed (because of the project start and end times) are included in this total.

Number of interviewers
This column reports on the number of open BASEtemps slips for each project. A value followed by a question mark refers to time slips opened before the current day. The numbers are hyperlinked to a cwnav.cgi list of the corresponding time slips.

Completes according to cwstats
This column reports the numbers of completed questionnaires according to the cwstats data base which is updated every hour.

Condition of the fieldwork
this icon produces a large table describing the state of the fieldwork based on the last call result; the table comprises three parts:

  • the first provides a picture of the distribution of last call result code by prepopulated stratum (PRESTRATE);
  • the second reports the average number of calls made according to last call result code and according to the combination of prepopulated stratum abnd result code;
  • the third describes call results within calculated strata (TESTQUOTAS); only cases that have been accessed are reported since TESTQUOTAS requires a calculation that is performed upon opening a case.

State of the call queue
This icon displays a table describing the state of call queue: it offers a breakdown of numbers by strata and last call result. The page also reports the parameters of every update performed since the last reinitialization of the call queue. A red (rather than yellow) icon indicates that the most recent update encountered some constraints (e.g., closed strata, strate where the maximum number of allowed numbers is reached).

Case groups
This icons brings up a listing of existing groups of cases that were predefined for use by the interviewers in selecting the cases they will be provided from the call queue.

Cases by results
This icon calls cwfreq.cgi and automatically builds a table according to call results and strata; each combination of a call result and a stratum is hyperlinked to the underlying list in the cwnav.cgi program.

Productivity
The Gantt chart icon opens cwprod.cgi with a selection for the current project. Productivity stats are available from there.

Entry in BASEprojets
This icon opens the BASEprojets entry for a given project.

Utilities
This icon brings up a cw.cgi menu with the project already selected.

Automatic quota closure

If the required conditions are fulfilled, CallWeb automatically closes PRESTRATE-based quotas as soon as the first interviewer reaches the quota-filled situation. Thereafter, no more cases from this newly-closed quota is dispatched or added to the call queue. The conditions that are necessary for this automation are as follows:

  • PRESTRATE and the first active QUOTA question have the same list of categories;
  • the project is defined as a "# CATI = yes" project in the project pound instructions or in the system installation file;
  • the project does not contain a "# Close full quota = no" instruction; adding this instruction to the system configuration file would deactivate the automatic quota closure system altogether;
  • the BASEprojets project exists and it contains the QUOTASPLEINS field;
  • the project has been compile while all of these conditions were met.

To re-open a quota that was closed after being reached, perform the following actions:

  • edit the questionnaire to increase the quota target for the quota in question in the definition of the quota variable;
  • recompile the questionnaire;
  • request a recalculation of the call queue or wait for the call queue to recalculate itself.

    • Control data collection

    The cwsuper.cgi interface gives access to field management actions for each project that is defined as "active" in BASEprojets. The following paragraphs describe each column of cwsuper.cgi interface.

    Define or stop updates
    This column may contain an open folder icon or a skull icon. The open folder icon indicates that there is no update planned for the project; clicking on this icon brings up the update planning interface (cwsuperpro.cgi). The skull icon indicates that there is an update planned for the project; clicking on this icon stops the automatic update and brings up the update planning interface.

    Most recent update
    This column indicates when then most recent project update has taken place — as long as a call queue exists for the project.

    Next update
    This column documents in how many minutes the next project update will take place.

    Additions with the most recent update
    This column informs about the number of telephone numbers which were added to the call queue at the last project update (e.g., new numbers, appointments, numbers brought back after a pause).

    Numbers available to interviewers
    This column contains the number of telephone numbers currently available for interviewers to use (the call queue). Note that numbers in time zones which are currently closed (because of the project start and end times) are included in this total.

    Number of interviewers
    This column reports on the number of open BASEtemps slips for each project. A value followed by a question mark refers to time slips opened before the current day. The numbers are hyperlinked to a cwnav.cgi list of the corresponding time slips.

    Completes according to cwstats
    This column reports the numbers of completed questionnaires according to the cwstats data base which is updated every hour.

    Condition of the fieldwork
    this icon produces a large table describing the state of the fieldwork based on the last call result; the table comprises three parts:

    • the first provides a picture of the distribution of last call result code by prepopulated stratum (PRESTRATE);
    • the second reports the average number of calls made according to last call result code and according to the combination of prepopulated stratum abnd result code;
    • the third describes call results within calculated strata (TESTQUOTAS); only cases that have been accessed are reported since TESTQUOTAS requires a calculation that is performed upon opening a case.

    State of the call queue
    This icon displays a table describing the state of call queue: it offers a breakdown of numbers by strata and last call result. The page also reports the parameters of every update performed since the last reinitialization of the call queue. A red (rather than yellow) icon indicates that the most recent update encountered some constraints (e.g., closed strata, strate where the maximum number of allowed numbers is reached).

    Case groups
    This icons brings up a listing of existing groups of cases that were predefined for use by the interviewers in selecting the cases they will be provided from the call queue.

    Cases by results
    This icon calls cwfreq.cgi and automatically builds a table according to call results and strata; each combination of a call result and a stratum is hyperlinked to the underlying list in the cwnav.cgi program.

    Productivity
    The Gantt chart icon opens cwprod.cgi with a selection for the current project. Productivity stats are available from there.

    Entry in BASEprojets
    This icon opens the BASEprojets entry for a given project.

    Utilities
    This icon brings up a cw.cgi menu with the project already selected.

    Automatic quota closure

    If the required conditions are fulfilled, CallWeb automatically closes PRESTRATE-based quotas as soon as the first interviewer reaches the quota-filled situation. Thereafter, no more cases from this newly-closed quota is dispatched or added to the call queue. The conditions that are necessary for this automation are as follows:

    • PRESTRATE and the first active QUOTA question have the same list of categories;
    • the project is defined as a "# CATI = yes" project in the project pound instructions or in the system installation file;
    • the project does not contain a "# Close full quota = no" instruction; adding this instruction to the system configuration file would deactivate the automatic quota closure system altogether;
    • the BASEprojets project exists and it contains the QUOTASPLEINS field;
    • the project has been compile while all of these conditions were met.

    To re-open a quota that was closed after being reached, perform the following actions:

    • edit the questionnaire to increase the quota target for the quota in question in the definition of the quota variable;
    • recompile the questionnaire;
    • request a recalculation of the call queue or wait for the call queue to recalculate itself.

      •    

Manage telephone numbers

In a CATI context, managing telephone numbers means identifying which telephone numbers must be made available to interviewers, and repeating this identification so as to make the most efficient use of the sample. In CallWeb CATI, this is accomplished in supervision modules which are entered via the cwsuper.cgi program. Any number of projects may by managed from one supervision workstation.

Principles

The principles of telephone number management implemented in CallWeb are as follows:

  • only numbers that have been selected explicitly to be accessed by interviewers are available to them (in the call queue);
  • numbers are added to the call queue only via the cwsuper.cgi update process;
  • updates may be done manually upon request or automatically at regular intervals; automatic updates probably shouldn't be done more often than every 10 minutes; a 20-minute interval has proven effective;
  • each manual update may include different sets of criteria and, hence, draw different types of numbers for interviewer usage;
  • appointments are automatically brought into the cann queue if the automatic update is selected;
  • automatic updates use the update parameters last entered; while previous updates may have left their selected numbers in the call queue, only numbers corresponding to the criteria last entered by the supervisor (and appointments, automatically) are added during automatic updates;
  • once a telephone number has been selected by an interviewer, it is reserved for their use for a period that is selected by the supervisor;

Supervision interface

From the cwsuper.cgi module, the supervisor selects one project to manage. Then, a menu such as the following is displayed.

This main supervision and field management menu is comprised of three areas:

  • the top part reports the number of telephone numbers in the current project call queue;
  • the right end-side lists existing call result codes; the supervisor selects the types of calls that they want added to the call queue and the delay between the last call and a new attempt; this section also allows for the inclusion of additional new cases (that have never been called);
  • the left end-side describes the specifics of the update request:
    • enter the last-call dates for the numbers you want brought into the call queue; this is normally left to default to a very large period of time to avoid losing cases;
    • determine the number of previous calls above which a number will not be brought into the call queue;
    • identify from which stratum or strata numbers should be drawn; it is probably best to select them all (as long as work is required in all of them) since CallWeb CATI manages time zone requirements by itself based on the calling times defined in BASEprojets;
    • select an automatic update frequency or Never for manual updates;
    • select a type of appointment management (relevant only in automatic updates) or None for no appointment management:
      • Massive appointment management: appointment calls are made by the interviewer available next in the project without regard for the identity of the interviewer who took the appointment.
      • Passive personalized appointment management: appointment calls are by the interviewer who took the appointment; if this interviewer is not available in the project, the appointment is missed.
      • Active personalized appointment management: in principle, appointment calls are by the interviewer who took the appointment; if this interviewer is not available in the project, 5 minutes after the appointment time, the number is attributed to the interviewer available next in the project.
    • determine how long the interviewer reserves a case when it is automatically brought to their attention;
    • click Submit to initiate the update; every minute, the server verifies whether it must perform an update, therefore it can take that long before the update is initiated;
    • the Reinitialize button empties the call queue; this is done without further warning.

Manage telephone numbers

In a CATI context, managing telephone numbers means identifying which telephone numbers must be made available to interviewers, and repeating this identification so as to make the most efficient use of the sample. In CallWeb CATI, this is accomplished in supervision modules which are entered via the cwsuper.cgi program. Any number of projects may by managed from one supervision workstation.

Principles

The principles of telephone number management implemented in CallWeb are as follows:

  • only numbers that have been selected explicitly to be accessed by interviewers are available to them (in the call queue);
  • numbers are added to the call queue only via the cwsuper.cgi update process;
  • updates may be done manually upon request or automatically at regular intervals; automatic updates probably shouldn't be done more often than every 10 minutes; a 20-minute interval has proven effective;
  • each manual update may include different sets of criteria and, hence, draw different types of numbers for interviewer usage;
  • appointments are automatically brought into the cann queue if the automatic update is selected;
  • automatic updates use the update parameters last entered; while previous updates may have left their selected numbers in the call queue, only numbers corresponding to the criteria last entered by the supervisor (and appointments, automatically) are added during automatic updates;
  • once a telephone number has been selected by an interviewer, it is reserved for their use for a period that is selected by the supervisor;

Supervision interface

From the cwsuper.cgi module, the supervisor selects one project to manage. Then, a menu such as the following is displayed.

This main supervision and field management menu is comprised of three areas:

  • the top part reports the number of telephone numbers in the current project call queue;
  • the right end-side lists existing call result codes; the supervisor selects the types of calls that they want added to the call queue and the delay between the last call and a new attempt; this section also allows for the inclusion of additional new cases (that have never been called);
  • the left end-side describes the specifics of the update request:
    • enter the last-call dates for the numbers you want brought into the call queue; this is normally left to default to a very large period of time to avoid losing cases;
    • determine the number of previous calls above which a number will not be brought into the call queue;
    • identify from which stratum or strata numbers should be drawn; it is probably best to select them all (as long as work is required in all of them) since CallWeb CATI manages time zone requirements by itself based on the calling times defined in BASEprojets;
    • select an automatic update frequency or Never for manual updates;
    • select a type of appointment management (relevant only in automatic updates) or None for no appointment management:
      • Massive appointment management: appointment calls are made by the interviewer available next in the project without regard for the identity of the interviewer who took the appointment.
      • Passive personalized appointment management: appointment calls are by the interviewer who took the appointment; if this interviewer is not available in the project, the appointment is missed.
      • Active personalized appointment management: in principle, appointment calls are by the interviewer who took the appointment; if this interviewer is not available in the project, 5 minutes after the appointment time, the number is attributed to the interviewer available next in the project.
    • determine how long the interviewer reserves a case when it is automatically brought to their attention;
    • click Submit to initiate the update; every minute, the server verifies whether it must perform an update, therefore it can take that long before the update is initiated;
    • the Reinitialize button empties the call queue; this is done without further warning.

   

Attribution of telephone numbers

There are two ways to attribute telephone numbers to interviewers: manually via the Search function or automatically. In the manual Search, the interviewer is provided with a list of numbers to call and they use them to query the data base. This is an adequate approach to focus specifically on certain cases (say, in-bound calls) but it is not an efficient way to manage the call queue or interviewer time. For this, use the automated attribution of cases.

When numbers are attributed automatically (by the interviewer simply requesting a New number), CallWeb scans the call queue and identifies the next priority number. The following logic is applied:

  • only numbers corresponding to the interviewer and time constraints are considered. The following cases are discarded:
  • within the pool of available numbers, cases are dispatched with the following priorites:
    • appointments have the highest priority but their priority diminishes as one moves away from the appointment time (e.g., if appointments were due at 10:00, 10:05 and 10:10, the interviewer requesting the next case at 10:11 is given the 10:10 appointment); appointments are defined as disposition codes requiring a callback date; if an appointment is missed by more than 30 minutes, it is dispatched only if the respondent's time is within the project working hour — otherwise, appointments are respected, even outside project working hours;
    • cases with fewest calls come next so as to equalize the number of times cases are attempted;
    • call disposition codes with shorter return-to-the-queue times have a higher priority of selection than cases with longer return times (e.g., busy results with a return time of 30 minutes have a higher priority than no-answer results with a return time of 4 hours);
    • untouched cases have the lowest priority;
    • if refusals are brought back into the call queue, a refusal which was followed by another call result is controlled by the latter disposition code.

Attribution of telephone numbers

There are two ways to attribute telephone numbers to interviewers: manually via the Search function or automatically. In the manual Search, the interviewer is provided with a list of numbers to call and they use them to query the data base. This is an adequate approach to focus specifically on certain cases (say, in-bound calls) but it is not an efficient way to manage the call queue or interviewer time. For this, use the automated attribution of cases.

When numbers are attributed automatically (by the interviewer simply requesting a New number), CallWeb scans the call queue and identifies the next priority number. The following logic is applied:

  • only numbers corresponding to the interviewer and time constraints are considered. The following cases are discarded:
  • within the pool of available numbers, cases are dispatched with the following priorites:
    • appointments have the highest priority but their priority diminishes as one moves away from the appointment time (e.g., if appointments were due at 10:00, 10:05 and 10:10, the interviewer requesting the next case at 10:11 is given the 10:10 appointment); appointments are defined as disposition codes requiring a callback date; if an appointment is missed by more than 30 minutes, it is dispatched only if the respondent's time is within the project working hour — otherwise, appointments are respected, even outside project working hours;
    • cases with fewest calls come next so as to equalize the number of times cases are attempted;
    • call disposition codes with shorter return-to-the-queue times have a higher priority of selection than cases with longer return times (e.g., busy results with a return time of 30 minutes have a higher priority than no-answer results with a return time of 4 hours);
    • untouched cases have the lowest priority;
    • if refusals are brought back into the call queue, a refusal which was followed by another call result is controlled by the latter disposition code.

   

Analyse productivity

cwprod.cgi, the productivity reporting module, works hand in hand with cwappels.pl to create and to exploit a data base of time spent on projects and results obtained.

Sources of information

cwappels.pl draws information from two sources to create the BASEprod data base (a CallWeb-format data base):

  • daily, during the night, cwappels.pl creates the BASEappels data base which documents each call found in live projects. In the process, it tags each call as a completed interview or a refusal based on the call results and their behaviour. The module also converts GMT-based times stored in the call history to the local server time;
  • time spent on projects is obtained from the BASEtemps data base — but only from time transactions which
    • have not yet been processed, to avoid double counting;
    • which are CATI-related according to a flag placed by the interviewer interface when it created the time transaction; and,
    • which are closed.

cwappels.cgi matches time transactions to call results at the interviewer + project + time level and stores the resulting data in BASEprod; it is normally called once a day, at night. Once a time transaction from BASEtemps has been processed, it is not re-analyzed. Therefore, modifications to time transactions after cwappels.cgi has processed them are disallowed.

Producing reports

The cwprod.cgi module queries the BASEprod data base according to projects or interviewers or dates or shifts and returns a number of self-explanatory indicators of performance (e.g., the number of completed questionnaires per hour).

One final composite index requires some explanation. Labelled "index", it accounts simultaneously for completes and refusals while recognizing that there are circumstances when completes and refusals have differing values. Specifically, the default index equation is as follows:

    ( c1 + 2c2 + 5c3 - 3r1 ) / hours
    where
    • c1 = number of questionnaires completed on the first call
    • c2 = number of questionnaires completed on subsequent calls
    • c3 = number of questionnaires completed after a refusal
    • r1 = number of first refusals (note that refusals after an initial refusal are not penalized)
    • hours = number of hours logged in BASEtemps

This default index can be redefined by entering a new calculation in the productivity_index installation option, which affects all projects, or by adding a new calculation as part of a # Productivity index pound instruction, on a project by project basis.

Analyse productivity

cwprod.cgi, the productivity reporting module, works hand in hand with cwappels.pl to create and to exploit a data base of time spent on projects and results obtained.

Sources of information

cwappels.pl draws information from two sources to create the BASEprod data base (a CallWeb-format data base):

  • daily, during the night, cwappels.pl creates the BASEappels data base which documents each call found in live projects. In the process, it tags each call as a completed interview or a refusal based on the call results and their behaviour. The module also converts GMT-based times stored in the call history to the local server time;
  • time spent on projects is obtained from the BASEtemps data base — but only from time transactions which
    • have not yet been processed, to avoid double counting;
    • which are CATI-related according to a flag placed by the interviewer interface when it created the time transaction; and,
    • which are closed.

cwappels.cgi matches time transactions to call results at the interviewer + project + time level and stores the resulting data in BASEprod; it is normally called once a day, at night. Once a time transaction from BASEtemps has been processed, it is not re-analyzed. Therefore, modifications to time transactions after cwappels.cgi has processed them are disallowed.

Producing reports

The cwprod.cgi module queries the BASEprod data base according to projects or interviewers or dates or shifts and returns a number of self-explanatory indicators of performance (e.g., the number of completed questionnaires per hour).

One final composite index requires some explanation. Labelled "index", it accounts simultaneously for completes and refusals while recognizing that there are circumstances when completes and refusals have differing values. Specifically, the default index equation is as follows:

    ( c1 + 2c2 + 5c3 - 3r1 ) / hours
    where
    • c1 = number of questionnaires completed on the first call
    • c2 = number of questionnaires completed on subsequent calls
    • c3 = number of questionnaires completed after a refusal
    • r1 = number of first refusals (note that refusals after an initial refusal are not penalized)
    • hours = number of hours logged in BASEtemps

This default index can be redefined by entering a new calculation in the productivity_index installation option, which affects all projects, or by adding a new calculation as part of a # Productivity index pound instruction, on a project by project basis.

   

Interviewing — Introduction

Interviewers are responsible for the selection of the types of calls they will make during their shift. CallWeb CATI then feeds them one number after the other, as soon as they have provided a call result code for the number they were provided. Much of the interviewer work is done from a single screenful of information.

Interviewing — Introduction

Interviewers are responsible for the selection of the types of calls they will make during their shift. CallWeb CATI then feeds them one number after the other, as soon as they have provided a call result code for the number they were provided. Much of the interviewer work is done from a single screenful of information.

   

Log-in procedure

Interviewers must log into the CallWeb CATI system every time they start their shift and every time they need to change project or change the nature of the telephone numbers they want to handle within a project.

Interviewers enter the CallWeb CATI system using the int1acces.cgi script. They enter their user name and password as they were supplied in BASEpasse by the supervisor. They also specify in which language they want the interface to appear to them — the system default language is pre-selected.

Validation of the log-in is done immediately.

If they select the demonstration mode, interviewers are taken through exactly the same steps as they would in real mode (project selection, case selection, etc.) except none of their selections are saved, either in the call history or in the questionnaire itself.

Log-in procedure

Interviewers must log into the CallWeb CATI system every time they start their shift and every time they need to change project or change the nature of the telephone numbers they want to handle within a project.

Interviewers enter the CallWeb CATI system using the int1acces.cgi script. They enter their user name and password as they were supplied in BASEpasse by the supervisor. They also specify in which language they want the interface to appear to them — the system default language is pre-selected.

Validation of the log-in is done immediately.

If they select the demonstration mode, interviewers are taken through exactly the same steps as they would in real mode (project selection, case selection, etc.) except none of their selections are saved, either in the call history or in the questionnaire itself.

   

Selecting a project, strata and types of calls

Once logged-in, the interviewer is shown the list of all active projects. He/she clicks on the button corresponding to the project he/she was attributed for the shift.

The interviewer then needs to identify the cases he/she was told to work on. The case selection is always based on the stratum membership and on call dispositions, at a minimum. It is possible to add a third selection criterion, as is displayed below and as is explained on the next page.

int2select

If call groups are defined for the project, the interviewer case selection windows includes a radio group (as in the exemple above) which includes each of the groups defined as well as the capacity to make an ad hoc selection. Interviewers are expected to make the selection which corresponds to the instructions they were given.

The system asks for confirmation and validates these entries before proceeding with the interviewing process.

The selection made by the interviewer on this menu is stored in the BASEtemps data base for eventual audit.

Selecting a project, strata and types of calls

Once logged-in, the interviewer is shown the list of all active projects. He/she clicks on the button corresponding to the project he/she was attributed for the shift.

The interviewer then needs to identify the cases he/she was told to work on. The case selection is always based on the stratum membership and on call dispositions, at a minimum. It is possible to add a third selection criterion, as is displayed below and as is explained on the next page.

int2select

If call groups are defined for the project, the interviewer case selection windows includes a radio group (as in the exemple above) which includes each of the groups defined as well as the capacity to make an ad hoc selection. Interviewers are expected to make the selection which corresponds to the instructions they were given.

The system asks for confirmation and validates these entries before proceeding with the interviewing process.

The selection made by the interviewer on this menu is stored in the BASEtemps data base for eventual audit.

   

Selecting cases according to a third criterion

The previous page explained how interviewers are called upon to select a project to work on, and cases to access according to the project strata and the most recent call disposition.

Interviewers can also be offered a third criterion (beyond the strata and call dispositions) to select cases within a project. Interviewers could then select cases on the basis of, say, the respondent language or gender or any other (known or yet unknown) characteristic.

In order to activate this feature, the following steps must be taken:

  • the questionnaire must include a "# CATI selection 3" instruction which indicates which question in the questionnaire acts as the third selection criterion. The instruction syntax is as follows: # CATI selection 3 = question_name, YES|NO
    • the "question_name" must correspond to a question which exists in the questionnaire; its categories correspond to the relevant groupings of cases (e.g., a language question would contain all of the relevant language codes);
    • the YES|NO selection is called the "action field": if set to YES, it allows interviewers to modify the value of the datum from their call management window (e.g., it could allow them to enter a language code based on an answering machine message, where no language was known in advance).
  • the question indentified in the "# CATI selection 3" instruction must exist in the questionnaire; it should probably be of the STOCK type so that it is not displayed during the interview but this is not a requirement; if the action field is set to NO in the pound instruction, the question could be given an INFOCATI type so that the existing value is shown to interviewers.

Once this feature is activated, the following happens:

  • a third selection criterion box is displayed to interviewers in the login process; this box includes the categories of the target question in the questionnaire as well as an additional category representing the absence of data (e.g., no language information was available for the case);
  • interviewers select one or more of the third selection categories to draw cases from the call queue;
  • if the action field is set to YES, interviewers are shown a radio group (or a dropdown list if the SELECTION3 question bears the DROPDOWN type) of categories in their call management interface and they have the ability to change the existing data for the case they are managing.

Selecting cases according to a third criterion

The previous page explained how interviewers are called upon to select a project to work on, and cases to access according to the project strata and the most recent call disposition.

Interviewers can also be offered a third criterion (beyond the strata and call dispositions) to select cases within a project. Interviewers could then select cases on the basis of, say, the respondent language or gender or any other (known or yet unknown) characteristic.

In order to activate this feature, the following steps must be taken:

  • the questionnaire must include a "# CATI selection 3" instruction which indicates which question in the questionnaire acts as the third selection criterion. The instruction syntax is as follows: # CATI selection 3 = question_name, YES|NO
    • the "question_name" must correspond to a question which exists in the questionnaire; its categories correspond to the relevant groupings of cases (e.g., a language question would contain all of the relevant language codes);
    • the YES|NO selection is called the "action field": if set to YES, it allows interviewers to modify the value of the datum from their call management window (e.g., it could allow them to enter a language code based on an answering machine message, where no language was known in advance).
  • the question indentified in the "# CATI selection 3" instruction must exist in the questionnaire; it should probably be of the STOCK type so that it is not displayed during the interview but this is not a requirement; if the action field is set to NO in the pound instruction, the question could be given an INFOCATI type so that the existing value is shown to interviewers.

Once this feature is activated, the following happens:

  • a third selection criterion box is displayed to interviewers in the login process; this box includes the categories of the target question in the questionnaire as well as an additional category representing the absence of data (e.g., no language information was available for the case);
  • interviewers select one or more of the third selection categories to draw cases from the call queue;
  • if the action field is set to YES, interviewers are shown a radio group (or a dropdown list if the SELECTION3 question bears the DROPDOWN type) of categories in their call management interface and they have the ability to change the existing data for the case they are managing.

   

Automatic number, particular number or terminate

The interviewer now faces a decision as to the next task:

  • asking for a new telephone number to be supplied automatically by CallWeb CATI according to the scheduling priorities (New Number button);
  • entering a complete telephone number (with its 5-digit random suffix) to access a particular case (in the box, before clicking the Search button);
  • closing the work period and the time slip, getting ready to resume in another project, stratum or call status, or to have a cup of tea (button Close the work period).

    • int3travail

    Automatic number, particular number or terminate

    The interviewer now faces a decision as to the next task:

    • asking for a new telephone number to be supplied automatically by CallWeb CATI according to the scheduling priorities (New Number button);
    • entering a complete telephone number (with its 5-digit random suffix) to access a particular case (in the box, before clicking the Search button);
    • closing the work period and the time slip, getting ready to resume in another project, stratum or call status, or to have a cup of tea (button Close the work period).

      • int3travail

         

Managing a call

Whether the interviewer has requested an automatic number or a specific case, a menu resembling the one below is displayed.

int3travail

This menu is made up of four areas:

  • The top area relates to the telephone number selected. The number is displayed on a yellow button, ready to dial. This button is used to start the questionnaire in a new browser window in case the contact is successful. If the project parameters allow that interviewers modify the telephone number, two text boxes are offered in case a different telephone number needs to be recorded; this new number is saved with the "Save this number" button.
  • The middle left part of the menu supplies information on the case: the comment recorded as part of the last contact; the stratum to which the case belongs; any other data that was given the INFOCATI type; and, information on the last call. This is also where the appointment buttons are located (see last bullet).
  • The bottom left part of the menu gives the interviewer the choice of the operation that will follow the present case: either the system will supply another automatic number or it will display the three-way decision menu which allows to search for a particular number or to terminate a work session.
  • The right side of the menu lists possible result codes (remember that these result codes are not fixed but rather entirely customizable on a project by project basis). Once the interviewer has determined how the call ended (completion, refusal, etc.), he/she clicks on the appropriate button; this result is appended to the call history and the interviewer is supplied with the window selected in the bottom left portion of the current menu. The interview completion button is always first in the list. Appointment-related call results are listed to the left of the other call results. Call result buttons are colour-coded according to whether they allow (yellow), require (green) or disallow (red) the use of a comment (event if a comment is disallowed, it is possible to carry over a comment from a previous call using the radio group in the middle left portion of the menu).

A contact script (text) may be supplied in HTML format in file consigne.html in the CallWeb project directory. If such a file exists, it is hyperlinked to a button displayed in the middle left portion of the menu.

A better solution for contact scripts, though, is to use a CONTACT-type question. Such a question is not displayed as part of the normal questionnaire operation. If present in the questionnaire script, a button is added to the interviewer case management interface (labelled "contact script"). Clicking it pops a new window with the CONTACT question text. This text may contain recalled values (e.g., the name of the person to interview or any other information available in the data record).

If a # Historique = oui or # Historique = yes pound instruction exists in the questionnaire, the entire call history is hyperlinked to a button displayed in the middle left portion of the menu. Since this is an interviewer productivity killer, it is customarily not used. It is possible to display the call history without identification of the interviewers who logged the previous calls using this variation on this pound instructions: # Historique = oui, sans interviewer or # Historique = oui, without interviewer.

Managing a call

Whether the interviewer has requested an automatic number or a specific case, a menu resembling the one below is displayed.

int3travail

This menu is made up of four areas:

  • The top area relates to the telephone number selected. The number is displayed on a yellow button, ready to dial. This button is used to start the questionnaire in a new browser window in case the contact is successful. If the project parameters allow that interviewers modify the telephone number, two text boxes are offered in case a different telephone number needs to be recorded; this new number is saved with the "Save this number" button.
  • The middle left part of the menu supplies information on the case: the comment recorded as part of the last contact; the stratum to which the case belongs; any other data that was given the INFOCATI type; and, information on the last call. This is also where the appointment buttons are located (see last bullet).
  • The bottom left part of the menu gives the interviewer the choice of the operation that will follow the present case: either the system will supply another automatic number or it will display the three-way decision menu which allows to search for a particular number or to terminate a work session.
  • The right side of the menu lists possible result codes (remember that these result codes are not fixed but rather entirely customizable on a project by project basis). Once the interviewer has determined how the call ended (completion, refusal, etc.), he/she clicks on the appropriate button; this result is appended to the call history and the interviewer is supplied with the window selected in the bottom left portion of the current menu. The interview completion button is always first in the list. Appointment-related call results are listed to the left of the other call results. Call result buttons are colour-coded according to whether they allow (yellow), require (green) or disallow (red) the use of a comment (event if a comment is disallowed, it is possible to carry over a comment from a previous call using the radio group in the middle left portion of the menu).

A contact script (text) may be supplied in HTML format in file consigne.html in the CallWeb project directory. If such a file exists, it is hyperlinked to a button displayed in the middle left portion of the menu.

A better solution for contact scripts, though, is to use a CONTACT-type question. Such a question is not displayed as part of the normal questionnaire operation. If present in the questionnaire script, a button is added to the interviewer case management interface (labelled "contact script"). Clicking it pops a new window with the CONTACT question text. This text may contain recalled values (e.g., the name of the person to interview or any other information available in the data record).

If a # Historique = oui or # Historique = yes pound instruction exists in the questionnaire, the entire call history is hyperlinked to a button displayed in the middle left portion of the menu. Since this is an interviewer productivity killer, it is customarily not used. It is possible to display the call history without identification of the interviewers who logged the previous calls using this variation on this pound instructions: # Historique = oui, sans interviewer or # Historique = oui, without interviewer.

   

Time keeping

Interviewers enter the CallWeb CATI time reporting module using the int4temps.cgi script. They enter a start date and an end date for the report to be produced as well a their user name and password as they were supplied in BASEpasse by the supervisor.

int4temps

CallWeb CATI then produces a daily report of hours logged for the requested period.

Time keeping

Interviewers enter the CallWeb CATI time reporting module using the int4temps.cgi script. They enter a start date and an end date for the report to be produced as well a their user name and password as they were supplied in BASEpasse by the supervisor.

int4temps

CallWeb CATI then produces a daily report of hours logged for the requested period.

   

Appendix A

CATI Project initiation checklist

The following checklist is offered as a guide to control that all steps of the project installation process have been completed.

1

         

Edit the BASEprojets project to document the new project; make sure the project is labelled "active".
2

         

Edit the BASEpasse project to ensure that each interviewer has a user ID.
3

         

Insert a PRESTRATE question in the questionnaire.
4

         

Ensure that the PRESTRATE question text segment lists each active stratum along with the maximum number of cases that can be used from the sample in each case, as in 1=50, 2=100, 3=200 if the intent is to limit the number of cases used from stratum 1 to 50.
5

         

Insert a CALCTESTQUOTAS question in the questionnaire.
6

         

Ensure that the CALCTESTQUOTAS is a CALCUL question which defines the TESTQUOTAS question, as is TESTQUOTAS = $PRESTRATE.
7

         

Insert a TESTQUOTAS question in the questionnaire.
8

         

Ensure that the TESTQUOTAS syntax is respected:
 

         

the "complete" parameter should be the name of a question which will systematically contain something in completed questionnaires and systematically be empty in incomplete questionnaires; typically, the "complete" question is a BLANK question which is only accessed as part of a completed questionnaire;
 

         

the "skip" parameter should be the name of a question where cases beyond quotas are sent to display a Sorry message and terminate the interview; typically, the "skip" question is a CULDESAC and BACKWALL question which is only accessed as part of a quota-filled questionnaire; using display conditions or skips, make sure that the quota-filled cases do not have a value in the Complete question (unless quota-filled cases do constitute a complete case);
 

         

each active quota must be listed, along with the target number of completion as in 1=50, 2=100, 3=200 if the intent is to complete 50 questionnaires in stratum 1.
9

         

Make sure that there is one field in the questionnaire for each field that must be pre-populated. Plan to pre-populate non-numeric data with at most four digits into the main part of the question; other types of data must be pre-populated into the open-end part of the question. Ensure that the pre-populated fields which must be displayed to the interviewers are given an INFOCATI type.
10

         

Create a subdirectory in the CallWeb directory to store the project files. Prefix the subdirectory name with "cw" so that CallWeb recognizes it as a project directory. Give read and write permissions to "the world" and to the owner on that directory.
11

         

Copy a call result code file (.ccw) from another project into the project directory and name it according to the project name ("project.ccw").
12

         

Carefully review each result code in cwcodescati.cgi to ensure that the associated behaviours are appropriate for the current project; add new codes or delete old ones according to the requirements of the project.
13

         

Compile the project and ensure that there were no compilation errors. Correct errors and re-compile.
14

         

If appropriate, create an HTML page called "consigne.html" containing general instructions to interviewers and/or the contact text and place it in the project directory.
15

         

Create a tab-delimited file of data to be pre-populated which includes, at a minimum, for each case, the _telkey, the _telephone field and group membership in PRESTRATE.
 

         

Make sure that the first line of the file identifies correctly the field to be pre-populated: think through whether the main part or the open-end part of a question needs to be fed the data.
 

         

The simplest way to create this tab-delimited file is to use Excel to build a spreadsheet including the required calculations and to save the sheet as a "tab-delimited" file from within Excel.
16

         

Send the pre-population data file to the server and perform the pre-population.
 

         

Using cwnav.cgi, verify that the data were pre-populated as expected.
17

         

From the supervisor menu, add telephone numbers to the list accessible to interviewers.
 

         

Enter the number of New numbers to be made available.
 

         

Make sure to include all categories of results that should be automatically brought back to the attention of the interviewers on a regular basis (e.g., busy, no answer, but probably not fax and not in service).
 

         

Make sure to request automatic updates at least every 20 minutes.

Appendix A

CATI Project initiation checklist

The following checklist is offered as a guide to control that all steps of the project installation process have been completed.

1

         

Edit the BASEprojets project to document the new project; make sure the project is labelled "active".
2

         

Edit the BASEpasse project to ensure that each interviewer has a user ID.
3

         

Insert a PRESTRATE question in the questionnaire.
4

         

Ensure that the PRESTRATE question text segment lists each active stratum along with the maximum number of cases that can be used from the sample in each case, as in 1=50, 2=100, 3=200 if the intent is to limit the number of cases used from stratum 1 to 50.
5

         

Insert a CALCTESTQUOTAS question in the questionnaire.
6

         

Ensure that the CALCTESTQUOTAS is a CALCUL question which defines the TESTQUOTAS question, as is TESTQUOTAS = $PRESTRATE.
7

         

Insert a TESTQUOTAS question in the questionnaire.
8

         

Ensure that the TESTQUOTAS syntax is respected:
 

         

the "complete" parameter should be the name of a question which will systematically contain something in completed questionnaires and systematically be empty in incomplete questionnaires; typically, the "complete" question is a BLANK question which is only accessed as part of a completed questionnaire;
 

         

the "skip" parameter should be the name of a question where cases beyond quotas are sent to display a Sorry message and terminate the interview; typically, the "skip" question is a CULDESAC and BACKWALL question which is only accessed as part of a quota-filled questionnaire; using display conditions or skips, make sure that the quota-filled cases do not have a value in the Complete question (unless quota-filled cases do constitute a complete case);
 

         

each active quota must be listed, along with the target number of completion as in 1=50, 2=100, 3=200 if the intent is to complete 50 questionnaires in stratum 1.
9

         

Make sure that there is one field in the questionnaire for each field that must be pre-populated. Plan to pre-populate non-numeric data with at most four digits into the main part of the question; other types of data must be pre-populated into the open-end part of the question. Ensure that the pre-populated fields which must be displayed to the interviewers are given an INFOCATI type.
10

         

Create a subdirectory in the CallWeb directory to store the project files. Prefix the subdirectory name with "cw" so that CallWeb recognizes it as a project directory. Give read and write permissions to "the world" and to the owner on that directory.
11

         

Copy a call result code file (.ccw) from another project into the project directory and name it according to the project name ("project.ccw").
12

         

Carefully review each result code in cwcodescati.cgi to ensure that the associated behaviours are appropriate for the current project; add new codes or delete old ones according to the requirements of the project.
13

         

Compile the project and ensure that there were no compilation errors. Correct errors and re-compile.
14

         

If appropriate, create an HTML page called "consigne.html" containing general instructions to interviewers and/or the contact text and place it in the project directory.
15

         

Create a tab-delimited file of data to be pre-populated which includes, at a minimum, for each case, the _telkey, the _telephone field and group membership in PRESTRATE.
 

         

Make sure that the first line of the file identifies correctly the field to be pre-populated: think through whether the main part or the open-end part of a question needs to be fed the data.
 

         

The simplest way to create this tab-delimited file is to use Excel to build a spreadsheet including the required calculations and to save the sheet as a "tab-delimited" file from within Excel.
16

         

Send the pre-population data file to the server and perform the pre-population.
 

         

Using cwnav.cgi, verify that the data were pre-populated as expected.
17

         

From the supervisor menu, add telephone numbers to the list accessible to interviewers.
 

         

Enter the number of New numbers to be made available.
 

         

Make sure to include all categories of results that should be automatically brought back to the attention of the interviewers on a regular basis (e.g., busy, no answer, but probably not fax and not in service).
 

         

Make sure to request automatic updates at least every 20 minutes.

   

Appendix B

Recent changes and additions

DateChange / addition
November 30, 2015Creation of the agents data base table upon need.
February 14, 2015Addition of the # Other n in cwsuper pound instruction.
July 14, 2014Addition of Break, Coaching, and Training buttons on the case selection screen.
July 12, 2014Every QUOTA variable is indexed in the database to speed up call queue updates.
November 26, 2012Addition of the capacity to save and reload call queue update schemes.
November 20, 2012The calling time window can be defined independently for each day of the week, as well as separately for each call group.
November 28, 2011The batch dialer can be used with batches of one, eliminating the need for an agent queue, and answering machine detection is optional.
September 8, 2011Call disposition codes can be reordered within categories and alphabetically in cwcodescati.cgi.
August 27, 2011Call disposition codes can now be attributed display conditions.
August 24, 2011Several batch dialer disposition codes can be mapped to the same CallWeb call disposition code.
August 17, 2011Extension of the ability to flag bad telephone numbers available as INFOCATI "T"-type open-end parts: a list of categories of situations can be displayed as a dropdown in the interviewer interface.
August 16, 2011The batch dialer senses a situation where all channels are used and adapts.
April 20, 2011Addition of a predictive/batch dialer which automatically interprets call results, stores them in the CallWeb call history and passes live calls to interviewers/agents.
November 18, 2010Support added for Asterisk 1.6.
July 5, 2010Addition of the "no interface" option to cwphone.cgi.
April 7, 2010The SELECTION3 variable can be defined as a DROPDOWN question, in which case it is presented as such to the interviewer.
March 11, 2010cwnav.cgi can reassign GMT offsets massively when the telephone number GMT offets are changed (for example, Saskatchewan in Canada).
December 5, 2009Addition of CSS control over the CATI buttons.
November 23, 2009Addition of interviewer personal notes.
September 13, 2009Call disposition codes can be attributed a permission level such that they are displayed to interviewers or not according to the level of permission assigned to the interviewer.
August 19, 2009Only CATI projects (i.e., those with disposition codes) are offered to interviewers during their login procedure (thus excluding Web projects in the same instance).
July 18, 2009Addition of a new module, cwsuperplan.cgi, which calculates the projected callback queue for all active projects.
July 16, 2009Addition of the # Basic call management pound instruction to control the type of delay values used in call queue management.
July 8, 2009The call history can be displayed without identification of the interviewers who logged the calls.
February 11, 2009The productivity reporting module reports the number of calls made per hour excluding time spent toward completed interviews.
February 9, 2009Interviewers are offered a Switch projects button so that they can change projects without having to log out and back in.
February 8, 2009Addition of the "training mode" that displays the questionnaire without consideration for the skips and display conditions and which does not substitute response recalls. This is meant as a demonstration mode for interviewer training.
December 2, 2008Addition of the $contexte{interviewer} key that contains the name of the interviewer as stored in the questionnaire record (_stock field).
November 24, 2008Addition of an automatic quota closure mechanism in CATI mode.
August 28, 2008The field management module (cwsuper.cgi) is fully customizable such that only key information can be displayed, making it cell-phone browser friendly.
June 23, 2008The field management module (cwsuper.cgi) calculates projected interviewer hours required to complete a project and reports variance with budgeted hours.
May 31, 2008The default interviewer productivity index may now be redefined across projects using the productivity_index installation option or on a project by project basis using the "Productivity index" pound instruction.
May 30, 2008Monitoring of interviews is now possible for external telephone numbers.
May 24, 2008Users of the CallWeb dialer based on the Asterisk PBX can now display the entire call history of a particular telephone number in the cwphone.cgi module.
May 9, 2008Correction of the way the VERBATIM question type treats multiple-response questions. A bug-fix, really.
May 6, 2006The Do-not-call list is now real-time: a number found in the list is not dialled — in addition to not being prepopulated at the outset. This allows for immediate action on respondent requests.
March 31, 2008New asynchronous messaging system for supervisors integrated in the CATI control centre.
March 13, 2008A group label can be added to projects in BASEprojets. It is used to group projects on the CATI control centre page.
February 12, 2008New shift_start_time_ installation instruction controls the time of day stored in time transactions at the beginning of shifts.
February 11, 2008Modification of the case reservation procedure to dispatch cases without locking tables while avoiding double dispatch.
February 11, 2008Addition of the ability for interviewers to search for a case across multiple projects. This is particularly useful for the in-bound component of projects.
February 7, 2008Addition of the ability to flag bad telephone numbers available as INFOCATI "T"-type open-end parts.
February 7, 2008Addition of drill-down links in cwprod to ease the analysis of the productivity data.
February 2, 2008Addition of a messaging system for supervisors to instruct interviewers. Interviewers can be selected by projects they work on.
December 4, 2007A new CONTACT type of question acts as a contact script for telephone interviews.
December 1, 2007The Linear CATI mode pound instruction changes the system behaviour such that the questionnaire opens in the same window as the call management screen and a button is displayed at the top of the questionnaire to return to the call management screen.
November 26, 2007The Maximum interviewers pound instruction controls how many interviewers can log into a project at once.
October 18, 2007Call results are stored (and immediately accessible) in BASEappels as soon as the interviewer registers one. Thus, supervisors can get real-time data on call results by polling BASEappels and interviewers get reliable counts on their result buttons.
October 4, 2007Addition of supervisor control over the priority of callbacks, i.e., numbers least used first (the rule up to now) vs. numbers most used first.
October 2, 2007cwnav can scan BASEtemps looking for overlapping and open transactions. The results are stored in the ERROR BASEtemps field.
October 2, 2007Interviewers can be defined in BASEpasse as not accruing time in BASEtemps.
October 1, 2007Addition of various fields in BASEpasse and BASEtemps in preparation for additional features. THIS UPDATE REQUIRES RECOMPILING BASEpasse and BASEtemps.
September 29, 2007Addition of ability to select a subset of data columns in cwprod.
September 29, 2007Addition of the average duration of the completed questionnaires in cwprod. THIS UPDATE REQUIRES RECOMPILING BASEprod.
September 27, 2007Addition of the capacity for interviewers to visualize their own time accumulated in CallWeb data bases.
September 24, 2007Tighter control of the call queue: interviewers must enter a call result before requesting another number. NOTE: this change requires that the call back queues be updated from the CATI center module.
September 20, 2007Addition of a field to the call queue to identify the interviewer who reserved a particular case.
September 18, 2007The number of call results of each type obtained during the day is displayed to the interviewer.
September 18, 2007Addition of a short version of the field result report.
September 3, 2007Extension of the interviewer demonstration mode. In the new demo mode, interviewers are taken through all of the steps of the real mode but none of their inputs are saved in the data bases.
September 1, 2007Addition of the mass modification of call result codes.
August 31, 2007Addition the Supervisor Password pound instruction to control access to the call queue management.
August 31, 2007Addition of supervisor functions to control the call back queue.
May 31, 2007A new option controls the display of appointment schedules in the cwsuper.cgi module.
May 24, 2007The cwsuper.cgi module can display real time counts of completed questionnaires. It can also can report the activity in non-CATI projects.
April 23, 2007The State of the Fieldwork table now includes all quota testing questions.
April 20, 2007Modification to the classification scheme for disposition codes and of the calculation of response rates to respect new MRIA/Statistics Canada standards. CAUTION: this update requires that CATI code classification be revised in active projects for the response rate calculation to work.
April 19, 2007The contrain_to_groups installation instruction controls the display of the free selection of cases when groups exist for a CATI project.
March 27, 2007Added the ability to play audio files during interviews..
March 7, 2007The interviewer appointment clock can be displayed as a 12-hour clock or as a 24-hour clock.
March 1, 2007Appointments are dispatched no earlier than two minutes before the appointment time; appointments outside of normal project hours are not dispatched if missed by more than 30 minues.
February 13, 2007Interviewers can change their own password if the system installation includes the allow_password_change_by_interviewers option.
February 9, 2007Addition of a demo or practice mode for interviewers; they can work in the questionnaire without saving any data.
February 2, 2007The identification of the last human contact among call results was speeded up and made available in data extraction.
January 16, 2007Addition of a selection criterion in cwnav to identify cases which have been attributed for interviews.
December 11, 2006Time zones may be defined at the telephone exchange level to accommodate exceptions to the area code rules.
December 8, 2006Working hand in hand with the Asterisk PBX software, cwphone.cgi documents current telephone activity and initiates audio-visual supervision.
December 6, 2006Various adjustments to avoid that the same case be distributed to two interviewers simultaneously.
October 28, 2006Interview groups are now dynamic: changes made by supervisors to group definitions are automatically dispatched to interviewers.
October 26, 2006Addition of interview groups and of the capacity for interviewers to request cases on the basis of these groups.
October 25, 2006Addition of a third selection criterion for pulling cases from the data base.
October 24, 2006New CATI selection 3 pound instruction.
August 16, 2006Addition of a Do-not-call list feature using the BASEdonotcall project and the "Use do not call list" and "Do not call email" pound instructions.
August 13, 2006Complete integration with the Asterisk open source PBX.
August 8, 2006The "state of the call queue" button in cwsuper.cgi now displays the average number of calls per case.
August 8, 2006New selection criterion in all utility programs allowing focus on cases inside or outside the call queue.
August 8, 2006New installation options to control the permissible delay between the recording of two calls to the same case.
July 31, 2006New installation options to control the size of the comment entry box for interviewers.
June 7, 2006New option to report on the most recent call or the most recent human contact in cwoutcomes.cgi.
May 22, 2006Addition of the cwprod.cgi productivity reporting module..
February 19, 2006Each project has its own earliest and latest call times which are enforced upon assignment of telephone numbers such that a number will not be dispatched to be called outside of this time bracket.
February 19, 2006Call times and appointment times are stored in GMT time.
February 13, 2006A search for a particular record performed by an interviewer can now use _telkey or _telephone as well as be based on the full field, the beginning of the field or any part of the field.
February 13, 2006The telephone number (in the _telephone field) is now distinct from the case key (_telkey).
February 10, 2006The new VERBATIM question type allows for the easy cleaning of character open-ends at the end of an interview.
January 18, 2006The priority given to each case in the call-back list depends, in part, on the most recent call result (i.e., call results with short latency are given more priority than call results with long latency).
January 18, 2006The pace at which cases are brought back into the interviewing pool can be adjusted to the previous call result code (e.g., Busy signals can be brought back to interviewers faster than No answer calls).
January 18, 2006Acceleration of the interviewer login.

Appendix B

Recent changes and additions

DateChange / addition
November 30, 2015Creation of the agents data base table upon need.
February 14, 2015Addition of the # Other n in cwsuper pound instruction.
July 14, 2014Addition of Break, Coaching, and Training buttons on the case selection screen.
July 12, 2014Every QUOTA variable is indexed in the database to speed up call queue updates.
November 26, 2012Addition of the capacity to save and reload call queue update schemes.
November 20, 2012The calling time window can be defined independently for each day of the week, as well as separately for each call group.
November 28, 2011The batch dialer can be used with batches of one, eliminating the need for an agent queue, and answering machine detection is optional.
September 8, 2011Call disposition codes can be reordered within categories and alphabetically in cwcodescati.cgi.
August 27, 2011Call disposition codes can now be attributed display conditions.
August 24, 2011Several batch dialer disposition codes can be mapped to the same CallWeb call disposition code.
August 17, 2011Extension of the ability to flag bad telephone numbers available as INFOCATI "T"-type open-end parts: a list of categories of situations can be displayed as a dropdown in the interviewer interface.
August 16, 2011The batch dialer senses a situation where all channels are used and adapts.
April 20, 2011Addition of a predictive/batch dialer which automatically interprets call results, stores them in the CallWeb call history and passes live calls to interviewers/agents.
November 18, 2010Support added for Asterisk 1.6.
July 5, 2010Addition of the "no interface" option to cwphone.cgi.
April 7, 2010The SELECTION3 variable can be defined as a DROPDOWN question, in which case it is presented as such to the interviewer.
March 11, 2010cwnav.cgi can reassign GMT offsets massively when the telephone number GMT offets are changed (for example, Saskatchewan in Canada).
December 5, 2009Addition of CSS control over the CATI buttons.
November 23, 2009Addition of interviewer personal notes.
September 13, 2009Call disposition codes can be attributed a permission level such that they are displayed to interviewers or not according to the level of permission assigned to the interviewer.
August 19, 2009Only CATI projects (i.e., those with disposition codes) are offered to interviewers during their login procedure (thus excluding Web projects in the same instance).
July 18, 2009Addition of a new module, cwsuperplan.cgi, which calculates the projected callback queue for all active projects.
July 16, 2009Addition of the # Basic call management pound instruction to control the type of delay values used in call queue management.
July 8, 2009The call history can be displayed without identification of the interviewers who logged the calls.
February 11, 2009The productivity reporting module reports the number of calls made per hour excluding time spent toward completed interviews.
February 9, 2009Interviewers are offered a Switch projects button so that they can change projects without having to log out and back in.
February 8, 2009Addition of the "training mode" that displays the questionnaire without consideration for the skips and display conditions and which does not substitute response recalls. This is meant as a demonstration mode for interviewer training.
December 2, 2008Addition of the $contexte{interviewer} key that contains the name of the interviewer as stored in the questionnaire record (_stock field).
November 24, 2008Addition of an automatic quota closure mechanism in CATI mode.
August 28, 2008The field management module (cwsuper.cgi) is fully customizable such that only key information can be displayed, making it cell-phone browser friendly.
June 23, 2008The field management module (cwsuper.cgi) calculates projected interviewer hours required to complete a project and reports variance with budgeted hours.
May 31, 2008The default interviewer productivity index may now be redefined across projects using the productivity_index installation option or on a project by project basis using the "Productivity index" pound instruction.
May 30, 2008Monitoring of interviews is now possible for external telephone numbers.
May 24, 2008Users of the CallWeb dialer based on the Asterisk PBX can now display the entire call history of a particular telephone number in the cwphone.cgi module.
May 9, 2008Correction of the way the VERBATIM question type treats multiple-response questions. A bug-fix, really.
May 6, 2006The Do-not-call list is now real-time: a number found in the list is not dialled — in addition to not being prepopulated at the outset. This allows for immediate action on respondent requests.
March 31, 2008New asynchronous messaging system for supervisors integrated in the CATI control centre.
March 13, 2008A group label can be added to projects in BASEprojets. It is used to group projects on the CATI control centre page.
February 12, 2008New shift_start_time_ installation instruction controls the time of day stored in time transactions at the beginning of shifts.
February 11, 2008Modification of the case reservation procedure to dispatch cases without locking tables while avoiding double dispatch.
February 11, 2008Addition of the ability for interviewers to search for a case across multiple projects. This is particularly useful for the in-bound component of projects.
February 7, 2008Addition of the ability to flag bad telephone numbers available as INFOCATI "T"-type open-end parts.
February 7, 2008Addition of drill-down links in cwprod to ease the analysis of the productivity data.
February 2, 2008Addition of a messaging system for supervisors to instruct interviewers. Interviewers can be selected by projects they work on.
December 4, 2007A new CONTACT type of question acts as a contact script for telephone interviews.
December 1, 2007The Linear CATI mode pound instruction changes the system behaviour such that the questionnaire opens in the same window as the call management screen and a button is displayed at the top of the questionnaire to return to the call management screen.
November 26, 2007The Maximum interviewers pound instruction controls how many interviewers can log into a project at once.
October 18, 2007Call results are stored (and immediately accessible) in BASEappels as soon as the interviewer registers one. Thus, supervisors can get real-time data on call results by polling BASEappels and interviewers get reliable counts on their result buttons.
October 4, 2007Addition of supervisor control over the priority of callbacks, i.e., numbers least used first (the rule up to now) vs. numbers most used first.
October 2, 2007cwnav can scan BASEtemps looking for overlapping and open transactions. The results are stored in the ERROR BASEtemps field.
October 2, 2007Interviewers can be defined in BASEpasse as not accruing time in BASEtemps.
October 1, 2007Addition of various fields in BASEpasse and BASEtemps in preparation for additional features. THIS UPDATE REQUIRES RECOMPILING BASEpasse and BASEtemps.
September 29, 2007Addition of ability to select a subset of data columns in cwprod.
September 29, 2007Addition of the average duration of the completed questionnaires in cwprod. THIS UPDATE REQUIRES RECOMPILING BASEprod.
September 27, 2007Addition of the capacity for interviewers to visualize their own time accumulated in CallWeb data bases.
September 24, 2007Tighter control of the call queue: interviewers must enter a call result before requesting another number. NOTE: this change requires that the call back queues be updated from the CATI center module.
September 20, 2007Addition of a field to the call queue to identify the interviewer who reserved a particular case.
September 18, 2007The number of call results of each type obtained during the day is displayed to the interviewer.
September 18, 2007Addition of a short version of the field result report.
September 3, 2007Extension of the interviewer demonstration mode. In the new demo mode, interviewers are taken through all of the steps of the real mode but none of their inputs are saved in the data bases.
September 1, 2007Addition of the mass modification of call result codes.
August 31, 2007Addition the Supervisor Password pound instruction to control access to the call queue management.
August 31, 2007Addition of supervisor functions to control the call back queue.
May 31, 2007A new option controls the display of appointment schedules in the cwsuper.cgi module.
May 24, 2007The cwsuper.cgi module can display real time counts of completed questionnaires. It can also can report the activity in non-CATI projects.
April 23, 2007The State of the Fieldwork table now includes all quota testing questions.
April 20, 2007Modification to the classification scheme for disposition codes and of the calculation of response rates to respect new MRIA/Statistics Canada standards. CAUTION: this update requires that CATI code classification be revised in active projects for the response rate calculation to work.
April 19, 2007The contrain_to_groups installation instruction controls the display of the free selection of cases when groups exist for a CATI project.
March 27, 2007Added the ability to play audio files during interviews..
March 7, 2007The interviewer appointment clock can be displayed as a 12-hour clock or as a 24-hour clock.
March 1, 2007Appointments are dispatched no earlier than two minutes before the appointment time; appointments outside of normal project hours are not dispatched if missed by more than 30 minues.
February 13, 2007Interviewers can change their own password if the system installation includes the allow_password_change_by_interviewers option.
February 9, 2007Addition of a demo or practice mode for interviewers; they can work in the questionnaire without saving any data.
February 2, 2007The identification of the last human contact among call results was speeded up and made available in data extraction.
January 16, 2007Addition of a selection criterion in cwnav to identify cases which have been attributed for interviews.
December 11, 2006Time zones may be defined at the telephone exchange level to accommodate exceptions to the area code rules.
December 8, 2006Working hand in hand with the Asterisk PBX software, cwphone.cgi documents current telephone activity and initiates audio-visual supervision.
December 6, 2006Various adjustments to avoid that the same case be distributed to two interviewers simultaneously.
October 28, 2006Interview groups are now dynamic: changes made by supervisors to group definitions are automatically dispatched to interviewers.
October 26, 2006Addition of interview groups and of the capacity for interviewers to request cases on the basis of these groups.
October 25, 2006Addition of a third selection criterion for pulling cases from the data base.
October 24, 2006New CATI selection 3 pound instruction.
August 16, 2006Addition of a Do-not-call list feature using the BASEdonotcall project and the "Use do not call list" and "Do not call email" pound instructions.
August 13, 2006Complete integration with the Asterisk open source PBX.
August 8, 2006The "state of the call queue" button in cwsuper.cgi now displays the average number of calls per case.
August 8, 2006New selection criterion in all utility programs allowing focus on cases inside or outside the call queue.
August 8, 2006New installation options to control the permissible delay between the recording of two calls to the same case.
July 31, 2006New installation options to control the size of the comment entry box for interviewers.
June 7, 2006New option to report on the most recent call or the most recent human contact in cwoutcomes.cgi.
May 22, 2006Addition of the cwprod.cgi productivity reporting module..
February 19, 2006Each project has its own earliest and latest call times which are enforced upon assignment of telephone numbers such that a number will not be dispatched to be called outside of this time bracket.
February 19, 2006Call times and appointment times are stored in GMT time.
February 13, 2006A search for a particular record performed by an interviewer can now use _telkey or _telephone as well as be based on the full field, the beginning of the field or any part of the field.
February 13, 2006The telephone number (in the _telephone field) is now distinct from the case key (_telkey).
February 10, 2006The new VERBATIM question type allows for the easy cleaning of character open-ends at the end of an interview.
January 18, 2006The priority given to each case in the call-back list depends, in part, on the most recent call result (i.e., call results with short latency are given more priority than call results with long latency).
January 18, 2006The pace at which cases are brought back into the interviewing pool can be adjusted to the previous call result code (e.g., Busy signals can be brought back to interviewers faster than No answer calls).
January 18, 2006Acceleration of the interviewer login.

   

Appendix C

Time data in CallWeb

There are two types of time data in CallWeb:

  • timestamps related to the questionnaires (questionnaire initiation time and prepopulation time); these are stored in server time, that is, the time returned by the server, within its time zone;
  • timestamps related to interviews (call time and appointment time); these are stored in GMT time so that the current time for the respondent can be calculated easily, but they are displayed in server time, and so that multiple CallWeb servers located in different time zones can collaborate on a single project.

Appendix C

Time data in CallWeb

There are two types of time data in CallWeb:

  • timestamps related to the questionnaires (questionnaire initiation time and prepopulation time); these are stored in server time, that is, the time returned by the server, within its time zone;
  • timestamps related to interviews (call time and appointment time); these are stored in GMT time so that the current time for the respondent can be calculated easily, but they are displayed in server time, and so that multiple CallWeb servers located in different time zones can collaborate on a single project.

   

Appendix D

Audio-visual supervision

Technical requirements. Audio supervision is accomplished via the telephone system. Using the Asterisk PBX system, CallWeb offers a way to easily connect with an on-going call. Video supervision is implemented using a VNC server installed on each interviewer station and a VNC client running on the supervisor station. TightVNC is a free implementation of the VNC protocol which has performed well in various installations. Refer to the TightVNC documentation for installation instructions relative to that software. The following assume the pre-installation of the Asterisk PBX and of TightVNC.

Operations. cwphone.cgi lists the phones lines in use and matches them with interviewer station IP addresses, interviewer name and project. The duration of the on-going call is also indicated. Once the supervisor station phone extension is supplied to cwphone.cgi, magnifying glass links are added to the page; clicking on one of them connects the supervisor phone to the on-going interview and pops a window showing the current state of the interviewer display.

Accessing recordings. If interview recording is activated in BASEprojets, corresponding .wav and .mp3 files are accessible from cwnav.cgi. Usual cwnav.cgi case selection tools can be used to focus on the cases of interest (e.g. completed interviews or cases handled by a certain interviewer). Selecting the "Display .wav/.mp3 files" checkbox adds a .wav/.mp3 column in the case-by-case output. Sound files are hyperlinked such that left-clicking opens the file with the sound application available on the local computer; it is also possible to save a local copy of the sound file by selecting the "Save target as" (or equivalent) command in the right-click context menu.

To the extent possible, sound file names give some indication about the content of the file. The name displayed starts with the date and time of the call, followed by the call sequence number (1 for the first call in a case), the language of the call (if available) and an indication of whether the call was a completed interview (CO) or not (UN). For example, in the image to the right, the last case contains a call made on October 14, 2009 at 8:22PM; it was the first call to the case and it led to a completed interview in French.

The real name of the file is longer than that displayed in cwnav.cgi. The underlying complete file name is prefixed with the project name and the case _telkey.


Installation. Assuming Asterisk and TightVNC are up and running, the rest of the installation required is as follows.

  • add the following context in /etc/asterisk/extension.conf and reload the Asterisk contexts:
    [ext-ecoute]
    exten => 8888,1,Answer
    exten => 8888,n,NoOp(cwphone.pl: ecoute=${ecoute})
    exten => 8888,n,ChanSpy(SIP/${ecoute}|q)
    exten => 8888,n,Hangup
  • on the Asterisk server, ensure that the supervisor station has access to the PBX software in /etc/asterisk/manager.conf
  • on the supervisor station:
    • ensure that "vncviewer" is installed
    • ensure that Perl is installed (which it is by default on a Linux station)
    • install the Net::Telnet Perl module
      • perl -MCPAN -e shell
      • install Net::Telnet
      • exit
    • copy the cwphone.pl script on the supervisor station and note down its location
    • install Firefox (version 1.5 or more)
    • in Firefox, install the StartALocalProgram extension (may require issuing the following command at the system prompt: "firefox startalocalprogram.xpi"; restart Firefox after installation)
    • in Firefox, enter the URL about:config and edit the following keys:
      • put the full path to Perl (usually /usr/bin/perl) in the following keys: extensions.startalocalprogram.launcherLocation and extensions.startalocalprogram.launcherLocation.linux (or mac or windows)
      • put the full path to cwphone.pl in the following keys: extensions.startalocalprogram.programToLaunch and extensions.startalocalprogram.programToLaunch.linux (or mac or windows)

Appendix D

Audio-visual supervision

Technical requirements. Audio supervision is accomplished via the telephone system. Using the Asterisk PBX system, CallWeb offers a way to easily connect with an on-going call. Video supervision is implemented using a VNC server installed on each interviewer station and a VNC client running on the supervisor station. TightVNC is a free implementation of the VNC protocol which has performed well in various installations. Refer to the TightVNC documentation for installation instructions relative to that software. The following assume the pre-installation of the Asterisk PBX and of TightVNC.

Operations. cwphone.cgi lists the phones lines in use and matches them with interviewer station IP addresses, interviewer name and project. The duration of the on-going call is also indicated. Once the supervisor station phone extension is supplied to cwphone.cgi, magnifying glass links are added to the page; clicking on one of them connects the supervisor phone to the on-going interview and pops a window showing the current state of the interviewer display.

Accessing recordings. If interview recording is activated in BASEprojets, corresponding .wav and .mp3 files are accessible from cwnav.cgi. Usual cwnav.cgi case selection tools can be used to focus on the cases of interest (e.g. completed interviews or cases handled by a certain interviewer). Selecting the "Display .wav/.mp3 files" checkbox adds a .wav/.mp3 column in the case-by-case output. Sound files are hyperlinked such that left-clicking opens the file with the sound application available on the local computer; it is also possible to save a local copy of the sound file by selecting the "Save target as" (or equivalent) command in the right-click context menu.

To the extent possible, sound file names give some indication about the content of the file. The name displayed starts with the date and time of the call, followed by the call sequence number (1 for the first call in a case), the language of the call (if available) and an indication of whether the call was a completed interview (CO) or not (UN). For example, in the image to the right, the last case contains a call made on October 14, 2009 at 8:22PM; it was the first call to the case and it led to a completed interview in French.

The real name of the file is longer than that displayed in cwnav.cgi. The underlying complete file name is prefixed with the project name and the case _telkey.


Installation. Assuming Asterisk and TightVNC are up and running, the rest of the installation required is as follows.

  • add the following context in /etc/asterisk/extension.conf and reload the Asterisk contexts:
    [ext-ecoute]
    exten => 8888,1,Answer
    exten => 8888,n,NoOp(cwphone.pl: ecoute=${ecoute})
    exten => 8888,n,ChanSpy(SIP/${ecoute}|q)
    exten => 8888,n,Hangup
  • on the Asterisk server, ensure that the supervisor station has access to the PBX software in /etc/asterisk/manager.conf
  • on the supervisor station:
    • ensure that "vncviewer" is installed
    • ensure that Perl is installed (which it is by default on a Linux station)
    • install the Net::Telnet Perl module
      • perl -MCPAN -e shell
      • install Net::Telnet
      • exit
    • copy the cwphone.pl script on the supervisor station and note down its location
    • install Firefox (version 1.5 or more)
    • in Firefox, install the StartALocalProgram extension (may require issuing the following command at the system prompt: "firefox startalocalprogram.xpi"; restart Firefox after installation)
    • in Firefox, enter the URL about:config and edit the following keys:
      • put the full path to Perl (usually /usr/bin/perl) in the following keys: extensions.startalocalprogram.launcherLocation and extensions.startalocalprogram.launcherLocation.linux (or mac or windows)
      • put the full path to cwphone.pl in the following keys: extensions.startalocalprogram.programToLaunch and extensions.startalocalprogram.programToLaunch.linux (or mac or windows)

   

Appendix E

Playing sound files during an interview

Technical requirements. Playing sound files during an interview is accomplished via the telephone system. Using the Asterisk PBX system, CallWeb offers a way to easily start and stop playing such sound files. Sound files must be saved on .gsm format. Under Linux, several sound file editors can save files in this format. Under Windows, WavPad does it too.

Operations. Start playing a sound file by inserting a CALCUL question in the questionnaire and performing the following calculation: PLAY = start_wav("sound_file") where "sound_file" is the name of the file on the Asterisk server, typically custom/some_name without extension (since Asterisk will select the most relevant file format). The sound file will stop playing at the end of the file; it can be stopped using another CALCUL: STOP = stop_wav().

Installation. Assuming Asterisk is up and running, the rest of the installation required is as follows.

  • create one Asterisk meetme room for each interviewer station; name them 6 preappended to the last two portions of the station IP address (e.g., the meetme room for station 192.168.10.128 is 610128).
  • add the following context in /etc/asterisk/extension_custom.conf and reload the Asterisk contexts:
    [cw-to-meetme]
    exten => _.,1,Answer
    exten => _.,n,MeetMe(${EXTEN}|q)
    exten => _.,n,Hangup()
    [cw-play-wav]
    exten => s,1,Answer
    exten => s,2,MeetMe(${myconf}|q)
    exten => s,3,Hangup
    exten => endmsg,1,Answer
    exten => endmsg,2,Playback(${mysoundfile})
    exten => endmsg,3,Hangup
  • create the gsm sound files and place them on the Asterisk server in the following directory: /var/lib/asterisk/sounds

Appendix E

Playing sound files during an interview

Technical requirements. Playing sound files during an interview is accomplished via the telephone system. Using the Asterisk PBX system, CallWeb offers a way to easily start and stop playing such sound files. Sound files must be saved on .gsm format. Under Linux, several sound file editors can save files in this format. Under Windows, WavPad does it too.

Operations. Start playing a sound file by inserting a CALCUL question in the questionnaire and performing the following calculation: PLAY = start_wav("sound_file") where "sound_file" is the name of the file on the Asterisk server, typically custom/some_name without extension (since Asterisk will select the most relevant file format). The sound file will stop playing at the end of the file; it can be stopped using another CALCUL: STOP = stop_wav().

Installation. Assuming Asterisk is up and running, the rest of the installation required is as follows.

  • create one Asterisk meetme room for each interviewer station; name them 6 preappended to the last two portions of the station IP address (e.g., the meetme room for station 192.168.10.128 is 610128).
  • add the following context in /etc/asterisk/extension_custom.conf and reload the Asterisk contexts:
    [cw-to-meetme]
    exten => _.,1,Answer
    exten => _.,n,MeetMe(${EXTEN}|q)
    exten => _.,n,Hangup()
    [cw-play-wav]
    exten => s,1,Answer
    exten => s,2,MeetMe(${myconf}|q)
    exten => s,3,Hangup
    exten => endmsg,1,Answer
    exten => endmsg,2,Playback(${mysoundfile})
    exten => endmsg,3,Hangup
  • create the gsm sound files and place them on the Asterisk server in the following directory: /var/lib/asterisk/sounds

   

Appendix F

Batch dialer installation

Technical requirements. The batch dialer requires an Asterisk 1.6 server. The CallWeb server needs to be able to connect to the MySQL server on the Asterisk machine.

Operations. Batch dialing is requested in BASEprojets by specifying the number of telephone numbers to dial in a batch (setting the batch size to 1 deactivates the batch dialer). When the interviewer requests the next case, that many calls are issued. Non-human contacts are identified and stored in the call historically automatically. Human calls are passed on to the interiewer. If more than one human contact are identified in a batch, the excessive ones are dropped and entered an "extra" result is stored in the call history.

Installation

  • On the Asterisk server:
    1. create the "cw" MySQL data base;
      CREATE DATABASE IF NOT EXISTS cw;
    2. create the "cwdial" table in the cw data base on the Asterisk server
      CREATE TABLE IF NOT EXISTS cw.cwdial
          (
          insert_date char(14) NOT NULL,
          insert_epoch char(14) NOT NULL,
          client char(64) NOT NULL,
          projet char(64) NOT NULL,
          lot char(64) NOT NULL,
          _telkey char(64) NOT NULL,
          _telephone char(32) NOT NULL,
          interviewer char(64) NOT NULL,
          n_dans_lot int(10) unsigned NOT NULL,
          resultat char(32) NOT NULL,
          KEY client (client),
          KEY lot (lot),
          KEY _telkey (_telkey)
          );
    3. place a new copy of cwAST.pl in /usr/bin
    4. place the cadenceur.conf Asterisk context file in /etc/asterisk
    5. integrate this context file in the dial plan, in extensions_custom.conf
      #include "cadenceur.conf"
    6. restart Asterisk
      asterisk -rx "dialplan reload"
  • On the CallWeb server:
    1. update CallWeb to the most recent version using cwupdate.cgi
    2. compile the version of BASEprojets which contains an open-end portion to question SIGNALEUR (Does the project use the auto-dialler? (# calls))
    3. place cwdial.pl in the utilities directory of the CallWeb instance
    4. add a cron entry to start cwdial.pl every minute (it will die immediately if it is already running); the CLIENT is found in the usager.conf file
      cd /var/www/instance && perl cwdial.pl CLIENT

Appendix F

Batch dialer installation

Technical requirements. The batch dialer requires an Asterisk 1.6 server. The CallWeb server needs to be able to connect to the MySQL server on the Asterisk machine.

Operations. Batch dialing is requested in BASEprojets by specifying the number of telephone numbers to dial in a batch (setting the batch size to 1 deactivates the batch dialer). When the interviewer requests the next case, that many calls are issued. Non-human contacts are identified and stored in the call historically automatically. Human calls are passed on to the interiewer. If more than one human contact are identified in a batch, the excessive ones are dropped and entered an "extra" result is stored in the call history.

Installation

  • On the Asterisk server:
    1. create the "cw" MySQL data base;
      CREATE DATABASE IF NOT EXISTS cw;
    2. create the "cwdial" table in the cw data base on the Asterisk server
      CREATE TABLE IF NOT EXISTS cw.cwdial
          (
          insert_date char(14) NOT NULL,
          insert_epoch char(14) NOT NULL,
          client char(64) NOT NULL,
          projet char(64) NOT NULL,
          lot char(64) NOT NULL,
          _telkey char(64) NOT NULL,
          _telephone char(32) NOT NULL,
          interviewer char(64) NOT NULL,
          n_dans_lot int(10) unsigned NOT NULL,
          resultat char(32) NOT NULL,
          KEY client (client),
          KEY lot (lot),
          KEY _telkey (_telkey)
          );
    3. place a new copy of cwAST.pl in /usr/bin
    4. place the cadenceur.conf Asterisk context file in /etc/asterisk
    5. integrate this context file in the dial plan, in extensions_custom.conf
      #include "cadenceur.conf"
    6. restart Asterisk
      asterisk -rx "dialplan reload"
  • On the CallWeb server:
    1. update CallWeb to the most recent version using cwupdate.cgi
    2. compile the version of BASEprojets which contains an open-end portion to question SIGNALEUR (Does the project use the auto-dialler? (# calls))
    3. place cwdial.pl in the utilities directory of the CallWeb instance
    4. add a cron entry to start cwdial.pl every minute (it will die immediately if it is already running); the CLIENT is found in the usager.conf file
      cd /var/www/instance && perl cwdial.pl CLIENT