AI Concierge – UX Specification

Related Technical Authority: AI Concierge – Technical Specification

1. Purpose

This UX specification governs the staff-facing experience of the AI Concierge module — the voice and call-orchestration module that handles inbound calls during out-of-hours and overflow periods, executes rota-triggered outbound recovery calls, and automates post-call workflow creation. It defines the interaction model, surface layout, state representations, and governance visibility for the primary staff audience (receptionists, clinical coordinators, practice managers, and compliance officers) who monitor, intervene in, and configure AI-handled calls. It also establishes the UX boundaries that keep the AI's actions transparent, auditable, and never mistakable for human staff actions.

2. Core UX Principles (Non-Negotiable)

These principles take precedence over visual preferences. If a design choice conflicts with a principle below, the principle wins.

• Action-first — users see the action they need next, not abstract status displays.
• Governance always visible — when AI is involved, users always know what AI did and what they are confirming. Every AI-generated suggestion, response, and action is visually distinct from a staff action.
• No dead toggles — every UI control either does something or does not appear. Configuration settings that are not active for the current tenant must not render as disabled controls.
• Calm by default — the Agent Console does not pulse, flash, or demand attention unless a call genuinely requires human intervention. Recovery workflows running in the background surface as status, not as alerts.
• Progressive disclosure — call detail (full transcript, full audit trail, verification record) is one click away from the live queue view; it is not always-on.
• AI transparency, always — Because the technical spec (§7) requires the AI to introduce itself as an AI on every call and prohibits any AI action from misrepresenting itself as human, the UI must reinforce this at every touchpoint: AI-generated content carries a persistent, visible AI attribution marker; staff-initiated actions carry the staff actor's identity. Neither state may be ambiguous. (needs UX writer input — specific AI badge label and visual treatment)
• Verified before disclosed — Because the technical spec (§3.3) prohibits disclosure of patient-specific data before the verification state reaches Verified, the UI must make the current verification state immediately legible at the point any sensitive information is displayed or any one-click action is offered. Actions that are locked pending verification must be visually suppressed, not merely disabled. (needs UX writer input — specific suppressed-state microcopy)

3. Design Philosophy

Mental model

The Agent Console is modelled as a control room for live and recent calls, not as a communications inbox. The dominant metaphor is a dispatcher's view: staff see what is happening right now, what the AI has already handled, and what needs a human decision. The AI is a capable colleague who has done preparatory work — the staff member's job is to review, confirm, or take over, not to start from scratch.

Role separation from AI Assistant (Aiden)

AI Concierge and AI Assistant (Aiden) are both AI guidance layers within the platform but operate across fundamentally different interaction paradigms and must not be conflated in staff-facing UX. Aiden functions as a text-based, in-session assistant — described in its own specification as "a knowledgeable, calm colleague standing just behind the user's shoulder" — surfacing suggestions within staff-facing screens and requiring explicit human confirmation for all consequential actions. AI Concierge, by contrast, is a voice and telephony layer that acts autonomously during calls (within its governed constraints) and surfaces its outputs to staff after the fact or during passive monitoring, rather than as in-session prompts.

Both modules share the same foundational governance principles: AI suggestions are always labelled and attributed, humans retain control over consequential actions, and no AI output may be mistaken for a human action. Where a staff member encounters AI-generated content that originated from AI Concierge — whether in the Agent Console, in a Task Manager task, or within a Communication Hub thread — the attribution marker must clearly identify AI Concierge as the source, not Aiden, so that staff understand the provenance and the escalation path. The two modules must use visually consistent attribution conventions whilst remaining distinguishable. (needs UX writer input — differentiated AI attribution label treatment for Concierge vs. Aiden)

Empty states

An empty call queue (no active or recent calls) is a positive state — it means no calls are waiting. Empty states must communicate this clearly rather than implying a loading failure. (needs UX writer input — empty-queue message) Outside configured out-of-hours or overflow windows, the queue view should surface the next scheduled window so staff understand when the AI will next be active.

