Hey everyone. I took over this Genesys Cloud org about six months ago and we are trying to set up SMS routing. Everything works great for the initial text message. The problem is that our customers sometimes take three or four days to reply. When they finally text back, the conversation routes to a completely different agent! Our agents are complaining that they lose all the context. Is there a simple setting to just keep the SMS session open longer, or do I have to build some crazy Architect flow to check the last agent who handled the number?
In PureConnect, interaction persistence was handled differently. In Genesys Cloud, asynchronous message routing utilizes a concept called Threading Timeline. The default configuration disconnects the interaction and returns the agent to queue if the customer does not reply within 72 hours.
You cannot simply leave the interaction ‘active’ indefinitely because it affects agent utilization and capacity rules. You must configure Last Agent Routing within your inbound message flow using the Get Conversation Data action to retrieve the previous agent ID.
This threading behavior is the absolute bane of my existence! I have spent hours trying to build real-time wallboards, and these lingering 72-hour SMS threads completely break the ‘active interactions’ metrics! The API considers the thread ‘connected’ even if the agent is offline! Do not increase the threading timeline timeout! It will completely ruin your reporting data. You have to use the Architect flow to look up the last agent, like the previous post mentioned. It is ridiculous that Genesys does not just have a simple toggle for ‘Sticky Agent Routing’ on the queue level.
From a Quality Management perspective, allowing a single interaction to span multiple weeks creates significant challenges for evaluation scheduling. Our evaluators require discrete interaction segments. If you implement Last Agent Routing via Architect, ensure you also configure the flow to append a custom participant attribute indicating a resumed session.
This allows the QM team to filter their evaluation queries effectively. Do not rely solely on the default conversation ID, as it may fragment across multiple routing attempts.