This is the second part in our guide to computer-assisted telephone interviewing (CATI). If you've not read it, we recommend that you read the main article first and then continue on to part 3 on the advanced case management sample workflow. This article is accompanied by a sample form, dataset definition, and sample data in this folder.
The basic case management sample workflow is designed to demonstrate concepts. For a more complete solution, we urge you to try the advanced case management sample workflow after reading this part of the guide and testing the basic sample.
Whether you use the basic or advanced case management workflow samples, you'll be using the most automated, scalable approach to CATI on the SurveyCTO platform, which can be deployed using mobile devices or web forms. This solution uses case management in combination with publishing form data into server datasets, and pre-loading to organize the process of attempting to contact respondents and interview them, automatically discontinuing contact attempts when appropriate (e.g. after X number of failed call attempts, after a wrong number, etc).
CATI running on SurveyCTO Collect for Android is made possible through the call-phone-number field plug-in (read more about field plug-ins), which allows the user to automatically populate the dialer for calling (if you plan on using iOS devices or web forms instead, see the Choice of platform heading in the first part of this guide).
Deploying this starter kit on your server
Download a copy of each of the resources for this starter kit from this Google Drive folder. Download copies to your local computer. In the case of the Google Sheet form definition, either save a copy to your Google Drive or download a copy (File > Download as > Microsoft Excel).
3.1 Form design
Deploy the form design first. You'll have the choice of V1 of the basic sample, which has instructions to manually dial phone numbers, and V2 of the basic sample, which can automatically populate the Android phone dialer app with phone numbers.
Click on a "+" button on the left of the Design tab, then Upload form definition, pick the form design from either your computer or Google Drive, and upload.
3.2 Field plug-in
If you're chosen V2 of the basic sample form, attach the call-phone-number field plug-in using the Select one or more files to upload as form attachments option, as part of the form deployment process.
If you're testing on web forms or on an iOS device, the V2 sample form will also work, but will display instructions to dial manually.
|Field plug-ins are distributed from the field plug-in catalog, but as a convenience, the call-phone-number plug-in can be found in the basic sample's resource folder.|
3.2 Cases definition
Deploy the cases dataset definition second. Click on a "+" button on the left, then Add server dataset, and choose the New dataset from definition option. Pick and upload the "cases.xml" file.
In this workflow (and the advanced one), phone numbers for dialing are pre-loaded from the attached "cases" dataset. In addition, when you submit filled forms to the server, the cases dataset is updated with information about the call, such as the number of call attempts so far.
If you already have a "cases" dataset, you can create another with a different ID, other than "cases". This is possible even on a server with one team. However, before a user will be able to interact with a cases dataset with an ID other than "cases" (the default), it will need to be assigned a custom user role that specifies the new, non-default "cases" dataset ID. To create a user role, visit the User roles and permissions section of the Configure tab of the server console. Be sure to specify your custom cases dataset ID under the Please provide the dataset ID for case management (optional) option during role creation. From there, under Your users, create data collection-only user accounts with the custom user role you've just created.
The sample cases dataset we've provided in this starter kit has the ID "cases", but you can modify it to deploy it with a different ID. Open the "cases.xml" in a text editor, changing the ID of the dataset, which can be found between the <id> tags:
Lastly, note that as part of the team creation process, a custom cases dataset can be specified for all user roles created for that team.
3.3 Seed your cases dataset (optional)
To deploy this starter kit for quick testing, upload the "cases.csv" file into the cases dataset. Click on Upload under the Cases dataset's title, and pick and upload the "cases.csv" file. This will get you started with 5 example cases.
However, you can also create your own test cases, or correctly format your own real-life case data. Use the example cases data CSV file as a template. Remember that when the users column is blank, all SurveyCTO Collect users share that case (read about case management for more details).
4. Using the basic workflow
4.1 The case list
To start using the case management system, you'll need to enable case management on your mobile device. In the SurveyCTO Collect app, enable Manage Cases from Admin Settings. In web forms, login at this address:
First open the Manage Cases menu. You'll see the list of available cases in table list view (as opposed tree list view). You'll be able to scroll through the list of cases, sort them using different columns, and filter the list, as required. Tap on a case to open it.
|For an alternative workflow beginning with opening a form from Fill Blank Form, see the non-case management CATI workflow.|
4.2 Viewing a case
Once you've opened a case from the case list, you'll see the case's label at the top, followed by a Fill Blank Form section from where you can pick any form associated with the case. Our samples have only one form, but if your survey is longer, you can divide it over more than one form, which will all appear there.
Below the Fill Blank Form section, you'll see a Finalized Forms section as you start finalizing forms, whether you have been able to send them to the server or not (i.e. this works without an internet connection).
The Finalized Forms section can be valuable for understanding the status of case, particularly if you use the instance_name feature to dynamically name filled forms. Dynamic instance_name values could remind the user of what happened in each prior call attempt for that respondent.
|The Finalized Forms section does not appear when using web forms, but web forms require that you work online anyway.|
4.3 Filling out the form and submitting data
Fill out the form as you normally would, noting which label parts are instructions, and which parts are the script to read out during the call. Whether successful or not, in this workflow, the idea is that you finalize and send a form submission to the server for each contact attempt. Every time you submit a filled form to the server, some of your form data gets published to the cases dataset. That new data updates that case's last call status (in "last_call_status"), and increases the count of how many calls have been made so far (in "num_calls"). If you made an appointment to call back, the appointment details are also captured (in "callback_time").
What if your team won't be working on a reliable internet connection? That's a limitation for now (which we're working on), but so long as you're not recording an appointment, the worst result can be that your case management system doesn't take account of some calls for a few cases, and these cases would get one or two more call attempts. Given the inexpensive nature of an unsuccessful call attempt, this should be tolerable for most projects.
|For readers with doubts about case management while working offline, it can still work well. Case management facilitates the unique assignment of cases to specific phone interviewers, and when your team can be online, you'll get the most out of the feature. If your team might be working offline at times, train them on the use of the Finalized Form section of the case view, and be sure to design useful dynamic instance_name values for your forms.|
4.4 Keep the cases dataset up-to-date on the server
When you are able to submit data, the cases dataset on the server will update automatically, but not necessarily instantly. It can be close to instantaneous, but it can take up to 5 minutes, depending on how busy form publishing is.
However, you might see a button on the server dataset on the Design tab to force an update. Use this during testing.
4.5 Keep the cases dataset up-to-date on SurveyCTO Collect
Importantly, users must install form updates between form submissions with the same case. Various pieces of data that make the CATI system work depend on the form "seeing" what happened in the previous form submission with that case (as discussed above).
Keeping the cases dataset (and any other server dataset) up-to-date on SurveyCTO Collect for Android became dramatically easier as of SurveyCTO Collect version 2.70.1, an early release. We strongly recommend using the early release version, which will make updating cases much easier. However, if you prefer sticking to the official release of SurveyCTO Collect, consult these instructions.
With SurveyCTO Collect 2.70.1+ installed, tap on the 3 dot icon in the top right, enter General Settings, and enable the following options:
- Auto download with network and Wi-Fi
- Auto download on demand (new)
- Auto install downloaded update (new)
Consult the early release guide for more details, but once installed, you'll benefit from these improvements:
- The cases list will be updated as soon as it is opened (without needing to be refreshed), and will display a "last updated" date and time.
- When you open a form, SurveyCTO Collect will check for a new version of the form, and for updates to attached datasets, which it will then download and install. When the form opens, if anything was updated, the user will be informed, displaying a time stamp.
With these new advantages, your enumeration team won't need to manage the process of updating the case list, the form, or attached pre-load data. All of this can be automatic in the SurveyCTO Collect early release (version 2.70.1) on Android. An internet connection is required.
|Note: None of this matters for web forms, as web forms always use the latest form version, and latest cases data when they're opened.|
5. Some notes on understanding the solution
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 help you understand how to implement CATI even better, we'll be improving it over time. Make sure to click on the "Follow" button at the top of part 1 of this guide to stay up-to-date.
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 does.
- The form data (which you can view in exports) will 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, click on the hyperlinked form name following Published from: under the cases dataset's title on the Design tab. This reveals the field mapping, which is a list of published form fields (on the left) linked to server dataset columns (on the right). With a sense of what is stored in the cases dataset, you'll start to get a sense of what will be passed into new blank forms in this starter kit.
- The cases dataset's contents can also be viewed between form submissions to see what changed. On the Design tab, click on the Edit button for the cases dataset, and you'll see a table of values. These can be edited right here. Alternatively, you can also click on Download, Download data to export cases dataset for outside viewing in CSV format.
6. 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:
- You'll probably want your cases to be uniquely assigned to different cases. Give enumerators unique user IDs on your server, and place those in the users column of the cases dataset to create a unique assignment.
- 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 3 now but you can revise it upward.
- The "reschedule_no_ans" field sets the default call back time, if no appointment to call back was made. Right now that date and time is "tomorrow at 9am".
Note: 9am is stylized as 09-00 instead of 09:00 so that when editing the CSV in Excel, it is not auto-formatted by accident.
Please continue to part 3 of the guide and see the next part on the advanced case management sample workflow for CATI.
Do you have thoughts on this guide? We'd love to hear them! Feel free to fill out this feedback form.