Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Discovery Brief: Conversational Analytics

Project: Conversational Analytics

Status: CANDIDATE

Last Updated: Aug 26, 2025

Product Manager: @David Walters

Jira Epic: https://cxtsoftware.atlassian.net/browse/XD-50402Pending approval

Part I: The Opportunity Proposal

Problem Statement

  • Core Problem: Clients and their customers can’t quickly get trusted answers or basic analytics from the Client Portal without opening tickets or navigating multiple screens; this creates friction for users and avoidable cost for us.

  • For the Customer:

    • “Where’s my order?” questions (WISMO) and data retrieval require context-switching (search forms, filters, CSV exports) or contacting support.

    • Non-technical users can’t self-serve analytics (“last 6 months by customer, grouped by service level, with outliers”).

    • Answers are slow, fragmented, and hard to share.

  • For the Business:

    • High volume of low-complexity support (WISMO/status, “how do I” questions) drives avoidable cost and impacts CSAT for our customers.

    • Missed expansion opportunities: analytics are under-discovered and under-used in the portal, limiting perceived value and account stickiness—especially in regulated verticals where auditability and timely answers matter.

    • Our strategy is to invest in the Intelligence Layer; lack of conversational access to data and knowledge slows that strategy.

Vision

To enable portal users to ask plain-language questions and receive grounded answers, status lookups, and instant data visualizations by embedding a safe, auditable conversational copilot in the Client Portal.

Proposed Solution

We believe we can solve this problem by building a Client Portal Copilot (“Conversational Analytics”) that allows users to:

  • Ask natural-language questions (e.g., “How many orders in the last 6 months?”) and receive inline charts/tables.

  • Retrieve order/tracking details using identity-aware lookups (their own orders, or by ID).

  • Ask support questions answered via RAG over our documentation (e.g., Confluence).

This will likely include:

  • Chat UI in the Client Portal with inline renderers (tables, Chart.js visuals, copy/download).

  • Backend orchestrator (LLM + tools) with:

    • Safe SQL translator (parameterized queries, row/time limits, allow-list of views).

    • Order/Tracking lookup tool (tenant-scoped).

    • RAG over product docs (with citations).

  • Observability & guardrails: prompt/response logging, cost, latency, success/error tagging, and human-fallback paths.

Out of Scope for this version:

  • Taking actions that modify state (e.g., cancel order, change address).

  • Complex multi-hop analytics (“order retention across custom business calendars”).

  • Mobile app work; mobile web should be acceptable but not optimized.

  • External-data joins or non-CXT sources.

  • Proactive recommendations/next-best-action (nice-to-have later).

Initial Goals & Success Metrics

  • Increase User Self-Sufficiency & Engagement

    • Achieve a 25% weekly adoption rate (Weekly Active Users interacting with the co-pilot) within 2 months of launch.

  • Deliver Demonstrable Value

    • 15% of active users successfully generate at least one data visualization per month.

Goal

Success Metric (KPI)

Increase User Self-Sufficiency & Engagement

Achieve a 25% weekly adoption rate (Weekly Active Users interacting with the co-pilot) within 2 months of launch

Deliver Demonstrable Value

15% of active users successfully generate at least one data visualization per month.

Capture Customer Signal of Value

≥ 1 positive reference (CAB meeting, account manager feedback, or customer quote) confirming reduced inbound WISMO demand in first 90 days.

Phase II: Discovery & Validation

Purpose of this section: To be completed after initial discovery work (user interviews, data analysis). It de-risks the project by validating the problem and proposed value. This section provides the evidence and confidence needed to move from "Candidate" to "Ready for Design/Build."

Deep Dive: Users & Context

