We are experiancing an intermittent issue where when requesting a chat our customers are not always connected to an agent. The offer is presented to the agents and one will accept but the customer doesn’t enter the conversion.
When testing for customer experience it seems that the box that says “waiting for agent” with the estimated time is not appearing in the window on the customers side.
Has anyone else experienced this? Does anyone have a solution?
Fastpath Service 4.1.0
Fastpath Webchat 4.0.0
Openfire runs on a linux server by it’s self with the Fastpath Service plugin
Fastpath Webchat runs on another linux server
A third linux server acts as a proxy to Webchat
This issue seems to be completely intermittent but affects multiple sessions when it crops up before disappearing on it’s own. Sometimes if caught in time closing the queue and reopening it seems to clear it up.
Yes, we had this problem also.
The ‘queue position text’ doesn’t show and then the page stops polling to see if the agent has connected, even though the chat is being presented to the agents.
This seemed to happen intermittently as you say, but I’ve seen it specifically on slow networks and on cleared caches more often. Our agents are distributed and I witnessed this behavior doing training during remote site visits many times.
You can force this problem (in OpenFire 3.6.4) by removing the variables for queueWaitTime and queuePosition from the ‘Queue Position Text’ settings in your FastPath Workgroup text settings. The script will try to fill in these details and fail, stopping the page from functioning.
I don’t know exactly what was wrong, but one thing that helped a lot was beefing up the database and memory. The faster the server can respond with the queueWaitTime and queuePosition variables, the less often this problem occurs.
We eventually contracted out to fix this and I’m not sure exactly what was changed. My sense is that some basic error checking was added and perhaps an automatic page refresh on failure.
We have doubled the RAM and added another CPU to each VM in the cluster that hosts Fastpath. Hopefully this will help - will monitor the situation.
We encounter this issue as well. Did you find a solution?