Use Busa Feedback to trace roadmap decisions back to user feedback

Feature requests arrive in support email, community conversations, and interview notes. A summary can reduce the reading load, but a product decision needs a traceable answer: are these comments describing the same problem, who is affected, and why should the team act?

Busa Feedback is a Busabase template connecting raw feedback, clustered requests, and roadmap proposals. The agent prepares and clusters material; the operator inspects evidence and decides. Start with an authorized export or manual notes before connecting every channel.

Install in the intended workspace

Open the Busa Feedback template, sign in, and select the workspace for installation. Confirm the target team before proceeding. Demo records illustrate the interface and must not be counted as customer feedback.

Prepare product identifiers, channel names, collection methods, scoring weights, and roadmap lanes. Sources can use sibling-agent handoffs, exports, or manual collection. A registered source does not automatically provide platform credentials or data access.

Resolve the template’s declared dependencies before the corresponding write operations. Keep missing connections visible. Store secrets in secure configuration; the source records should contain necessary configuration names rather than token values.

Official inbox screenshot with English demo data, not real customer feedback. ↗ busabase.com

Understand the eight Bases

The template source declares products, sources, feedback, requests, roadmap, proposals, sync-log, and settings. These separate product identity, original material, interpretation, decisions, and execution history.

Feedback records retain original text, timestamps, permalinks, user context, and request-id. Requests hold the problem statement, proposed specification, and representative feedback references. Proposals connect the request to a decision and editable draft. Roadmap records show the resulting lanes.

The operator should be able to move from a request back to the original material. A well-defined problem can still be deferred; a complaint can reveal a bug rather than a feature request. Preserve those distinctions instead of forcing every item into a roadmap candidate.

Ingest each source item once

A payload contains a source block and items with stable external_id values, text, received time, available permalinks, and user context. ingest_feedback.mjs is the raw-feedback entry point. Omit --apply to inspect the dry run before applying authorized writes.

The record identifier is derived as fb-<source_id>-<external_id>. Reimporting the same source item should be idempotent. Cross-channel repetition still requires judgment: different external identifiers do not prove independent users or distinct needs.

Use material about your own products from channels you are authorized to process. Retain the necessary text and safe links rather than whole platform payloads, credentials, or unrelated personal information. Mark missing provenance explicitly.

Official requests screenshot with English demo data, not real customer feedback. ↗ busabase.com

Cluster problems while preserving the voices

Give the connected agent an instruction such as:

Read new feedback and group it by product and underlying user problem. Preserve representative quotations and source links. Keep similar wording separate when the intended outcomes differ. Draft the problem statement, proposed scope, and unresolved questions; link the original items. Separate bugs, spam, and feature needs, and show the records the clustering would change.

The agent performs the analysis; apply_clusters.mjs validates and writes assignments. Raw-feedback triage states include new, clustered, ignored, and insight. Request states include candidate, roadmap, declined, and needs_info.

Frequency and weighted score are derived from linked feedback on reads, not manually entered request fields. The schema defines weighted score as the sum of linked user weights. These weights express the operator’s policy; they do not measure proven commercial return or decide priority automatically.

Review proposals in the roadmap interface

The agent can propose promotion, decline, merge, or changelog work with reasons, evidence, and editable text. The operator reviews the underlying comments, checks grouping, revises the draft, and approves, requests changes, or blocks it.

Approved in the template’s proposals Base is a business verdict. It is distinct from a Busabase ChangeRequest’s merge state. Change Requests follow the effective writer permission: write access can merge immediately, while proposal-only access waits for review.

Save concrete review notes. Revisions return to needs_review after the agent addresses the requested changes. Keeping human corrections on the relevant records lets future runs reuse the decision rather than infer it again.

Official roadmap screenshot with English demo data, not real customer feedback. ↗ busabase.com

Approval is not proof of delivery

execute_decisions.mjs prints a dry-run plan by default. After confirmation, --apply handles internal roadmap changes and request merges. Outbound replies and changelog work become handoff_ready; the script itself never sends a reply or publishes a changelog.

A proposal marked done therefore does not prove that a user received a message. The appropriate external tool must carry out a separately authorized handoff, and the outcome should be logged. Distinguish approval of a decision, approval of wording, and authorization to send.

Accept one real batch before expanding

Check idempotent imports, links back to original comments, counts after assignments change, saved human edits, and the boundary between internal execution and external handoff. Broad channel coverage can come later.

The useful result is a product decision the team can explain: the original feedback, the operator’s reasoning, and a specific next action remain connected.

For installation acceptance details, read template installation boundaries before importing real feedback.