Salesforce リードの取引開始を図解:取引先・取引先責任者・商談に何が起きるか

このページには広告リンクを含みます。

リードと商談の違いは「案件として追うかどうか」

リード(Lead)は、1件の中に会社の情報と人の情報が同居したオブジェクトです。名刺1枚を1レコードで持てるので、見極めの前の入り口に向いています。

商談(Opportunity)は金額やフェーズ、完了予定日を持つ案件のレコードです。取引先(Account)の下にぶら下がります。名刺を全部商談に入れると、案件ではないものがパイプラインに混ざり、売上予測の数字が信用できなくなります。編集部のおすすめは、次の条件をどれか満たしたらリードから商談へ進める、という基準を営業部と先に決めることです。

  • 相手の課題と予算の話ができた
  • 提案の場が決まった
  • 担当者が社内で検討すると言った

取引の開始で何が起きるか

リード1件が取引の開始によって取引先、取引先責任者、商談の3つへ分かれ、変換後のリードは参照のみで残る流れの図
取引の開始で、リード1件の情報が3つのレコードへ分かれる

押すだけに見えますが、裏では次のことが1回の処理で起きます。

対象 何が起きるか 選べること
取引先 新規作成、または既存の取引先へ統合 名前を入れるか、既存を選ぶ
取引先責任者 新規作成、または既存の取引先責任者へ統合 名前を入れるか、既存を選ぶ
商談 新規作成。Lightning Experience では既存の商談も選べる 既存の候補は最大20件まで表示
活動 3つのレコードに付く Sales Engagement のケイデンス由来は除く
キャンペーン メンバーは取引先責任者へ移る。直近のものが商談の主キャンペーンソースになる 既存の取引先責任者と重なれば、進んだほうのステータスが残る
リード本体 変換済みになり参照のみで残る 見るには「取引開始済みのリードの表示および編集」権限が要る

変換するユーザーには、リード・取引先・取引先責任者の作成と編集の権限と、「リードの取引開始」(Convert Leads)権限が必要です。商談を新規で作るなら商談の作成権限、既存の商談へつなぐなら編集権限も要ります。権限の組み方はプロファイルと権限セットの記事で扱っています。

API から変換する場合は、convertLead() の doNotCreateOpportunity で商談を作らない指定ができます。既定では商談が作られます。

標準項目の項目マッピング

標準項目は Salesforce が自動で対応づけます。主なものは次のとおりです。全体は公式の Lead Conversion Field Mapping にあります。

リードの項目 取引先 取引先責任者 商談
会社名 取引先名 取引先 商談名、取引先名
姓・名 なし 姓・名 なし
メール なし メール なし
電話 電話 電話 なし
住所 住所(請求先) 住所(郵送先) なし
リードソース 取引先ソース リードソース リードソース
リード所有者 所有者 所有者 所有者
業種 業種 なし なし
役職 なし 役職 なし
キャンペーン なし なし 主キャンペーンソース

注意したいのは、説明(Description)の行き先です。標準の対応では取引先責任者だけに入ります。リードの説明に案件の経緯を書く運用だと、商談を開いても見えません。案件の経緯は、商談へ対応づけたカスタム項目に書くか、活動として残すほうが確実です。

カスタム項目のマッピングの条件

設定には「アプリケーションのカスタマイズ」(Customize Application)権限が要ります。型の組み合わせには決まりがあります。

リード側の型 対応づけられる先 注意
チェックボックス、通貨、日付、メール、数値、電話、URL など 同じ型のみ 通貨・数値・パーセントは長さと小数桁も同じにする
テキスト、テキストエリア テキスト、テキストエリア、ロングテキスト、選択リスト 選択リストは値を制限していないものだけ
選択リスト テキスト、テキストエリア、値を制限していない選択リスト ロングテキストへは不可。長さが足りないと切れる
参照 同じオブジェクトを指す参照 別のオブジェクトを指す参照へは不可
自動採番 テキスト、テキストエリア
数式 対応づけない 公式が避けるよう書いている

ほかに次の決まりがあります。

  • 対応先は元の項目と同じ長さか、それより長くする。
  • 1つの対応先に指定できる元の項目は1つだけ。
  • 対応づけた項目を削除したり型を変えたりするときは、先に対応を外す。
  • リード・取引先・取引先責任者・商談の項目が合計2,000を超えると、マッピング画面が反応しなくなることがある。この場合は Metadata API などで管理する。

判断に迷うのは「どのオブジェクトへ送るか」です。編集部のおすすめは、変わらない情報は取引先、人に属する情報は取引先責任者、今回の案件に属する情報は商談、という分け方です。展示会名は今回の案件のきっかけなので、商談へ送ります。

既存の取引先へ統合すると空欄しか埋まらない

既存の取引先へ統合するとき、値が入っている項目はそのまま残り、空欄の項目だけリードの値で埋まることを示す図
既存レコードへ統合すると、埋まるのは空欄だけ

新規で作る取引先や取引先責任者には、リードの値が入ります。一方、既存を選ぶと動きが変わります。

  • 既存の値は上書きされない。空欄だけがリードの値で埋まる。
  • 住所は項目ごとに判定される。市区町村だけ空なら、そこだけ埋まる。
  • 州/国/テリトリー選択リストが有効な組織では、都道府県と国は、既存の取引先責任者の両方が空のときだけ移る。
  • メール送信除外(Email Opt Out)と電話連絡拒否(Do Not Call)は、既存の取引先責任者へは更新されない。

