Genesys Cloud - Main

Hi everyone,

I have a question about the new Inactivity Handling feature for messaging conversations.

From what I understand, a conversation is considered inactive when either the customer or the agent stops responding for the configured period. However, the queue configuration provides only a single inactivity timer and a single action, which means the same timeout and treatment are applied regardless of which side was inactive.

In our use case, we would like to handle these scenarios differently. For example:

• If the customer is inactive, we may want to wait longer and then route the conversation to an Architect flow or disconnect it.
• If the agent is inactive after the customer has sent a message, we may want to use a different timeout and potentially a different treatment.

Is there currently any native way to differentiate customer inactivity from agent inactivity, with separate timers and/or actions?

I considered routing the interaction to an Architect flow and trying to determine who sent the last message, but this seems like it could make the solution considerably more complex just to distinguish the two inactivity scenarios.

Is there a simpler or recommended approach for this today?

Thanks!

Your understanding is correct. Currently, Inactivity Handling uses a single inactivity timeout and treatment, regardless of whether the customer or agent is inactive.

There doesn't appear to be a native way to configure separate timers/actions for each side. To differentiate them, you would likely need custom logic in Architect to identify who sent the last message, which adds complexity.

I think having separate customer inactivity and agent inactivity timers/treatments would be a useful enhancement, especially for messaging channels where these two scenarios represent very different operational situations.

It would be interesting to hear from Genesys whether there is a recommended pattern for handling this today, or if separate inactivity handling by participant is something planned for the feature.

That was my understanding as well.

Using Architect to identify the last participant who sent a message seems to be the possible workaround today, but it adds a fair amount of complexity for something that could potentially be handled directly by the inactivity configuration.

Having separate timers and treatments for customer and agent inactivity would definitely make this feature more flexible, especially since these scenarios usually require very different business rules.