Dashboard Metrics Pipeline
Purpose
Section titled “Purpose”Define the future cross-system workflow that turns raw reviews, comments, and conversations into dashboard-ready signal, system, and outcome metrics.
This workflow exists because the Dashboard should not derive future analytics directly from route-local UI state. It needs a canonical pipeline for:
- signal detection
- triage and routing summaries
- KB gap identification
- outcome recording
- aggregate materialization
Workflow stages
Section titled “Workflow stages”1. Interaction intake
Section titled “1. Interaction intake”An inbound item arrives from a supported surface such as:
- social comments
- review platforms
- web chat
- messaging channels
- future supported inboxes
Required outputs:
- workspace scope
- channel type
- app surface
- timestamp
2. Signal classification
Section titled “2. Signal classification”The platform classifies the item into dashboard-relevant signal buckets.
Examples:
- dissatisfaction detected
- severe negative signal
- success / praise signal
- neutral informational request
Required event family:
customer_signal.*
3. Theme clustering
Section titled “3. Theme clustering”The system groups related signals into reusable friction or opportunity themes so the dashboard can show ranked topic clusters instead of only raw counts.
Examples:
- refund expectations
- scheduling friction
- missing compatibility guidance
Required event family:
customer_signal.theme_clustered
4. Triage and routing
Section titled “4. Triage and routing”The platform decides what to do next with the interaction.
Possible paths:
- auto-handle
- assist human responder
- escalate to human review
- block or defer due to policy, quality, or missing knowledge
Required event family:
ai_triage.*
5. Reply and knowledge grounding
Section titled “5. Reply and knowledge grounding”If the system generates or assists a reply, it should record:
- whether a reply was generated
- whether a reply was sent
- whether KB weakness or missing guidance reduced quality/confidence
Required event family:
ai_reply.*
6. Outcome capture
Section titled “6. Outcome capture”Once enough downstream evidence exists, the system may record outcome-level signals such as:
- resolved
- recovered
- reopened
- successful human handoff
Required event family:
interaction.outcome_*
Outcome capture must remain conservative until attribution rules are approved.
7. Aggregate materialization
Section titled “7. Aggregate materialization”The analytics layer groups the recorded events into dashboard payload groups:
readinessSummarycustomerSignalSummarysystemSummaryoutcomeSummarytopFrictionThemesrecentActivityrecommendedActions
Materialization may be:
- near-real-time
- batched
- hybrid
The route contract must not assume a specific storage engine.
Canonical flow summary
Section titled “Canonical flow summary”flowchart LR intake[InteractionIntake] --> signal[SignalClassification] signal --> theme[ThemeClustering] signal --> triage[TriageAndRouting] triage --> reply[ReplyAndGrounding] triage --> human[HumanEscalation] reply --> outcome[OutcomeCapture] human --> outcome signal --> aggregate[DashboardAggregate] theme --> aggregate triage --> aggregate reply --> aggregate outcome --> aggregateMinimum rollout path
Section titled “Minimum rollout path”Phase 1
Section titled “Phase 1”Enable dashboard-ready signal and system metrics:
- dissatisfaction detected
- severe negative count
- theme clustering
- escalations triggered
- KB gap detected
- auto vs assisted vs escalated handling split
Phase 2
Section titled “Phase 2”Enable dashboard-ready outcome metrics:
- resolved
- recovered
- reopened
- successful handoff
Phase 3
Section titled “Phase 3”Enable more advanced trend and quality layers only after attribution and governance mature.