Qontak | CRM | Workspace Homepage — Phase 1: SDR Workspace

PRD Type: PHASE — Phase 1 of the Reimagine CRM Workspace initiative

HEADER BLOCK

Field	Value
PM	PM Qontak Group
PRD Version	1.0
Status	DRAFT
PRD Type	PHASE
Epic	QON-16894
Squad	Qontak CRM Squad
RFC Link	N/A — no RFC required
Figma Master	Workspace Prototype
Anchor	Dashboard Workspace ANCHOR PRD
Labels	`epic:[Reimagine CRM Workspace 1st delivery]` \| `module:[workspace]` \| `feature:[qontak]`
Last Updated	2026-07-01

HEADER BLOCK
CONDITIONAL BLOCK: PHASE CONTEXT
1. One-liner + Problem
2. What Happens If We Don't Ship This Phase
3. Target Users + Persona Context
4. Non-Goals
5. Constraints
6. New Features
7. API & Webhook Behavior
8. System Flow + User Stories + ACs
9. Rollout
10. Observability
11. Success Metrics
12. Launch Plan & Stage Gates
13. Dependencies
14. Key Decisions + Alternatives Rejected
15. Open Questions
PRD CHANGELOG

CONDITIONAL BLOCK: PHASE CONTEXT

Field	Detail
Anchor PRD	Dashboard Workspace ANCHOR PRD
Phase Number	Phase 1 of 3
Phase Goal	Deliver the Workspace platform and SDR Workspace (Today's Priorities, Today's Progress, Quick Actions) as the default post-login landing page for SDR users, enabling role-based priority surfacing and activity tracking without multi-module navigation.
Prior phases	N/A — this is Phase 1, no prior phases.
This phase	Workspace platform foundation (Section framework, Widget rendering framework, Role visibility model, Data integration layer, AI capability framework, Widget personalization) + SDR Workspace committed widget set (Today's Priorities, Today's Progress, Quick Actions).
Deferred to next	Phase 2 (August): BD Workspace onboarded onto the same platform. Phase 3 (September): AM Workspace onboarded. Knowledge Base widgets: timeline TBD (outside Q3 scope).
Cross-phase deps	Widget framework architecture (Section framework, role visibility model, Widget Data Service API contracts) established in this phase MUST remain stable and extensible for Phase 2/3 BD and AM onboarding — no breaking changes to core platform contracts.

1. One-liner + Problem

One-liner: Enable SDR users to identify and act on the highest-priority work items of the day from a single, role-personalized Workspace homepage within Qontak, without switching modules.

Problem: SDR users currently spend 10–15 minutes each morning manually navigating 4–5 separate modules (Inbox, Deals, Activities, Tasks, Contacts) to understand what requires attention, with no built-in prioritization signal and no shared surface for daily execution. High-priority leads can sit uncontacted for hours because no single view aggregates "interested lead waiting response" or "conversation idle" signals, increasing time-to-action and suppressing CRM adoption.

For full initiative context, see the Dashboard Workspace ANCHOR PRD.

2. What Happens If We Don't Ship This Phase

SDR users continue the 10–15 min daily context-switching routine across modules with no improvement through Q3 — compounding user frustration and slowing CRM habit formation during the critical post-onboarding window.
High-priority leads remain uncontacted for hours due to the absence of any aggregated priority signal, directly reducing pipeline velocity.
BD Workspace (Phase 2, August) and AM Workspace (Phase 3, September) cannot be onboarded without the platform foundation this phase delivers — a slip on Phase 1 delays the entire Q3 roadmap.
The "Make the Intelligence Promise Real" OKR (Theme 1) loses its primary Q3 vehicle.

3. Target Users + Persona Context

Persona	Role	Goal	Pain	Workaround
Primary — SDR Staff	Sales Development Representative (Individual Contributor) responsible for daily pipeline execution: responding to interested leads, following up on idle conversations, and completing scheduled activities.	Start the workday knowing exactly which leads and conversations need immediate action, and process them consecutively without navigating away.	Opens Inbox, Contact list, Task list, and Activities separately each morning — 10–15 min of navigation with no built-in prioritization. High-priority leads sit uncontacted for hours.	Manually reviews each module; builds personal mental model of today's priorities. No system support.
Primary — SDR Lead	Sales Development Representative (Team Lead) responsible for both personal execution and monitoring team health and performance.	Execute daily tasks while maintaining visibility into team pipeline, activities, and performance without switching to separate reporting tools.	No unified view combining personal execution priorities and team-level health signals — must switch between modules and pull reports manually.	Same module-switching as SDR Staff, plus manual report pulls for team status. Reactive rather than proactive.
Out of scope (Phase 1)	BD (Business Development): Phase 2, August. AM (Account Manager): Phase 3, September.	—	—	—

Full persona background: see Dashboard Workspace ANCHOR PRD. See Constraints section for feature flag scope and plan availability.

4. Non-Goals

Scoped to Phase 1 only. Items marked "Phase N" are deferred to the specified phase, not ruled out.

Mobile / native app Workspace — Phase 1 is web only. Mobile support deferred.
BD persona widget set — Deferred to Phase 2 (August). BD users are onboarded onto the same platform after Phase 1 validation.
AM persona widget set — Deferred to Phase 3 (September).
Knowledge Base widgets — Timeline TBD; outside Q3 scope.
Drag-and-drop widget reordering — Phase 1 uses a predefined fixed layout. User-initiated reordering deferred to Phase 2 based on user feedback.
Tenant-admin Workspace configuration — No admin UI to configure widget sets per tenant. Widget sets remain Product-defined in Phase 1. Tenant-admin capability may be explored in future phases.
Inline / modal Quick Actions — Quick Actions in Phase 1 are navigation shortcuts only. Inline form or modal flows within the Workspace frame are out of scope.
Real-time data via WebSocket — Qontak CRM does not have WebSocket support. Data freshness is handled via scheduled auto-refresh per section TTL (see Constraints).
Per-widget scalability optimization — Intentionally deferred. Phase 1 validates widget value; optimization follows.
Zoho → Qontak migration data mapping — Deferred to Phase 3 (AM persona).

5. Constraints

