Automatic Capacity Release and Message Session

During testing in our operation, we evaluated both the automatic inactivity feature and the message session trigger for Chat/Messaging support. While these functionalities have proven effective within a general framework, we identified some scenarios where their behavior did not fully align with our operational needs.

One of the main issues observed was that tickets in other statuses, such as Hold and Resolved, that were reopened as "Open" were automatically marked as inactive. As a result, tickets without a definitive response were closed without proper follow-up to users. This behavior occurred in both the automatic capacity release and session triggers.

Additionally, during periods of high backlog, response times increased. We identified cases where the user became inactive before receiving an initial response from an agent, negatively impacting the support experience.

Given these scenarios, we believe that inactivity should be identified based on who became inactive first: the user or the agent. Therefore, we suggest the following:

• Implement a mechanism to determine whether the last message was sent by the agent or the user.
• If the user becomes inactive after the last message sent by the agent, inactivity rules should be applied.
• If the last message was sent by the user, the rule should not be applied.

This approach would ensure better ticket handling, preventing unnecessary closures and improving the user experience in customer support.

Additionally, for operations with multiple messaging channels, automatic capacity release is applied globally across all channels based on the Messaging configuration. Since we use different strategies for Chat, WhatsApp, X, Instagram, and Facebook, this configuration has had a negative impact on our operations.