Chatti Live – Conversations

Route

• Path: /account/conversations
• Parent: README.md
• Nav group: Chatti Live in the authenticated account shell

This is the current shipped route location in the app shell. Do not implement a separate /chatti-live/conversations route for the demo.

Purpose (business goal)

Provide a workspace-scoped monitoring and triage surface for customer conversations handled through Chatti Live channels.

For the demo MVP, this page is a read-only operations surface:

• visibility into conversation volume and status
• fast filtering and sorting
• lightweight triage of items needing attention
• inspection of a selected conversation or a placeholder detail state

Out of scope for the demo MVP:

• replying
• assignment changes
• archive actions
• AI composer / suggestions
• real-time streaming updates

Current implementation status

• Current app state: ComingSoon placeholder at /account/conversations
• Current document goal: define the demo-ready MVP that replaces the placeholder

User roles & permissions

• Agent
• Manager
• Workspace Admin
• Permissions (MVP/TBD): conversations.view

Deferred permissions for future operational actions:

• conversations.reply
• conversations.assign
• conversations.archive

Reference: Roles & Permissions Model

Architecture fit

This page fits the current architecture if implemented as an account-shell route with page-local workspace context:

• route remains /account/conversations
• shell navigation remains unchanged
• the page owns the workspace selector/filter behavior
• demo data is client-side seeded and filtered in-page

This avoids introducing a second routing model for Chatti Live while still keeping the page grouped under the Chatti Live navigation section.

Layout structure (demo MVP)

The page uses the standard account shell and a two-column operational layout.

1. Merged page header / toolbar

• page title: Conversations
• title row and controls live in the same bordered top section with no divider between them
• page-level workspace selector
• page-level platform selector (All platforms, multi-select)
• search input
• sort control (Newest first / Oldest first)
• filters trigger with active filter count

2. Metrics summary row

Summary cards derived from the currently filtered dataset:

• Total Conversations
• Active Chats
• Closed Chats
• Archived Chats
• Requires Attention
• Avg Response

For the demo, Avg Response is allowed only if it is derived from seeded message/thread timestamps. If thread timing is not seeded, replace it with a safer derived metric such as Avg messages / conversation.

3. Main content

Two-column layout:

• Left: conversation list
• Right: selected conversation detail placeholder

Recommended desktop split:

• list column: fixed or semi-fixed width (360-420px)
• detail column: fills remaining width

4. Detail panel behavior

• default state: Select a conversation to view its messages.
• demo state: show lightweight mock thread or metadata summary for the selected item
• future state: full thread + reply composer

Filters & controls (demo MVP)

Search

• Placeholder: Search conversations
• Matches:
  • contact name
  • last message preview
  • assigned agent name
  • channel/source label

Use debounced client-side filtering for the demo.

Sorting

• Newest first (default)
• Oldest first

Sort key: last_message_at

Filters

Supported in the demo:

• Workspace
• Platform
• Date range

Nice-to-have in the same client-side architecture:

• Status

Conversation list

Each row should include:

• avatar or fallback icon
• contact name (Unknown when missing)
• relative timestamp or compact date/time
• last message preview
• status badge
• message count
• source/channel indicator
• assigned agent label if present

Selection behavior

• Clicking a row selects it
• Selected row is visually highlighted
• Selection updates the right detail panel

Priority treatment

• Requires attention rows must be visually distinguishable
• status badge colors must be accessible and consistent

States

• Loading: only needed if client seed hydration or future data fetch introduces latency
• Empty (no data at all): No conversations yet.
• Empty (filtered): No conversations match the current filters.
• Detail default: Select a conversation to view its messages.
• Complete: list + metrics + detail placeholder visible

Do not use There is nothing pending as the general empty copy for this page; that wording implies an inbox-only unresolved queue rather than a full conversation history surface.

Demo data requirements

The page must be implementable with seeded demo data before backend integration.

Use the companion seed spec:

• Chatti Live – Conversations Demo Data

Demo data model (minimum)

type DemoConversation = {
  id: string;
  workspace_id: string;
  contact_name: string | null;
  contact_avatar_url?: string | null;
  status: "active" | "closed" | "archived" | "attention";
  source: "web-chat" | "facebook-messenger" | "whatsapp" | "sms";
  assigned_agent_name?: string | null;
  last_message: string;
  message_count: number;
  requires_attention: boolean;
  created_at: string;
  updated_at: string;
  last_message_at: string;
};

Optional thread data for a richer detail panel:

type DemoConversationMessage = {
  id: string;
  conversation_id: string;
  sender: "customer" | "agent" | "system";
  sender_name?: string | null;
  body: string;
  sent_at: string;
};

Business logic (demo MVP)

• All metrics recalculate from the filtered dataset.
• Workspace selector swaps the in-page data context; it does not require route navigation.
• Search, date filtering, and sorting are client-side only for the demo.
• requires_attention may be seeded explicitly rather than inferred.
• Status and requires_attention may coexist, but badge hierarchy must be clear.

Future scope (not in demo MVP)

• Reply composer
• Assignment actions
• Archive action
• AI-generated summaries
• AI reply assistance
• real-time updates / websockets
• CRM/contact enrichment

API dependencies (future)

Future backend target surface:

• GET /conversations
• GET /conversations/{id}
• GET /conversations/{id}/messages
• POST /conversations/{id}/reply
• POST /conversations/{id}/assign

These are not required for the demo implementation.

Enterprise constraints

• Multi-workspace isolation is required even for demo data structure.
• Search and filtering must not imply cross-workspace leakage in future production wiring.
• Avoid exposing unnecessary PII in seeded data.

Edge cases

• Unknown contact name
• Very long last message
• Zero-message edge records should not be seeded for demo unless explicitly testing ingestion failure
• Conversation marked attention but also closed
• Multiple conversations from the same contact across different channels

Security & compliance considerations

• Seed data should use fictional contacts and safe placeholder message content.
• Do not model or log sensitive PII unnecessarily.
• Future reply/assignment actions must be permission-gated, but the demo MVP is read-only.

Reference: Security & Compliance

Analytics events (future)

Demo MVP can defer analytics. When implemented later, likely candidates include:

• conversations.viewed
• conversations.filtered
• conversations.sorted
• conversations.selected

Reference: Analytics Events (MVP)