顧客の課題が一つに収まらないときは？複数分類と根拠の残し方

青葉商会の佐藤は森製作から、設備の点検漏れと部品探しの手間という二つの要望を聞きました。点検は毎週、部品探しは故障時に起きます。

CRMの課題欄が一択だと、点検漏れを選んだ時点で部品探しの要望が一覧から消えます。

要望を複数持てるようにし、各要望の発生場面・根拠記録・優先順を商談へ結び付けます。 参照資料「HubSpot: Create and edit properties」で確認した範囲は、レコードの属性欄、標準欄と独自欄、空欄の区別。 この節の会社・担当・社内基準は架空の教材です。

この章の根拠：出典1

「要望N13-1 点検漏れ」の入力は、毎週の確認担当が不明です。ここでは10月3日の面談記録を根拠にします。記録の判断欄には「先に担当整理を確認」と残します。

「要望N13-2 部品探し」の入力は、故障時に旧品番を探すです。ここでは頻度はまだ未確認です。記録の判断欄には「次に品番資料を確認」と残します。

「要望N13-3 自動発注」の入力は、佐藤が考えた案です。ここでは提案仮説の欄へ分けます。記録の判断欄には「顧客要望として登録しない」と残します。

比較表は横に動かして全ての列を確認できます。

佐藤は顧客の発言を長文の備考に置くだけでなく、要望ごとのIDを付けます。課題分類は検索のために使い、具体的な作業場面は記録へ戻って読めるようにします。

複数選択のタグだけなら二つの課題を探せますが、どちらを先に確認するかは分かりません。要望IDと優先順を持つと、点検担当の整理を先に進める理由を説明できます。

要望IDを付けると優先順を変えても元の発言を失いません。自動発注という佐藤の仮説は顧客の要望二件へ混ぜず、どの課題を解く案かを関係で示します。

複数の窓口が逆の優先順位を述べた場合は一つに平均しません。生産部と保守担当それぞれの希望を残し、今回は誰の仕事を対象にするかを次回面談で確認します。

分類の件数は課題を述べた顧客数や市場需要の大きさとは異なります。この一社の要望から全顧客の優先順位を推定しません。

窓口の優先が違う場合は佐藤が点検担当と生産担当の対象作業を確認します。優先順位は今回の相談の範囲で確定し、会社全体の恒久的な順序として他案件へコピーしません。

佐藤がN13-1とN13-2をD13へ関連付け、田中は点検担当の現状と旧品番の資料所在を別の確認タスクにします。自動発注案は顧客発言と混ぜずに準備します。

点検漏れで検索しても部品探しで検索しても同じD13が見つかり、集計では一商談として数えるかを確認します。タグの数を商談数へ足しません。

高橋はタグ検索から二つの要望の具体的な作業へ戻れるか試します。営業案を顧客の発言として記録した誤りがあれば発言者と原メモを照合し、仮説欄へ訂正して確認待ちと残します。

点検の抜けと部品検索の困りごとを別の要望として記します。各要望へ発言者、場面、優先順、確認日を置きます。

検索の分類は要望の中身を置き換えません。商談件数も要望の数だけ増やさず、一つの購買判断に含まれるかを確認します。

佐藤は今回先に扱う仕事を確認し、高橋は検索から原記録へ戻ります。未確認の提案仮説は顧客要望へ昇格させず残します。