Agent Chat Idle Timers

[Robert Crawley]

Hello, we are in the process of launching our agent chat implementation. We're not initially using virtual agent, I have a greeting configured to just pass straight to an available agent. We had a question about the idle timers though. It looks to me that once the chat is initiated and the agent has joined the chat, there's just the one timer? I have both properties configured, for the reminder check and then the cancel chat property. We have tested it out, and the base build is working. User doesn't respond, reminder check triggers, user still doesn't respond, the user is notified the chat is ending, and then the chat is cancelled.

My question is how do we control for idle user vs idle agent? We noticed that an agent could go idle for some reason, and as long as the user continues to respond then the chat will remain active. Based on what I'm seeing in the documentation, this is expected behavior? I imagine we would need to create a separate job to handle agent timeout and remove agent from the existing scheduled job or is there a setting in here that I'm missing? 

[pavani_paluri]

Hi @Robert Crawley ,

ServiceNow system has been set up to handle idle users not agents. If a user stops replying, the system sends a reminder after a few minutes.Then ends the chat if the user still doesn’t respond.
This is working as expected — and it’s all controlled by system settings you already configured.

We can set up a script or scheduled job that checks all ongoing chats that looks at the last time the agent sent a message.
If the agent hasn’t said anything in, say, 5 or 10 minutes, send a message to the user like agent is not available, can transfer to other available agent or end the chat.

Mark it helpful if this helps you to understand. Accept solution if this give you the answer you're looking for
Kind Regards,
Pavani P

[Robert Crawley]

Thanks for the clarification Pavani. I appreciate it.

[Robert Crawley]

Hey @pavani_paluri . So, I found what I thought might be a cleaner approach for our on_hold requirement, without breaking into much of the OOB options. It's mostly working.

The existing script include IdleChatHandler does a check against sys_cs_session_binding for topic.state in chatInProgress or autoPilotInProgress. That topic is a reference to the sys_cs_conversation record for the chat. My solution was to add an addition choice option of On Hold which would then invalidate this particular check, and prevent the idle timer from including my held chat interaction.

Setup

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 if the 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, when the interaction is placed on hold, then set it to chatInProgress when the interaction is move back to Work In Progress.

So, with this in place the chat does become "held", the idle timer ignore the record. Once the interaction was moved to on hold, the IdleChatTimer ignored it and the chat was left open for 24 minutes (where our normal reminder time is 5 minutes, and cancel chat threshold is 10 minutes). Once I put the interaction back to Work In Progress, the idle timer picked it up and presented the idle warning at 5 minutes and ended the chat at 10 as expected. 

New issue though: When the sys_cs_conversation is set to On Hold the chat pane is hidden from view in the Service Operations Workspace (where we're running our chat from). Additionally, the chat user is unable to send a message they receive "message not delivered". Once the interaction moves back to Work In Progress the chat window is visible again, and chat messages are delivered properly between the user and agent. 

I have been reviewing business rules, ui actions, script includes, the workspace itself in UI Builder, etc but can't seem to find where the declaration is for an active conversation state. Do you know where that might be? I'm assuming it's just looking for chatInProgress or autoPilotInProgress similar to the ChatIdleTimer, but I haven't been able to locate it yet. 

[Robert Crawley · Accepted solution]

So, updating what the system considers an "active" conversation appears to be locked into the API and in a json payload. I didn't really want to try, not sure I could, messing with that side of this requirement. I ended up adding a boolean field for chat on hold to the conversation table. I then adjusted my business rule to update that field when the chat/interaction is placed on hold. Next, i needed to clone the existing ChatIdleTimer and two scheduled jobs that call that script include. I updated the script include to query for topic.u_chat_on_hold = false. With that in place the interaction is ignored by the idle timer while the interaction is on hold. When the agent moves the interaction back to Work In Progress, the br clears the flag on the conversation and the script include/scheduled job pick up the interaction and timeout the chat normally.