CATI starter kit part 3: advanced case management sample workflow

This is the third part in our guide to computer-assisted telephone interviewing (CATI). If you've not read it, we recommend that you read the main article, and part 2 on the basic case management sample workflow.This article is accompanied by a sample form, dataset definition and sample data in this folder

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. To help keep the basic sample workflow simple, we avoided many of these problems to help keep the sample simple. Seeing as many data collection projects moving to CATI will deal with many of these challenges, we now deal with them in this part of our CATI guide.

As this advanced sample uses the basic sample as a starting point, and the workflow is mostly the same, this part of the guide will not repeat part 2 of this guide on the basic workflow (so do refer to part 2 again if you need to). Rather, part 3 will deal with the differences and improvements over the basic sample.

In terms of components required for the set up, the advanced CATI starter kit only differs from the basic workflow with an additional field plug-in to launch SMS.

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.

1. Contact attempts

We've made some adjustments on attempts to reach the respondent. The following improvements have been made:

  • The threshold of attempts was raised from 3 to a more realistic 5 calls.
  • If the respondent is available and willing to reschedule at the 5th (or final) attempt, the threshold goes up by 1 (it is illogical to be able to make an appointment that you can't keep). However, it will not be possible to make an appointment on this 6th and final call.
  • For each attempt, the time and status are published to the cases dataset. Now you are able to track all attempts made by case.

2. Phone numbers

The basic sample provided only one phone number per respondent, and did not anticipate that it might be possible to make records of new and better phone numbers for contacting that person. In the real world, sometimes people have multiple phone numbers, and sometimes the best number to reach someone on doesn't even belong to them! We've made the following phone number-related improvements:

  • The advanced CATI sample workflow allows you to capture multiple phone numbers. Whether you have multiple phone numbers associated with a respondent to start with or not, you can build up a list of up to 5 phone numbers to contact the respondent. These can be the phone numbers for the respondent directly, family members, neighbors, colleagues etc.
  • Whenever you're scheduling a follow-up call with the respondent, or someone that knows the respondent (a family member, friend, neighbor, etc.) answers the phone call, the best number to reach the respondent is registered. It can either be one of the phone numbers already stored or a new one that will be added to the cases dataset. This is the first phone number appearing the next time the case is opened.
  • Whenever the person that answers the phone call is not the respondent, then any relationship between them and the respondent is recorded, along with their name. This will store relevant information about all phone numbers stored for each case.
  • Any time a phone number doesn’t ring (e.g. a bad number), it will be filtered in the cases dataset and won’t appear again in the future.

3. Scheduling times to call back

The following improvements have been made when making appointments to call back:

  • We introduced some flexibility on rescheduling. Before, if no one answered, the interview was automatically scheduled for the next day at 9 AM. Now, 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.
  • Instead of leaving a voicemail, you’ll now send an SMS using the launch-sms field plug-in, notifying the respondent that we will contact them again soon.

4. Cases to be reviewed

You may have noticed the field “needs_review” in the basic 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 in two different occasions:

  1. If the total number of contacts updates to 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 case, when opening the case, there would not be any phone number to be called. To avoid such scenarios, we’re allocating these cases for review.
  2. 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.

The relevant fields in the design are "review_status", "needs_review", and "review_error".

"review_error" is a note field in the design, which is required, and relevant when ${review_status} != null is true. 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. If you're using the early release version of SurveyCTO Collect, updates can be dramatically easier.

"review_status" is a calculate field that pre-loads the review status generated by the form from the cases dataset. Another way of resolving the review status would be for your office team to edit this value manually. This might be easier to do by a.) exporting the cases dataset, b.) subsetting down to the cases under review, c.) deciding what to do with those cases (whether to allow the team to continue with them), and d.) uploading that updated case data with the merge option, to allow your team to continue to work on those cases.

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

The last relevant field is "needs_review", a calculate field which has an expression which determines the circumstances under which a case is flagged for review. 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).

5. Other improvements

We've also made the following general improvements:

  1. The consent given by the respondent is stored in the cases 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.
  2. There are now two different fields: “now_closed” and “now_complete” that will tell you whether the case is closed and completed. While a completed case is a closed case, the other way around is not true. A case can close once one reaches the threshold of attempts (5), for example. The “now_complete” field will help you assess the success rate of your survey.

There are some other subtle improvements too. We suggest that you follow the advice under the "Some notes on understanding the solution" heading in part 2 of this guide, in relation to the advanced sample.

Also, consider the non-case management CATI workflow which you can read about here.

The end (for now).

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


Please sign in to leave a comment.