Issues Sending SMS to Queue When the Chat Starts Internally

[CITMark]

Hello all,

I have a client that needs to have multiple employees view SMS conversations at the same time, and chime in individually when needed.

We have inbound SMS going to a queue, and we have the "Take Control" option enabled in the queue so responses don't automatically take ownership of the chat. This works exactly as we need it for SMS messages that start when the client makes the initial message.

My issue is when an employee starts a conversation.

I have tested transferring to the SMS queue, which does allow everyone else in the queue to see it, but the user that transferred the chat isn't included in it anymore (even though they are part of that queue).

The only option that seems to work is to mark the chat as "dealt with" right after the initial SMS is sent, and then the responses will come into the queue naturally. My issue with this is that nobody will see the context for the response from the original message as it will start a new thread.

Is there a way around this that anyone has found?

 

[KyriacosS_3CX]

I have tested transferring to the SMS queue, which does allow everyone else in the queue to see it, but the user that transferred the chat isn't included in it anymore (even though they are part of that queue).

Hello,

This should be the correct way of doing it, and I double checked, the original sender continues to see the chat as a member of the queue.

Can we confirm/check some things?
The original sender, are they a true member of the queue or a Supervisor? If agent, then the chat should be visible in Recent chats, if Supervisor, then they would need to select the actual queue in the Chat view filters.

In the chat Report, if you do a fresh test and open the details of the specific chat, that would show if some queue member is Taking that chat and therefore hiding it.

Let's see if these two checks turn up something.

 

[CITMark]

Hello, thank you for your response.

I did find that the issue was because the extension I was testing with was a user in the SMS queue, but was also set as a supervisor.

For some reason, when I transferred conversations to the group while I was both a user and a supervisor, it would transfer without me being a part of it. When I removed the extension from the supervisor role and left it as a user, it would transfer to the group while retaining that extension's membership of the group.

As mentioned previously, when transferring, it would add everyone in the group, but not the extension I was transferring from.

To reiterate for anyone else seeing this, you don't want to add a user as a supervisor if they are already in the user list of the queue.

Thank you again.

 

[KyriacosS_3CX]

Hello,

If a user is both an Agent and a Supervisor in a queue, it should not make a difference.

To make sure we are talking about the exact same scenario, let me brake it into steps:

1. User A is both Agent and Supervisor in a queue Q. The queue has other agent members, B, C, D.
2. User a goes to the Chat panel, clicks + and sends an SMS to a mobile phone Z that has no existing conversation.
3. Before or after Z replies, A hits the transfer button on the chat and points it to Q.
4. User A sees the chat is Recents and when the chat filter is set to Q.
5. If another agent Takes the chat, user A sees it only with filter set to Q, via their Supervisor role.

If the above is not the behaviour you see, could you detail exactly what you do see/actions performed, so we can trace where things differ?

 

[CITMark]

Steps 1 -3 is correct.

User A doesn't see the chat that was transferred in "Recents", but can see it when they filter by the Queue 'Q'. They also don't have the ability to respond.

When they click on the "information" tab in that conversation, it shows all chat participants of Queue 'Q', but doesn't include User A.

This did not happen after I removed User A from the "Supervisor Role".

I will say, I did add User A back as a supervisor role now to double-check and it doesn't appear to be having the issue anymore. I'm not 100% sure what happened, but it does appear to be working correctly with User A as a User and as a Supervisor.