Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Silent Chats Issue - Ability to Monitor Callers Active Connection #761

Open
JoabHInclineIT opened this issue Nov 20, 2024 · 3 comments
Open

Comments

@JoabHInclineIT
Copy link

Hi,

In our LexWebUI / embedded CCP implementation, we are facing an issue of silent chats that has become more severe over time.

Scenario:

  1. A chat customer enters the queue via a webpage that embeds the LexWebUI widget. While they wait in the queue, the LexWebUI widget is kept minimised.
  2. The customer decides to close their browser due to waiting times, but they remain active in the queue.
  3. An agent answers the chat, thinking that a caller is present and continues to wait until they deem the chat is no longer active (we used delivery receipts, and store the contactId, participantId, participantToken in browser storage for 2 minutes to allow them to reconnect if they reopen the tab).
  4. The agent ends the chat and is then available to receive the next contact.

Due to the nature of the chat customers, it's critical for us to understand their connection status and be able to inform agents when the caller no longer has the LexWebUI tab open.

Are we able to make use of any underlying websocket events to trigger messages to the agent so they know when a caller is no longer active? The standard connect idle timer is not suitable for this as we need to implement a real-time mechanism for monitoring connections.

I understand that connect uses the Participant Service to manage websocket connections between customers and agents. Are we able utilise the SendEvent API as a way for agents to verify a customers connection, or is there a better alternative?

image

We are currently using the v0.21.2 stack for our application.

Please let me know if you require any further information.

Thanks

@atjohns
Copy link
Contributor

atjohns commented Nov 20, 2024

Okay so let me make sure I understand, basically you want to know if someone minimizes the tab and send an event/message to the agent that the customer is no longer active? And then if they open the tab another event/message to let them know it was opened?

@JoabHInclineIT
Copy link
Author

Thanks for the quick response.

A minimise event message, reconnect event message and tab closure event message to agents would likely give them the data they need to make an informed decision about ending the chat.

Ideally we'd also give the agents visibility of any network issues that are being experienced on the customer side e.g. if their network drops out temporarily.

@atjohns
Copy link
Contributor

atjohns commented Nov 20, 2024

Okay so yes I think at least a subset of these is possible, we have event handlers build into the Web UI for some of these actions.

In actions.js, there is an action handler to toggle what happens when the user minimizes called toggleIsUiMinimized. You could modify that to also trigger a new function in the live chat handlers to send a message to Connect. I would say the easiest thing would be to treat this like a regular message the user would type but send something like 'customer minimized tab' or 'customer reopened tab'.

You could probably avoid writing a new function altogether and just do something along these lines in the toggle function...

toggleIsUiMinimized(context) {
....
    context.commit('toggleIsUiMinimized');
    if (context.state.chatMode === chatMode.LIVECHAT && liveChatSession) {
        if(context.state.isUiMinimized) {
                  sendChatMessage(liveChatSession, "Chat window opened");
        }
       else {
                  sendChatMessage(liveChatSession, "Chat window closed");
       }
    }
.....
  },

Unfortunately there is no good way to handle closure of the entire browser tab (maybe you could detect the web socket connection being broken on the Lambda, which is located here)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants