Claudeでアップセル・クロスセル候補を洗い出す手順

既存顧客へのアップセル(上位プランへの切り替え)とクロスセル(別の製品の追加)の候補は、Salesforceを接続したClaudeに「誰が何を買っていて、何がまだ買われていないか」を突き合わせさせると、短時間で一覧にできます。要は3段階です。対象の取引先を絞り、購入済みの品目と照らして空白を見つけ、更新時期や直近の動きで優先順位を付けます。

最終的にどの顧客へ提案するかを決めるのは営業担当です。Claudeが担うのは、Salesforceに入っているレコードを横断して読み、根拠つきの叩き台を作るところまでです。

Salesforceにつなぐ経路は2通りある

候補出しには、Claudeから顧客・商談データを読める状態が前提です。経路は大きく2つあります。

プラグインは、Salesforceが作った37個の営業スキルと、SalesforceおよびSlackのコネクタを一式にしたものです。使い始めるまでに、3者が順番に作業します。

プラグインの画面は、管理者とメンバーで入口が違います。自分の権限で見えるほうを探します。カスタムコネクタでつなぐ手順はClaudeとSalesforceを連携する方法にまとめています。

どちらの経路でも、Claudeはユーザー本人のSalesforceアカウントでサインインします。見えるのは、そのユーザーの既存の権限で許されたデータだけです。担当外の取引先が結果に出てこないのは、不具合ではなく権限どおりの動きです。

候補出しに使うデータを先に棚卸しする

アップセルとクロスセルの分析は、材料が足りないと成立しません。最低限、次の3種類が要ります。

• 取引先(Account): 業種、規模、担当者など顧客の属性
• 受注済みの商談(Opportunity): 何をいつ買ってもらったか
• 購入品目の情報: 商談に紐づく商品明細や、自社で作った契約・サブスクリプション用のオブジェクト

3つ目は組織ごとに設計が違います。Salesforceの標準MCPサーバーのうちSObject Readsは、読み取りとクエリだけを行います。変更系のツールを持たないので、候補出しの入口に向きます。ただし購入品目がどのオブジェクトにあるかは組織しだいなので、最初の一手は分析ではなく棚卸しです。

私が閲覧できるSalesforceのオブジェクトのうち、取引先・受注済み商談・
購入品目・契約に関係しそうなものを列挙してください。
それぞれについて、分析に使えそうな項目名と、直近1件のサンプルを見せてください。

この結果で、購入履歴がどのオブジェクトに入っているかが分かります。契約や請求のデータがSalesforceの外にある会社では、ここで「Salesforceだけでは購入品目が追えない」と判明することもあります。その場合は、購入履歴を別のデータとして用意するか、統合顧客データを引ける仕組みがあるかを先に確かめます。

分析の入口にするMCPサーバーを選ぶ

Salesforceの標準MCPサーバーは、種類ごとに持つツールが決まっています。候補出しで関わるのは次の5つです。

標準サーバーは既定で無効で、管理者が有効にします。ツールの構成は変えられません。どのサーバーでもユーザー単位で認証し、項目レベルのセキュリティ・オブジェクト権限・共有ルールが全ツール呼び出しに適用されます。権限で見えない項目は、手順4で「データなし」になる原因の一つです。

標準のツールで足りないときは、Apex Invocable Actions・Flows・Named Queriesなどを自組織のMCPツールとして公開する方法もあります。購入品目の集計の仕方を固定したい組織では、この方法が選択肢になります。

5ステップで候補リストを作る

棚卸しが済んだら、対象の絞り込み、購入済み品目の一覧化、空白の洗い出し、優先順位付け、根拠つきの表づくりの順に指示します。1回で全部を頼まず、途中の結果を確認しながら進めるほうが、根拠の追える一覧になります。

手順1: 対象の取引先を絞る

全取引先を一度に見ると、結果が粗くなります。担当範囲や期間で切ってから始めます。

私が担当する取引先のうち、過去2年以内に受注済みの商談がある取引先を
一覧にしてください。取引先名・業種・直近の受注日・受注金額の合計を
列にして、受注金額の大きい順に並べてください。

手順2: 取引先ごとに購入済みの品目を出す

対象が決まったら、何を買ってもらっているかを取引先ごとに並べます。この段階で「品目の名前が商談ごとに揺れている」といったデータ上の問題が見つかります。

上の取引先それぞれについて、これまでに購入された品目を一覧にしてください。
品目名の表記が揺れている場合は、同じものと判断した根拠を添えて統合案を出してください。

手順3: 買われていない品目を洗い出す

ここが候補出しの中心です。アップセルとクロスセルで見る角度が違います。

品目Aを購入済みで、品目Bを購入していない取引先を挙げてください。
業種と規模が近く、すでに品目Bも買っている取引先が
何社あるかを並べて示してください。

ここでの「近い顧客が買っている」は、あくまで社内データ上の共通点です。そのまま需要の証拠にはなりません。次の手順で、個別の事情を足していきます。

手順4: 優先順位を付けるシグナルを足す

空白が見つかっただけでは、どの顧客から当たるかは決まりません。優先度を分けるのは、次のようなシグナルです。

