A Common Question from Customers: Can you repeat a question until a respondent is finished? | XM Community
Skip to main content

The Customer's Request



I have a customer who is doing a survey which requires the respondent to fill out a block multiple times for different products. My customer asked if I could put a block on repeat, and when they're finished, it would break the cycle flow and exit the survey. Note, this isn't a 'Loop and Merge' scenario - no input changes the survey block - it's the same every time.



Solution Overview



I opted for a solution where there are Batch Ids and the surveyor (an employee of the company - so there would be a level of instruction) would take the survey repeatedly, but in batches. Here was my solution: I am MORE than open to suggestions!





(Preface, this is a solution that I am still working on, and it may have kinks. I make sure that I state my confidence level before posting something that might not be correct, and this is one of those times that I admit that there may be a better way.)



Solution Details



I had a Survey Link with a query parameter `BATCH_ID`. If it was empty, It would go to a first, conditional block that would ask for the Batch Name, and then encode that into that BATCH_ID, and then assign it to itself, with the BATCH_NAME being the English version of the batch.



The respondent would fill out the block, and then at the very end, there were two choices: 'Continue Batch' or 'Start New Batch'. If they Continued, the current `BATCH_ID` would be included in the link, and the survey would open, decode the `BATCH_ID` and store the `BATCH_NAME` and `BATCH_ID` in the Embedded Data, and then the survey would go normally. If they hit 'Start New Batch', it would provide a link that would _not_ have a BATCH_ID, and they would be prompted for the Batch Name, and it would continue by generating the ID as above.



I had a hard time trying to figure out how to make that happen, but here is the thought process I went through, and how I explained it to my customer:

If you're making an Excel Spreadsheet, and you are manually entering this information in, a loop in a Qualtrics form would be like adding columns indefinitely. Your survey would only have as many rows as you had respondents, but it would be hard to slice and dice the data when you have hundreds of columns. Its far easier to analyze data which has a set number of columns, but an indefinite number of rows, and are grouped together by a batch Id. That really resonated with my customer, and so we're moving forward with the given approach.



Potential Flaws:



The introduction of nominal identifiers is an accident waiting to happen. If they say `Sally's Diner` as a batch, and then retake the survey and enter `Sallys Diner`, the omission of the apostrophe would obliterate any relationship between the surveys, creating two separate branches. To solve this, the Batch ID Generator strips out grammar, removes non-alphanumeric characters, and then produces the ID, but still, that wasn't solid enough of a defense for me.



One solution I'm playing with (this project is still open and being actively developed) is to, when a BATCH_ID is generated, ask for an Email Address of the Respondent, and then email them a link for them to return to if they need to continue the Batch after a certain period of time.



This may not be the best solution, and I am open to better approaches.



But the benefit of this is that the Customer will easily be able to filter, sort, and slice the data in their Dashboards by BATCH_NAME, and isolate that batch for individual analysis.
I think this is a clever solution to the infinite loop problem for sure. I'd do you one better to say that you could even write a basic dashboard that ingests this data from the api, and prints information compiled for your client in an easy to read, and quick to use format.
I wanted to so badly! But the customer needed it all to be hosted on the platform. Is there a way you can do those custom API calls in the Dashboard?
Not really sadly 😞
Man, I wish! But its reassuring to hear you say that because this was in place of a solution like that. I was extremely confident that you couldn't do API calls in Custom Dashboards, but hearing you say the same solidifies that.



We've had a few Ubuntu solutions for that that have worked really well! One of the things our customers struggle with is paying hosting fees. One day perhaps haha!
@Michael_Campbell_RedPepper - Does your client want to see all the responses and number of attempts? I am trying to understand what a use case for this might be. Maybe something like a form of training (keep doing it until you get it right) then see how many times it takes the average person, then who laggards and who exceeds.



Is that roughly the ask? If so, even though you said this isn't a loop and merge, I can imagine a build where it does leverage loop and merge.



If they don't need to see all the attempts, then this actually gets _much_ easier.
For sure! The scenario was vague because I was trying to say it in a way that the customer would be as anonymous as possible, but see that I didn't really give the required detail. The Respondent is observing customers responding to products, one after another. The granularity of the survey is a person's response to a specific product, and the granularity of the batch is the person's responses during their customer experience that day.



Does that make a little more sense?
Got it ! So the repeating block is sort of like a repeating survey, but without burning through responses. The main difficulty is minimizing the number of responses (I assume because of cost) while keeping the responses in the same field, but broken out by batch, for ease of mapping to the dashboard (Vocalize?)



Hmmm, that is a tricky one.



If you didn't have the response restriction (and maybe you don't), then you could achieve this pretty easily by building out 2 separate surveys. One that is the survey in it's entirety that has a URL redirect to the second upon completion. This will record the response and still keep the Respondent in the survey. The other survey is just block you want repeated that has two end of survey logics; one to record and redirect to the start of this survey, the other to record and close. - You have probably figured out that this doesn't even need to be 2 separate surveys if you just apply branching logic with an embedded data field that you hard code in the URL redirect, but to keep it simple, I explained it as 2 surveys.

Leave a Reply


Terms & Conditions