Chatti Live – Conversations Demo Data

Purpose

Define the seeded data model and dataset shape for the demo implementation of /account/conversations.

This document is intentionally implementation-friendly: it should be enough to create local mock data, demo metrics, filters, and a selected conversation detail state without backend APIs.

Seed strategy

Use a workspace-first seed structure:

• one shared list of demo workspaces already present in the app
• a conversation dataset scoped by workspace_id
• optional message-thread dataset keyed by conversation_id

For the demo, data can live in:

• local static TS seed files, or
• a small mock module near the route implementation

Do not introduce a fake API layer unless the implementation specifically benefits from it.

Minimum types

export type DemoConversationStatus =
  | "active"
  | "closed"
  | "archived"
  | "attention";

export type DemoConversationSource =
  | "web-chat"
  | "facebook-messenger"
  | "whatsapp"
  | "sms";

export type DemoConversation = {
  id: string;
  workspace_id: string;
  contact_name: string | null;
  contact_avatar_url?: string | null;
  status: DemoConversationStatus;
  source: DemoConversationSource;
  assigned_agent_id?: string | null;
  assigned_agent_name?: string | null;
  last_message: string;
  message_count: number;
  requires_attention: boolean;
  created_at: string;
  updated_at: string;
  last_message_at: string;
};

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

Recommended seed volume

Use enough data to make filters, sorting, scrolling, and empty states believable without making the demo noisy.

• 4 to 6 workspaces represented
• 8 to 14 conversations per workspace
• 3 to 8 messages for selected-detail threads

Recommended total:

• around 40 to 60 conversations overall
• threads for only a subset of conversations if implementation time is tight

Status distribution

Each workspace should include a realistic spread:

• active: the majority
• attention: a small but visible set
• closed: a moderate set
• archived: a smaller historical set

Suggested percentage target:

• active: 45-55%
• attention: 10-20%
• closed: 20-30%
• archived: 10-15%

requires_attention should usually align with attention, but include 1 or 2 deliberate mismatches across the whole dataset to validate badge/rendering logic if needed.

Source distribution

Use all currently relevant Chatti Live families:

• web-chat
• facebook-messenger
• whatsapp
• sms

Suggested mix:

• web-chat: highest volume
• facebook-messenger: medium
• whatsapp: medium
• sms: lowest

Workspace recommendations

Reuse recognizable workspace names already present in the app demo data, such as:

• Starbucks
• BMW
• Target
• Tesla
• Walmart

Not every workspace must have the same number of conversations. Uneven distribution looks more credible.

Example record characteristics

Seed rows should vary across:

• short vs. long names
• known vs. unknown contact
• short vs. long last-message preview
• assigned vs. unassigned
• recent vs. older timestamps
• different channels per workspace

Include a few recognizable operational scenarios:

• customer asks about pricing
• support follow-up after missed reply
• escalation-needed complaint
• order/status request
• appointment or reservation clarification
• duplicate outreach across channels

Metrics derivation rules

All summary cards should be derived from the filtered list, not separately hard-coded.

• Total Conversations: total filtered records
• Active Chats: count where status === "active"
• Closed Chats: count where status === "closed"
• Archived Chats: count where status === "archived"
• Requires Attention: count where requires_attention === true or status === "attention"

For the final metric:

• preferred: Avg Response derived from seeded timestamps if the dataset supports it
• fallback: Avg Messages / Chat

Do not hard-code any metric values independent of the visible list.

Empty-state coverage

Seed data should make it easy to test:

• default populated state
• workspace with very few items
• search with no matches
• date range with no matches
• filters that leave exactly one result

At least one workspace should have only 2-3 conversations so sparse states are visible.

Selection and thread coverage

For richer demos, include message threads for:

• at least 1 active conversation per workspace
• at least 1 attention conversation overall
• at least 1 closed conversation overall

Thread recommendations:

• 3 to 8 messages each
• mix of customer and agent senders
• one optional system message for status-change or assignment audit flavor

Naming and timestamp guidance

Use fictional but believable values.

• Contact names: common first/last names or null
• Agent names: reuse seeded workspace agents where available
• Timestamps: spread across the last 30 days
• Last-message timestamps: recent enough that Newest first sorting is obvious

Suggested file layout

One reasonable implementation shape:

src/app/account/conversations/_lib/demo-conversations.ts
src/app/account/conversations/_lib/demo-conversation-messages.ts
src/app/account/conversations/_lib/conversation-derived-metrics.ts

If the route stays small, a single seed module is also acceptable.

Example seed object

const demoConversation: DemoConversation = {
  id: "conv_bmw_001",
  workspace_id: "bmw",
  contact_name: "Maya Thompson",
  status: "attention",
  source: "web-chat",
  assigned_agent_id: "agent_bmw_02",
  assigned_agent_name: "Sophia Carter",
  last_message: "I still haven't received an update about the service appointment.",
  message_count: 6,
  requires_attention: true,
  created_at: "2026-03-12T09:15:00.000Z",
  updated_at: "2026-03-12T10:02:00.000Z",
  last_message_at: "2026-03-12T10:02:00.000Z",
};

Implementation notes

• Keep all IDs deterministic so selected rows and seeded threads remain stable.
• Prefer plain arrays plus derived selectors over prematurely abstract repositories/stores.
• If the page later migrates to real APIs, keep the route-level view model close to this seed shape to reduce rewrite cost.