Side Quest

Project 02

01Product and GTM systems

Designed

Customer Feedback Intelligence

Turn customer conversations into product decisions.

An intelligence workspace that would connect feedback across Sales, Customer Success, and Support to show recurring product needs, account context, and commercial impact. From the first request to a product decision and a customer follow-up, the design keeps a traceable loop. This page is a sample. It does not read live systems.

Role
Product strategy, GTM systems, and workflow design.
Stage
Designed. The field loop at Truffle is not this app.

Feedback workspace

Illustrative figures, not results

24Sample signals

8Sample themes

5Sample accounts

Featured theme

Enterprise identity and provisioning

Four sample notes, three fictional accounts. One closed-lost line mentions SCIM. That is context, not revenue.

View details
Try one example: An access request, reviewed before a promise

Guided example: An access request, reviewed before a promise

Synthetic walkthrough

Fictional customer feedback. Reviewing a theme here does not commit a real roadmap or send a customer message.

Step 1 of 4

Preserve the observation

Harbor Bank (fictional), Sales, March 2026: “New admins wait days for access to the security console.” Status: Needs review.

Built with

Confirmed in the repository that renders this page. Planned tools stay in the case study and are not shown as logos.

02The feedback problem

Customer feedback is everywhere. Product context is not.

  • Sales

    New admins wait days for console access.

  • Customer Success

    SCIM was named in the pilot and never turned on.

  • Support

    SSO works. Contractor roles do not.

  • Closed-lost

    Security review required SCIM.

One theme, after review

Enterprise identity and provisioning

  • 4 related sample signals
  • Harbor Bank, Lumen Health, Northline Freight
  • Opportunity context: a lost expansion that named SCIM. Not a dollar figure.
  • Each original sentence stays attached as evidence.
Explore the workflow

03Product experience

From a customer signal to a decision a person still has to make.

Five steps in the browser. Accounts are fictional. Confirming a theme does not create a roadmap item.

Feedback inbox

Illustrative demo data

Architecture and implementation

04System architecture

How the feedback loop would work.

Solid pills are what this page does with sample notes. Dashed pills are planned. Nothing here calls a CRM, a ticket system, or a model.

Feedback sources

Sales conversations at Truffle are the field habit. This site does not read CRM, calls, success notes, or tickets.

  • CRM

    Planned

    Planned source. Not connected.

  • Call records

    Planned

    Planned source. Not connected.

  • Customer Success notes

    Planned

    Planned source. Not connected.

  • Support tickets

    Planned

    Planned source. Not connected.

Intelligence processing

The demo shows a suggested theme you can correct. Ingestion and deduplication are not built. No model runs.

  • Ingestion

    Planned

    Planned. The sample is hardcoded.

  • Structured extraction

    Planned

    Fields are designed. Nothing extracts them.

  • Classification

    In this demo

    You can confirm or edit a suggestion locally.

  • Deduplication

    Planned

    Planned. The sample is already grouped by hand.

  • Evidence preservation

    In this demo

    The original sentence stays on the card.

Product intelligence

Themes, accounts, and a review a person confirms. Confirming the demo does not update a roadmap.

  • Normalized feedback

    In this demo

    Five sample records.

  • Account context

    In this demo

    Fictional accounts stay on each note.

  • Feedback themes

    In this demo

    Two sample themes with filters.

  • Product review

    In this demo

    A local confirm. It does not persist.

  • Decision tracking

    Planned

    Planned record of who accepted what.

Closed loop

A follow-up draft you can edit and copy. It does not send, and a shipped feature would not close every request.

  • Product status updates

    In this demo

    Local status only. Not a release.

  • Release information

    Planned

    Planned join to Product Release Intelligence.

  • Account owner review

    Planned

    Designed step. No owner inbox here.

  • Customer follow-up

    In this demo

    Draft you can copy. It does not email.

Design decisions and tradeoffs

05Product decisions

Designing for a focused MVP.

Account context over raw volume

Four notes from three accounts, including a loss, matter more than forty identical upvotes with no account.

A person confirms the roadmap

A suggestion can group notes. It cannot promise a customer that something will ship.

Sit beside the tools that already hold the notes

CRM, success notes, and the backlog stay where they are. This layer points at them. It does not replace them.

Technical notes

Planned records. Signal, Theme, Account, Evidence, Persona, Outcome.

MVP question. Does a theme with the account attached change what Product reviews, faster than a raw request list?

Out of scope. Replacing the backlog tool, and auto-committing roadmap items from a model.

06Outcomes and roadmap

Measuring what matters.

Proposed metrics. Nothing below has been measured in this repository.

Data quality

  • Feedback classification accuracy
  • Account association accuracy
  • Time to identify recurring themes

Proposed. Not measured.

Product adoption

  • Product review rate
  • Share of themes with a recorded decision

Proposed. Not measured.

Business outcomes

  • Closed-loop communication rate
  • Follow-ups that match the decision, without claiming every request is done

Proposed. Not measured.

  1. Designed now

    • Manual import of notes
    • A normalized theme
    • A board
    • The account left on the note
  2. Next

    • CRM and call-note intake
    • Tighter duplicate detection
    • A decision log
  3. Later

    • Join to release intelligence
    • Account-specific updates
    • More sources

Explore related work

Back to all projects