Problem Statement
Currently, when a customer replies to a closed conversation after seven days, the platform automatically creates a new conversation. While this is configurable to change from 7 days to another time frame. It is global and not configurable per brand.
Our Services Team (Brand) conversations frequently resume weeks or even months later. A common example is a student following up to reschedule training or re-engage on a previously planned service. In these scenarios, the automatic creation of a new conversation fragments context, increases handling time, and requires agents to manually search historical threads to regain continuity.
For other Brands other than the primary, there may be teams like Services or Training where maintaining a single, long-lived conversation thread materially improves clarity, efficiency, and customer experience.
Current Limitation
The conversation reopen window is controlled by a global workspace setting. This creates a structural constraint where behavior optimized for one Brand cannot be differentiated from another Brand or other long-cycle engagement models.
Proposed Enhancement
Introduce brand-level configurability for the closed-conversation reply window.
Specifically:
-
Allow the reopen window to be configured per brand, rather than globally
-
Enable extension of the window beyond seven days, for example 90 days or longer
-
Optionally allow the window to be disabled entirely so late replies continue in the original conversation
Business Impact
This enhancement would:
-
Preserve conversational context for long-running engagements
-
Reduce agent effort and cognitive load caused by fragmented threads
-
Improve internal efficiency and training delivery workflows
-
Allow organizations to align Intercom behavior with multiple Brand engagement models within the same workspace
Strategic Value
As customers increasingly use Intercom across Support, Services, Training, and Customer Success, brand-level configurability enables Intercom to better support differentiated operational models without compromise. This change would unlock greater platform flexibility while maintaining sensible defaults for Support-centric teams