サポートメール、コミュニティ、インタビューに似た要望が散らばると、製品担当者は同じ問題なのか、誰が困っているのか、なぜ今取り組むのかを調べ直すことになります。短い要約だけでは、その判断の根拠が残りません。
Busa Feedbackは、原文のフィードバック、分類した要求、ロードマップ提案を結ぶBusabaseテンプレートです。Agentが整理と提案を担当し、人が証拠と取捨選択を確認します。まず権限のあるエクスポートや手作業のメモから始められます。
インストール先と入力元を確認する
Busa Feedbackのテンプレートページからログインし、対象workspaceを選びます。チームの保存先を確認してください。デモの記録は画面説明用で、実際の顧客データとして数えません。
製品識別子、情報源、収集方法、重み、ロードマップの列を準備します。入力は別Agentからの受け渡し、エクスポート、手入力などです。情報源に名前を登録しても外部サービスの権限は自動で得られません。
依存機能や接続が不足する場合は、該当する書き込みの前に整えます。接続していないチャネルを収集済みにしません。秘密値は安全な設定に置き、情報源表には必要な環境変数名などを保存します。
公式のinbox画面。英語のデモデータで、実際の顧客データではありません。 ↗ busabase.com
八つのBaseで根拠と判断を分ける
テンプレートのソースにはproducts、sources、feedback、requests、roadmap、proposals、sync-log、settingsがあります。製品、原資料、解釈、判断、実行履歴を別々に管理します。
feedbackは原文、時刻、参照リンク、ユーザー情報、request-idを保持します。requestsは問題の説明、提案範囲、代表する原文を保存します。proposalsが判断と編集可能な草稿を扱い、roadmapに採用した列が表示されます。
担当者は要求から原文に戻れる必要があります。明確な問題でも保留できますし、苦情が新機能ではなく不具合を示すこともあります。すべてを機能要求に押し込みません。
一つの入力を重複計上しない
取り込みpayloadにはsourceとitemsを用意し、安定したexternal_id、原文、受信時刻、利用できるpermalink、ユーザー情報を含めます。ingest_feedback.mjsが統一入口で、--applyなしでdry-runを確認してから許可された書き込みを適用します。
識別子はfb-<source_id>-<external_id>です。同じ入力の再取り込みは冪等になります。別チャネルへの転載などはAgentが確認します。異なる外部IDだけでは、独立したユーザーや要望の証明になりません。
自社製品と利用権限のあるチャネルの資料を使います。必要な原文と安全なリンクを残し、不要な個人情報やプラットフォーム応答全体は持ち込みません。出典不足は明示します。
公式のrequests画面。英語のデモデータで、実際の顧客データではありません。 ↗ busabase.com
表現よりも利用上の問題で分類する
新しいフィードバックを製品と根本の利用問題でまとめてください。代表原文と参照先を残し、似た文面でも目指す結果が違えば分けてください。問題、提案範囲、未確認点を記録し、原資料へ対応付けます。不具合、不要情報、機能要求を区別し、変更予定の記録を先に示してください。
分類はAgentの分析で、apply_clusters.mjsが検証と書き戻しを担当します。feedbackのnew、clustered、ignored、insightは整理状態です。requestsのcandidate、roadmap、declined、needs_infoは要求の扱いを示します。
頻度とweighted-scoreは関連feedbackから読み取り時に計算されます。Agentが数値を直接記入しません。スキーマ上、重み付き得点は関連user-weightの合計です。チームの重み設定は方針であり、利益の実測や自動的な優先順位ではありません。
Roadmap画面で理由と草稿を審査する
Agentは採用、却下、統合、changelogの提案を理由と証拠、編集可能な文章とともに作ります。担当者は原文、統合範囲、草稿を確認し、承認、修正要求、ブロックを選びます。
proposals表のapprovedは業務判断です。BusabaseのChangeRequestがマージされた状態とは別です。Change Requestsは有効権限に従い、write権限なら即時マージでき、提案専用ならレビュー待ちになります。
review-noteには変更すべき範囲と理由を具体的に残します。Agentは修正後needs_reviewに戻します。人の訂正が記録されれば、次回も同じ判断を引き継げます。
公式のroadmap画面。英語のデモデータで、実際の顧客データではありません。 ↗ busabase.com
承認とユーザーへの送信を分ける
execute_decisions.mjsは既定でdry-run計画を表示します。確認後--applyで内部のロードマップ調整や要求統合を適用します。返信と更新告知はhandoff_readyになるだけで、このスクリプト自身は送信や公開をしません。
そのため提案がdoneでも送信完了の証拠にはなりません。対応ツールを使い、明確な許可の範囲で別途実行して結果を残します。内部判断、文章承認、実際の送信を区別してください。
実際の一つのバッチで確かめる
同じ資料の再取り込みで件数が増えないか、原文へ戻れるか、関連変更で数値が更新されるか、人の修正が残るか、内部処理と外部への引き継ぎが区別できるか確認します。
全チャネルの接続を待つ必要はありません。一つの許可されたエクスポートで、原文、担当者の理由、次の行動がつながる一巡を確認してから広げます。
実データを取り込む前にテンプレート導入時の確認も参照し、構造と内容の採用状態を確認します。