Error states

Errors that affect a live call (telephony failure, transcript loss, verification error) are urgent and must surface immediately in the active call view with a clear, single recovery action — typically a manual takeover prompt. Errors that affect background recovery workflows (retry exhaustion, suppression signal failure) surface as task-level alerts, not screen-level interruptions, consistent with the calm-by-default principle.

AI suggestions

AI suggestions (operator guidance scripts, proposed one-click actions, intent summaries) are always presented as drafts for staff review, never as executed decisions. Staff confirm or dismiss; the AI does not act autonomously on suggestions. Suggestions carry an AI attribution marker and a timestamp. Accepted, overridden, and ignored suggestions are all recorded in the audit trail (§8 of the technical spec), so the UI must support dismissal as an explicit action, not just inaction.

Multi-step flows

Where a staff action is irreversible — handover initiation, transcript export, task creation from a call — a confirmation step is required. The confirmation step must show the consequences of the action (e.g. which task will be created, which contact's transcript will be exported) before committing. This is consistent with the audit requirements in technical spec §8.

Undo / redo

Because call thread audit trails are immutable and append-only (technical spec §13.1), undo is not available for actions that generate an audit event. The UI must not offer undo for one-click Agent Console actions. Pre-confirmation steps serve as the point at which a user can cancel rather than undo.

Read-only vs editable surfaces

Call transcripts are immutable (technical spec §13.2, rule 13). The transcript panel must be visually read-only: no edit affordances, no cursor on content. Staff annotations (staff_notes) are append-only and must be presented as a separate, clearly bounded annotation layer, not inline with the transcript. Configuration surfaces (§13.3 of the technical spec) are editable only for roles with configuration permissions; for all other roles they render as read-only summaries.

4. Primary Surfaces

4.1 Web portal

Who uses it: Receptionists, clinical coordinators, practice managers, compliance officers, practice admins.

The web portal is the primary and, for this module, the dominant surface. The technical spec (§5.1) defines the Agent Console within Communication Hub as the primary staff delivery surface. All key tasks occur here.

Key tasks performed here:

• Monitor the live call queue — view active calls by mode (Out-of-Hours, Overflow, Recovery), duration, and queue assignment.
• Review the screen-pop context card for an active call — identity verification status, upcoming appointments, open forms, open tasks, family disambiguation prompt.
• Read the live streaming transcript with key-moment markers as a call progresses.
• Review AI-generated operator guidance and intent-aware scripts in the Operator Guidance Panel.
• Execute one-click Agent Console actions — takeover, transfer, create task, send form, send payment link (where enabled), open booking UI — subject to RBAC.
• Review completed call threads: final outcome, intent summary, full transcript, audit trail.
• Export transcripts and audit logs (practice managers and compliance officers only).
• Configure recovery thresholds, suppression windows, out-of-hours schedules, approved policy wording, and telephony routing maps (practice admins and practice managers only).
• Filter the calls workspace by call mode, call state, queue/department, date range, final outcome, and verification state.

Layout pattern: Split-pane. The left pane presents the live call queue (list); the right pane presents the detail view for the selected call — context card, transcript panel, operator guidance panel, and one-click action bar. This mirrors the list-detail pattern described for the Agent Console in technical spec §5.1 and is appropriate for a dispatcher model where multiple calls may be live simultaneously.

4.2 Tablet app

The technical spec (§5.2) explicitly notes "no content captured — needs definition" for the tablet surface. It is therefore not possible to infer a complete tablet UX from the technical spec. The following reflects only what can be safely inferred.

Who uses it: (needs product decision — technical spec §5.2 is explicitly undefined)

Key tasks performed here:

• At minimum, receptionists at front-of-house may need to see incoming call alerts and queue status on a tablet. However, the Agent Console one-click actions (RBAC-governed) and live transcript viewing are defined only for the web portal in the technical spec. Extending these to tablet requires an explicit product decision.

Touch ergonomics: One-handed reach; glove-friendly tap targets ≥48 px; confirmation modals must be reachable in the lower two-thirds of a portrait tablet screen. (needs product decision — tablet surface scope is undefined in the technical spec)

4.3 Mobile app (patient or staff)

The technical spec (§5.3) explicitly states: "AI Concierge does not present a direct patient mobile app surface; patient-facing outputs are spoken responses during calls and links sent via approved channels (SMS/email) through Communication Hub." There is no mobile app surface for this module. Staff mobile access is not mentioned in the technical spec and should not be assumed.

This module has no mobile app surface. Patient-facing outputs are delivered as spoken AI responses during calls and as links dispatched via Communication Hub over SMS or email.

5. Interaction Model

5.1 Primary flows

Flow A — Inbound call, AI-handled to completion

Inferred from technical spec §4.1, §3.2, and §3.3.

Inbound call received
        │
        ▼
Call Thread created (state: Ringing)
        │
        ▼
AI answers → introduces itself as AI (state: AI Answered)
        │
        ▼
Caller identification attempted (state: Identifying Caller)
  │
  ├─ Shared number? → Disambiguation prompt → resolve to single contact
  │
  ▼
Sensitive intent detected?
  ├─ Yes → Identity verification challenge (state: Verifying Identity)
  │         │
  │         ├─ Verified → proceed with intent handling
  │         └─ Verification Failed → generic responses only; offer staff handover
  │
  └─ No  → Proceed directly to intent handling
        │
        ▼
Intent handling — multi-turn dialogue (state: Handling Intent)
  │
  ├─ Self-service resolved → outcome recorded → Call Thread: Completed
  │
  ├─ Unresolved → Follow-Up Created → Task Manager task emitted
  │
  └─ Handover requested (caller or AI escalation) → see Flow B

Staff visibility during Flow A: The live call queue shows the call in progress with its current state badge. Staff may observe the streaming transcript and context card at any time. No action is required from staff unless they choose to take over.

Flow B — Staff takeover (handover)

Inferred from technical spec §4.5 and §3.2.

Handover Requested (initiated by caller or AI escalation)
        │
        ▼
Agent Console surfaces: transcript, intent summary, context card
One-click "Take over" action highlighted
        │
        ▼
Staff confirms takeover
        │
        ▼
State: Routing to Queue → State: Staff Connected
AI steps out; transcript continues if configured
        │
        ▼
Call resolved by staff → outcome recorded → Call Thread: Completed
        or
Call transferred → outcome recorded → Call Thread: Completed

The confirmation step before takeover must show the staff member the current intent summary and verification state so they are contextually prepared before speaking. (needs UX writer input — confirmation modal copy and layout)

Flow C — Rota-triggered outbound recovery

Inferred from technical spec §4.2, §6.1, and §13.2.

Appointment Manager emits rota cancellation event
        │
        ▼
AI Concierge assesses eligibility
(consent, contact preferences, fatigue/suppression rules)
        │
        ├─ Ineligible → no call; Task Manager follow-up created
        │
        ▼
Suppression record created; suppression signal emitted to Campaign Manager
        │
        ▼
Outbound recovery call initiated (Call Thread created, mode: Recovery)
        │
        ├─ Accepted → escalate to staff or governed booking flow
        │
        ├─ Declined / No answer → retry (up to configured threshold)
        │         └─ Threshold exhausted → Task Manager follow-up; suppression lifted
        │
        └─ Terminal outcome reached → suppression-lifted signal emitted to Campaign Manager

Staff visibility during Flow C: Active recovery workflows appear in the call queue with a Recovery mode badge. Exhausted recovery attempts surface as Task Manager tasks, not as live call entries. Suppression status is not directly surfaced to staff in the Agent Console but is visible in the call thread detail for compliance review.

Alignment with Appointment Manager's constraint-visibility model: Where a recovery call leads into a booking flow (the "Accepted" branch above), the UX must honour the same constraint-visibility principles that govern Appointment Manager's Find Next flow. Specifically: practitioner availability constraints, absence periods, and any scheduling rules that narrow the set of bookable slots must be surfaced to staff in the Agent Console's context card or handoff summary — they must never be silently omitted. If the AI proposes a specific slot or appointment as part of a recovery conversation, that proposal must be presented to staff (and, where relevant, confirmed by staff before commitment) with the same labelled, attributed treatment as any other AI suggestion: a visible AI attribution marker, a clear indication that this is a proposal rather than a confirmed booking, and a confirmation step before the appointment is created. Staff must be able to see why a given slot was suggested and what constraints applied, so that the automation is observable and explainable, consistent with Appointment Manager's governance model. (needs UX writer input — constraint-context display within recovery handoff summary)

Flow D — Configuration (practice admin / practice manager)

Inferred from technical spec §13.3.

Staff navigates to AI Concierge configuration settings
        │
        ▼
Settings available (role-gated):
  - Short-notice recovery window
  - Suppression expiry window
  - Recovery retry thresholds and back-off
  - Out-of-Hours and Overflow schedules
  - Approved policy wording library
  - Whitelisted patient record fields for AI disclosure
  - Transcript recording continuation during staff takeover
  - Payment link enablement
  - Telephony routing maps
        │
        ▼
Change made → confirmation step (irreversible or compliance-significant changes)
        │
        ▼
Change saved → audit event recorded

Configuration changes that affect live call behaviour (e.g. disabling out-of-hours mode, changing retry thresholds mid-recovery) should surface a warning that the change will affect currently active workflows. (needs UX writer input — warning message copy)

5.2 State machines (mirror of technical spec §3)

Call Thread state machine

All states and transition rules inferred from technical spec §3.2.

Calls in Handover Requested state must be visually elevated above other active calls in the queue — this is the state that most urgently needs staff attention. The elevation must not rely on colour alone (accessibility requirement).

State transitions are irreversible where the technical spec defines them as such (e.g. calls MAY NOT return to Ringing or AI Answered once Handover Requested or later). The UI must not offer any control that would imply these transitions are reversible.

Identity verification state machine

All states inferred from technical spec §3.3.

"Suppressed" means the action does not appear in the UI at all, not that it appears greyed out. This prevents staff from attempting an action that will fail at the point of execution. (needs UX writer input — tooltip or inline explanation for why certain actions are absent when verification has failed)

5.3 Empty / loading / error / offline states

Live call queue

• Empty state: No active calls. Surface the next configured out-of-hours or overflow window so staff understand when the AI will next be active. If no window is configured, surface a prompt to configure one. (needs UX writer input — empty queue message)
• Loading state: Skeleton rows representing call queue entries; skeleton preserves the column structure of the queue.
• Error state: If the call queue cannot be loaded (e.g. Communication Hub connectivity failure), display an inline error with a single retry action and a timestamp of the last successful load. Do not show a blank pane. (needs UX writer input — error message)
• Offline state: The Agent Console is a web surface and requires connectivity. In offline state, display the last-known queue state as read-only with a clear "You are offline — live data unavailable" banner. One-click actions must be disabled (and visually absent) when offline, as they cannot be executed or audited without connectivity. (needs UX writer input — offline banner copy)

Live transcript panel

• Empty state: No transcript segments yet (call just started). Display a waiting indicator. Do not show a blank panel. (needs UX writer input — waiting-for-transcript message)
• Loading state: Progressive — transcript segments appear as they stream. The panel scrolls to the latest segment automatically unless the staff member has manually scrolled up (in which case a "jump to live" affordance appears).
• Error state: If transcript streaming is interrupted, display an inline warning within the transcript panel — not a full-screen error — with the timestamp of the last received segment. The call continues; only the transcript display is affected. (needs UX writer input — transcript interruption message)
• Offline state: As above — transcript display requires connectivity; last-received segments remain visible as read-only.

Configuration settings

• Empty state: Settings with no value configured (e.g. no policy wording entries yet) must surface an explicit empty state with a direct action to add the first entry. (needs UX writer input — empty settings prompts)
• Loading state: Skeleton form fields.
• Error state: Inline field-level validation errors for invalid configuration values; page-level error if settings cannot be saved. (needs UX writer input — validation error messages)
• Offline state: Configuration surfaces must not allow saves when offline; display a read-only view with an offline banner.

6. Component Inventory

New components introduced by this module

• Live call queue row — a single call's status, mode badge (Out-of-Hours / Overflow / Recovery), duration timer, assigned queue, and current state badge. Appears in the Agent Console calls workspace left pane.
• Screen-pop context card — composite card showing caller identity verification status, upcoming appointments (read-only from Appointment Manager), open forms, open tasks, and family disambiguation prompt where applicable. Appears in the right pane when a call is selected.
• Live transcript panel — streaming, read-only transcript display with timestamped, speaker-labelled segments and key-moment markers. Includes append-only staff annotation layer. Appears in the right pane.
• Operator guidance panel — intent-aware, policy-safe script suggestions generated by the AI, each carrying an AI attribution marker. Supports staff dismiss/confirm interaction. Appears in the right pane alongside the transcript.
• One-click action bar — RBAC-governed set of contextual actions (takeover, transfer, create task, send form, send payment link, open booking UI). Actions appear only when permitted by the current user's role and the current verification state. Appears at the base or side of the right pane.
• Verification state indicator — compact badge/indicator showing the current identity verification state (Unverified / Verification Prompted / Verified / Verification Failed) with verification method on hover/expand. Appears within the context card.
• Call state badge — visual indicator of the current Call Thread state. Used in both the queue row and the detail header.
• AI attribution marker — persistent inline marker identifying AI-generated content (suggestions, transcript responses, intent summaries) as distinct from staff actions. Used throughout the transcript panel and operator guidance panel. (needs UX writer input — marker label and accessible description)
• Configuration settings panel — tenant-scoped settings form for recovery thresholds, suppression windows, schedules, policy wording, and telephony routing. Visible only to permitted roles; renders as read-only summary for all others.

Reused from the design system

• Form field components (text, select, toggle) — used in configuration settings panel.
• Confirmation modal — used for irreversible one-click actions and configuration changes.
• Filter bar — used in the calls workspace.
• Skeleton loader — used for queue and transcript loading states.
• Inline error / warning banner — used for error and offline states.
• Toast notification — used for action confirmations (task created, form sent).

7. Visual Design Notes

• Typography: (needs UX writer input — heading and body scale to be defined by the design system; monospace may be appropriate for transcript content to aid readability and scanning)
• Colour: Semantic colour usage must follow the platform design system. State colours for call states and verification states must be semantically consistent with the platform's success / warning / error / info palette. Verification Failed must use the error semantic colour. Verified must use the success semantic colour. AI attribution markers must use a distinct, neutral semantic colour that does not conflict with success/warning/error states. Specific hex values: (needs design system input)
• Iconography: (needs UX writer input — icon set to be confirmed from the platform design system). Icons must never appear without a visible label or programmatic accessible label. The AI attribution marker must have a consistent icon paired with its label throughout the Agent Console.
• Motion: The live transcript panel uses progressive reveal as new segments stream in — this is functional motion tied to real-time data, not decorative animation. All other motion must be minimal. State badge transitions (e.g. Verifying Identity → Verified) may use a brief, non-looping transition to draw attention to the change without being distracting. Motion can be reduced via prefers-reduced-motion; all streaming and transition animations must respect this preference.

8. Accessibility & Inclusivity

The module MUST meet WCAG 2.2 AA. Specifically:

• Text contrast ≥4.5:1 (normal) / ≥3:1 (large)
• All interactive controls reachable via keyboard
• Focus states visible
• Form fields have programmatic labels
• ARIA used only where native semantics are insufficient
• Touch targets ≥44×44 px on mobile/tablet
• Motion can be reduced via prefers-reduced-motion
• Screen reader tested on NVDA / VoiceOver / TalkBack

Module-specific accessibility requirements:

• The live transcript panel streams new content in real time. New transcript segments must be announced to screen readers without overwhelming the user — an ARIA live region with polite assertiveness is appropriate. Key-moment markers may warrant assertive announcement. The exact ARIA live region strategy requires review with an accessibility specialist.
• The verification state indicator and AI attribution markers must be conveyed to screen readers with meaningful text labels, not colour or icon alone.
• The one-click action bar must communicate to assistive technology which actions are absent due to verification state, so staff using screen readers understand why an expected action is not present. (needs accessibility specialist input — ARIA pattern for contextually absent actions)
• The technical spec (§14) requires that callers be able to request human staff at any point in the spoken dialogue. This is a spoken-interface accessibility requirement: the AI's voice interaction must use plain language and controlled vocabulary, and the option to speak to a human must be surfaced consistently and early in every call flow.

9. Internationalisation

• Locale-aware date/time/number formatting
• All user-facing strings externalised
• Layouts tolerant of 30% string-length growth (German, French)
• RTL support: not required at launch unless explicitly added to the platform roadmap
• Call timestamps and durations in the transcript panel and queue must use the tenant's configured locale and timezone, not UTC display, as these are operationally significant for staff reviewing calls.
• The approved policy wording library (§13.3 of the technical spec) is tenant-configured, not translated by the platform. Internationalisation of policy wording is the practice's responsibility.

10. Cross-Module UX Touchpoints

All integrations inferred from technical spec §6, §10, and §13.1.

• Communication Hub — The Agent Console lives inside Communication Hub. Call threads, transcripts, and task/form dispatch events are surfaced through Communication Hub's container. Staff transition from a Communication Hub conversation thread to an AI Concierge call thread without leaving the Communication Hub surface. The boundary between the two must be visually clear so staff know which module's data and actions they are acting on. (needs UX writer input — visual treatment of the module boundary within Communication Hub)
• Task Manager — Unresolved calls and exhausted recovery workflows create tasks in Task Manager. Staff see a linked-task indicator in the call thread detail; clicking it navigates to Task Manager. The handoff must carry call thread context (intent summary, call thread ID) so staff arriving in Task Manager have enough information to act without returning to the call record.
• Appointment Manager — Read-only appointment data (upcoming appointments, booking eligibility) surfaces in the screen-pop context card. The "Open booking UI" one-click action hands off to Appointment Manager's governed booking flow. Staff must not be asked to re-enter context that was already captured in the call thread. The handoff must pre-populate whatever Appointment Manager's booking flow accepts from the call context. Where AI Concierge has proposed or initiated a booking during a recovery call, the handoff to Appointment Manager must carry any constraint context (practitioner availability, absence, scheduling rules) that the AI used in its proposal, so that staff can verify the suggestion is valid before confirming it in the booking flow.
• Treatment Pipeline Manager — Lead and Opportunity data (BookingEligibility, Stack) surfaces in the context card. New lead creation during a call (§4.3) must be confirmed to staff in the Agent Console with a visible link to the created record in Treatment Pipeline Manager. Staff must not be left uncertain whether a lead was created. Any AI-generated triage summary or lead intake data that AI Concierge passes to Treatment Pipeline Manager must carry a visible AI attribution marker within the pipeline record, consistent with Treatment Pipeline Manager's governance model (which requires AI-supplied triage summaries — whether originating from AI Concierge or AI Assistant (Aiden) — to be visually distinguished and attributed). The Agent Console must make the provenance of lead data explicit at the point of creation: staff should be able to see which data fields were AI-generated and which were drawn from verified caller input, before the record is committed to the pipeline.
• Campaign Manager — There is no direct staff-visible UX touchpoint with Campaign Manager from the Agent Console. Suppression signals are system-level events. Staff do not need to manage suppression manually; however, the call thread detail should surface the suppression status of a contact (active / lifted) for compliance review purposes, not as an actionable control.
• Access Manager — RBAC enforcement is invisible to staff when permissions are met. When a one-click action is absent due to the user's role, the UI must not show a locked/disabled version of the action — it must simply not appear. Staff who need to understand why an action is unavailable can consult their role permissions via Access Manager. (needs UX writer input — guidance text or help link to Access Manager role information)
• Audit & Compliance — Staff with export permissions can export transcripts and audit logs. The export action appears in the call thread detail. The exported artefact format and delivery mechanism should be confirmed with the Audit & Compliance module's own UX specification.

UX consistency rules:

• One-click action buttons must appear in a consistent position across all call detail views — defined as a fixed action bar, not contextually repositioned based on content.
• AI attribution markers must appear in every surface where AI-generated content is displayed, including content that flows from the Agent Console into Communication Hub threads and Task Manager tasks.
• Verification state must be visible wherever patient-specific data from a call is displayed — including in Task Manager tasks and Communication Hub threads that carry call context.

11. Governance & Auditability

All governance requirements inferred from technical spec §8, §7, and §3.

• AI-generated content (intent summaries, operator guidance scripts, suggested follow-up actions, transcript responses) is visually distinct from staff actions throughout the Agent Console. AI content carries a persistent AI attribution marker. Staff actions carry the staff actor's name and timestamp. (needs UX writer input — AI badge label and staff actor display format)
• Every one-click Agent Console action that is audit-significant (takeover, transfer, task creation, form/payment dispatch) requires an explicit confirmation step before execution. The confirmation modal must state the action, the target (call thread ID, contact name where verified), and the actor. This mirrors the audit log entry that will be created. (needs UX writer input — confirmation modal copy)
• The current user's role is visible in the application header (via Access Manager / Communication Hub's host surface). Active permissions are reflected by the presence or absence of action controls, not by explicit permission lists in the call UI.
• Read-only states are visually distinct from editable states. The transcript panel is persistently read-only with no edit affordances. The staff annotations field is explicitly labelled as append-only. Configuration settings are visually read-only for roles without configuration access — not merely uneditable form fields, but a distinct read-only summary layout.
• The identity verification state is visible at all times in the context card while a call is active. It does not collapse or hide behind progressive disclosure during a live call — it is always-on for live calls because it governs what staff can see and do.
• The audit trail for a completed call thread is accessible from the call thread detail view for users with appropriate permissions. It must be presented as an ordered, time-stamped event log with actor labels (AI / staff member name / system). Immutability must be surfaced — no editing affordances, explicit "immutable record" label. (needs UX writer input — immutable record label)
• The AI Concierge must never visually imply that the AI is human. Any UI element that represents the AI as a participant in a call (e.g. in the transcript speaker labels) must use a consistent non-human label. (needs UX writer input — AI speaker label in transcript)