Field	Value
Platform	Web only. No mobile or native app support in Phase 1.
Performance	Skeleton renders ≤ 1s from page load. Widget data p95 ≤ 2s. Workspace fully interactive p95 ≤ 3s.
Refresh cadence	Today's Priorities (Action widgets): ≤ 1 min auto-refresh. Today's Progress (Progress widgets): ≤ 5 min auto-refresh. Quick Actions: static (no data fetch). Insight (SDR Lead): refresh cadence TBD per widget data source.
Data refresh mechanism	Open for Engineering to propose. FE auto-polling preferred; refresh button per-section acceptable as last resort. Final approach confirmed during implementation.
Widget isolation	Widgets must fail independently — one widget error cannot block or crash other widgets on the page.
Widget personalization	Persisted per user account (cross-session, cross-browser). Not per-device session.
Feature flag	`workspace_homepage_enabled` — per CID, default OFF. Enabled per CID during Internal Alpha.
Role visibility	Determined by Team × Staff Level (SDR / BD / AM × Staff / Lead). Resolved server-side from user profile at page load. Mid-session permission sync is out of scope — changes reflect on next page load.
State restore	Workspace must restore user's previous scroll, expanded section, and filter state on same-session return from another module. Cross-session state restore is out of scope (handled by personalization).
Extensibility	Widget framework (Section framework, Widget registry, role visibility model, Widget Data Service API contracts) must be extensible for Phase 2/3 BD and AM onboarding without re-engineering the platform core.
Nice to have	Embed enrich page data (Phase 1, if capacity allows).

6. New Features

6.1 Workspace Homepage — Page

Field	Detail
URL	`/workspace` (or embedded iframe path — final URL TBD with Engineering)
Access	Any CRM user whose CID has `workspace_homepage_enabled = ON` AND has a valid Team assignment. Default post-login landing page when flag is ON.

Component Tree:

Component	Parent	Purpose
WorkspacePage	—	Top-level page container; handles routing, feature flag check, role resolution
WorkspaceHeader	WorkspacePage	Page header: user greeting, date, global refresh indicator
SectionContainer	WorkspacePage	Reusable section wrapper; accepts widget registry response per section type
TodaysPrioritiesSection	SectionContainer	Today's Priorities section: renders Action widget set for SDR role
TodaysProgressSection	SectionContainer	Today's Progress section: renders Progress widget set for SDR role
QuickActionsSection	SectionContainer	Quick Actions section: renders static navigation shortcuts
InsightSection	SectionContainer	Insight section: rendered for SDR Lead only; renders Team-level Insight widgets
WidgetCard	SectionContainer	Reusable widget wrapper: skeleton, data, error, empty states; independent load/fail
WidgetErrorState	WidgetCard	Per-widget error + Retry CTA; isolated — does not affect sibling widgets
EmptyStateCard	WidgetCard	Per-widget empty state with contextual copy
PersonalizationControl	WidgetCard	Per-widget hide/show toggle; triggers preference persistence

UI States:

