jdev - 2025-12-15

That's interesting. How did the agent get allocated to a customer and how did the customer know which muc to connect to?

erik, the client created an empty MUC, and sent a XEP-0045 invitation to the team they wanted to chat with

The mapping to a particular agent was encoded in the full JID, so an agent's JID looked like <company>@<domain>/<agent>

In practice we supported an array of different backend software that agents were using, so that resource encoded whatever info each proprietary backend used to represent an agent/session

Thanks for sharing! It seems your approach does not queue customers until an agent is available. We're agents always available then?

The software the agents were using would show pending chats, and allow them to accept and join

Ok. The xep seems to try to prevent multiple agents ending up in a single customer chat. How does that work in your case? And how does the customer know what their position in the queue is? I mean, the xep has a facility to communicate that to the waiting customer. (Not that I need it in my case, but curious about the general case, really)

erik, we didn't communicate queue position to the customer, we just focused on trying to minimize wait times generally (it varied between use cases, but in general there is a very sharp drop-off after 10-30s of waiting)

I don't recall any issues with multiple agents from the same company/team joining (though in some cases we intentionally had multiple agents in a chat)

Ah. Ok. So by the sound of it, you didn't seek to solve some of the things the xep did take into scope. That's fine, of course, but doesn't mean the xep needs to be discarded, does it?

does support need anything outside regular modern XMPP even? in my mind all agents log in to the same JID, they see all messages from everyone and any one of them can respond

Depends on the scale of the support system, I guess.

For me, that would work as long as the users can only see the replies intended for them. It will be a lot of sifting through age t replies otherwise....

erik, I'm not going to say the XEP should be discarded if someone finds it useful. I think my point is simply that it isn't strictly necessary. For us, reusing existing XMPP protocols was more natural and simpler (able to use pretty much any existing XMPP library, for example).

Thinking of it, the same applies to solutions using that xep, right? It depends on regular muc for the chat component. The xep solves _agent allocation_ not chat itself. Whereas your solution focused more on the chat itself than allocating agents. Having these thoughts, I think you focussed on tangent problems.

> does support need anything outside regular modern XMPP even? in my mind all agents log in to the same JID, they see all messages from everyone and any one of them can respond that's what we used to do. it is hard to keep track of status and stuff though which is why we moved to chatwoot ↺

singpolyma, right, but that could be improved if you used a custom client (which chatwoot basically is)

and a custom client would be needed for the workgroup XEP anyway

MattJ - do you know of any XEPs other than Workgroups that document approaches for this?

I don't

That's kind of my point really, I don't know that any additional XEPs are needed

Even if it's not a protocol, a 'best approach' kind of description would be handy

That could've guided people to something more lightweight than Workgroup Queues.

That wouldn't really be my approach

IM clients aren't really designed for this use case, so someone needs to build the software

If, during/after building that software, some protocol patterns seem like they deserve commenting on for interoperability purposes, a XEP would certainly be warranted

Until such software exists though, I think it would be a totally pointless exercise

Fair

Developing protocols is always a chicken and egg problem. There isn't that much required from the client. It's more the agent software which needs to have special support

Only needs to know how to send the queue join and chat request acceptance.

These days I would probably look towards pubsub for implementing stuff like this

Then you don't need any kind of special server support or specialized component

Would be nice to have that write up of your thoughts on that, I have to agree with Guus. That will help people find effective and efficient solutions.

What kind of write-up?

essay style at least 10 pages, you have until next week

😅

change the font size to 12.4 and line spacing to 2.4 teacher won't notice... you reckon kids still do this? :P

No chatgpt writes all the papers now