12. Notification & Communication Patterns

All notification patterns inferred from technical spec §8, §4.5, §4.2, and §6.3.

• In-app banner — Used for offline state (persistent banner: "You are offline — live data unavailable") and for configuration changes that affect active workflows (e.g. "This change will affect currently active recovery calls"). Banners are dismissible only when the condition they describe has resolved.
• Toast — Used for confirmations of successfully completed one-click actions: task created, form sent, payment link sent, handover confirmed. Toasts are brief and non-blocking, consistent with calm-by-default. They do not require acknowledgement. (needs UX writer input — toast copy for each action type)
• Elevated queue prominence — Calls in Handover Requested state are visually elevated within the live call queue (not a separate notification channel — an in-surface prominence change). This is the primary mechanism for drawing staff attention to calls that need human action. It must not rely on colour alone.*
• Push notification (via Communication Hub) — If a call enters Handover Requested state while a staff member is away from the Agent Console, a push notification may be appropriate to alert them. This notification must be delivered via Communication Hub — not directly from AI Concierge. The specific trigger conditions and audience for push notifications require a product decision. (needs product decision — push notification trigger conditions and staff audience)
• Email / SMS (via Communication Hub) — Outbound confirmation messages to patients (e.g. appointment confirmation links, form links) are dispatched via Communication Hub. Staff do not author these directly — they trigger them via one-click actions in the Agent Console. AI Concierge does not send email or SMS directly.*
• Task Manager notifications — When AI Concierge creates a follow-up task (unresolved call or exhausted recovery), Task Manager is responsible for notifying the appropriate staff member per Task Manager's own notification rules. AI Concierge emits the task creation event; it does not own the downstream notification.

