Expert Conversation Interface — Design Proposal
Author: Design Review (Senior UI/UX) Date: 2026-05-03 Status: Draft — for founder review
0. Executive Summary
The current expert queue UI is functional but conflates too many distinct concerns into a single scrollable pane, creating cognitive load that will compound as the AI becomes more capable and tasks become more complex. This document proposes a redesigned interface built on three core principles:
- Separate what the client sees from what the expert thinks. The client conversation is a historical record and communication surface; the expert workspace is a decision-making environment. These are different jobs with different UX requirements.
- Make the AI a first-class participant, not a form field. The current "AI Suggestion" panel feels like a text box you might accept or discard. The redesign treats the AI as a briefing partner whose reasoning is visible and whose proactive insights are surfaced.
- Adapt to complexity, not to a one-size-fits-all. A 30-second approval of a draft reply and a 3-day agentic task reconciliation are fundamentally different tasks. The UI should make the simple case effortless and the complex case comprehensible.
1. Current State Analysis — What's Broken
1.1 The Single Pane Is Overloaded
TicketDetail.tsx stacks, top to bottom:
- Conversation thread (user + agent + expert messages, up to 340px)
- AI Suggestion panel (confidence + draft text + action buttons)
- Internal Notes (collapsible)
- Action bar (response textarea + 5–6 action buttons)
The expert must mentally separate four distinct concerns while scrolling through a single linear stack. There is no visual hierarchy that communicates what is client-facing vs. internal, what is AI-generated vs. expert-written, or what requires a decision vs. what is reference material.
1.2 Message Roles Are Visually Conflated
In CustomerThread, both role === "agent" and role === "expert" messages render with the same Amy avatar. The only distinction is a tiny (Expert) or (AI, 72%) sub-caption. An expert scanning the thread cannot quickly answer: "What has the client actually experienced? Has anything been sent yet? Was the last response AI or human?"
The thread also includes no indication of whether messages were sent, pending, or unsent drafts. There's no visual marker for escalation events (the moment the AI decided to stop and ask for help).
1.3 Two Competing Response Composers
The expert can compose a response in two places simultaneously:
- The AI Suggestion panel's edit textarea (
mode === "edit"inAISuggestionPanel) - The action bar's draft textarea at the bottom (
ActionBar.draft)
These both call the same endpoint (acceptSuggestion) but they are positioned at different points in the page, have different button labels, and operate independently. This creates confusion about which "compose" gesture commits the response.
1.4 The Escalation Context Is Buried
The most important piece of information for an expert — why did the AI decide it couldn't handle this? — is rendered as a single truncated line in the ticket header (item.reason || item.escalationReason || "Escalated ticket"). It has the same font size as the ticket ID. There is no confidence score, risk level narrative, or AI reasoning visible without digging into message metadata.
1.5 AI Reasoning Is Invisible
The agent service returns chain-of-thought reasoning that informs its confidence score, but no version of this reasoning is shown in the UI. The expert sees "confidence: 72%" with no explanation of what made the AI uncertain. This forces experts to re-derive the AI's logic from the raw conversation, duplicating cognitive work.
1.6 Agentic Tasks Are Disconnected
Multi-step agentic tasks live on a separate /workspace/tasks route. If a ticket arrives that triggered an agentic task, the expert must leave the queue view entirely to review and approve steps. There is no inline path from the conversation context to the task approval flow.
1.7 Internal Notes Are Hidden by Default
Internal notes start collapsed. Because they're collapsed, experts may not think to add them. Because they're rarely added, future experts picking up a deferred ticket have no context. The default should be visible (or at least a prominent "0 notes" indicator that invites addition).
1.8 No Path to AI-as-Peer
The current UI has one interaction mode: AI produces a draft → expert approves or replaces it. There is no surface for the expert to ask the AI a question, request more context, or see AI proactive insights beyond the initial draft. Any future where the AI becomes a bidirectional collaborator requires a dedicated conversational surface between AI and expert — which currently does not exist.
2. Message Taxonomy — Definitions and Display Rules
Before designing the layout, we must define each message type precisely. Confusion about message types is the root cause of most current UI problems.
2.1 Message Types
| Type | Definition | Visible To | Source |
|---|---|---|---|
| Client Inbound | A message sent by the client (user/team member) through any channel | Expert, Client | role: "user" |
| Client Outbound | A message that was actually delivered to the client — could be AI-approved or expert-written | Expert, Client | role: "agent" or role: "expert" with sent: true |
| AI Draft Response | The AI's proposed reply, not yet sent to the client | Expert only | role: "agent" with sent: false / suggestion panel |
| AI Escalation Note | Structured explanation of why the AI escalated: trigger, confidence, risk classification, specific concern | Expert only | item.reason, item.riskLevel, message.confidence |
| AI Reasoning | The AI's internal chain-of-thought that produced its confidence score and draft | Expert only (on demand) | message.metadata.reasoning (new field needed) |
| AI Proactive Insight | An unsolicited observation from the AI to the expert, mid-review ("I noticed…", "You may want to…") | Expert only | New message type (Phase 2) |
| Expert Message | A response composed by the expert and sent to the client | Expert, Client | role: "expert" with sent: true |
| Internal Note | Expert-only commentary on a ticket, never delivered to client | Expert only | is_internal: true |
| Agentic Step | A proposed or executed tool action as part of a multi-step plan | Expert, Client (simplified) | AgenticTask.steps[n] |
| Progress Update | A message sent to the client summarising task progress on a long-running request | Expert, Client | New message sub-type (Phase 2) |
2.2 Visual Treatment per Type
Client Inbound
- Right-aligned bubble, neutral background (
--bg-elevated) - Channel icon (email, WhatsApp, etc.) in top-right corner of first message in a sequence
- No avatar needed — the channel icon is sufficient identity
- Timestamp below bubble
Client Outbound (AI-approved)
- Left-aligned bubble, accent-tinted background (
--accent-subtle) - Amy avatar (the named specialist)
- Label: "via AI · [confidence]%" in muted caption
- Not visually distinguished from Expert Message on the client side — but experts can see the label
Client Outbound (Expert-written)
- Left-aligned bubble, same accent-tinted background
- Amy avatar (maintains persona)
- Label: "via Expert" in muted caption with expert initials indicator
- Subtle badge distinguishes it from AI-approved without breaking client experience
AI Draft Response
- Visually distinct from sent messages — dashed border, lighter background, AI brand color accent
- "DRAFT" pill badge — makes the "not sent" status impossible to miss
- Never appears in the Client View pane (see layout section)
AI Escalation Note
- Card-style component at the top of the Expert Workspace pane — not an inline message bubble
- Contains: escalation trigger summary, risk badge, confidence score, key concern
- Should be the first thing an expert reads when opening a ticket
AI Reasoning
- Collapsed by default under the AI Escalation Note
- "Show AI reasoning" expandable section
- Rendered as a monospace/prose block with subdued styling — it's reference material, not the primary read
- Shows chain of thought that explains the confidence score
Expert Message — same as Client Outbound (Expert-written) above
Internal Note
- Distinct visual language: yellow/amber accent border, notepad icon
- Author initials + name + timestamp
- Clearly labeled "Internal Note" — never ambiguous
- Permanently visible in the Expert Workspace pane (not collapsed)
Agentic Step
- Timeline card showing: step number, tool name, description, parameters summary, risk badge, status
- Color-coded by step status: pending (neutral), approved (green), executing (pulsing blue), complete (green check), failed (red)
- Approve/Reject buttons appear inline on pending steps — not on a separate page
Progress Update (Phase 2)
- Special message type in Client View — appears as an AI-generated progress summary to the client
- Expert can trigger or edit these
- Visually distinct from regular responses: clock icon, "Progress Update" label
3. Two-Pane Design Proposal
3.1 The Recommended Split
The two-pane split the founder proposed is correct. Here is the precise definition of each pane:
Pane A — Client View (left pane) "What does the client experience?"
This pane is a faithful representation of the conversation as the client sees it. It contains only:
- Client Inbound messages
- Client Outbound messages (AI-approved and Expert-written, labeled with provenance)
- Agentic task progress cards (simplified view — not the internal step details)
- Progress updates to the client
- The response composer (at the bottom)
What is explicitly NOT in this pane:
- AI drafts (not yet sent)
- AI reasoning or escalation notes
- Internal notes
- Confidence scores or risk labels
- Any information the client doesn't have access to
The expert can see exactly what the client sees, making it easy to answer "what does the client know right now?" and "what tone/context should my response assume?"
Pane B — Expert Workspace (right pane) "What do I need to decide?"
This pane is everything internal to the expert's decision-making process. It contains:
- AI Briefing Card (escalation note + confidence + risk + AI draft)
- AI reasoning (expandable under the briefing card)
- Agentic task step-by-step approval (when applicable)
- Internal notes (always visible, not collapsed)
- Expert-to-AI chat thread (Phase 2)
- Ticket management actions (Resolve, Defer, Reassign)
3.2 Full Layout Specification
┌──────────────────────────────────────────────────────────────────┐
│ QUEUE LIST (280px fixed) │ CLIENT VIEW │ EXPERT WORKSPACE │
│ │ (flex: 1.2) │ (flex: 1) │
│ [Org tabs] │ │ │
│ [Status tabs] │ Ticket │ ┌─ AI Briefing ─┐ │
│ [Risk/Sort filters] │ header: │ │ CRITICAL · 54%│ │
│ ───────────────── │ Customer │ │ Escalation: │ │
│ ● CRITICAL 2m │ name · ch │ │ Client asked │ │
│ Customer name │ badge │ │ for refund on │ │
│ "Can you refund my…" │ │ │ an order not │ │
│ ───────────────── │ ╭──────────╮ │ │ in our system │ │
│ ● HIGH 8m │ │ user msg │ │ │ │ │
│ Customer name │ ╰──────────╯ │ │ [Show AI │ │
│ "Where is my order?" │ │ │ reasoning ▸] │ │
│ ─── ────────────── │ ╭──────────╮ │ └───────────────┘ │
│ ▸ MEDIUM 1h │ │ Amy sent │ │ │
│ Customer name │ │ via AI │ │ ┌─ AI Draft ────┐ │
│ "I need help with…" │ ╰──────────╯ │ │ DRAFT ░░░░░ │ │
│ │ │ │ │ │
│ │ ╭──────────╮ │ │ "I understand │ │
│ │ │ user msg │ │ │ your concern │ │
│ │ │ (latest) │ │ │ about the │ │
│ │ ╰──────────╯ │ │ refund…" │ │
│ │ │ │ │ │
│ │ ─────────── │ │ [Accept & Send]│ │
│ │ ┌─────────┐ │ │ [Edit Draft] │ │
│ │ │ Compose │ │ │ [Write Own] │ │
│ │ │ response│ │ └───────────────┘ │
│ │ │ as Amy… │ │ │
│ │ └─────────┘ │ ─ Internal Notes ─ │
│ │ [Send] [↩] │ [+ Add note…] │
│ │ │ No notes yet. │
│ │ │ │
│ │ │ ─ Actions ─────────│
│ │ │ [Resolve] [Defer] │
│ │ │ [Reassign] [→Me] │
└──────────────────────────────────────────────────────────────────┘
3.3 Interaction Model
Opening a ticket:
- Expert clicks a ticket row in the Queue List
- Pane A (Client View) populates with the full conversation history, scrolled to the bottom (most recent)
- Pane B (Expert Workspace) shows the AI Briefing Card at top, followed by AI Draft, Internal Notes, Actions
- The AI Briefing Card is the natural first read — the expert's eyes land on it before anything else
The response flow — simple case (AI draft acceptable):
- Expert reads AI Briefing Card (escalation reason, confidence, risk)
- Expert skims the Client View to understand conversation context
- Expert reads the AI Draft in the Expert Workspace
- Expert clicks "Accept & Send" in the AI Draft section
- The draft appears in the Client View composer, pre-populated
- A brief "Sending as Amy…" confirmation, then the message appears in Client View as a sent message (labeled "via AI, 54%")
- The AI Draft section collapses/clears in the Expert Workspace
- Expert clicks "Resolve" — ticket leaves the queue
The response flow — expert wants to edit: 1–3. Same as above 4. Expert clicks "Edit Draft" → the draft text becomes editable in a textarea within the Expert Workspace 5. Expert makes edits → "Send Edited" button 6. Message appears in Client View as sent (labeled "via Expert (edited AI)") 7. A correction category prompt appears briefly: "Why did you edit?" — optional, but always present to encourage capture
The response flow — expert writes from scratch: 1–2. Same as above 3. Expert reads the AI Draft but discards it ("Write Own" button → draft panel collapses) 4. Expert's focus moves to the Client View response composer at the bottom 5. Expert types and sends — response appears in Client View as "via Expert"
Why the response composer is in the Client View pane: The composer belongs in the Client View because you are writing into the conversation. You should be looking at the conversation thread while typing your response — not scrolling a separate pane. The Expert Workspace handles AI interaction and ticket metadata; it should not also be the place where you compose the final message.
The "Accept & Send" button from the Expert Workspace does a one-click commit without requiring the composer. "Edit Draft" pre-populates the composer in Client View and focuses it.
3.4 Ticket Header (Shared / Above Both Panes)
A shared header bar above both panes (not duplicated in each) shows:
- Customer identifier (email, phone, Slack handle)
- Ticket ID (monospace, truncated)
- Risk badge (color-coded CRITICAL / HIGH / MEDIUM / LOW)
- Status badge
- Channel badge (email, WhatsApp, etc.)
- Assignee indicator ("You" / "Unassigned" / initials)
- Time in queue
This eliminates duplication and gives both panes context without eating vertical space in either.
3.5 Mobile Adaptation
On mobile (<768px), the three panels collapse to a bottom-sheet tabbed model:
- Queue tab: the list panel
- Conversation tab: the Client View (becomes the primary view when a ticket is selected)
- Workspace tab: the Expert Workspace, with AI Briefing and actions
This is a regression from desktop but acceptable for mobile triage. The most common mobile action is "accept and send" or "defer" — both achievable from the Conversation tab with the AI Brief visible on the Workspace tab.
4. AI-as-Peer Model
4.1 The Progression
The UI must support three phases of AI capability without requiring a redesign at each phase transition:
Phase 1 — AI as Draft Generator (now) AI produces a single draft. Expert approves/edits/replaces. The Expert Workspace shows the AI Briefing Card + AI Draft. This is a read-only relationship: AI speaks, expert listens.
Phase 2 — AI as Proactive Advisor (next) AI can surface observations beyond its draft: context from previous conversations, risks in the proposed action, relevant policies the expert should know about. The Expert Workspace gets an "AI Insights" section that the AI can write to asynchronously — not just when an escalation fires.
Phase 3 — AI as Bidirectional Peer (future) The expert can ask the AI questions in context. "What was the outcome of the last similar ticket from this customer?" "What would happen if I agreed to this refund?" "Can you draft a version that's more apologetic?" This requires a persistent AI chat thread embedded in the Expert Workspace.
4.2 AI Briefing Card (Phase 1)
The AI Briefing Card is a structured component that replaces the current loose combination of item.reason + confidence badge + suggestion text. It contains:
┌──────────────────────────────────────────────┐
│ 🔴 CRITICAL · Confidence 54% · Risk: HIGH │
│ ────────────────────────────────────────── │
│ Escalation trigger: │
│ "Client requesting refund for order #4421; │
│ order not found in our system. Potential │
│ fraud signal or data sync issue." │
│ │
│ [▸ Show AI reasoning] │
└──────────────────────────────────────────────┘
The escalation trigger is written in plain English by the AI — not a raw field value. It should be a 1–3 sentence explanation that answers: "Why am I seeing this? What does the AI think is going on? Why wasn't the AI confident enough to handle it?"
The "Show AI reasoning" expander reveals the chain-of-thought — the AI's internal deliberation. This is reference material for experts who want to understand the AI's logic, not the default read.
4.3 AI Insights Section (Phase 2)
Below the AI Briefing Card and AI Draft, a new "AI Insights" section appears when the AI has proactive observations to share. These are distinct from the escalation note:
┌──────────────────────────────────────────────┐
│ 💡 AI Insights │
│ ────────────────────────────────────────── │
│ • This customer has escalated twice in the │
│ past 30 days, both related to order sync │
│ issues. Previous resolution: manual │
│ credit applied. │
│ │
│ • Your refund policy allows a maximum of │
│ £50 without manager approval. The order │
│ value was £38. │
└──────────────────────────────────────────────┘
The expert doesn't need to ask for these — the AI surfaces them automatically. The insights are non-blocking: the expert can ignore them entirely. But they reduce the time an expert spends on background research.
Insights are generated when the queue item is created (or shortly after), not in real time. The UI shows a loading indicator in the Insights section while they're being generated, so experts know to wait briefly before acting.
4.4 Expert-to-AI Chat Thread (Phase 3)
A persistent input at the bottom of the Expert Workspace pane (or in a dedicated "AI" tab within it) allows the expert to message the AI directly:
Expert: What was the last order this customer successfully received?
AI: Order #4398, delivered 2026-04-14. A replacement for a
previous lost shipment (#4301). Both orders to the same
address. No complaints after #4398.
Expert: Draft me a response that offers a £25 goodwill credit
without admitting fault.
AI: [Draft updated in AI Draft section above]
This is rendered as a simple two-party chat thread — no special chrome. The AI's responses appear inline; if the AI updates the Draft above, a small indicator in the Draft section says "Updated by AI at 14:32".
Implementation note: The backend needs to support expert-initiated messages to the agent as a new message type that doesn't go to the client. The frontend should re-use the existing Socket.io infrastructure for real-time AI responses.
4.5 Trust and Transparency Rules
As the AI becomes more agentic, the UI must make its boundaries clear:
- AI can never send a message to the client without expert approval. The "Accept & Send" action is always expert-initiated. Even with a confidence threshold of 0 (always auto-send), auto-sent messages should be visible in the Client View with an "auto-approved" label that the expert can audit.
- AI reasoning is always accessible. The expert can always see why the AI did what it did. The "Show AI reasoning" expander is permanent, not just for low-confidence items.
- AI insights are advisory, not instructions. The UI should never frame AI insights as directives ("You must…"). They are observations ("I noticed…", "You may want to…").
- AI draft provenance is preserved. When a message is sent as an edited AI draft, the system records both the original AI draft and the expert's edits. This feeds the correction learning loop and is accessible in the ticket audit trail.
5. Long-Running Request Pattern
5.1 The Problem
The current UI assumes a ticket is a single exchange: client sends message → AI drafts reply → expert approves. Real work doesn't work like this. A request to "reconcile all Amazon orders for October" is a multi-day, multi-step task. The current UI has no model for this.
5.2 Agentic Task Integration — Inline, Not Separate Page
Agentic tasks should be visible inline in the ticket detail view, not on a separate /workspace/tasks page. When a ticket triggered an agentic task, the Expert Workspace pane shows a new section above Internal Notes: "Task Plan".
┌──────────────────────────────────────────────┐
│ Task Plan — 5 Steps │
│ ────────────────────────────────────────── │
│ ✓ Step 1 · Fetch Amazon orders (Oct) │
│ Tool: amazon_query · Risk: LOW │
│ Status: Executed · 14:02 │
│ │
│ ⏳ Step 2 · Match orders to Shopify │
│ Tool: shopify_query · Risk: MEDIUM │
│ Status: Pending approval │
│ [▸ View parameters] │
│ [Approve] [Reject with feedback] │
│ │
│ ○ Step 3 · Update 14 mismatched SKUs │
│ Tool: shopify_query · Risk: HIGH │
│ Status: Waiting for Step 2 │
│ │
│ ○ Step 4 · Generate reconciliation report │
│ ○ Step 5 · Notify client with summary │
└──────────────────────────────────────────────┘
The expert can see the full plan at a glance. Each step shows its tool, risk level, and current status. Pending-approval steps have inline Approve/Reject buttons. This eliminates the context-switch to /workspace/tasks entirely.
The /workspace/tasks page can remain as a "Task Overview" for experts who want to see all pending agentic task approvals across multiple tickets — but the approval action itself is always available inline.
5.3 Client View for Long-Running Tasks
In the Client View pane, the conversation looks different for long-running tasks. Instead of a linear message thread, there's a Task Timeline component:
╭────────────────────────────────────────────╮
│ 🔄 Amazon Order Reconciliation (Oct) │
│ Started: 2026-10-01 · 3 of 5 steps done │
│ [View details ▸] │
╰────────────────────────────────────────────╯
╭────────────────────────────────────────────╮
│ ✅ Step 1 complete: Fetched 847 orders │
│ Amy · 2026-10-01 14:02 │
╰────────────────────────────────────────────╯
╭────────────────────────────────────────────╮
│ ✅ Step 2 complete: Matched against │
│ Shopify. Found 14 discrepancies. │
│ Amy · 2026-10-01 14:18 │
╰──── ────────────────────────────────────────╯
╭────────────────────────────────────────────╮
│ ⏳ Step 3 in progress… │
│ Updating 14 SKUs in Shopify. │
│ Amy · 2026-10-01 14:25 │
╰────────────────────────────────────────────╯
The client sees a clear progress trail. Each completed step generates a brief summary message (written by the AI, approved by the expert or auto-generated based on risk). The client doesn't see the internal step details — just outcome summaries.
5.4 Progress Updates to Client
For long-running tasks, the expert should be able to send progress updates to the client without resolving the ticket. This is a new action in the Client View composer: a "Progress Update" message type that is visually distinct from regular responses and labeled as such for both the client and the expert.
The AI can draft progress updates proactively ("3 of 5 steps complete. Updating Shopify inventory now. Expected completion: 2 hours.") — these appear in the AI Draft section with a "Progress Update" badge and can be accepted, edited, or discarded like any other draft.
5.5 Ticket State for Long-Running Tasks
Long-running tasks need a richer status model than unread → in_review → resolved. The recommended additions:
| Status | Meaning |
|---|---|
task_in_progress | Agentic task executing; waiting for steps to complete |
awaiting_client | Expert sent a question to the client; waiting for reply |
deferred | Deferred by X hours; not immediately actionable |
These map to the existing status field on conversations and are surfaced in the Queue List panel as distinct badges — so experts can filter their queue by "tasks in progress" separately from "pending approval" items.
6. Simple vs. Complex Request Flows
The redesigned UI must handle both ends of the complexity spectrum without adding friction to the simple case.
6.1 Simple Flow — "What's my refund status?"
A client asks a simple, answerable question. AI confidence: 94%. Risk: LOW.
Expert experience:
- Ticket arrives in queue. AI Briefing Card shows:
LOW · 94% · Escalation: Confidence just below threshold for this org (threshold: 101). - AI Draft section shows the draft response — 2 sentences.
- Expert reads both panes in ~10 seconds.
- Clicks "Accept & Send." Response appears in Client View. Done.
- Ticket auto-resolves (or expert clicks Resolve — 1 click).
Total time: 15–30 seconds. The redesign doesn't add steps to this flow. The AI Briefing Card is compact. The draft is visible without scrolling. One click sends it.
The queue list row for this ticket should visually convey its simplicity: a LOW risk badge, a high confidence indicator, and a "quick accept" affordance inline on the row (on hover: a ✓ button that accepts-and-sends without even opening the detail view). This is a power-user feature for experts clearing a backlog of low-risk, high-confidence items.
6.2 Complex Flow — "Reconcile all Amazon orders for October"
A client requests a multi-step business operation. AI creates a 5-step agentic plan. Risk: HIGH for some steps.
Expert experience, Day 1:
- Ticket arrives. AI Briefing Card shows:
HIGH · Agentic task pending approval · 5 steps. - Task Plan section in Expert Workspace shows the full plan.
- Expert reviews Step 1 (risk: LOW) — parameters look correct. Approves.
- Step 1 executes automatically. Client View updates with "Step 1 complete" summary.
- Expert reviews Step 2 (risk: MEDIUM) — approves.
- Steps 3–4 are HIGH risk. Expert adds an internal note: "Checked with client — they confirmed OK to proceed on all 14 SKUs."
- Expert approves Steps 3–4.
- Step 5 is a client notification — expert reviews and edits the draft, sends.
- Ticket transitions to
task_in_progress.
Expert experience, Day 2:
- Queue shows ticket as
task_in_progresswith a "1 step needs review" badge (Step 4 failed — a Shopify rate limit error). - Expert opens ticket, sees the failure in the Task Plan section.
- AI Insight: "Step 4 failed due to Shopify rate limit. I recommend retrying after 6 hours or reducing the batch size."
- Expert approves the retry. Done.
Expert experience, Day 3 (completion):
- All steps complete. AI generates a summary progress update to the client.
- Expert reviews and sends. Ticket resolved.
The same UI layout handles both Day 1, Day 2, and Day 3 interactions — the Task Plan section expands or contracts based on how many steps exist, and the AI Draft section adapts to show whatever the AI needs the expert to approve next.
6.3 Medium Flow — "Can you help me dispute this invoice?"
A client needs back-and-forth. No agentic task. Multiple exchanges over 2 days.
Expert experience:
- Ticket arrives. Confidence: 61% (uncertain about the resolution). Risk: MEDIUM.
- AI Draft is a reasonable first response asking for the invoice details.
- Expert accepts draft. Response sent.
- Ticket status:
awaiting_client. - Client replies with invoice PDF (attachment). Ticket re-enters queue with new AI escalation (can't read PDFs).
- Expert reviews PDF inline (attachment viewer in Client View). Adds internal note with key details.
- Expert writes own response (the AI draft doesn't have the invoice details). Sends.
- Ticket resolved.
In this flow, the Client View pane shows the full back-and-forth growing over time. The Expert Workspace Notes section accumulates context across sessions. The AI Draft reflects each new escalation as it arrives.
7. Open Questions — Decisions Needed Before Implementation
7.1 Should the Composer Live in Client View or Expert Workspace?
Recommendation: Client View. (Argued in Section 3.3.)
The counter-argument is that the composer is part of the "deciding and acting" workflow, which is what the Expert Workspace is for. But composing a message is fundamentally about the conversation — you should be looking at the thread while you type. Place the composer where the context is.
Decision needed: Confirm this before building. It determines the layout of both panes.
7.2 What Happens to the Separate /workspace/tasks Page?
Recommendation: Repurpose as a "Tasks Overview" dashboard (queue depth, pending approvals across all tickets) but remove the step approval flow from it — approvals happen inline in the ticket detail.
The risk: some experts may prefer to batch-approve steps across multiple tickets without context-switching into each ticket. The Tasks Overview page could support this with an inline approval widget per task. But this is a power-user feature, not the primary path.
Decision needed: Should /workspace/tasks remain a functional approval surface, or become read-only overview? Determines whether we need to maintain two approval code paths.
7.3 How Is AI Reasoning Stored and Surfaced?
Currently, message.metadata can hold arbitrary fields. The AI chain-of-thought is not consistently stored. Before Phase 1 of this redesign can work fully, the agent service needs to reliably populate message.metadata.reasoning with a human-readable explanation.
Decision needed: Define the reasoning field format. Recommendation: a plain-English paragraph (100–300 words) summarising the AI's decision process. Not raw LLM output — the AI should be instructed to write for an expert audience.
7.4 Confidence Score Granularity and Display
Currently confidence is a 0–1 float displayed as a percentage. "54%" doesn't mean much to most experts. Consider:
- A simple band system: "Low confidence (below 60%)" / "Moderate (60–85%)" / "High (85%+)"
- Or: keep the percentage but add a plain-English interpretation: "AI was uncertain about the refund eligibility"
Recommendation: Keep the number (it's meaningful to power users and for analytics) but always pair it with the escalation trigger text that explains why — which is more actionable than the number alone.
Decision needed: Pure number, banded, or number + explanation? Affects the AI Briefing Card design.
7.5 What Does the Client See During Expert Review?
When a ticket is in in_review, the client may be waiting. Options:
- Nothing — client just waits (current behavior)
- An automatic "We're looking into this" holding message (sent when the ticket enters
in_review) - An expert-initiated progress update
Recommendation: Option 2 for tickets open >2 minutes. Auto-send a brief acknowledgment as Amy after a short delay, customisable per-org. This improves client experience without requiring expert action for every ticket.
Decision needed: Should this auto-acknowledgment exist? What's the delay threshold? Is it opt-in per org or platform default? Affects the conversation model significantly.
7.6 Multi-Expert Collaboration on a Single Ticket
The current system supports internal notes and reassignment but not real-time co-review. For complex tickets, two experts may want to discuss the ticket without one of them fully reassigning it.
Recommendation: Phase 2 feature. For now, internal notes are sufficient. In Phase 2, the Internal Notes section becomes a lightweight threaded discussion, not just a flat list of notes. Each note can be "replied to" inline.
Decision needed: Is inline expert-to-expert discussion a P1 feature (blocking this redesign) or P2 (can come later)? This affects how the Internal Notes section is structured in v1.
7.7 Inline "Quick Accept" on Queue Rows
Section 6.1 proposes a hover affordance on queue rows to accept-and-send without opening the detail view. This requires the draft text to be pre-loaded in the queue response (currently it's fetched separately per ticket).
Decision needed: Is the performance cost of pre-loading drafts in the queue list acceptable? Alternatively, the quick-accept could navigate to the ticket and auto-submit — a two-step action. Both approaches have tradeoffs.
7.8 Correction Capture Flow
When an expert edits an AI draft, the redesign shows a "Why did you edit?" prompt (correction category). Currently this is an optional field. The question is how to increase capture rate without adding friction.
Recommendation: Make the correction category a single required click (radio buttons or icon buttons, not a dropdown). The expert must select one category before "Send Edited" becomes enabled. This trades a tiny UX cost for significantly better training signal. Categories should be max 5 options with icons: 🧾 Factual error · 🎭 Tone · 📎 Missing context · ⚡ Wrong action · ✨ Just my preference.
Decision needed: Is mandatory correction categorisation acceptable to the Expert team? If experts find it annoying, they may prefer to use "Accept & Send" even on edited drafts to avoid it — which defeats the purpose.
Appendix A — Component Inventory
Components that need to be created or significantly modified:
| Component | Action | Notes |
|---|---|---|
TicketDetailPane | New | Replaces TicketDetail.tsx — is the orchestration container for the two-pane layout |
ClientViewPane | New | Pane A — client conversation + composer |
ExpertWorkspacePane | New | Pane B — AI briefing, draft, notes, actions |
AIBriefingCard | New | Escalation note + risk + confidence + expandable reasoning |
AIInsightsSection | New (Phase 2) | Proactive AI observations |
AIExpertChat | New (Phase 3) | Bidirectional expert↔AI thread |
AIDraftSection | Replaces AISuggestionPanel | Same logic, new layout and visual treatment |
TaskPlanSection | New | Inline agentic step approval (replaces /workspace/tasks approval flow) |
ConversationThread | Replaces CustomerThread | Stricter message type rendering, Client View only |
InternalNoteThread | Replaces InternalCollab | Always visible, threaded (Phase 2), not collapsible |
ResponseComposer | Replaces action bar textarea | Lives at bottom of Client View pane |
TicketActions | Replaces action bar buttons | Lives at bottom of Expert Workspace — Resolve, Defer, Reassign, Assign |
TicketHeader | Refactor | Shared bar above both panes, not duplicated |
TicketRow | Minor update | Add quick-accept hover affordance, agentic task indicator |
ProgressUpdateComposer | New (Phase 2) | Client-facing progress update in Client View |
MessageBubble | Refactor | Message type-aware rendering per taxonomy in Section 2 |
Appendix B — Design Principles Summary
- One pane for the client's reality, one for the expert's decision space. Never mix them.
- The AI Briefing Card is the first thing an expert reads. It must be at the top of the Expert Workspace, always visible.
- There is one response composer. It lives in the Client View pane. AI draft actions populate it; they don't have their own separate send paths.
- Internal information has distinct visual DNA. Notes, AI reasoning, and escalation data are visually distinct from client-visible content. An expert should never accidentally confuse the two.
- Approve agentic steps inline. The context is in the ticket; the approval should be there too.
- Simple tickets get out of the expert's way. The quick-accept path should be 1–2 clicks maximum.
- Complex tickets reward depth. The full task plan, AI reasoning, and note history should be accessible without leaving the ticket view.
- Build Phase 3 architecture now. The Expert-to-AI chat thread should be stubbed in Phase 1 (read-only AI briefing) so Phase 2 and Phase 3 are additive, not structural redesigns.