Survey Management and data gathering

smcgrath44 · ‎01-20-2015

We are having some challenges with the Survey Management application and wanted to reach out to the community and see if we are alone or not. We want a survey sent out to each user upon resolution of a ticket. The information that we would like to get back goes well beyond the questions and answers in the survey. We would also like to get the following:

Technician who resolved the ticket
The Assignment Group that the resolving tech is a member of for the ticket
Business Service, Category and CI information that can be reported with survey data

We on on Eureka. We have been legacy surveys and want to utilize the new survey tool that ulitize the assessment and metrics tables. Does anyone out there have a similar challenge and or solution to this? Much thanks!

Steve McGrath

ServiceNow Administrator

Harvard Business School

TrevorK · ‎01-20-2015

We have just implemented surveys ourselves...or assessments...or whatever you want to call them. We opt'ed to use the new survey/assessment features and not legacy surveys, even though when we went through it legacy surveys seemed much easier. Our choice was based on a suspicion that legacy surveys would not see future development, whereas assessments would.

My post below will be based on using Assessments (Survey Management module), however I can reference the Legacy Survey's if you need.

I believe we are doing everything you want to do - we are sending out an email upon resolution of a ticket. I will walk you through our steps, and let me know which numbers you want me to go into further detail:

1) Upon closure of an Incident or RITM, we determine if a survey is required. For example, we do not want to survey students and there are certain assignment groups that do not receive a survey. We use a flag on the TASK table that we fill in if a survey is required.

2) Our notifications are two-tiered. We send a normal "Your Incident has been resolved" if our "Survey Required" flag is false. This comes off the Incident table. If "Survey Required" is true, we send a notification off of the Assessment Instance table. Because the Assessment Instance has "Trigger ID" (a field that contains the sys_id of the record calling it), we use a Mail Script to lookup the associated Incident or RITM information based on the sys_id. We then send out a "Your Incident has been resolved" email similar to above, however it is from the Assessment Instance table. We include our survey specific information in it (we use some cool graphics to entice them to click on the survey) and the Incident/Task information, which is obtained through the mail script.

3) Client takes the survey, we then do a custom table to transform the results into a format that is much easier for management to handle (a table where each row contains the questions/answers, rather than the ServiceNow format of each row being a question). We have some reporting we need to do based on the results of a specific question, and this kept it the "prettiest" for management and the most functional for our user base. The table just updates upon a survey changing to "Complete". Because we have the "Trigger ID" value (which again is the sys_id of the incident/task that called it), we can reference who the analyst was that did the ticket, the business service, etc.

Just in case anything does not make sense, I have attached a screenshot of our survey invitation email. It is run off the Assessment Instance table. While we do not show the CI/Business Service/etc., I think the other fields we pull demonstrate that we can pull those fields too.

If you have any further questions, feel free to post them. Or send me a message privately/email me and I can go into it further. We personally found the new Assessment module a bit overwhelming at first and it took longer than expected to develop it into something usable. But I think our stats are at a 12% response rate, so we must be doing a good job (our research department indicates this is a good response rate for unsolicited electronic surveys).

My apologies - I realize this is a bit long but I was unsure where exactly you were looking for feedback.

View solution in original post

dklimas · ‎02-25-2015

This does answer my question. It sounds great that you customize the survey based on one of three answers.

Are you filling in the first question based on a parameter in the URL using a technique like this SNGuru article?

http://www.servicenowguru.com/scripting/client-scripts-scripting/parse-url-parameters-client-script/

TrevorK · ‎02-25-2015

I am sure there are multiple ways to do it - but no, we are not doing it that way. We are doing it through passing a parameter to a UI Page directly (survey.do - I assume it's the default one? It's been so long I forget) and dealing with it on there.

Kalaiarasan Pus · ‎02-25-2015

The long post was required here and was spot on .. Thanks for sharing this And I liked the faces on the email as well

bernyalvarado · ‎07-29-2015

What a great response Trevor Kuebler!!!

Would you mind sharing a little bit more of what you did in your point #3 (easy survey response table from where to report on)?

Thanks,

Berny

TrevorK · ‎07-29-2015

Sure.

We found that it was difficult to pull reports that management wanted - essentially they wanted to know what the response was to each question in the survey in a row-by-row basis. The default reporting structure puts each individual answer in it's own row, but that makes it much more difficult to pull reports (using SN, obviously other tools that do Business Intelligence could do much better). We tried using views, etc. but kept running into the usual SN reporting limitations.

What we have done is every time a survey is submitted it writes to a custom table. The script populates the questions/answers in the appropriate fields (so that it is consistent for each), and if for some reason the number of questions changed, it grows the table to accommodate by adding columns. Right now we only have one survey, but in the future we will most likely have a custom table for each survey (just to make it easier).

We found this approach allows management to easily create their own reports. For example, it is easy to say "For all surveys where the response is "Good" show me the answer for "What can make good great?". This would be much more challenging for management to do in the existing tools, because each answer is it's own row.

I am sure a good BI program would be the best tool, but we have had challenges integrating with Tableau and such so far, so this is the best way we could find to give the reporting capabilities to management. After all, the survey functionality is useless without being able to report on the responses in a manner that is easily understood. So we took the approach of using coding to make it easier to understand, rather than expecting the user to do something themselves (export to Excel, etc.).

Hope that helps. Anything that needs further explanation or something just let me know!