Transfer to Live Agent abruptly ends if max queue time is reached.

[Michael Scepano]

Hi all,

My current chatbot flow is designed where a user has an issue, they progress through all the troubleshooting steps in the bot, and if the issue remains unresolved, they are presented with the option to log a service ticket OR contact a live agent. If they wish to speak to a live agent, we run a check to see if there are agents available using vaSystem.isLiveAgentAvailable(), and if so, we run the vaSystem.connectToAgent() function. Once this has been run, the user waits in the queue to be picked up. If an agent is occupied with other work, or is on a call with someone else, and does not pick up the call within 3 minutes (which is the currently set max queue wait time), the chat is abruptly ended.

It seems that there is no way for users to re-enter the Virtual Agent flow, so we can provide them an option to log a ticket instead. This is important as currently, all their previously typed in information and troubleshooting is lost. In my research, it seems I am not the only one experiencing this issue, and that moving to Live Agent is a one way street, that cannot be returned from - which appears to almost be a design flaw as you lose control of the flow once you try connecting to a live agent.

I thought it would be an easy fix to use the function vaSystem.didConnectToLiveAgent() , but as the code does not run past Connect to Agent, I am confused as to what the point of the above function is, as it operates on the past tense, which is inaccessible. Refer to: https://docs.servicenow.com/bundle/quebec-now-intelligence/page/administer/virtual-agent/concept/vir...

One of the problems is that vaSystem.isLiveAgentAvailable() does not query for real agent capacity, instead only checks if an agent is online. One solution might revolve around writing code that queries for real agent capacity, and then only transfers a user to the queue if that availability exists - however, this may not be possible if the value is not accessible in SNOW. Another solution could be to rewrite the vaSystem.connectToAgent() function, however I was unable to find the code for this (as was another colleague and forum member), so maybe if someone can shed light on the code within that function we may be able to modify it appropriately - however this will still be unlikely to resolve the issue as we likely still won't be able to return to the VA flow. 

To me, it doesn't make sense why if a live agent request is not answered, that the interaction should just be dropped into the ether, instead of returning to the flow where we can then control it exactly as we wish - because clearly if it has not been answered by a live agent, then the interaction is unhandled.

Has this issue affected anyone else, and if so, were you able to overcome it?

[Eliza · Accepted solution]

Hi @Michael Scepano,

I have potentially good news for you - we have released the Queue Triggers functionality in Utah. This feature provides the functionality for you to add entry points back into the Virtual Agent flow.

Queue Triggers enable actions to be conducted after a particular amount of time has passed for a customer waiting to be connected to a live agent.

Two trigger types exist:

• Wait Time: Customer remains in the queue after action takes place.
• Max Wait Time: Customer is removed from the queue, with next steps presented to them via actions.

Once the trigger time has been achieved, then you are able to perform the following actions:

Action Types	Wait Time Triggers	Max Wait Time Triggers
In-Queue Messages	✔	✔
Invoke flows/sub-flows	✔	✔
Switch into new topics		✔

In your scenario, you could set the Max Wait Time trigger to 3 minutes, so, after a user has been waiting that long, they are then directed into a Virtual Agent topic that asks them to create a service ticket.

Hope this helps!

[Michael Scepano]

Hi Eliza,

Thankyou so much for this - this is fantastic news! Apologies for the slow reply, I have two accounts (one company, one personal) and so I somehow missed this until now. I believe we might have spoken on the ideas portal some time ago about some new upcoming features that might help, but of course not much could be said until it was released.

Anyway, I'm really thankful for you taking the time to explain this - I'll make a motion to upgrade our system from Tokyo - once that happens, we'll be able to follow through with the solution.

Many thanks again,

Michael 🙂

[srvalw92]

HI @Eliza ,

I found it as a great solution for performing action after a particular time. I am trying to transfer chat to another queue once max wait time met. For that i just created a Topic , but somehow its not transferring chat to another queue. Could you please help, how can i proceed with this requirement?

[Omkar Bhamare]

Hello, the Issue has been resolved for me I have just added the "Target Wait Time" same as "Max Wait Time". Please let me know if the issue still exists for you.

Thank You