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.
This use case covers the following sections:
- Deploy the workflow now!
- Understanding the workflow
- Workflow components
- Customization and improvements
- Change log
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. |
2. Deploy the workflow now!
Click below to view this workflow in the Hub and install it on your server.
| Note: This is a case management workflow. To test it, follow these steps after deploying the workflow. The cases dataset name is "Cases CATI". |
| Advanced users can find the sample workflow files in this folder. For help with manual deployment, check out our support article Deploying form definitions and server datasets. |
3. 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. Probably the single most useful way to understand the advanced sample workflow is the flow chart diagram below:
Choosing your approach (case management vs non-case management)
There are two ways to set up CATI: with and without case management. Here are the main differences between these 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/respondents |
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. Workflow components
You can find the case management CATI sample workflow files in this resource folder, and the non-case management CATI workflow files in this resource folder. You will also need the phone-call and launch-sms field plug-ins. Here are the names of the files you need:
| Case Management Workflow Component Files Click on the section to access the files. |
||||||||||||||||||||||||
Forms
Enumerator Datasets
Cases Datasets
Server Datasets
|
||||||||||||||||||||||||
| Non-Case Management Workflow Component Files Click on the section to access the files. |
||||||||||||||||||||||||
Forms
Enumerator Datasets
Server Datasets
|
Learn more about each of these components in the CATI sample workflows guide, and follow these instructions to deploy them on your server console.
5. Customization and improvements
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.
5.5 Cases to be reviewed
You may have noticed the field “needs_review” in the 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 (“review_error”) 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, take a look at the relevant fields in the design - "needs_review", "review_status" and "review_error". If you would like to change the circumstances under which a case is declared as requiring review, you should change the expression under “needs_review”. Of course, this feature is optional, and you can simply delete all these fields to drop this functionality from CATI.
5.5 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.
5.6 Other customizations
- 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.
6. Change Log
| Version 2 |
September 2023
|
| Version 1 |
March 2020
|
You can see and explore all other CATI sample workflows in our Guide to CATI sample workflows
Do you have thoughts on this guide? We'd love to hear them! Feel free to fill out this feedback form.
0 Comments