Dear,
Is it possible to use Qualtrics for a "feedback round" type of setup.
Where a group of respondents gets invited for feedback on a couple of topics, (multiple surveys)
but in a way that they can log in somewhere, and see the surveys that they CAN take, and the surveys they have already taken.
Plus also access to a report with the results of those surveys.
Kr
JV
Page 1 / 1
I think you may need to purchase the Qualtrics 360 in order to do this. https://www.qualtrics.com/employee-experience/360-degree-feedback/
It can probably be done with some custom coding as well, but I would not know how to do that.
It can probably be done with some custom coding as well, but I would not know how to do that.
> @uhrxx005 said:
> I think you may need to purchase the Qualtrics 360 in order to do this. https://www.qualtrics.com/employee-experience/360-degree-feedback/
>
> It can probably be done with some custom coding as well, but I would not know how to do that.
Thanks,
I checked the 360 degree solution,
However it is meant to evaluate a person, not to evaluate a topic/project...
Or should I bend the 360 solution and pretend a project is a person.
PS a sample question in such a survey would be "I think the communication on this project is going well" yes/no. If that clarifies the context.
> I think you may need to purchase the Qualtrics 360 in order to do this. https://www.qualtrics.com/employee-experience/360-degree-feedback/
>
> It can probably be done with some custom coding as well, but I would not know how to do that.
Thanks,
I checked the 360 degree solution,
However it is meant to evaluate a person, not to evaluate a topic/project...
Or should I bend the 360 solution and pretend a project is a person.
PS a sample question in such a survey would be "I think the communication on this project is going well" yes/no. If that clarifies the context.
You can do this with an authenticator block, branching logic, custom end of survey blocks and embedded data to update with a contact list trigger. It is a little complicated, but essentially you need
1.An authenticator block that directs to a landing page of available surveys they can take with display logic that keying off the presence of embedded data.
2. Each survey in a block (or series of blocks).
3. Branching logic that navigates to each "survey" based on selection from #1.
4. Embedded data assigned after a survey is completed.
5. Use a contact list trigger to add embedded data from #4, which indicates that a given survey has been taken (and thus can be used to hide the survey as an option in #1).
1.An authenticator block that directs to a landing page of available surveys they can take with display logic that keying off the presence of embedded data.
2. Each survey in a block (or series of blocks).
3. Branching logic that navigates to each "survey" based on selection from #1.
4. Embedded data assigned after a survey is completed.
5. Use a contact list trigger to add embedded data from #4, which indicates that a given survey has been taken (and thus can be used to hide the survey as an option in #1).
@Akdashboard
So then you'd have actually one Survey? With each individual "survey" actually being a branch in the background?
That seems difficult for reporting then...
It also doesn't seem to fit other requirements in a "feedback round", some of the surveys should be repeated every two weeks, in the next "round".
Also with the branch logic, I don't think there can be a notification to participants when a new survey is added, or can it? And what about inviting different people to different "surveys".
So then you'd have actually one Survey? With each individual "survey" actually being a branch in the background?
That seems difficult for reporting then...
It also doesn't seem to fit other requirements in a "feedback round", some of the surveys should be repeated every two weeks, in the next "round".
Also with the branch logic, I don't think there can be a notification to participants when a new survey is added, or can it? And what about inviting different people to different "surveys".
1. "So then you'd have actually one Survey? With each individual "survey" actually being a branch in the background?
That seems difficult for reporting then..."
* Doesn't _have_ to be a single "survey", I just find it a lot easier to maintain. You can easily just have the branches go to custom EOS blocks with URL Redirects. With that said, ease or reporting is highly dependent on the complexity and similarity of your data sets.
2. It also doesn't seem to fit other requirements in a "feedback round", some of the surveys should be repeated every two weeks, in the next "round".
* You can be creative in the type of embedded data you update. For example, if a survey should only be taken once every 2 weeks, then you can post the date that the survey can be retaken and use that as part of your display logic. You are just limited in how creatively you program.
3. Also with the branch logic, I don't think there can be a notification to participants when a new survey is added, or can it? And what about inviting different people to different "surveys".
* Strictly speaking no, but since you need to program new surveys anyway, is it really much more work to send out an email when a new survey has been added? You will already have the full list of recipients, so it just programming a simple email. As for inviting new people to a survey, that is a business practice and not a programming question. First step is defining how you would want everything to function THEN you can think through how the programming would need to support that.
That seems difficult for reporting then..."
* Doesn't _have_ to be a single "survey", I just find it a lot easier to maintain. You can easily just have the branches go to custom EOS blocks with URL Redirects. With that said, ease or reporting is highly dependent on the complexity and similarity of your data sets.
2. It also doesn't seem to fit other requirements in a "feedback round", some of the surveys should be repeated every two weeks, in the next "round".
* You can be creative in the type of embedded data you update. For example, if a survey should only be taken once every 2 weeks, then you can post the date that the survey can be retaken and use that as part of your display logic. You are just limited in how creatively you program.
3. Also with the branch logic, I don't think there can be a notification to participants when a new survey is added, or can it? And what about inviting different people to different "surveys".
* Strictly speaking no, but since you need to program new surveys anyway, is it really much more work to send out an email when a new survey has been added? You will already have the full list of recipients, so it just programming a simple email. As for inviting new people to a survey, that is a business practice and not a programming question. First step is defining how you would want everything to function THEN you can think through how the programming would need to support that.
Leave a Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.