13. Open Questions

The following questions must be resolved before this UX spec is promoted from draft to published. Several are carried forward from or extend the technical spec's own open questions (§15).

1. Tablet surface scope — The technical spec (§5.2) explicitly defers tablet surface definition. A product decision is required on which (if any) Agent Console capabilities are available on tablet, and for which staff roles, before a tablet UX can be specified.
2. Short-notice recovery window default — Carried from technical spec open question 1. Until the default is defined, the configuration UI cannot surface a sensible pre-filled value. (product / clinical decision required)
3. Transcript retention display — Carried from technical spec open question 2. The call thread detail view needs to display the retention expiry date for compliance purposes, but this cannot be designed until the platform-mandated retention bounds are defined.
4. Telephony failover user-facing behaviour — Carried from technical spec open question 3. If the AI cannot answer and calls are routed to staff queues or voicemail, the queue view must reflect this state. The exact routing decision determines the UX treatment.
5. Whitelisted patient record fields — Carried from technical spec open question 4. The screen-pop context card cannot be fully designed until it is known which fields may be displayed post-verification. A safe default (no fields shown until explicitly whitelisted) is the assumed UX stance, but this needs product confirmation.
6. Transcript recording during staff takeover — default — Carried from technical spec open question 5. The configuration toggle exists, but the default-on vs. default-off decision has compliance implications that affect how the toggle is labelled and whether it carries a compliance warning. (needs legal / compliance input)
7. Push notification triggers for Handover Requested — Product decision needed on whether staff away from the console receive push notifications for Handover Requested calls, and if so, which roles and under what conditions. See §12 above.
8. AI speaker label in transcript — The transcript must label AI speech consistently and in a way that makes clear to staff that the speaker is an AI system, not a human colleague. (needs UX writer input — label and visual treatment)
9. One-click action bar position and overflow behaviour — When a user's role permits many actions simultaneously, the action bar layout and overflow behaviour (e.g. a "more actions" overflow menu) need to be defined. The design must ensure that the most time-critical action (takeover) is always immediately visible and not hidden in overflow.
10. Suppression status display in call thread detail — A product and compliance decision is needed on whether suppression status (active / lifted) should be surfaced in the call thread detail view for compliance review, and if so, for which roles. This is noted as a recommendation in §10 above but is not yet confirmed.
11. Audit log export format — The Audit & Compliance module's UX specification should define the export format and delivery mechanism; AI Concierge's export action must align with that. This is a cross-module consistency decision.
12. MFA for sensitive operations — Carried from technical spec open question 6. Until Access Manager formally declares which operations require MFA, the Agent Console cannot surface appropriate pre-action prompts. The UX impact is that transcript export and configuration changes may require an additional authentication step that needs designing.
13. AI attribution label differentiation (Concierge vs. Aiden) — Where both AI Concierge and AI Assistant (Aiden) may contribute AI-generated content that flows into shared surfaces (Task Manager tasks, Communication Hub threads), the visual treatment of attribution markers must distinguish the source module whilst remaining consistent in style. The specific label conventions and visual differentiation require agreement between the AI Concierge and Aiden UX workstreams. (needs UX writer input — cross-module attribution label convention)
14. Constraint-context display in recovery booking handoff — Where a recovery call leads to a booking proposal, the format and placement of practitioner availability and scheduling constraint context within the Agent Console handoff summary or Appointment Manager handoff requires design definition, in alignment with Appointment Manager's constraint-visibility model. (needs UX writer input and cross-module design review)