%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
改善要望は、受け口の一本化、優先順位の基準、検証後の反映、要望者への返答の4点を決めれば回ります。チケットの設計表と判断基準を整理します。
HubSpotの改善要望の管理とは、現場から出る「ここを直してほしい」を、受け口・優先順位の基準・検証・反映・要望者への返答の5つの手順に分けて、チケットの1本のパイプラインで回し続ける運用のことです。 要望を受けた順に対応するのではなく、基準で順位を付け、反映の前に確認を挟み、結果を要望者に返すところまでを1つの流れにします。
導入から数か月がたつと、HubSpotの現場からは「この項目が入力しにくい」「このリストを毎週手で作っている」といった声が出てきます。その声がSlackや会議の場で消えていくと、使われない設定と、直されない不満だけが残ります——要望を集めることよりも、集めたあとに決める仕組みがないことのほうが、定着を止める原因になります。
この記事では、要望を受けるところから反映後の確認までを、HubSpotの公式ナレッジで確認できた画面の場所と合わせて整理します。
この記事でわかること
- 要望が止まる4つの切れ目 ── 受け口、基準、検証、返答のどこで止まりやすいかを整理します
- チケットで作る要望管理の設計 ── パイプライン、ステータス、プロパティーの設計例を表で示します
- 優先順位を付ける5つの基準 ── 影響範囲、頻度、代替手段、データへの影響、変更の重さで判断します
- 反映の前に確認する手順 ── 変更の種類ごとに、検証と戻し方を決めます
- 準委任の伴走での回し方 ── 定着・運用改善の工程で、何をどの頻度で行うかを示します
改善要望が積み上がるだけで終わる4つの切れ目
改善要望が止まる場所は、たいてい4つのどれかです。要望の数が多いことが問題なのではなく、流れの途中に「誰も決めない場所」があることが問題です。まず、自社がどこで止まっているかを見ます。
要望を受ける場所が複数あると、同じ内容が別々に届き、誰がどこまで把握しているかが分からなくなります。受け口が決まっても、判断の基準がなければ、声の大きい人の要望が先に通ります。基準があっても、反映前の確認がなければ、直したことで別の画面が壊れます。そして反映したあとに要望者へ返答がなければ、次の要望は出てこなくなります。
切れ目ごとに起きること
次の表は、4つの切れ目で起きる症状と、この記事で扱う対処の対応です。自社の状況に近い行から読み始めてください。
| 切れ目 | 起きること | この記事での対処 |
|---|---|---|
| 受け口がない | 要望がSlack・会議・口頭に散らばる | チケットに一本化する |
| 基準がない | 声の大きさで順番が決まる | 5つの基準で点数を付ける |
| 検証がない | 直した設定が別の画面に影響する | 変更の種類ごとに確認方法を決める |
| 返答がない | 要望者が反映を知らず、次が出ない | 「反映済み」で必ず返す |
改善要望の管理で最初に決めるのは、優先順位ではなく、要望の置き場所です。置き場所が1つになると、数も、滞留日数も、反映までの流れも数えられるようになります。
要望の受け口は、HubSpotのチケットに一本化する
要望の置き場所は、HubSpotの中にあるほうが運用しやすくなります。理由は、要望の対象になるプロパティーやワークフローと、同じ画面から行き来できるからです。ここでは、チケットを要望の入れ物として使う設計を説明します。
チケットはもともと問い合わせ対応のための仕組みですが、チケット名・チケットの説明・チケットステータス・パイプライン・優先度・担当者といった既定のプロパティーが用意されています。内容は、公式ナレッジのHubSpotの既定のチケットプロパティー（HubSpotナレッジベース）で確認できます。社内の改善要望にも、そのまま転用できる構成です。
受け口を3つに絞る
要望の入口は、増やすほど管理が難しくなります。次の表の3つに絞り、それ以外の場所で出た声は、運用担当がチケットに転記する決まりにします。
| 受け口 | 向いている要望 | 運用担当の動き |
|---|---|---|
| チケットを直接作成 | 日常の業務で気づいた小さな不便 | 週に1回、新規を確認する |
| フォーム | 要望者が多く、書式を揃えたいとき | 送信内容をチケットとして確認する |
| 会議・Slackでの声 | 口頭で出た要望 | 運用担当が当日中にチケット化する |
フォームから直接チケットを作る設定は、公式ナレッジのフォームを作成する（HubSpotナレッジベース）に記載があります。旧フォームエディターの設定として、［その他］＞［マーケティング］＞［フォーム］から対象のフォームを編集し、「チケットのプロパティー」セクションの「自動的にチケットを作成」をオンにします。ただし、同じ記事には、2024年4月1日以降に作成されたアカウントでは、ヘルプデスクに接続されたフォームからのみチケットを作成できるという記載があります。自社のアカウントでどちらの条件になるかは、画面で確認してから設計します。
チケットの画面の位置づけ
下の画面は、チケットの一覧です。要望もこの一覧に並び、パイプラインのステータスで状況を見分けます。
チケット全体の使い方は、HubSpotチケット管理の使い方と設定手順で整理しています。この記事では、要望管理に必要な範囲だけを扱います。
要望専用のパイプラインとプロパティーを設計する
要望を問い合わせ対応と同じ画面に混ぜると、数も性質も違うものが並び、見分けにくくなります。要望専用のカスタムパイプラインを作り、ステータスを要望の流れに合わせるのが基本です。
パイプラインの作成手順は、公式ナレッジのパイプラインを設定およびカスタマイズする（HubSpotナレッジベース）に記載があります。設定アイコンから、左サイドバーの［データ管理］の［オブジェクト］を開き、「オブジェクトを選択」でチケットを選びます。［パイプライン］タブで［パイプラインを作成］から［ゼロから作成］を選び、名前を入力して作成します。作成と編集には「プロパティー設定の編集」の権限が必要で、カスタムパイプラインの作成にはStarter、Professional、Enterpriseのいずれかのサブスクリプションが必要です。
ステータスは「次に誰が動くか」で分ける
チケットではパイプラインのステージが「ステータス」と呼ばれます。既定のサポートパイプラインには、新規・先方待ち・要対応・クローズの4つがありますが、要望管理では、次に動く人が変わる場所でステータスを分けます。
| ステータス | 意味 | 次に動く人 |
|---|---|---|
| 受付 | 要望が届いた直後 | 運用担当 |
| 確認中 | 内容や再現条件を要望者に確認している | 運用担当・要望者 |
| 判定待ち | 優先順位の点数を付ける前 | 運用担当 |
| 対応予定 | 着手が決まり、時期が見えている | 実装担当 |
| 検証中 | 反映前の確認をしている | 実装担当・要望者 |
| 反映済み | 本番に反映し、要望者に返答した | 運用担当 |
| 見送り | 今は行わないと決め、理由を返した | 運用担当 |
ステージは追加と並べ替えができ、色も設定できます。チケットを含む取引以外のオブジェクトでは、各ステージを「進行中」か「クローズ済み」のどちらにするかを選びます。反映済みと見送りは、クローズ済みにしておくと、滞留している要望だけを数えやすくなります。
なお、レコードが残っているパイプラインや、他のツールで使われているパイプラインは削除できません。ステータス名は、運用を始めてから頻繁に変えると集計が崩れるため、最初に決め切ります。
プロパティーは5つだけ足す
既定のプロパティーに加えて、要望を判断するための項目を追加します。プロパティーの作成は、設定アイコンから左サイドバーの［プロパティー］を開き、「オブジェクトを選択」でチケットを選んで［プロパティーを作成］をクリックします。手順はプロパティーを作成および編集する（HubSpotナレッジベース）に記載があります。
| 追加するプロパティー | フィールドタイプの例 | 使い道 |
|---|---|---|
| 要望の種類 | ドロップダウン選択 | 入力項目・自動化・レポートなどで分類する |
| 影響する業務 | ドロップダウン選択 | どの業務の要望かを集計する |
| 影響する人数 | ドロップダウン選択 | 影響範囲の点数に使う |
| 代替手段 | ドロップダウン選択 | 「ある・手間がかかる・ない」で緊急度を見る |
| 反映予定の月 | 日付 | 要望者への返答時期を管理する |
プロパティーのオブジェクトタイプと内部名は、作成後に編集できないと公式ナレッジに記載されています。表示名は後から直せますが、内部名は作る前に決めます。命名の考え方は、HubSpotプロパティ設計と命名規則、データ型の選び方も参考になります。
優先順位は5つの基準で点数を付けて決める
要望が増えると、すべてを同じ重さで扱えなくなります。基準を決めずに順位を付けると、要望者との関係や、直近の出来事に引きずられます。点数を付ける基準を最初に決めておくと、見送るときにも理由を返せます。
ここで示す5つの基準は、StartLinkが定着・運用改善の工程で使う観点を整理したものです。HubSpotの標準機能ではなく、チケットの優先度プロパティーと、追加したプロパティーを組み合わせて運用します。
5つの基準と点数の付け方
各基準を1〜3点で付け、合計して順位を決めます。企業様（チーム）によって最適な形は異なりますので、基準の名前や配点は自社の業務に合わせて調整してください。
| 基準 | 1点（重い・小さい） | 3点（軽い・大きい） |
|---|---|---|
| 影響範囲 | 1人・1チームの不便 | 複数部門に及ぶ |
| 頻度 | 月に数回 | 毎日発生する |
| 代替手段 | 簡単な代替がある | 手作業で回避している |
| データへの影響 | 入力の見た目だけ | 集計・レポートの正確さに関わる |
| 変更の重さ | 設定の変更が大きい | 表示名や選択肢の追加で済む |
最後の「変更の重さ」だけは、軽いほど点数が高くなる点に注意してください。短い作業で効果が出るものを先に拾い、重いものは設計の時間を確保して計画に載せるためです。
合計点で行き先を決める
合計点は、反映の時期を決めるのに使います。点数をそのまま順位にするのではなく、行き先を3つに分けます。
| 合計点 | 行き先 | 返答の内容 |
|---|---|---|
| 12点以上 | 次の定例までに着手する | 着手と反映予定の月を返す |
| 8〜11点 | 月次でまとめて対応する | 次回の取りまとめ時期を返す |
| 7点以下 | 見送りまたは保留にする | 理由と、再提案の条件を返す |
見送りを決めるときは、必ず理由を書いて返します。「影響範囲が1人で、代替手段がある」と理由が示されれば、要望者は納得しやすく、条件が変わったときに再提案もできます。
見送りは、要望を断ることではありません。再提案の条件を示して返すと、要望の質が上がり、次の判断が早くなります。
ビューと定例で、滞留を見える状態にする
チケットを置いても、見る習慣がなければ止まります。HubSpotでは、保存済みビューで滞留を見える形にし、決まった頻度で見ることで、要望が流れ続ける状態を作れます。
ビューの作成手順は、公式ナレッジの更新版インデックスページで保存済みビューを管理する（HubSpotナレッジベース）に記載があります。対象のレコード一覧を開き、「+ ビューを追加」からビューの種類を選び、名前を付けてフィルターと列を設定し、右下の［公開］で完了します。ビューの種類にはテーブルビューのほか、ボードビューも選べます。
要望管理で作る保存済みビュー
作成直後のビューは、作成者とスーパー管理者のみが閲覧できる状態です。運用担当だけでなく要望者にも状況を見せたい場合は、［共有の管理］から公開範囲を選びます。
| ビュー名の例 | 絞り込みの考え方 | 見る人と目的 |
|---|---|---|
| 判定待ち | ステータスが「判定待ち」 | 運用担当が点数を付ける |
| 滞留（受付から日数が経過） | 作成日から一定日数がたち、ステータスが「受付」「確認中」 | 運用担当が返答漏れを見つける |
| 対応予定ボード | ステータスが「対応予定」「検証中」をボードで表示 | 実装担当が進捗を見る |
| 反映済み（直近） | ステータスが「反映済み」 | 要望者への返答を確認する |
定例は短く、頻度を分ける
要望管理の定例は、長くしないことが続けるコツです。頻度ごとに見る対象を分けると、目安として15分から30分で終わります。
- 週に1回：新規の要望を確認し、足りない情報を要望者に聞く。判定待ちのチケットに点数を付ける
- 隔週：対応予定のチケットの進捗を確認し、検証中のものを要望者に見てもらう
- 月に1回：反映済みのチケットを見直し、効果を確認する。見送りの理由を振り返る
- 四半期に1回：要望の種類や影響する業務の偏りを見て、設計や研修の改善につなげる
営業の取引ボードを見る週次レビューは、別の運用としてHubSpot予実管理とKPIダッシュボードの設定方法の考え方と組み合わせられます。要望の定例は、業務の数字ではなく、設定の改善に絞って行います。
反映の前に、変更の種類ごとに確認方法を決める
要望を反映するときの事故は、変更の大きさではなく、確認の抜けで起きます。小さな変更でも、既存のレポートやワークフローが参照していれば、影響は広がります。変更の種類ごとに、確認の方法と戻し方を先に決めておきます。
変更の種類別の確認表
次の表は、要望で多い変更の種類と、反映前の確認の例です。公式ナレッジで確認できた制約は、そのまま確認項目にしています。
| 変更の種類 | 反映前の確認 | 戻し方の考え方 |
|---|---|---|
| プロパティーの追加 | 内部名と、フィールドタイプを確定する | 内部名は編集できないため作る前に決める |
| フィールドタイプの変更 | 保存済みの値が無効にならないか確認する | 変更前の値を書き出しておく |
| パイプラインのステータス変更 | 使用中の参照（条件付きプロパティーなど）を確認する | 「使用箇所」の数値から参照を確認する |
| ワークフローの変更 | 登録条件と、動作するレコードの範囲を確認する | 変更前の設定を記録する |
| 権限の変更 | 変更後に見えなくなる画面がないか確認する | 変更前の権限の設定を控える |
サンドボックスで確認できるかを見極める
Enterpriseのサブスクリプションなら、サンドボックスで変更を試し、本番に反映できます。公式ナレッジのサンドボックスの変更を本番環境にデプロイする（HubSpotナレッジベース）では、設定アイコンから［サンドボックス］を開き、サンドボックスを作成し、本番アカウントで「デプロイを設定」を進める流れが示されています。
デプロイの前に、次の点を確認してください。
- デプロイはスーパー管理者の権限が必要で、一度に反映できる変更は最大300件です
- 開始後は取り消せないため、反映前に内容と競合を確認します
- コンタクト・取引・チケットなどのIDは、本番とサンドボックスで異なります
- 本番の連携は自動では接続されないため、テスト用に接続し直します
サンドボックスを使えない契約の場合は、影響が限られる範囲で先に試す運用に切り替えます。たとえば、新しいプロパティーは使う人を限定してから公開し、ワークフローは対象を絞った条件で先に動かします。サンドボックスの詳しい手順は、HubSpotサンドボックスの使い方で整理しています。
反映したあとに、要望者へ返して効果を確かめる
反映して終わりにすると、要望管理はすぐに形骸化します。反映したことを要望者に返し、狙った効果が出たかを確認することで、次の要望の質が上がります。
反映済みにするときは、チケットに、何をどう変えたかと、使い方が変わる点を記録します。要望者には、反映した日と変更の内容を、本人が分かる言葉で返します。使い方が変わるときは、手順を短くまとめて添えます。
効果の確認は、要望の理由に戻って行う
効果の確認は、要望を受けたときの理由に戻って行います。入力が面倒だという要望なら、反映後に入力の空欄が減ったか、入力の時間が短くなったかを確認します。レポートが見づらいという要望なら、そのレポートを見る頻度が増えたかを見ます。
効果が見えないときは、要望の背景を聞き直します。要望そのものが目的に合っていなかったり、別の課題が隠れていたりすることがあります。その場合は、同じチケットに追記し、新しい要望としてもう一度、受付から流します。
月次の確認で、次の3点を見ると、運用の状態が分かります。
- 受付から反映済みまでの日数が、伸びていないか
- 見送りの割合が、増え続けていないか
- 同じ種類の要望が繰り返し出ていないか
同じ種類の要望が繰り返し出るときは、個別に直すよりも、設計や研修を見直したほうが早く片付きます。運用ルールの整え方は、CRM運用ルール設計ガイドでも扱っています。
準委任の伴走で回すときの、工程ごとの進め方
要望管理は、仕組みを作るだけでは続きません。最初の数か月は、点数の付け方や返答の書き方に迷いが出るため、一緒に回しながら基準を固めます。StartLinkはHubSpotゴールドパートナーとして、導入の工程を、現状の整理・要件定義、設計・構築、データ移行、テスト・検証、定着・運用改善の流れで進めています。要望管理は、最後の定着・運用改善の工程で、準委任の伴走として扱います。
定着・運用改善の工程でやること
スモールスタートで、要望の種類と、使うステータスを絞って始め、運用しながら広げます。最初から全社の要望を受けるのではなく、まず1つの部門から始めるほうが、基準が固まりやすくなります。
| 段階 | やること | 成果物 |
|---|---|---|
| 現状の整理 | 要望が今どこに散らばっているかを集める | 要望の一覧と分類 |
| 設計・構築 | パイプライン、プロパティー、ビューを作る | 要望管理の設計書 |
| テスト・検証 | 実際の要望を数件流し、ステータスと点数を確認する | 運用ルールの初版 |
| 定着・運用改善 | 定例を回し、基準と返答の型を調整する | 点数表と返答の文例 |
AIを組み込む場面
要望の分類や要約には、AIを使える場面があります。Breezeで要望の種類を分類する、Claudeで同じ内容の要望をまとめる、といった使い方です。ただし、優先順位の最終判断と、見送りの返答は人が行います。AIに任せる範囲は、人が判断する箇所を先に決めてから決めます。
運用担当の役割分担は、HubSpot運用体制の構築ガイドで整理しています。要望の反映で権限を変えるときは、HubSpotパーミッション権限設計ガイドも合わせて確認してください。要望管理の設計から運用の伴走までを相談したい場合は、HubSpot導入支援のサービスをご覧ください。StartLinkはSync for freee / Sync for Notion の開発元でもあり、HubSpotと周辺のSaaSをつなぐ設計も含めて整理できます。
よくある質問
Q1. 改善要望の管理は、チケットではなくカスタムオブジェクトで作るべきですか
最初はチケットで始めることをおすすめします。チケットには、ステータス・優先度・担当者といった項目が既定であり、パイプラインとビューもそのまま使えます。件数が増え、チケットに入らない項目が必要になったときに、カスタムオブジェクトを検討します。判断の観点は、HubSpotカスタムオブジェクトの設計判断で整理しています。
Q2. 要望が多すぎて、点数を付けきれません
すべてに点数を付けず、まず「受付」のうち、重複と明らかな対象外を整理します。そのうえで、影響範囲が大きいものから点数を付けます。点数は短時間で付けられるよう、最初は5つの基準のうち3つに絞って始めても構いません。企業様（チーム）によって最適な形は異なりますので、運用の中で調整します。
Q3. 見送りにした要望者から不満が出ないか心配です
理由と再提案の条件を添えて返すと、不満は出にくくなります。見送りの理由が「影響範囲が1人で、代替手段がある」のように基準に沿っていれば、人ではなく基準で決まったことが伝わります。条件が変わったときに、同じチケットから再提案できるようにしておきます。
Q4. サンドボックスが使えない契約では、どう確認すればよいですか
使う人や対象のレコードを限定して先に反映します。新しいプロパティーは、権限で見える人を絞ってから公開します。ワークフローは、対象を絞った登録条件で先に動かして、動作を確認してから広げます。変更前の設定は記録しておくと、戻すときに迷いません。
Q5. 要望の定例は、誰が進行するのがよいですか
運用担当が進行し、要望者と実装担当が同席する形が基本です。運用担当が決まっていない場合は、定着・運用改善の工程で伴走する外部の担当が、最初の数回を進行し、進め方を引き継ぎます。
まとめ：改善要望は、置き場所と基準を決めれば回り始める
改善要望の管理は、仕組みの大きさではなく、決めておく項目の少なさで続くかどうかが決まります。この記事の要点は次のとおりです。
- 受け口はチケットに一本化する ── 他の場所で出た声は、運用担当が当日中に転記します
- ステータスは次に動く人で分ける ── 受付から反映済み・見送りまで7つで始めます
- 優先順位は5つの基準で点数を付ける ── 合計点で、着手・月次・見送りの行き先を決めます
- 反映の前に、変更の種類ごとに確認する ── 内部名の編集不可など、公式で確認できた制約を確認項目にします
- 反映したら要望者に返し、効果を確かめる ── 要望の理由に戻って、確認します
最初の一歩は、現在Slackや会議で出ている要望を目安として10件ほど集め、チケットの1本のパイプラインに入れて、点数を付けてみることです。実際に流すと、自社に合う基準とステータスが見えてきます。
自社の状況に当てはめた進め方を検討したい場合は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお問い合わせください。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