最後の点は、運用上の影響が大きい項目です。リードで「メール送信除外」にチェックした人を既存の取引先責任者へ統合すると、拒否の意思が移りません。統合のあとに確かめる手順か、別の更新の仕組みを用意してください。

一方で、変換時に新しい値で上書きしたい要件は、標準の動きではかないません。その場合は、リードの値を一度カスタム項目へ対応づけ、Flow で既存の項目へ書き込む方法を検討します。Flow の注意点はFlow の一括処理の記事を読んでください。

重複の扱いは Duplicate Management の設定で決まる

変換を始めると、標準項目の一致ルールによる候補が出ます。「変換」を押した時点で、カスタム項目の一致ルールによる候補がさらに出ることもあります。管理者は、重複の解消を終えないと変換を完了できないようにも設定できます。

ただし、カスタムの警告は変換中に表示されず、オブジェクトをまたぐ重複ルールは動きません。「リードと取引先責任者の重複ルールを作ったから安心」とは言えないので、ここは確かめてください。

取引の開始で踏みやすい設計の罠

入力規則で変換が止まる

変換中もトリガは動き、必須のカスタム項目と入力規則も効きます。たとえば商談に「金額は必須」という入力規則があるのに、リード側に対応づいた項目がなければ、変換はエラーになります。なお、[リードの設定] の [取引開始済みのリードに入力規則が必須](Require Validation for Converted Leads)を外すと、変換時に参照項目の検索条件は無視されます。

対策は3つあります。

  1. リードに同じ項目を持たせて対応づける。
  2. リードのチェックボックスを商談のカスタム項目へ対応づけて目印にし、入力規則の条件で除外する。
  3. 商談は変換のあとで入力してもらう運用に変え、入力規則をフェーズが進んだ時点の条件にする。

編集部のおすすめは3です。商談の必須項目をフェーズに合わせて増やすと、リードの項目を増やさずに済みます。保存時に何がどの順で動くかは実行順序の記事で確かめられます。

取引先責任者の役割に必須項目を足す

取引先責任者の役割(Opportunity Contact Role)に必須のカスタム項目を足すと、変換で商談を作れなくなります。リードとの間にマッピングがなく、値を入れる手段がないためです。

レコードタイプが意図とずれる

リードにレコードタイプがあっても、作られるレコードには変換するユーザーの既定のレコードタイプが付きます。取引先は全体の既定が使われます。インサイドセールスが変換すると、インサイドセールス用の商談レコードタイプになるわけです。変換後に Flow で直すか、既定の設定を見直してください。

リードソースの選択肢も、変換するユーザーの既定レコードタイプに左右されます。使いたい値がなければ、そのレコードタイプに値を追加します。

個人取引先を使う組織

Lightning Experience では、会社名が空のリードは個人取引先へ、値があるリードは法人取引先へ変換されます。個人向けと法人向けを扱う組織は、リードのレコードタイプとページレイアウトを分けて、法人側だけ会社名を必須にします。

活動とファイルの扱い

活動は3つのレコードに付きます。1か所で削除すると他からも消えます。所有者を変えて変換した場合、新しい所有者へ移るのは未完了の活動だけです。

メモ、キャンペーン履歴、マーケティングのアクションは新しい商談には移りません。商談から経緯を見たい運用なら、この点を事前に営業へ伝えてください。

大量の活動があるリード

活動が多いリードや、取引先・取引先責任者にトリガが多い組織では、Apex のガバナ制限に当たることがあります。一括変換を計画するなら、活動の多いレコードで先に試します。

現場の依頼から設計を考える

本番で使う前の確かめ方

取引の開始は元に戻せません。本番へ出す前に、Sandbox で次のパターンを試してください。

  • 全部新規で変換する
  • 既存の取引先へ統合する
  • 既存の取引先責任者へ統合し、値のある項目が残ることを見る
  • 既存の商談へつなぐ
  • 別の所有者を指定して変換し、活動の移り方を見る
  • 活動が多いリードを変換する

レポートで変換率を見るならカスタムレポートタイプの記事、データ全体の組み方は設計ガイドのハブを読むと、つながりが分かります。管理者の資格を目指す人は認定アドミニストレーターの勉強法もあわせてどうぞ。

よくある質問

Salesforce のリードと商談の違いは何ですか?
リードはまだ確度を見極めている見込み客で、商談は金額や完了予定日を持って追いかける案件です。Salesforce のリードは取引の開始を行うと、取引先、取引先責任者、商談へ分かれます。
取引の開始は取り消せますか?
取引の開始は元に戻せません。必要な場合は、できたレコードを手で直すことになるので、本番で使う前に Sandbox でマッピングと入力規則を試してください。
既存の取引先に取引の開始をすると、値は上書きされますか?
既存の取引先や取引先責任者の値は上書きされず、空欄の項目だけがリードの値で埋まります。リードの新しい電話番号を反映したい場合は、別の更新の仕組みが必要です。
リードのカスタム項目が取引の開始で引き継がれないのはなぜですか?
カスタム項目は自動では引き継がれません。リードの項目の画面にある [リードの項目の対応付け](Map Lead Fields)で、対応先の項目を指定します。対応先の型には決まりがあり、長さは元の項目と同じかそれ以上にします。
取引の開始がエラーで止まるのはなぜですか?
取引の開始でもトリガが動き、必須のカスタム項目と入力規則が効くためです。取引先や商談の入力規則に、リードから埋まらない項目が含まれていると止まります。