Reporting on user inputs in Virtual Agent

Ryax1 · ‎05-13-2022

Hi all,

Does anyone know of a way to report on user inputs within Virtual Agent? We would like to do some trend analysis on certain user inputs (e.g. seeing how many people clicked 'Yes' and how many clicked 'No' on a certain user input).

I am aware of the OOB dashboards and reports that ServiceNow offer for VA but none seem to fit this requirement. The only place that I can find these values are stored are within the 'transcript' field in the Interaction table or the sys_cs_message table but they don't seem 'report friendly' as they are free text with lots of other jargon in them!

Any help or suggestions would be appreciated.

Thanks

Rich

Gokul Janardana · ‎05-13-2022

Hello,

I had a similar requirement to report on the "Yes" and "No" response from a conversation. As you figured out, there are no reporting friendly fields to achieve this requirement. I can explain you something I tried and guess what, it worked.

Create a report on the table "sys_cs_message"
Filter the report by using "task.topic IS <Topic Name>" (The topic which contains the user input which you are looking for.
AND Filter the report again by using the specific user input title : "Payload CONTAINS <User Input Title>".
AND "Payload ENDS WITH "No"}" OR "Payload ENDS WITH "Yes"}"

I have used Donut to represent the "Yes" and "No" in the dashboard after adding a function field in the sys_cs_message table. Please let me know if you have any questions on how to do that.

Filter Sample:

Report Sample:

Feel free to let me know if you have more questions on this.

If you feel it is helpful, please accept the solution and mark the response as helpful!

View solution in original post

Akhila11 · ‎02-22-2023

Hi Gokul,

I am trying to implement something similar could you please share more details about how you used the function field in the report?

Afeefa Muskan · ‎06-27-2024

Hi @Gokul Janardana ,

I am trying to implement something similar could you please share more details about how you used the function field in the report?

Chris D · ‎05-13-2022

You're definitely not unique here. I created a similar post awhile back and ended up creating custom fields on the sys_cs_conversation_task table and a topic block to populate these fields mid-conversation to do such data reporting. I give the technical details on that post: Adding field(s) to Interaction Log table for more granular reporting? (i.e. "Did this help?" stats) ...

I didn't have a custom function field like Gokul suggested, but I have very similarly used the Payload on the sys_cs_message table as the only way to get an idea what users are clicking. That reply has a great way to report off it - which btw you will need to add the sys_cs_message table as an exception (sorry, I don't remember the sys_property) because you can't report off sys tables by default - but if it's something you don't necessarily need a report of and you just want to get a quick idea of how many times somebody clicked X, you can save the trouble of a custom field and editing the property just by going straight to the sys_cs_message table, finding the message you want to "report" on, and right clicking the payload "Show Matching".

Ryax1 · ‎05-16-2022

Thanks Chris, I assume you haven't seen any knock on affect since enabling the sys_property to allow for reporting on that system table such as performance issues or similar?

Rich

Chris D · ‎05-16-2022

I don't have any additional sys tables added for reporting (glide.ui.permitted_tables property, thanks Gokul!) so I can't comment on performance impacts - you will need to hear from @Gokul Janardanan on that.

I'm going to say (don't quote me on this) that there's no inherent performance issue to updating that property with additional tables... I think the serious concerns with performance would come from users querying potentially very large (and probably un-indexed) sys tables which then would have performance impacts. Perhaps the system does some automatic indexing on the backend on reportable tables, in which case maybe adding a table to that property can have an immediate impact, but I would venture to say that conservative usage of the property - adding one table at a time only if you have a very good use case (which doesn't involve frequent querying by many users) and no other option - you will probably be fine.