Component	State	Description
WorkspacePage	Loading	All section skeletons render within ≤ 1s; page chrome (header, nav) renders immediately.
WorkspacePage	Empty (No Team)	No widgets rendered. Message: "Your Workspace hasn't been configured yet. Please contact your administrator to assign your Team and Staff Level."
WorkspacePage	Error	Widget-level only — no page-level error. Each widget handles its own error state independently.
WorkspacePage	Success	All applicable sections rendered and interactive within p95 ≤ 3s.
WidgetCard	Loading	Skeleton loader per widget, renders within ≤ 1s.
WidgetCard	Empty	Contextual empty message per widget (e.g., "You're all caught up!" for Today's Priorities).
WidgetCard	Error	"Unable to load data. Please try again." + Retry CTA. Sibling widgets unaffected.
WidgetCard	Success	Widget data rendered within p95 ≤ 2s.

Prototype: Workspace Homepage

📊 UI State Diagram — WorkspacePage

stateDiagram-v2
    [*] --> Loading: User completes login (flag ON)
    Loading --> NoTeam: Role resolution — no Team assigned
    Loading --> Success: Role resolved; all widgets load
    Loading --> PartialLoad: ≥1 widget error (others succeed)
    NoTeam --> [*]: User contacts admin; re-login triggers re-resolution
    Success --> StateRestored: User navigates away and returns (same session)
    StateRestored --> Success: Background refresh completes
    PartialLoad --> Success: User retries failed widget; load succeeds
    PartialLoad --> PartialLoad: Retry fails; error state persists per widget

6.2 Today's Priorities Section

Purpose: Surfaces the highest-priority action items for the SDR's day, aggregated across data sources (Interested Lead Waiting Response, Conversation Idle, Scheduled Activities).

Priority Item Card — Required fields (all must be present on each card):

Field	Description
Company / Lead Name	The lead or company associated with the priority item
Priority Title	The widget category title (e.g., "Interested Lead Waiting Response")
Reason for appearing	Why this item surfaces (e.g., "Interested — waiting for response") — exact enum TBD with Engineering
Time indicator	How long the item has been in this state (e.g., "Last replied 3 hours ago")

Priority Item Card — Optional fields (shown when data is available):

Field	Description
Last message preview	Snippet of the most recent message in the conversation
Lead source	Broadcast / Manual Chat / API / etc.
Conversation owner	The assigned agent
Deal stage	Current deal stage if associated
Assigned campaign	Campaign name if applicable

Phase 1 committed widgets (Today's Priorities):

1.1 Interested Lead Waiting Response
1.2 Conversation Idle
1.3 Scheduled Activities

stateDiagram-v2
    [*] --> Loading: Workspace loads; section renders
    Loading --> Success: Widget Data Service returns ≥1 priority item
    Loading --> Empty: Widget Data Service returns 0 items
    Loading --> Error: Widget Data Service request fails or times out
    Success --> Refreshing: Auto-refresh interval triggers (≤1 min)
    Refreshing --> Success: Refresh returns updated data
    Refreshing --> Error: Refresh request fails
    Empty --> Refreshing: Auto-refresh interval triggers
    Error --> Loading: User clicks Retry
    Success --> ItemRemoved: SDR acts on item; item resolved/completed
    ItemRemoved --> Empty: Last item removed
    ItemRemoved --> Success: Remaining items still present

6.3 Today's Progress Section

Purpose: Shows the SDR's daily activity progress, automatically aggregated from existing CRM activity data. No manual trigger required.

Phase 1 committed widgets (Today's Progress):

Widget	Data Source	Description
Conversations Handled	CRM conversation activity log	Count of conversations the SDR has responded to today
Opportunities Advanced	CRM deal activity log	Count of deals moved forward today
Activities Completed	CRM activity log	Count of tasks/activities marked complete today
Work Summary	CRM activity aggregate	Daily roll-up of completed actions (Uploaded Leads, Broadcasts Sent, etc.) with links to relevant activity log

Auto-aggregation note: All Today's Progress widgets pull from existing CRM activity data — no new data storage introduced. Metric boundaries (exact definition of "Conversations Handled", data ownership per metric) must be finalized with Corporate Strategy Team / Data Analytics before Widget Data Service API schema is locked (see Dependencies).

6.4 Quick Actions Section

Purpose: Provides SDR with one-click navigation shortcuts to common CRM module entry points. Static section — no data fetch, no auto-refresh.

Phase 1 committed widgets (Quick Actions):

Action	Destination	Behavior
Upload Leads	Upload Leads page in CRM module	Full navigation to target page (not inline/modal)
Create Broadcast	Create Broadcast flow	Full navigation to target page
Create Task	Create Task flow	Full navigation to target page

6.5 Insight Section (SDR Lead only)

Purpose: Team-level visibility widgets surfaced exclusively for SDR Lead (Staff Level = Lead). Allows SDR Lead to monitor team pipeline, activities, and performance alongside personal execution widgets.

Phase 1 committed widgets (Insight — SDR Lead):

Widget	Description
Team Pipeline	Team-level pipeline status and deal health overview
Team Activities	Aggregate view of team activity completion and schedule
Team Performance	Team performance summary against daily/weekly targets

Note: Specific widget content, data sources, and exact metric definitions for Insight widgets are Product-defined and will be specified as incremental Content Items through ongoing Phase 1 discovery. These do not require platform re-engineering.

7. API & Webhook Behavior

#	Behavior	Entity Affected	Triggered By	Expected Behavior	Failure Behavior
1	Widget set resolution	User profile + Widget registry	User login with `workspace_homepage_enabled = ON`	System reads Team × Staff Level from user profile → queries widget registry → returns applicable Section + Widget set for role. Response scopes: SDR Staff (Priorities, Progress, Quick Actions); SDR Lead (+ Insight).	If registry unavailable: Workspace loads with empty state and config message. No widgets shown until role resolved.
2	Widget Data Service fetch	Widget data per section	Workspace page load; auto-refresh interval	Each widget queries Widget Data Service independently with TTL per section type. Returns data or error per widget — no batch blocking.	Per-widget: error state with Retry CTA. Other widgets unaffected. If all fail: each shows error independently; page-level fallback not triggered.
3	Widget Data Service auto-refresh	Today's Priorities section widgets	≤ 1 min interval (Action widgets)	Background re-fetch for Today's Priorities. State restore: previous data shown until fresh data arrives; no blank/zero transitional state. Completed/resolved items removed smoothly on refresh.	Refresh failure: previous data remains; per-widget error + Retry shown. No full page reload triggered.
4	Widget Data Service auto-refresh	Today's Progress section widgets	≤ 5 min interval (Progress widgets)	Background re-fetch for Today's Progress only. Metrics update in place.	Same as behavior #3 failure mode.
5	Widget personalization save	User personalization record	SDR clicks hide/show on a widget	Preference (widget ID + hidden=true/false) saved per user account. Applied on next Workspace render (and persisted cross-session). Optimistic UI: widget hidden immediately; reverted on save failure.	Save failure: optimistic UI reverted; widget reappears; inline error: "Couldn't save your preference. Please try again."
6	Workspace state restore	In-session UI state (scroll, expanded sections)	User navigates back to Workspace within same session	System restores previous scroll position, expanded section states, and filters. Background refresh begins immediately on return. Session state is not persisted cross-session.	Session expired: redirect to login. No stale state shown.

Engineering to confirm: HTTP method, path, request/response schema, error codes, caching strategy, and TTL feasibility per widget data source during RFC/technical design.

8. System Flow + User Stories + ACs

8.1 System Flow

Flow: SDR Daily Workspace Session · Type: User Journey

sequenceDiagram
    participant SDR as SDR User
    participant CRM as CRM Frontend
    participant Auth as Auth Service
    participant WS as Workspace Service
    participant Registry as Widget Registry
    participant WDS as Widget Data Service
    participant CDP as Qontak CDP

    SDR->>Auth: Login
    Auth->>CRM: Login success → check workspace_homepage_enabled (per CID)
    alt Flag = ON
        CRM->>WS: Route to /workspace
        WS->>Registry: Resolve widget set (Team=SDR, StaffLevel=Staff|Lead)
        Registry-->>WS: Widget set: [Priorities, Progress, Quick Actions] (+Insight if Lead)
        WS->>CRM: Render Workspace page with section skeleton (≤1s)
        par Independent widget fetches
            WS->>WDS: Fetch Today's Priorities data
            WDS->>CDP: Query interested leads, idle conversations, scheduled activities
            CDP-->>WDS: Priority items
            WDS-->>WS: Widget data → render priority cards
        and
            WS->>WDS: Fetch Today's Progress data
            WDS-->>WS: Activity aggregates → render progress counters
        end
        SDR->>CRM: Views Today's Priorities → clicks priority item card
        CRM-->>SDR: Navigate to conversation/contact detail page
        SDR->>CRM: Takes action (replies, logs call) → navigates back to Workspace
        CRM->>WS: Restore previous scroll + expanded state
        WS->>WDS: Background refresh (Today's Priorities ≤1 min elapsed)
        WDS-->>WS: Updated priority list → smooth removal of completed item
    else Flag = OFF
        CRM-->>SDR: Redirect to existing default CRM landing page
    end

    alt Widget Data Service error (any widget)
        WDS-->>WS: Error response
        WS-->>CRM: Per-widget error state + Retry CTA
        Note over CRM: Other widgets continue loading normally
    end

    alt No Team assigned
        Registry-->>WS: No widget set for user
        WS-->>CRM: Empty state — "Your Workspace hasn't been configured yet..."
    end

8.2 User Stories

User Story	Importance	Mockup / Technical Notes	Acceptance Criteria
WS-S01 — Workspace as Default Post-Login Landing As an SDR (Staff or Lead) with Workspace enabled for my org, I want to land on the Workspace homepage after login, so that I can immediately see my daily priorities without navigating separate modules.	Must Have	Prototype: Workspace Prototype Data Fields: • `workspace_homepage_enabled` (boolean) — CID-level feature flag • `team` (enum: SDR/BD/AM) — from user profile • `staff_level` (enum: Staff/Lead) — from user profile	Happy Path • AC-1: Given a user whose CID has `workspace_homepage_enabled = ON` and whose profile has Team = SDR and Staff Level = Staff, when the user completes login, then the system redirects to the Workspace homepage and renders Today's Priorities, Today's Progress, and Quick Actions sections with skeleton loading states within ≤ 1s. • AC-2: Given the sections are rendered in skeleton, when Widget Data Service responses arrive independently per widget, then each widget renders its data and the Workspace is fully interactive within p95 ≤ 3s. Error • ERR-1: Given a user whose CID has `workspace_homepage_enabled = OFF`, when the user completes login, then the system redirects to the existing default CRM landing page — Workspace is not shown. • ERR-2: Given a user whose CID has `workspace_homepage_enabled = ON` but whose profile has no assigned Team, when the Workspace loads, then the system displays an empty state: "Your Workspace hasn't been configured yet. Please contact your administrator to assign your Team and Staff Level." No widgets are rendered. Permission Model • CAN: Any user with flag = ON AND a valid Team assignment can access the Workspace. • CANNOT: Users with flag = OFF cannot access the Workspace regardless of Team assignment. • CANNOT: Users with no Team assignment see no widget content even when the flag is ON. UI States • Loading: All sections render skeleton loaders within ≤ 1s of login redirect. • Empty: No Team assigned → empty config message shown; no widgets rendered. • Error: No page-level error state — widget-level errors handled by WS-S02. • Success: All role-appropriate sections rendered and interactive within p95 ≤ 3s.
🧪 WS-S01 — Test Coverage	—	—	Boundary values ⚠️ TBD — QA: test user with flag = ON but no Team; flag = OFF with valid Team; flag = ON + Team = SDR with Staff Level = Lead (Insight section). State transitions ✅ defined — ERR-2 covers no-Team empty state; AC-1 covers flag ON → routing; ERR-1 covers flag OFF → legacy redirect. Data validation ⚠️ TBD — QA: test malformed user profile (Team set but Staff Level missing); registry returns empty widget set. Concurrency ⚠️ TBD — QA: two users from same CID log in simultaneously — verify per-CID flag resolution is consistent. Network/timeout ⚠️ partial — ERR-2 covers no-Team; registry unavailability covered by WS-S02 failure isolation.
WS-S02 — Widget Independent Load, Failure Isolation & Auto-Refresh As an SDR using the Workspace, I want each widget to load and refresh independently, so that a slow or failed widget doesn't block the rest of my view.	Must Have	Refresh cadence: • Action widgets (Today's Priorities): ≤ 1 min auto-refresh • Progress widgets (Today's Progress): ≤ 5 min auto-refresh • Quick Actions: static — no data fetch Performance SLA: Skeleton ≤ 1s; data p95 ≤ 2s; fully interactive p95 ≤ 3s. Technical Note: Refresh mechanism open for Engineering to propose. Auto-polling preferred; refresh button per-section acceptable as last resort.	Happy Path • AC-1: Given the Workspace is loading Today's Priorities, when Widget Data Service returns data for Widget A before Widget B, then Widget A renders immediately without waiting for Widget B — each widget resolves independently. • AC-2: Given Today's Priorities widgets have been rendered, when the ≤ 1 min auto-refresh interval triggers, then only Today's Priorities section re-fetches and updates in place — no full page reload, other sections unaffected. • AC-3: Given Today's Progress widgets are rendered, when the ≤ 5 min auto-refresh triggers, then only Today's Progress section re-fetches. Quick Actions section is not re-fetched (static). Error • ERR-1: Given a widget's data source returns an error or times out, when the widget attempts to load, then the affected widget displays: "Unable to load data. Please try again." with a Retry CTA. All other widgets on the page continue loading normally — zero impact on sibling widgets. • ERR-2: Given an SDR clicks Retry on a failed widget, when the retry request succeeds, then the widget replaces the error state with its data. When the retry fails again, the error state persists with the Retry CTA still visible. Permission Model • CAN: Any widget can independently retry its data load without affecting other widgets. • CANNOT: A single widget failure cannot block, error-out, or trigger a reload of any other widget on the page. UI States • Loading: Each widget renders a skeleton loader within ≤ 1s independently. • Empty: 0 data items for a widget → per-widget empty state. • Error: Inline error state + Retry CTA per widget; section layout and surrounding widgets preserved. • Success: Widget data rendered within p95 ≤ 2s; Workspace fully interactive within p95 ≤ 3s.
🧪 WS-S02 — Test Coverage	—	—	Boundary values ⚠️ TBD — QA: test exactly at 1 min refresh boundary for Action widgets; test 5 min boundary for Progress widgets. State transitions ✅ defined — AC-1–3 cover independent load; ERR-1–2 cover failure → retry → success/persist. Data validation ⚠️ TBD — QA: test widget receiving malformed/unexpected data shape from Widget Data Service. Concurrency ⚠️ TBD — QA: auto-refresh fires while SDR is mid-interaction with an expanded priority card — verify no UI disruption. Network/timeout ✅ defined — ERR-1 covers timeout; ERR-2 covers retry success and retry failure.
WS-S03 — Today's Priorities: Priority Item Card Preview & Action As an SDR, I want to see key context about each priority item directly on the Workspace, so that I can decide which items need attention without opening each conversation.	Must Have	Prototype: Workspace Prototype Required fields per card: `company_lead_name`, `priority_title`, `reason` (enum TBD), `time_indicator` Optional fields: `last_message_preview`, `lead_source`, `conversation_owner`, `deal_stage`, `assigned_campaign`	Happy Path • AC-1: Given Today's Priorities is loaded and the Interested Lead Waiting Response widget has ≥ 1 item, when the SDR views the widget, then each item card displays: Company/Lead Name, Priority Title, Reason for appearing, and Time indicator. Optional fields are shown only when data is available. • AC-2: Given the SDR is viewing a priority item card, when the SDR clicks on the card or its CTA, then the system navigates to the relevant conversation or contact detail page. • AC-3: Given Today's Priorities loads and the Interested Lead Waiting Response widget has 0 items, when the widget renders, then an empty state is shown: "You're all caught up! No interested leads waiting for a response." — the text "0 Priorities" is never shown as an empty or transitional state. Error • ERR-1: Given a priority item is displayed on the Workspace, when the SDR clicks on it but the underlying lead or conversation no longer exists (resolved, deleted, or reassigned), then the system shows an inline message "This item is no longer available" and smoothly removes the item from the list without reloading other items or the section. Permission Model • CAN: SDR can view priority items assigned to them or to their Team per Team assignment from user profile. • CANNOT: SDR cannot see priority items belonging to a different Team's widget set. • CANNOT: SDR cannot modify priority item content from the Workspace card — cards are read-only with navigate-to-action only. UI States • Loading: Today's Priorities section renders skeleton cards while Widget Data Service responds (≤ 1s). • Empty: 0 priority items → "You're all caught up! No interested leads waiting for a response." shown inside the widget area. • Error: Widget data fetch fails → individual widget error state with Retry CTA (WS-S02); other widgets unaffected. • Success: All required card fields rendered per item; optional fields shown only when data is available.
🧪 WS-S03 — Test Coverage	—	—	Boundary values ⚠️ TBD — QA: test card with all optional fields present vs. none present; test priority item with very long lead name or reason string. State transitions ✅ defined — AC-3 covers 0-item empty state; ERR-1 covers item-no-longer-exists removal. Data validation ⚠️ TBD — QA: reason enum — test unrecognized reason value from Widget Data Service (should gracefully degrade or show default copy). Concurrency ⚠️ TBD — QA: two agents simultaneously acting on the same priority lead — verify item removal is consistent for both. Network/timeout ⚠️ partial — Widget load failure handled by WS-S02. ERR-1 covers item-level navigation failure.
WS-S04 — Workspace State Restore on Return As an SDR processing multiple priority items consecutively, I want the Workspace to restore my previous scroll and expanded state when I return from taking action in another module, so that I can continue without losing my place.	Must Have	Never display: Stale "0 Priorities" or empty Today's Progress as a transitional state before fresh data loads — previous data remains visible until fresh data is ready. Technical Note: State persistence mechanism open for Engineering to propose. Must survive same-session navigation only — cross-session persistence handled by WS-S05. ⚠️ Engineering to confirm what constitutes "return to Workspace" vs. fresh navigation (browser back button vs. sidebar nav link click).	Happy Path • AC-1: Given an SDR has the Workspace open with Today's Priorities expanded showing 5 priority items, when the SDR clicks a priority item card → navigates to the conversation page → takes action → navigates back to the Workspace, then the Workspace immediately restores: the previous scroll position, the expanded state of Today's Priorities, and the previously visible priority items (using last-fetched data until refresh completes). • AC-2: Given the Workspace has restored previous state on return, when the background refresh completes for Today's Priorities, then the widget updates in place — completed or resolved items are removed smoothly, with no blank, zero, or flash transitional state shown at any point. • AC-3: Given the SDR has returned to the Workspace and background refresh is in progress, when the SDR views Today's Priorities, then the previous data remains fully visible with a subtle section-level loading indicator until fresh data arrives. Error • ERR-1: Given the SDR navigated away from the Workspace and their session has expired, when the SDR attempts to return to the Workspace URL, then the system redirects to the login page and does not attempt to restore stale Workspace state. Permission Model • CAN: State restore applies to any Workspace section the SDR had open during the current browser session. • CANNOT: State restore does not persist across login sessions — a fresh login always loads the Workspace from the default state with a fresh data fetch. UI States • Loading: Previous data displayed immediately on return; section-level loading indicator shown during background refresh. • Empty: N/A — previous data always displayed during restore; empty state shown only if fresh data confirms 0 items after refresh completes. • Error: Background refresh failure → previous data remains visible; per-widget error + Retry CTA shown (WS-S02). • Success: Background refresh completes; fresh data overlays previous state; completed items removed smoothly.
🧪 WS-S04 — Test Coverage	—	—	Boundary values ⚠️ TBD — QA: test restore after navigating away for exactly session timeout duration minus 1 second; test restore with 0 items remaining after all completed. State transitions ✅ defined — AC-1–3 cover restore → refresh → data overlay; ERR-1 covers expired session redirect. Data validation ⚠️ TBD — QA: test restore when all 5 previously visible items have been resolved (fresh data returns 0) — verify no stale items shown and empty state renders correctly. Concurrency ⚠️ TBD — QA: SDR has Workspace open in two tabs — tab A acts on an item; tab B restores state — verify tab B reflects fresh data without stale duplicate. Network/timeout ⚠️ partial — ERR-1 covers session expiry. Background refresh failure handled by WS-S02.
WS-S05 — Widget Personalization: Hide/Show As an SDR, I want to hide widgets I don't find useful, so that my Workspace shows only what's relevant to my workflow.	Should Have	Data Fields: • `widget_id` (string) — widget identifier • `hidden` (boolean) — per-user, per-widget preference • Stored per user account (cross-session, cross-browser). Reversibility: Any hidden widget can always be restored by the SDR at any time — no permanent widget deletion exists in the system.	Happy Path • AC-1: Given an SDR has at least one widget visible, when the SDR activates the hide option on a widget, then the widget is immediately removed from the visible layout and a brief undo/confirmation prompt is shown. • AC-2: Given an SDR has hidden a widget and logs out, when the SDR logs back in on any browser, then the previously hidden widget remains hidden — preference is persisted per user account. • AC-3: Given an SDR has one or more hidden widgets, when the SDR accesses personalization or restore settings, then all hidden widgets can be made visible again individually. Error • ERR-1: Given an SDR clicks the hide option on a widget, when the preference save request to the backend fails, then the widget reappears immediately (optimistic UI reverted) and an inline error message is shown: "Couldn't save your preference. Please try again." Permission Model • CAN: Each SDR can independently hide and show widgets for their own account. • CANNOT: One SDR's personalization preference cannot affect any other SDR's Workspace view. • CANNOT: Per-user widget preferences cannot override CID-level feature flag settings. • Reversibility: Any hidden widget can always be restored by the SDR — there is no permanent widget deletion at the system level. UI States • Loading: Personalization preferences fetched at Workspace load; widget visibility applied before render (no flash of hidden widgets). • Empty: All widgets hidden → "No widgets are currently displayed. Restore widgets from your settings." • Error: Preference save failure → optimistic UI revert + inline error notification. • Success: Widget hidden or restored immediately; preference persisted to backend.
WS-S06 — SDR Lead: Team Insight Widgets As an SDR Lead, I want to see Team-level Insight widgets (Team Pipeline, Team Activities, Team Performance) in addition to my individual execution widgets, so that I can monitor team health alongside my own daily work.	Must Have	Role resolution: System reads Staff Level = Lead → widget registry adds Insight section to response. SDR Staff receives no Insight section. Technical Note: Widget registry must differentiate Staff Level within the same Team (SDR Staff ≠ SDR Lead widget set). Specific Insight widget content and data sources defined as incremental Content Items through Phase 1 discovery.	Happy Path • AC-1: Given a user with Team = SDR and Staff Level = Lead, when the Workspace loads, then the system renders Today's Priorities, Today's Progress, and Quick Actions (same as SDR Staff) PLUS an Insight section containing Team Pipeline, Team Activities, and Team Performance widgets. • AC-2: Given a user with Team = SDR and Staff Level = Staff, when the Workspace loads, then the Insight section is NOT rendered — SDR Staff sees execution widgets only. Error • ERR-1: Given Staff Level = Lead and the Insight section's data source is unavailable, when the Workspace loads, then Insight widgets each display their individual error state with Retry CTA (WS-S02 failure isolation applies) — the SDR Lead still sees all execution widgets loading normally. Permission Model • CAN: SDR Lead sees both execution and Team-level Insight widgets. • CANNOT: SDR Staff cannot access the Team Insight section even if they share the same CID as an SDR Lead. • CANNOT: SDR Lead cannot see BD or AM Insight widgets — role resolution is Team-scoped. UI States • Loading: Insight section renders skeleton alongside other sections within ≤ 1s of page load. • Empty: No team data for a specific Insight widget → per-widget empty state (copy TBD per Insight widget during discovery). • Error: Each Insight widget failure is isolated — does not affect execution widgets. • Success: All sections rendered; Insight section populated with team-level data within p95 ≤ 3s.
WS-S07 — Quick Actions: Navigation Shortcuts As an SDR, I want Quick Actions on my Workspace to navigate me directly to the relevant CRM module, so that I can start common tasks without going through the main navigation.	Should Have	Scope: Navigation shortcuts only. No inline form, no modal, no CRM operation performed within the Workspace frame. Section type: Static — no data fetch, no auto-refresh. Renders on page load.	Happy Path • AC-1: Given an SDR is on the Workspace, when the SDR clicks the "Upload Leads" Quick Action, then the system navigates the SDR to the Upload Leads page in the CRM module. • AC-2: Given an SDR is on the Workspace, when the SDR clicks the "Create Broadcast" Quick Action, then the system navigates the SDR to the Create Broadcast flow. • AC-3: Given an SDR is on the Workspace, when the SDR clicks the "Create Task" Quick Action, then the system navigates the SDR to the Create Task flow. Error • ERR-1: Given the Quick Actions section encounters a widget framework rendering error, when the Workspace loads, then the Quick Actions section displays an error state with Retry CTA — failure is isolated and does not affect Today's Priorities, Today's Progress, or Insight sections. Permission Model • CAN: Any SDR with Workspace enabled can use all Quick Actions. • CANNOT: Quick Actions cannot perform any CRM operation inline within the Workspace — navigation to the target module is always required. UI States • Loading: N/A — static section, action buttons render immediately on page load with no data fetch. • Empty: N/A — always 3 defined action shortcuts; no data-dependent empty state. • Error: Widget framework rendering failure → section-level error state with Retry CTA; other sections unaffected. • Success: Three Quick Action shortcuts (Upload Leads, Create Broadcast, Create Task) visible and clickable.
WS-NEG-01 — No Workspace on Mobile / Native App (Guard Rail — Non-Goal #1: Mobile/native app, Phase 1 web only)	Guard Rail	—	• NEG-1: Given any CRM user accessing Qontak via a mobile or native app, when `workspace_homepage_enabled` is ON for their CID, then the Workspace is not surfaced on mobile — the user sees the existing default mobile experience unchanged.
WS-NEG-02 — No Drag-and-Drop Widget Reordering (Guard Rail — Non-Goal #5: Drag-and-drop deferred to Phase 2)	Guard Rail	—	• NEG-2: Given an SDR is on the Workspace homepage, when the user attempts to drag a widget card to a different position, then no drag interaction is triggered — widget positions remain fixed in the predefined layout order.

9. Rollout

Field	Detail
Feature flag	`workspace_homepage_enabled` (per CID, default OFF — see Section 5)
Rollout	Stage 1 → Internal Alpha: internal SDR users only (Qontak internal CIDs, flag enabled per CID manually). Stage 2 → Closed Beta: select external SDR pilot CIDs (scope TBD — PM + CSM to identify). Stage 3 → Open Beta: broader SDR-enabled CIDs pending Internal Alpha validation. GA → all eligible CIDs with SDR Team assignments.
Backward compat	Yes — existing CRM routing and default landing page unchanged for all CIDs with flag = OFF. No data model changes for non-Workspace users.
Migration	None required. Workspace is a new surface; no existing data or config is migrated. Widget personalization starts empty per user on first access.

10. Observability

Key Events:

Event Name	Trigger	Properties
`workspace_loaded`	Workspace page fully interactive	`user_id`, `cid`, `team`, `staff_level`, `load_time_ms`, `sections_rendered[]`
`section_rendered`	Each section finishes rendering	`section_id`, `widget_count`, `render_time_ms`, `has_error`
`content_item_clicked`	SDR clicks a priority item card or its CTA	`widget_id`, `section_id`, `item_type`, `lead_id`, `position_in_list`
`content_item_completed`	Priority item removed after SDR action (smooth removal)	`widget_id`, `item_id`, `completion_type`
`ai_action_clicked`	SDR clicks an AI-powered action	`widget_id`, `ai_action_type`, `lead_id`
`section_load_failed`	Widget Data Service returns error for a section	`section_id`, `widget_id`, `error_type`, `retry_count`
`widget_hidden`	SDR hides a widget	`user_id`, `widget_id`, `section_id`
`widget_shown`	SDR restores a hidden widget	`user_id`, `widget_id`, `section_id`
`quick_action_clicked`	SDR clicks a Quick Action	`action_id` (upload_leads / create_broadcast / create_task), `user_id`

Dashboard owner: Mixpanel — Product team (PM Qontak Group / Qontak CRM Squad)

Alerts:

section_load_failed rate > 2% of workspace_loaded events in any 15-min window → PagerDuty: Qontak CRM Squad on-call
Workspace p95 load time > 3s for > 5% of workspace_loaded events in any 30-min window → PagerDuty: Engineering Lead

10.1 Post-Launch Monitoring Cadence

Field	Detail
Review cadence	Weekly for the first 4 weeks post-Internal Alpha launch, then bi-weekly through GA.
Owner	PM Qontak Group (Qontak CRM Squad)
Review scope	DAR (Workspace Daily Active Ratio), module-switch reduction, widget CTR, widget error rate, section load time p95
Trigger thresholds	• DAR drops below 40% for 2 consecutive weeks → PM review within 48 hours; consider scope adjustment. • `section_load_failed` rate > 2% sustained for > 24 hours → Engineering escalation + rollback consideration. • Widget CTR < 20% after 2 weeks of Internal Alpha → PM review; reassess priority card content and design.
Rollback consideration	If widget error rate exceeds 5% and is unresolved within 24 hours, PM and Engineering Lead to assess partial rollback (disable affected widgets per CID via flag). Full Workspace rollback via `workspace_homepage_enabled = OFF` per CID.

11. Success Metrics

Adoption & Engagement:

Metric	Definition	Baseline	Target
⭐ Workspace Daily Active Ratio (DAR)	% of enabled SDR users who load the Workspace at least once per day	N/A — new feature	≥ 60% within 30 days of Internal Alpha launch
Widget CTR — Today's Priorities	% of `workspace_loaded` sessions with at least one `content_item_clicked` from Today's Priorities	N/A — new feature	≥ 40% within 30 days of Internal Alpha
Priority item expansion rate	% of Today's Priorities card clicks that result in navigation to the conversation/contact detail	N/A — new feature	≥ 30% within 30 days of Internal Alpha

Efficiency Impact:

Metric	Definition	Baseline	Target
Module-switch reduction	Average daily module-switch navigation actions per SDR vs. pre-Workspace baseline	Pre-Workspace baseline TBD (measure during Internal Alpha prep)	≥ 20% reduction vs. baseline within 30 days of GA

Quality & Reliability:

Metric	Definition	Baseline	Target
Widget error rate	% of widget renders that result in `section_load_failed`	N/A — new feature	≤ 2% sustained throughout Internal Alpha and beyond
Workspace p95 load time	95th percentile of `workspace_loaded` → fully interactive time	N/A — new feature	≤ 3s throughout Internal Alpha

Extensibility Gate:

Metric	Definition	Baseline	Target
Widget framework BD-readiness	Widget framework supports BD persona onboarding (Phase 2, August) without re-engineering the platform core	N/A — binary	Confirmed by Engineering Lead before Phase 2 grooming begins

All metrics tracked via Mixpanel. Dashboard owner: Product team.

12. Launch Plan & Stage Gates

Stage	Audience	Duration	Success Gate to Advance	Owner
Internal Alpha	Qontak internal SDR users (flag ON per internal CID)	2 weeks	DAR ≥ 60% sustained for 2 weeks; widget error rate ≤ 2%; no critical production issues; positive pilot feedback from internal SDR users	PM + QA
Closed Beta	Select external SDR pilot CIDs (scope: PM + CSM to identify, target 3–5 CIDs)	2–3 weeks	DAR ≥ 60% in pilot cohort; module-switch reduction trend visible; widget error rate ≤ 2%; no P1 production issues	PM + CSM
Open Beta	Broader SDR-enabled CIDs (Engineering + PM to scope)	2–3 weeks	All Closed Beta gates sustained; widget CTR ≥ 40%; PMM sign-off	Eng Lead + PM
GA	All eligible CIDs with SDR Team assignments	Ongoing	All Open Beta gates sustained for 2 additional weeks; `workspace_homepage_enabled` default remains OFF — GA flag strategy TBD	PM + PMM

13. Dependencies

Dependency	Owning Team	Deliverable Needed	Blocking?
Corporate Strategy Team — Workspace Data Definitions	Cross-team (Data / Analytics)	Finalized metric boundaries for Today's Progress counters (exact definition of "Conversations Handled", "Opportunities Advanced", "Activities Completed"; data ownership per metric) — must be confirmed before Widget Data Service API schema is locked.	YES — Blocking for July milestone
Widget Data Service API contract	Qontak CRM Engineering	Widget Data Service API schema (endpoints, request/response shape, TTL feasibility per widget data source, error codes) — must be finalized before widget development begins.	YES
Qontak CDP — Lead & Conversation Data	CDP Team	Read access to lead status, conversation idle signals, and activity data for Today's Priorities widget population.	YES
Widget framework extensibility review	Qontak CRM Engineering	Engineering Lead sign-off that the Phase 1 platform architecture (Section framework, widget registry, role visibility model) is extensible for Phase 2 BD onboarding without re-engineering.	YES — Gate for Phase 2 start

14. Key Decisions + Alternatives Rejected

Decisions Made:

Date	Decision	Rationale
2026-07-01	Workspace structured as ANCHOR + Phase PRDs (Phase 1: SDR, Phase 2: BD, Phase 3: AM)	Multi-phase initiative with distinct persona rollouts — ANCHOR + Phase structure keeps phase-specific scope isolated and avoids a single monolithic PRD.
2026-07-01	Workspace implemented as embeddable iframe page (candidate approach)	Enables faster iteration and independent deployment while integrating into existing CRM shell. Engineering to confirm final architecture.
2026-07-01	State restore on return (vs. reset on return)	SDR primary workflow involves consecutive priority item processing — resetting state after every navigation would force re-location of next item, creating friction. Restore + background refresh keeps data current while minimising context loss.
2026-07-01	Admin-level widget configuration: out of scope for Phase 1	Phase 1 focuses on validating Workspace value with Product-defined widget sets. Admin config complexity would slow Phase 1 delivery and reduce ability to iterate quickly during discovery.
2026-07-01	Data refresh via auto-polling (preferred) or refresh button per-section (last resort)	No WebSocket support in Qontak CRM. Auto-polling is preferred for freshness; refresh button is acceptable fallback. Final mechanism open for Engineering to confirm.
2026-07-01	Widget personalization: hide/show per user account (cross-session) — drag-and-drop deferred	Phase 1 validates widget utility before investing in reordering complexity. Hide/show enables minimal customization without significant engineering overhead.

Alternatives Rejected:

Alternative	Why Rejected	Date
Single PRD for entire Workspace initiative (no ANCHOR structure)	Initiative spans 3 distinct phases and 3 persona rollouts across Q3. A single document would become unmanageable — ANCHOR + Phase structure is cleaner for PM handoffs and Engineering per-Epic scoping.	2026-07-01
Full page reset on return from action (vs. state restore)	Resets force SDRs to manually re-locate their position after each consecutive action — unacceptable UX for a workflow involving 5–15 priority items processed back-to-back.	2026-07-01
Tenant-admin widget configuration in Phase 1	Adds significant Engineering and Product complexity; reduces ability to iterate and validate widget value quickly in the Internal Alpha window. Deferred to future phase.	2026-07-01
Inline / modal Quick Actions (vs. navigation shortcuts)	Inline flows within the Workspace frame require significant Engineering work per action type and add scope risk to the July milestone. Phase 1 validates navigation shortcuts as sufficient for SDR workflow entry.	2026-07-01

15. Open Questions

#	Type	Question	Owner	Deadline
1	Open Question	Data refresh mechanism: Engineering to propose final approach — FE auto-polling (preferred) vs. refresh button per-section (last resort). Final decision needed before Widget Data Service API schema is locked.	Engineering Lead	Before Widget Data Service design begins
2	Open Question	State restore trigger logic: what constitutes "return to Workspace" vs. fresh navigation? (Browser back button vs. sidebar nav link click.) Impacts implementation of WS-S04 state restore.	Engineering Lead	Before WS-S04 implementation
3	Open Question	"Reason for appearing" enum: exact reason string values per priority signal source (e.g., "Interested — waiting for response", "Conversation idle for 3h"). Needed to complete WS-S03 AC data validation.	Engineering + PM	Before WS-S03 development begins
4	Open Question	Workspace URL path and iframe architecture: final URL (`/workspace` or other), and whether embeddable iframe approach is confirmed. Engineering to propose.	Engineering Lead	Before Phase 1 development kickoff
5	Open Question	Insight widget data sources and content specs (Team Pipeline, Team Activities, Team Performance): exact definitions and data ownership for SDR Lead Insight widgets. To be defined through Phase 1 product discovery.	PM Qontak Group	Before Insight widget development begins
6	Open Question	Widget Data Service API schema: endpoints, request/response shape, error codes, caching strategy, TTL feasibility per widget data source. Engineering to finalize and confirm before widget development starts.	Engineering Lead	Blocking for July milestone
7	Assumption	Today's Progress metrics (Conversations Handled, Opportunities Advanced, Activities Completed, Work Summary) are derivable from existing CRM activity data without new data pipelines. Corporate Strategy / Data team to confirm exact metric boundaries and data ownership.	Corporate Strategy / Data Analytics	Blocking for July milestone
8	Risk	Phase 1 July milestone includes Platform [A] + all Phase 1 committed widgets [B]. Any Content Items added after the initial Engineering estimate are incremental scope and must not require platform re-engineering. Risk: scope creep from discovery adding widget requirements that inadvertently require platform changes. Mitigation: clear separation of Platform [A] (Engineering estimates once) and Content Items [B] (Product-defined, incremental).	PM + Engineering Lead	Ongoing throughout Phase 1
9	Risk	Widget framework extensibility for BD/AM (Phase 2/3): if Phase 1 platform decisions create hidden coupling that blocks BD onboarding in August, the Q3 roadmap is at risk. Mitigation: Engineering Lead sign-off on extensibility before Phase 2 grooming begins (see Dependencies).	Engineering Lead	Before Phase 2 grooming
10	Assumption	Widget personalization (hide/show) is stored per user account server-side. Engineering to confirm storage approach (user preferences table vs. existing profile extension).	Engineering Lead	Before WS-S05 development

PRD CHANGELOG

Version	Date	By	Section	Type	Summary
1.0	2026-07-01	Claude (groom-prd skill)	All	CREATED	Phase 1 PRD created from pre-grooming form + grooming session (PM Qontak Group). Includes 7 user stories (WS-S01–S07), 2 guard rails (WS-NEG-01–02), full system flow diagram, API behavior table, and test coverage matrices for all Must Have stories.

Qontak | CRM | Workspace Homepage — Phase 1: SDR Workspace

HEADER BLOCK

Table of Contents

CONDITIONAL BLOCK: PHASE CONTEXT

1. One-liner + Problem

2. What Happens If We Don't Ship This Phase

3. Target Users + Persona Context

4. Non-Goals

5. Constraints

6. New Features

6.1 Workspace Homepage — Page

📊 UI State Diagram — WorkspacePage

6.2 Today's Priorities Section

📊 UI State Diagram — Today's Priorities Widget

6.3 Today's Progress Section

6.4 Quick Actions Section

6.5 Insight Section (SDR Lead only)

7. API & Webhook Behavior

8. System Flow + User Stories + ACs

8.1 System Flow

8.2 User Stories

9. Rollout

10. Observability

10.1 Post-Launch Monitoring Cadence

11. Success Metrics

12. Launch Plan & Stage Gates

13. Dependencies

14. Key Decisions + Alternatives Rejected

15. Open Questions

PRD CHANGELOG

HEADER BLOCK​

Table of Contents​

CONDITIONAL BLOCK: PHASE CONTEXT​

1. One-liner + Problem​

2. What Happens If We Don't Ship This Phase​

3. Target Users + Persona Context​

4. Non-Goals​

5. Constraints​

6. New Features​

6.1 Workspace Homepage — Page​

📊 UI State Diagram — WorkspacePage​

6.2 Today's Priorities Section​

📊 UI State Diagram — Today's Priorities Widget​

6.3 Today's Progress Section​

6.4 Quick Actions Section​

6.5 Insight Section (SDR Lead only)​

7. API & Webhook Behavior​

8. System Flow + User Stories + ACs​

8.1 System Flow​

8.2 User Stories​

9. Rollout​

10. Observability​

10.1 Post-Launch Monitoring Cadence​

11. Success Metrics​

12. Launch Plan & Stage Gates​

13. Dependencies​

14. Key Decisions + Alternatives Rejected​

15. Open Questions​

PRD CHANGELOG​

HEADER BLOCK

Table of Contents

CONDITIONAL BLOCK: PHASE CONTEXT

1. One-liner + Problem

2. What Happens If We Don't Ship This Phase

3. Target Users + Persona Context

4. Non-Goals

5. Constraints

6. New Features

6.1 Workspace Homepage — Page

📊 UI State Diagram — WorkspacePage

6.2 Today's Priorities Section

📊 UI State Diagram — Today's Priorities Widget

6.3 Today's Progress Section

6.4 Quick Actions Section

6.5 Insight Section (SDR Lead only)

7. API & Webhook Behavior

8. System Flow + User Stories + ACs

8.1 System Flow

8.2 User Stories

9. Rollout

10. Observability

10.1 Post-Launch Monitoring Cadence

11. Success Metrics

12. Launch Plan & Stage Gates

13. Dependencies

14. Key Decisions + Alternatives Rejected

15. Open Questions

PRD CHANGELOG