Hello everyone,
I am using web messaging integrated with Dialogflow CX and was looking for a way to track conversations that go into handover but are abandoned by the user while in the queue , waiting for an operator.
Can you help me?
Thanks in advance,
Serena
Hi Serena,
We currently do not have a mechanism to track asynchronous web messages that appear to be abandoned while waiting for an agent to pick them up. I am going to pass your forum post onto the product manager group and see if he has other thoughts on this.
Thanks,
John Carnell
Manager, Developer Engagement
Hi Serena,
With our Async Channels, in general, we don't have a concept of "abandoned in-queue" as with legacy chat: that's by-design, because we want end-users to always resume conversations as needed.
If you really want to emulate sync-chat behavior, you might be able to simulate "abandoned" conversations by using In-queue Message Flow, and having a Bot to explicitly ask users whether they want to wait: if they answer No, then disconnect conversation with specific wrap-up code (for future tracking).
Note that If you go that route, you would be preventing that conversation from being served asynchronously by a live agent, who could respond even if end-user is not online at the same time.
If I am not mistaken, the current behaviour for messaging involving a bot seems to wait for the duration of the threading timeout (72 hours default) and then process the next action for "no intent". If that ultimately transfers to a queue then the agent will get an interaction with "nobody there". If this is 72 hours later it can be confusing - especially if the customer had typed something about an issue but ultimately did not provide intent.
Alternatively if the No Intent path in bot leads to Disconnect then the interaction remains "Live" forever (or longer than 2 months as that's as far as I looked). At least it won't go to an agent and waste their time.
I would like to find a way to end the interaction after the timeout has expired. All the customer did was open the Bot, read the welcome message and close the browser tab. If they never resume within the threading timeout then I would want to see that interaction "Ended". I can't find a way yet to do that.
I felt it was related to this topic but I can ask a new question if that's better?
I believe the Bot should play a role in that use-case, to filter out the noise and avoid non-qualified conversation to reach an Agent: the no-input handling is being improved for Bot, based on this Idea, to better refine Bot's behavior and allow it to potentially disconnect non-qualified conversations.
Yes I agree, and in the mean time have you any experience with knowing how to determine if a timeout occurred (i.e. no input for 72 hours)?
Form what I see the only way we can try this until an enhancement is implemented is to provide the inbound call flow with something tangible from the bot flow that it can use to determine if this idle connection should go to an agent or not. I can't think of any times when I'd want it to go to an agent but our customer wants an agent to review if the customer did type something and ended up giving up. They want to continually improve their bot/knowledge base to help more people within bot.
So use case 1) Bot starts, no input -> should just disconnect after 72 hours
case 2) customer enters some content in bot -> conditionally goes to agent
case 3) happy path where user selected an intent within bot and goes to agent like supposed to.
I think your enhancement will help us immensely. Currently I run a script daily to disconnect all messaging messaging conversations with no queue, no flow that are more than 2 days duration. This saves agents alot of time {"handling" dead messaging sessions and stops them logging faults with us about the undeliverable messages.
Based on an other thread I started I was answered that if an end-user starts a webmessaging and does not continue, the session remains 'open' for a maximum of 6 days!
The 72 hours threading timeline is only in place for disconnected webmessages and an enduser comes back within 72 hours.
@Paul_Lewis, can you give me that script you are running? I would be very curious how many of those we have and being able to terminate them.
We too encounter a lot of 'dead' messages that are a waist of time for our agents.
This is a good solution. I have implemented this too with an in-queue message flow. Providing the end-user 'Message.PositionInQueue', having it call a simplified bot flow asking end user if he want to wait. When no, disconnect, when yes remain in-queue and have it looped, so it will update the position in queue.
Problem remains if the end-user does not give any input, what to do next.
There is a problem with this solution. In GC, there is no Set Wrapup Code action in either the digital bot flows or in the inqueue message flows. So there is no way set this.
Fair point @Marty_Hand we'll revisit this, the use-case is valid, and wrap-up code would help with proper analytics.
@gemmaalvarez @AmelieWisniak FYI.
@Marty_Hand Working on it, so we will have set wrapup code in bots, and we are looking at exposing this in analytics too.
So glad to hear it!!! Thank you.