Advanced CATI sample workflow – SurveyCTO Support Center

This is part of our guide to computer-assisted telephone interviewing (CATI). If you've not read it, we recommend that you read the CATI sample workflows guide first. This article is accompanied by a sample form, dataset definition and sample data in this folder.

1. Overview

The advanced case management sample workflow for CATI builds on the basic sample workflow, developing it further to help you deal with more real-world situations.

In this CATI sample workflow, you’ll be able to:

	Have up to 5 phone numbers per respondent. These can be from the respondent directly, family members, neighbors, colleagues etc.
	From the above, select the “best phone contact number”.
	Filter out the phone numbers that are not working (e.g. they don’t ring).
	Making multiple contact attempts in the same form, whenever a call is unsuccessful and there are other phone numbers.
	Reschedule calls to a specific date and time.
	Track the number of contact attempts made so far, and close the case after 5 or 6 attempts (depending on respondents’ availability).
	Track the status and time of each contact attempt.

Probably the single most useful way to understand the advanced sample workflow is the PDF flow chart diagram you'll find in the resource folder. Please study that diagram while you test.

2. Workflow components

There are two ways to set up CATI: with case management, and below. You can find the case management CATI sample workflow files in this resource folder, and the non-case management CATI files in this resource folder. Here are the names of the files you need:

Component	Case management	Non-case management
Form definition	CATI advanced starter kit sample form	Advanced CATI starter kit sample form (non-case management)
Field plug-ins	phone-call.fieldplugin.zip and launch-sms.fieldplugin.zip	phone-call.fieldplugin.zip, launch-sms.fieldplugin.zip and table-list.fieldplugin.zip
Server dataset definition	cases.xml	respondents_advanced.xml
Server dataset records	cases.csv	respondents_advanced.csv

Learn more about each of these components in the CATI sample workflows guide, and follow these instructions to deploy them on your server console.

3. Key elements across approaches

	Case management	Non-case management
Unique identifier	The unique identifier is stored in the ”id” column of the cases dataset and "caseid" field of the form. Using the caseid field type, the unique identifier is retrieved and stored automatically based on the "id" value of the case selected via the Manage Cases menu.	The unique identifier is the “id_key” column of the server dataset (to be indexed for faster look-ups), and the field “id” of the form. The unique identifier is stored by the "id" field from the "id" server dataset column by loading multiple choices from the server dataset "respondents" (webinar).
Searching for cases	The table under the Manage Cases menu is a direct feature of case management on SurveyCTO Collect. It can be customized on the Design tab of your SurveyCTO server console by clicking on the Settings button of your cases dataset.	The table at the beginning of the form is constructed using the table-list field plug-in (field: “id”). Row content can be customized by changing the data stored in the column of the server dataset used for choice labels. In the sample setup, the choice list "respondents" uses the "respondent_details" column of the "respondents_advanced" server dataset to load the choices. Make sure the content of that column follows the requirements of the table-list field plug-in.
*Assigning Users to cases (optional***)	You can automatically assign cases to users by placing configured usernames into the “users” column of your cases dataset.	You can assign cases to users by filtering the table display using the search() function so enumerators only see cases where their username is in the "users" column (field: “id”).
Closing cases	Using the above direct feature, by updating the "users" value of the row to the value "Closed” (field: “pub_to_users”), the case will disappear from the Manage Cases menu, since there is no user with the username “Closed”.	The form uses the "now_closed” column of the server dataset to filter out cases, again with the search() function, so that only cases that have a "now_complete" value of ‘No’ will appear (field: “id”). *Note:* The search() function can have up to two filters, so you can combine both filters mentioned above to display 1) open cases that are 2) assigned to a specific user.

4. Understanding the workflow

Between the form design and cases dataset, there are a lot of moving pieces. A write up comprehensive enough to discuss each part that is important would be very long, so instead of a detailed write-up, we're providing some notes to help you understand both.

To understand the form and cases dataset publishing workflow, we suggest you pay attention to the following:

In the form design, each of the calculate fields is annotated in the label property. These annotations are intended to provide you with descriptions of what’s happening behind the scenes, since the label will not show up in the actual form for a calculate field. Read through these descriptions to understand what each field does.
Use the form inspector to test your form, and analyze submitted form data (which you can view in exports) to help you understand the final result of each of the calculations in the form.
To understand the relationship between the form and the cases dataset (see image below):

