Advanced Conversation Lifecycle: Rule-Based Creation of New Conversations for Stale or Closed Chats

[ldaniel-jmz]

Hello Chatwoot Team,

We are using the platform extensively for our customer communication over WhatsApp, and it's a core part of our operations.

As we've scaled our usage, we've encountered a significant challenge in the long-term management of conversation lifecycles. This is a common use case for any business using persistent channels like WhatsApp, where conversations lack a natural "closing" point.

The Problem: The "Single Endless Thread" vs. "Conversation Chaos"

The current global lock_to_single_conversation setting forces a difficult choice between two suboptimal scenarios:

1. Enabled: This is excellent for managing a single, active customer case. However, it results in "zombie threads" where a customer returning months later with a new, unrelated issue reopens an old conversation. This creates confusion for agents, mixes distinct business cases, and makes it hard to track case-specific history.
2. Disabled: This often leads to "conversation chaos," where a single customer issue can get fragmented across multiple conversations, making it difficult to maintain context.

The core business need is to treat discrete customer requests as separate conversations, even for the same contact. An appointment from January is a different case than a new inquiry from the same customer in June.

Proposed Solutions

We propose introducing more granular, rule-based logic to handle this lifecycle. Here are three potential solutions, ordered from a fundamental core-model change to a more specific automation rule.

1. A New, Terminal Conversation Status: Closed (The Core Feature)

This is the most robust and architecturally sound solution, following standard helpdesk/ticketing patterns.

• How it works: Introduce a new, final conversation status called closed. This state would be more definitive than resolved and would signify that a business case is completely finished.
• Business Logic: If an incoming message arrives from a contact, and that contact's most recent conversation is in the closed state, Chatwoot must create a new conversation for this message.
• Rule Hierarchy: This logic should always take precedence over and ignore the global lock_to_single_conversation setting. A closed state explicitly marks the end of a lifecycle, and the system should respect that by starting a new, clean thread.

2. Time-Based Auto-Creation Rule (The Automation Layer)

This would be a powerful, "set and forget" feature for automated housekeeping.

• How it works: In the Inbox settings, introduce a new, separate configuration section:

  "Start a new conversation for returning contacts"

  ☐ Enable if contact's last resolved conversation is older than: [ 7 ] [ Days | Hours | Weeks ]

• Rule Hierarchy: This rule would also override the lock_to_single_conversation setting when its time-based conditions are met. It provides an automated way to achieve a similar outcome to the Closed status for conversations that are simply abandoned rather than explicitly closed.

3. Per-Conversation Override Flag (The Granular/API Solution)

This provides a precise instrument for developers and automation workflows (like n8n).

• How it works: Introduce a new boolean property on the conversation object, settable via the API: create_new_on_next_message: true. An automation workflow could set this flag on a conversation after a specific business process is completed.
• Business Logic: When a new message arrives from that contact, Chatwoot checks their last conversation. If it is resolved AND the create_new_on_next_message flag is set to true, it must create a new conversation for this message.
• Rule Hierarchy: This per-conversation directive would provide the most granular level of control, overriding all other global settings for that specific interaction.

Business Impact:

Implementing any of these solutions would provide much-needed control over the conversation lifecycle. It would dramatically improve operational efficiency, agent experience, and the clarity of customer interaction data for any business that handles multiple, distinct cases with the same customers over time.

Thank you for your time and for considering this important architectural improvement.