手順3の候補それぞれについて、次の3点を確認して表に足してください。
・契約の更新予定日
・その取引先に紐づくオープン中の商談の有無と担当者
・直近の活動日(最終更新日でも可)
確認できなかった項目は、空欄にせず「データなし」と書いてください。

手順5: 根拠つきの表にまとめる

最後に、そのまま営業会議に持ち込める形に整えます。列は決め打ちで指定します。

次の列の表にまとめてください。
取引先 / 購入済み品目 / 候補の品目 / アップセルかクロスセルか /
根拠(参照したレコードの種類と日付)/ 優先度(高・中・低とその理由)/
確認が必要なデータ
根拠の列には、取得したレコードに基づく事実だけを書き、
推測は「推測」と明記してください。

「根拠は取得した事実だけ、推測は明記」という指定を入れると、事実と推測が列の上で分かれます。根拠の列があれば、担当者が該当レコードを開いて裏を取れます。

候補を商談前の下調べにつなげる

表ができたら、優先度の高い数社だけを選んで個別に掘り下げます。一覧の段階では見えなかった経緯が、ここで出てきます。

候補の上位3社について、過去の商談の経緯を時系列で整理してください。
・失注や保留になった提案があれば、その時期と理由の記載
・担当者の異動や体制変更を示すレコード
・今回の候補品目と、過去の提案内容が重なっているか

過去に同じ品目を提案して見送られていた顧客は、候補の表だけ見ると有望に映ります。経緯を読んでから当たるかどうかを決めると、二度目の提案が空振りに終わるのを避けやすくなります。CRMの商談準備にClaudeを使う流れはClaudeで商談準備をCRM連携で効率化する方法にもあります。

繰り返し使うなら指示を型にしておく

毎月同じ切り口で候補を出すなら、上の指定をプロジェクトの指示文などに置いておくと、担当者ごとの出力がそろいます。例えば次のような内容です(自組織のオブジェクト名に合わせて書き換えます)。

# アップセル・クロスセル候補の出し方
- 根拠にしてよいのは、Salesforceから取得したレコードの内容だけ
- 表の列は「取引先 / 購入済み品目 / 候補 / 種別 / 根拠 / 優先度 / 要確認」
- 取得できなかった項目は「データなし」と書く。補完しない
- Salesforceのレコードを更新する提案は、更新内容を先に示してから確認を取る

この指示文は、Claudeに何度同じ質問をしても集計の範囲が揺れにくくすることを狙った書き方です。期間を「今期」のような相対表現にせず日付で書くのも、同じ狙いです。

プラグインのスキルで補える場面

Salesforce in Claudeプラグインを使える組織なら、候補出しの前後を営業スキルが補います。公式の例には次のものがあります。

• 更新準備: 更新が近い顧客について、Salesforce・カレンダー・メールをもとに概要をまとめる
• パイプライン確認: 商談のパイプラインをカバレッジ目標と照らし、注意が要る商談を見る
• 四半期ビジネスレビュー(QBR)資料: 取引先データから資料の下書きを作る
• 会議のフォローアップ: 通話の文字起こしやメモから、フォローアップのメールとSalesforceへの更新案を作る

「30日以上触れていない自分の取引先を見せて」といった問いも、公式が挙げる使い方の一つです。手順4の「接点が途切れている顧客」に、そのまま使えます。

候補が固まったあとの流れは、更新準備のスキルで顧客ごとの概要を作り、QBR資料の下書きに提案の材料を載せる形が自然です。商談の停滞や失注の側から見直したいときは、Salesforce商談分析をClaudeに任せる方法とCoworkで営業の失注分析を進める方法が対になる内容です。

Salesforceへの書き戻しは承認制

候補リストをSalesforceに残したい場合、たとえば商談やタスクの作成をClaudeに頼むことがあります。プラグインでは既定で、Claudeが変更を書き込む前にその内容を見せ、「Allow once」「Always allow」「Deny」のいずれかを選ぶ形です。

候補出しの段階は「Allow once」で1件ずつ確認しておくのが無難です。「Always allow」は名前のとおり承認を省く選択肢なので、一覧の質が安定してから検討します。読み取りだけで足りる分析なら、SObject Readsに限定する構成もあります。書き戻しを許したいが削除は許したくない場合は、作成と更新だけを扱い削除のないSObject Mutationsというサーバーもあります。

出てきた候補が外れるときの原因

候補が現場の感覚とずれるときは、Claudeの指示より先にデータ側を疑います。

• 購入品目の粒度がばらばら: 商談ごとに品目名の表記が違うと、「買っていない」の判定が狂います。手順2の統合案で確認します。
• 契約の終了日が更新されていない: 実際は解約済みの顧客が「更新間近」として上位に出ます。
• 別システムで契約している: Salesforceに購入履歴がなく、空白に見えても実は購入済みの場合があります。
• 権限の範囲: 接続したユーザーが見られない取引先は分析に含まれません。チーム全体を分析したいときは、必要な閲覧権限を持つ担当者の名前で実行します。

まとめ

購入履歴がSalesforceのどこにあるかで、この手順の成否はほぼ決まります。購入品目が外部の契約システムにある組織では、候補出しの前に、購入データをClaudeが読める場所へ置くところから始めることになります。