Under the cases dataset's title on the Design tab, click on the hyperlinked form name following Published from. This reveals the field mapping, which is a list of published form fields (on the left) that will publish into server dataset columns (on the right).
Analyze the cases dataset's contents between form submissions to see what changed. On the Design tab, click on the Edit button of the cases dataset, and you'll see a table of all server dataset data. These can be edited right here. Alternatively, you can also click on Download > Download data to export the cases dataset in CSV format for outside viewing.

The server dataset is attached to the form, which allows the form to pull in any values using the pulldata() function.

The form is set to publish into the server dataset. This means that the above fields on the left are published whenever a submission is sent to the server.

5. Things you may want to customize

CATI systems can be complex, and everything in this starter kit is customizable. However, here is a short, non-exhaustive list of things you might consider changing in the existing form design:

5.1 Tracking call attempts

This sample workflow defines a call attempt as a submission. However, one submission can include multiple call attempts. The way this sample workflow is designed is that you keep calling to all phone numbers available until someone answers.

You may want to change this approach or use the phone-call-log() to store and track all call attempts made in each submission.

5.2 Number of call attempts to close a case

The value in the "stop_at" field is the maximum number of calls to be made, before declaring a respondent unreachable. It is set at 5 now, and it can go up to 6, in case the respondent is available to finish the interview in a final call, but you can revise it upward.

5.3 Scheduling times to call back

At the time of rescheduling the interview, you can choose to either i) call back in X hours, specifying the number of hours or ii) schedule the call back date and time manually, using a calendar. Additionally, you can send an SMS using the launch-sms field plug-in, notifying the respondent that we will contact them again soon.

Rescheduling rules can change depending on each project’s requirements, so customize the sample form as you please. See our article on Rescheduling call attempts in CATI.

6. Cases to be reviewed

You may have noticed the field “needs_review” in the advanced CATI sample form. If this calculate field returns any value, then the case is considered to be under review and cannot be filled-out by the enumerator - once they open the case, they will be prompted with a warning note field that will prevent them from swiping forward. Only by changing this value back to empty, manually updating the cases dataset on the server, the case will be “unlocked” to the enumerator. In this sample form, this only happens on two different occasions:

If the total number of contacts reaches 0. We're filtering out phone numbers whenever they are not connected to working phones, using the field “filter_phones”. In an extreme example, we may end up filtering out all phone numbers available. In this scenario, when opening the case, there would not be any phone number to call. To avoid such scenarios, these cases are suspended for review.
If the response to the field “best_phone_confirm” is "Will send an SMS with the phone number". A limitation of our sample form is that it does not provide a method to add phone numbers to a case separately from the main form. The only way to do this is by manually adding the phone number to the cases dataset on the server console, hence suspension.

To understand how this is happening, we should take a look at the relevant fields in the design - "needs_review", "review_status" and "review_error":

"needs_review" is a calculate field which has an expression which determines the circumstances under which a case is flagged for review (described above). Please study the expression to decide if you'd like to change the circumstances under which a case is declared as requiring review (assuming you want to use this feature at all).
"review_status" is a calculate field that pre-loads the “needs_review” value from the last form submission for that case. The only way of resolving the review status would be for your office team to edit this value manually. This might be easier to do by:

exporting the cases dataset,
subsetting down to the cases under review,
deciding what to do with those cases (whether to allow the team to continue with them), and
uploading that updated case data with the merge option (updating only those cases), to allow your team to continue to work on those cases.

"review_error" is a note field in the design, which is required, and relevant when the “review_status” of the server dataset has any value. This is what's holding up your enumerators. The simplest way to let them continue working is to make the field not required, delete it, or disable this field, and have them update to the latest version of the form.

Another idea for the review feature, is that one might publish data to Zapier, to notify you when records require review.

7. Consent

The consent given by the respondent is stored in the server dataset, so that you won’t need to ask for consent in a subsequent call. Depending on your research ethics procedure, it may be a requirement to renew consent, so revise accordingly.

8. Continuing your design work

There may be other concerns you want to address in your form designs, and our help doesn't end here. Here are a few relevant resources that might be useful:

Considering that phone surveys can be easily cut off in the middle of the survey, either due to respondents’ availability or network connection, you may want to design your form to accept incomplete interviews.
Are you collecting data in a multilingual setting? If you don't know which languages your respondents speak in advance, match them with enumerators who speak the right language with this approach.
Do you anticipate needing to replace members of your sample? See this resource.

Do you have thoughts on this guide? We'd love to hear them! Feel free to fill out this feedback form.