Functionality to pause Agent chat timeouts

[Henri1]

Hello all,

I have the following request to fulfill for the Agent chat:

Agents should be able to pause chat session timeouts

The purpose of this functionality is that when Agent needs to for example take a remote connection session with the Caller, neither of them are using the chat even though they both are interacting with each other. This will lead to chat timeouts and the chat session often ends to timeout before they return to that view.

Since there is an automatic chat session timeout monitoring (which is a good thing), we would need some kind of functionality how agents could indicate that the chat timeout should be paused.

I was thinking that could we access the Session Binding record through the Interaction record? Below is the view where this functionality should be initiated.

Table for the Session Binding records that contain the session activity information: sys_cs_session_binding

Scheduled Script Execution 'Idle Chat Timer Task' that initiates timeout monitoring: /nav_to.do?uri=sysauto_script.do?sys_id=90e0b96e3b5000109cbbcea234efc42f

Script include 'IdleChatHandler' to update the records: /nav_to.do?uri=sys_script_include.do?sys_id=8a1a896a3b1000109cbbcea234efc4cf 

Any ideas how this requirement could be completed? I am yet to find a way the connection between Interaction record and Session Binding record. If I would find that, then I could just create for example a BR to Interaction table that would initiate this functionality that would pause chat timeout for this session.

Thank you already in advance.

[SASMLU]

We are also challenged by the timeout and the fact that the chat agent doesn't have the ability to affect it. Based on what we understand, only the customer has the ability to reset the timeout. This is awkward since it might be a situation where the hot potato is on us and we have to ask the customer to respond so we don't get timed out.

[Henri1 · Accepted solution]

Seems that we found now a solution. It is not pretty and I'm sure it's against all the best practices but at least it is working.

What we did:

• On interaction table we created a new column with type True/False. Agent can then use this field in the Service Operations Workspace.
• In IdleChatHandler script include we created a script before it checks the lastActivityTime variable. This script queries interaction records where the new column is set as True. If it finds a record(s), then it will create a conversation message to the corresponding conversation where Direction is "inbound". 

Yes, this will create every two minutes (scheduled job default frequency) a new conversation message that is not visible for the end user nor for the agent. But at least this will update the lastActivityTime and therefore you don't have to touch removeReminderConversations for example.

I hope this helps others AND ServiceNow will create OOB functionality soon as well. I'm a dreamer, I know...

[Robert Crawley]

Hello Henri1. I know your resolution indicates you found a solution, even if it was not ideal. Have you done any more research on this particular use case? We have a similar need to interrupt the idle timers so an interaction can be placed "on hold". I was going to use your suggestion, but ended up going down a different path.

I ran into similar issues running down the inner workings of the whole chat interaction and was equally frustrated with finding a link between those binding records and the actual interaction. However, I think I might have found the link. Looking into the interaction xml, I found that there are these two fields; channel_metadata_document and channel_metadata_table. When looking at the xml, I see the table is set to sys_cs_conversation and the document is a sys_id. Which, is handy to have since that sys id is referenced on sys_cs_session_binding in both the topic and session_topic fields. I thought of doing something on binding directly, but after mapping it out I came up with what I think is a much simpler solution. The IdleChatHandler script include is just doing a simple lookup to build the conversations array within that getAllConversations function, and that is then used in the other functions to determine timer handling on the identified chat sessions. The query is only looking for topic.state in chatInProgress or autoPilotInProgress. So, my solution was to just cause the check to inherently fail by adding an On Hold state to the conversation table.

Unfortunately the conversation table's state choice list doesn't include an on hold option, so I went ahead and added one. From there I built out a business rule on Interaction that checks for a state change to On Hold, and then pushes an  update to that conversation record to set the conversation.state field to On Hold. When the agent changes it back to in progress it pushes that update back to set the conversation back to chatInProgress.

tl/dr

To allow for interactions to be On Hold

Create a new choice record for sys_cs_conversation, On Hold (on_hold), I used sequence 7.

Create an on after, update business rule on Interaction that checks for the advanced condition current state changes to On Hold or previous state is On Hold and current state is Work In Progress

update the sys_cs_conversation.state field to on_hold, and then flip it back to chatInProgress for the inverse.

In testing, it is working to the point that the idle timer is now interrupted, however once I move the interaction to On Hold then the chat window is hidden from view in the workspace for the agent. It returns once I move the interaction back to In Progress. Another NOW Mystery to unravel, so I'll need a new box of scooby snacks, but at least the idle timer can be interrupted. Hope that helps.