Proposal: Unify Tickets into Omnichannel Conversations (Conversational Support Architecture)

[JOY]

Summary & Proposal

Hi @bbbbbbbbbbbbba! Currently, AgentDesk maintains two parallel entities for handling customer inquiries:

1. Conversations ( _conversation, _message): Real-time chat, AI Agent loop, web/WeCom/Telegram/Zalo/Email messaging.
2. Tickets ( _ticket, _ticket_progress): Static issue records with title, description, manual status (pending, in_progress, done), and progress logs.

We propose unifying Tickets into Conversations to transition AgentDesk into a modern AI-First Omnichannel Customer Support Platform (similar to modern platforms like Intercom, Crisp, Front, and Zendesk Messaging).

---

Key Pain Points of the Split Architecture

1. Fragmented Agent Experience:

   • Customer support representatives in the Workbench have to navigate between /workbench (Conversations) and /workbench/tickets (Tickets).
   • Chatting with a customer and logging internal resolution progress happens in separate screens.

2. Context Disconnect:

   • When a ticket is created from a conversation, the ongoing chat context is frozen in time into a static ticket description. Follow-up customer replies in the chat do not naturally update the ticket state unless manually synchronized.

3. Duplicated Metadata & Operational Overhead:

   • Assignee, Team, Priority, Tags, Customer, and Status exist on both _conversation and _ticket.
   • Routing and assignment workflows have to be duplicated or synchronized across both models.

---

The Modern Omnichannel Solution

Instead of treating Tickets and Conversations as separate destinations, a Conversation IS the Ticket:

1. Enriched Conversation Model:

   • Add ticket-grade capabilities directly to Conversation:
     • Issue Lifecycle: open (unassigned/pending) $\rightarrow$ �ctive (in-progress/agent serving) $\rightarrow$ waiting (waiting for customer) $\rightarrow$
       esolved / closed.
     • Priority & SLA Tracking: Urgency levels (low,
       ormal, high, urgent) and SLA timers on conversations.
     • Internal Notes & Progress: Special internal messages (sender_type = note) visible only to agents, directly in the chat timeline.
     • Unified Tagging & Custom Fields: Assign tags, categories, and custom attributes to conversations.

2. Unified Workbench UX:

   • Single unified inbox for all channels (Web, Email, Telegram, Zalo, WeCom).
   • Sidebar panels provide full customer 360°, CRM integration, and issue metadata alongside the real-time conversation timeline.

3. Seamless AI $\rightarrow$ Human Workflow:

   • AI Agent handles inquiries directly in the conversation.
   • When complex troubleshooting or human escalation is needed, the AI Agent simply changes the conversation status, sets priority/tags, or routes to an agent team—without needing to create an external static ticket record.

---

Migration & Backward Compatibility Path

• Phase 1: Add internal notes (enums.IMMessageTypeNote) and conversation priority/SLA fields.
• Phase 2: Add conversation quick filters (My Inbox, Unassigned, Priority, Closed, SLA Breached) to the Workbench.
• Phase 3: Provide a simple database migration to link existing _ticket records into historical conversations and deprecate standalone ticket tables.

We would love to hear the maintainers' and community's thoughts on this architectural direction!

[bbbbbbbbbbbbba]

@JOY Thanks for this valuable architectural proposal. We agree with the overall direction: consolidating conversation and ticket capabilities could reduce context fragmentation and eliminate duplicated routing and assignment logic.

One real-world support scenario we would like to clarify is that a single conversation can contain multiple independent issues. For example, a customer may first ask about a billing discrepancy and later report an account-permission problem
in the same chat. These issues may require different teams, priorities, owners, and SLA targets, and may be resolved at different times.

The proposed “Conversation IS the Ticket” model appears to assume that one conversation represents one work item. For the multi-issue case, have you considered capabilities such as:

• Creating multiple independent Cases/Issues under one Conversation;
• Giving each Case its own title, status, priority, assignee, team, and SLA;
• Allowing a Case to reference a specific range or set of messages in the conversation;
• Keeping the Conversation as the unified communication timeline, while Cases carry independently trackable and closable work;
• Defining clear aggregation rules between the overall conversation status and the statuses of its multiple Cases.

This could preserve the unified inbox and smooth AI-to-human workflow while avoiding the need to force multiple unrelated issues into one status, assignee, and SLA.

We would be interested in your thoughts on a “one Conversation to multiple Cases/Issues” model and whether you have considered a similar splitting mechanism.