What is this section for? To ground the project in reality by deeply understanding who we are building for and the context they operate in. This prevents ivory-tower assumptions.

  • Primary User Persona:
    How to write it: Summarize the target user in a few bullet points. Include their role, main goals, top frustrations, and level of tech-savviness. You can link to a more detailed persona document if one exists.

  • Core Job(s) To Be Done (JTBD):
    How to write it: Use the "When..., I want to..., so that..." format to describe the user's underlying need. Focus on their motivation and desired outcome, not on features. You should have 1-2 core jobs for a well-scoped project.

  • Environment & Context:
    How to write it: Describe where and how the user works. Are they in a noisy office or a quiet remote setting? Are they constantly interrupted? What devices do they rely on? This context is crucial for making good design decisions.

Deep Dive: Problem Validation

What is this section for? To provide overwhelming evidence that the problem is real and painful. This section details the "why now" with qualitative and quantitative data.

  • Detailed Pains & User Quotes:
    How to write it: List the top 3-5 pain points you've uncovered in your research. For each pain, add a direct, impactful quote from a user interview. This makes the pain feel real. If possible, add a data point showing the business impact (e.g., "This leads to an estimated 5 hours of wasted work per week.").

  • Current Workarounds:
    How to write it: Describe the "hacks" or inefficient processes users have created to solve this problem today. Mentioning things like spreadsheets, sticky notes, constant emailing, or using multiple different tools are strong signals of an unmet need.

  • Secondary Stakeholders:
    How to write it: Think beyond the primary user. Who else is affected by this problem or will be affected by the solution? List them and what they care about (e.g., "Operations Manager - cares about team efficiency and cost reduction."). This helps prevent blind spots during rollout.

Deep Dive: Hypotheses & Risks

What is this section for? To explicitly state our core beliefs and identify the biggest risks that could cause this project to fail. The goal of discovery is to validate these hypotheses and mitigate these risks.

  • Opportunity Hypothesis:
    How to write it: Frame your core bet in a single statement. A good format is: "We believe that by [building the proposed solution] for [our persona], we will achieve [a desirable customer outcome], leading to [a measurable business impact]."

  • Key Assumptions to Validate:
    How to write it: List the 3-5 most critical things that MUST be true for your hypothesis to succeed. These are your leaps of faith. Frame them as statements to be proven (e.g., "We assume users are willing to share their data for optimization.").

  • Key Risks & Mitigations:
    How to write it: Identify the biggest known threats to the project's success (technical, business, or user-related). For each risk, propose a concrete mitigation (a plan to reduce the risk) or a spike (a time-boxed investigation to learn more).

Validation Plan & Next Steps

What is this section for? To turn discovery into an actionable plan. This lists the specific activities you will undertake to learn, validate assumptions, and mitigate risks.

  • Learning Goals:
    How to write it: Turn your "Key Assumptions" into questions you need to answer. What are the most important unknowns we need to resolve in the next 1-4 weeks? (e.g., "Can users easily understand our proposed workflow?").

  • Activities & Experiments:
    How to write it: List the concrete tasks you will perform to answer your learning goals. Be specific: "Conduct 5 interviews," "Test a clickable prototype with 8 users," "Perform a technical spike on the X API." Assign an owner and an ETA to each.

  • Success Signals:
    How to write it: Define what "good" looks like for each activity before you start it. This helps avoid confirmation bias. For example: "We'll consider the prototype successful if at least 4 out of 5 users can complete the core task without assistance."

Discovery Partners & Interested Customers

What is this section for? To demonstrate a ready "lab" for interviews and a potential list of beta customers. This builds confidence that we have a path to getting feedback.

How to write it: List the companies and specific contacts who have expressed interest or agreed to help. Include their status (e.g., "Contacted," "Interview scheduled," "Expressed strong interest for Beta"). This shows you've done the legwork.

Project Documents & Links

What is this section for? A centralized hub for all project-related artifacts. Keep this updated as the project progresses.

How to write it: As you create new documents (research notes, Figma files, technical docs, Jira epics), add the links here. This turns your brief into a true and lasting project hub for anyone who joins the project later.