lead-routing

リードルーティング

すべてのインバウンドリードが、指名された担当者に割り当てられ、その担当者に受け入れられるための割り当てロジックを設計します。この分野に業界公認のフレームワークはありませんが、実務担当者の間では、順序付きの優先順位リスト（ルールウォーターフォールとも呼ばれます）を上から評価し、最初に一致したルールを適用し、監視対象の最終受け皿で終了するという事実上のパターンに、独立して収束しています。ブランド化された方法論ではなく、一般的な慣行として提示してください。

ルーティングと割り当ては同じではありません。

• 割り当て： CRM のオーナーフィールドへの書き込みです。
• ルーティング： リードの取り込みから、担当者が責任を引き受けるまでの一連の流れです。あるいは、タイマーとエスカレーション経路を備えた、可視性のある例外をシステムが発生させるまでを指します。

ルーティングの失敗の多くは、表面化しません。

• ルールは実行される
• ダッシュボードには緑色で表示される
• リードは、誰も所有していないキューで未対応のままになる

ここでは、リードスコアは設計目標ではなく、厳密に入力として扱います。ユーザーがすでに持っているスコアを次のように利用してください。

• 優先順位付けのシグナル：対応可能なリードのうち、どれから先に対応するかを決める
• 適格性のゲート：しきい値を超えたリードだけをルーティングする

スコアリングモデル自体の設計や調整は行わないでください。これは兄弟スキルの mbfinotti/revops-skills@lead-scoring が担当します。

ヒアリング

• 何かを設計する前に質問してください。

• 1 回のメッセージで質問は 1 つにしてください。

• 可能な場合は、選択肢を提示してください。

• ユーザーがすでに回答している質問は省略してください。

• リードは何によって作成され、どの取り込み経路を通りますか？ウェブフォーム、API、リストのインポート、チャット、スケジューリングツール、CRM 同期、手動入力などです。

• 取り込み時に、どのリード属性が安定して入力されていますか（国、企業規模、業界、メールドメインなど）？空欄になりがちなものはどれですか？

• チームの構成はどうなっていますか？担当者は何人で、どのプール（SDR、AE、セグメント別チーム、専門担当者など）に所属し、どのような専門性を持っていますか？

• 対応時間とタイムゾーンはどうなっていますか？営業時間外や週末のインバウンドリードはありますか？

• 営業モデルは B2B のアカウントベース、B2C／大量処理、PLG のセルフサービス、それとも混合型ですか？月あたりのリード数はおおよそどのくらいですか？

• 指名アカウントリスト、パートナー経由の案件登録、既存顧客の除外ルールはありますか？それらはどこかでバージョン管理されていますか？

• このチームにとって「公平」な配分とは何ですか？均等な順番、未対応案件数の均等化、立ち上がり期間や勤続期間に応じた比例配分、または案件価値の機会均等ですか？

• 現在、対応 SLA はありますか（ある場合）？測定されていますか？

• コンプライアンス上の制約はありますか？データの保存場所、同意要件、規制対象の業種などです。

• 入力として利用できるリードスコアはありますか？そのスコアは何を意味し、信頼できるものですか？

• 新しいルーティングをいつまでに稼働させる必要がありますか？その日付は確定ですか、それとも目標ですか？

• 今日発生している誤ルーティングを一度だけ修正したいですか？それともチームの成長後も機能し続ける配分システムが必要ですか？

• 工数の上限はどのくらいですか？利用可能な管理者の作業時間、日常的に CRM を管理する担当者の有無、定期的なガバナンスプロセス（ウェイトの見直し、テリトリーの変更など）をチームが実施するかどうかを教えてください。

最後の 3 つの回答は、タイムラインだけでなく、このスキルでの選択肢の順位にも影響します。提案する前に、それらを踏まえて順位を付け直してください。どの回答がどの選択肢を左右するかは「配分のバリエーション」を参照してください。

ワークフロー

1. インタビューを実施し、ルールを提案する前に、設計に必要な回答を収集します。

2. ルールに手を加える前に計測を整備します。各段階のタイムスタンプ（captured、eligible、decision、assigned、notified、accepted、first action）を記録します。これらがなければ、ルーティング変更が機能したことを証明できません。

3. 振り分けの前に、リードとアカウントの照合を修正します。アカウントドメインのフィールドを標準化します。まずメールドメインで照合し、次に会社名のあいまい一致を使います。一致率が約90％未満、または重複率が約5％を超える場合、ルールが実行される前にリードが漏れてしまいます。まずデータをクリーンアップします。

4. 優先順位の階層（次のセクション）を、最も具体的なものから最も一般的なものへと上から順に記述し、ドキュメントとしてバージョン管理します。適格性の階層では、誰がリードを担当できるかを決めます。振り分けでは、適格な候補者の中から担当者を選ぶだけです。

5. まずチームにとっての「公平」の定義を書き出し、チームの回答が実際に裏付ける最も上位の段階を選んで、振り分け方式を決めます。デフォルトは段階1の、対応可能か確認する単純な順次ローテーションです（「振り分けの方式」を参照）。

6. キャッチオールを、実際に機能する状態として設計します。以下を備えた、監視対象のトリアージキューです。

   • 担当者を明確に指定する
   • 当日中のSLAを設定する
   • 定期的に発生する例外をルールに変換する週次レビューを行う

   ここで設計し、最初にリリースします。「優先順位の階層」にある構築順序の最上位に置き、すべてのルールより先に対応します。

7. 承諾のタイマーを追加します。リードが割り当てられてからN分以内に承諾も対応もされない場合、記録された理由コードとともに、指定されたバックアップ担当者へ再ルーティングします。判定結果とCRMへの書き込み結果は別々のフィールドに保持し、書き込みに失敗したケースと、ルールに一致しなかったケースを区別できるようにします。

8. ルーティングマトリクス（条件 → 担当者 → SLA、優先順位順）と、すべてのルール、重複条件、取り込み経路を網羅する合成テストパックを作成します。references/precedence-ladder-example.md と references/test-pack-and-rollout.md を参照してください。

9. テストパックを使ってサンドボックスでテストします。可能であれば、過去の実際のリードを再生します。その後、日次の照合とロールバック計画を用意して、カナリアセグメントを通じて展開します。シャドーモードは、カナリアでは影響を抑えられない変更に限って使用します（順位については references/test-pack-and-rollout.md を参照）。割り当てに影響するロジックを本番環境で直接編集してはいけません。

10. 下記の「測定」の合格基準に照らして検証します。すべての基準を満たすまで、ルール、照合、またはカバレッジを改善します。完成した設計をセクションごとにユーザーへ提示し、承認を得ます。

    • ルーティングマトリクス
    • テストパック
    • 監視計画

11. ハーネスに永続メモリがある場合は、承認済みの階層、公平性の定義、基準を記憶させます。後の変更依頼では、インタビューをやり直さず、それらを出発点にします。

優先順位

ルールは上から順に並べ、最初に一致したものを適用します。ユーザーが実際に持つ情報に合わせた、妥当なデフォルトの順序は次のとおりです。

1. 法務・規制・契約上の優先事項 — データの保管場所、同意に関する制約、契約上のパートナーの権利。決定論的かつバージョン管理され、推測で補われることはありません。
2. バージョン管理されたリストに基づく、指定アカウントまたは戦略的アカウントの担当権。
3. 一致したアカウントに関する進行中の商談、または進行中の営業プロセス。
4. 既存アカウントと階層の担当権 — 次のローテーション担当者ではなく、関係性を築いている担当者にルーティングします。
5. テリトリーの境界 — チームが採用している組み合わせによる、地域、セグメント、業界。
6. 製品、スキル、言語の適格性。
7. キャパシティと対応可能状況 — 未対応リードの上限、休暇、営業時間。
8. 公平な割り当て — ティア1〜7で形成された対象プール内で、選択した配分方式を適用します。
9. 統制された例外 — 監視対象のキャッチオール・トリアージキュー。

構造上のルールが2つあります。

• ティア1〜6で適格性を定義し、ティア7〜8ではその範囲内でのみ配分します。この2つを混同すると、エンタープライズ向けリードがSMB担当者に割り当てられてしまいます。
• 階層間で担当権が競合する場合（一致した子会社の親会社を別の担当者が担当している場合）は、滞留時間の計測機能を備えた、人が管理する競合キューにルーティングします。自動ルールには決して任せません。

この一覧は、意図的に効率性の順には並べておらず、効率性を理由に並べ替えることもありません。これは評価順序、つまり最も具体的なものから順に照合し、最初に一致したものを適用するための順序です。したがって、効率性を基準に並べ替えると、どのルールを先に作るかではなく、どのルールが適用されるかが変わります。

構築順序は効率性によって決まり、上記とは異なる順序になります。

• 効率性（構築順序）：ティア9のキャッチオール > ティア4の既存アカウント担当権 > ティア5のテリトリー > ティア6の製品・スキル・言語 > ティア7〜8の配分

• 工数（構築順序）：ティア5のテリトリー（1週間、その後は定期的なジョブ） > ティア6（1週間に加えて、担当者ごとのスキルフィールド） > ティア4（一致率を条件として1〜2日） > ティア7〜8（「配分方式のバリエーション」を参照） > ティア9（1時間）

• ティア9のキャッチオールを最初に： 1時間の作業で、通知されずに消えるリードをすべて可視化された例外にできます。また、他のティアを測定可能にする唯一のティアです。

• 次にティア4の既存アカウント担当権： 既存顧客が、これまで一度も話したことのない担当者に渡されるという、最も深刻な誤ルーティングを防ぎます。ただし、一致率が90％を下回る場合は効果がないため、まず照合を改善してください。

• ランキングの対象外であるティア1〜3： 法務上の優先事項、指定アカウント、進行中の商談は譲れない条件であるため、その割合で判断が変わることはありません。

配分方式のバリエーション：順位付け

ラウンドロビンはアルゴリズムの総称であり、それぞれ「公平」の定義が異なります。

よくある設定ミスは次のとおりです。

1. チームが考える公平性の定義に合わない方式を選ぶ
2. 最も複雑な方式を選ぶ

実際に得られる成果、つまりリードへの対応速度と担当者が感じる公平性（アルゴリズムが主張する公平性ではありません）を、コストと照らして順位付けします。

• 管理者による設定時間

• ルールに必要な継続的なガバナンス

• CRMにあらかじめ備わっている必要があるフィールド

• 担当者がルールに慣れた後、元に戻す難しさ

• 効率性：対応可能状況を確認する通常ローテーション > キャパシティベース > 加重方式 > 多層スタック

• 価値：多層スタック > キャパシティベース > 対応可能状況を確認する通常ローテーション > 加重方式

• 工数：多層スタック > 加重方式 > キャパシティベース > 対応可能状況の確認 == 通常ローテーション

• コンプライアンスコスト：加重方式 == 多層スタック > キャパシティベース == 対応可能状況の確認 == 通常ローテーション

• 通常ローテーションと対応可能状況の確認は、工数が同じです： どちらも、チームがすでに管理しているデータ（ローテーションリストと、チームがすでに信頼している休暇カレンダー）に対する純粋な設定であり、新しいフィールドも継続的な管理責任者も必要ありません。

• 加重方式と多層スタックは、コンプライアンスコストが同じです： どちらも、意図的に一部の担当者へ他の担当者より多くのインバウンドリードを割り当てます。これは収益を得る機会に影響するため、導入前に営業リーダーシップと報酬担当者の承認が必要です。また、担当者が自分の加重値を把握した後は、気付かれない形で元に戻すことはできません。

他の3つの方式には、このようなリスクはありません。 ランク1 - 稼働状況を確認する単純な順番制（デフォルト）。 順番が次の担当者に割り当てます。休暇中または営業時間外の担当者は飛ばします。公平とは、実際に対応可能な人の間で順番を均等に回すことです。

• 得られるもの: ここで実現できる最大の単一のスピード・トゥ・リード改善です。不在の担当者にリードを割り当てることがなくなります。これは、単に配分が偏るのではなく、リードを完全に失う原因となる問題です。
• 必要なもの: 順番制の運用負荷はほぼゼロ、稼働状況の確認に約1時間、常設の責任者は不要です。
• うまくいかない場合: 順番は均等でも未対応リードの件数が大きく偏る場合、またはカレンダー上の在席状況を営業対応能力と取り違える場合です。
• 低コストの改善: 未対応リード件数をすでに把握できるなら、件数が上限を超えた担当者を飛ばすハードキャップを追加します。負荷はほぼゼロで、常設の調整役を置かずにランク2の保護効果の大半を得られます。

ランク2 - 対応可能数に基づく配分（稼働状況の確認は継続）。 未対応リードが最も少ない担当者に次のリードを割り当てます。公平とは、未対応業務の負荷を均等にすることです。

• 得られるもの: 順番ではなく業務負荷で偏りを測れます。また、誰にも気づかれないままリードを抱え込んでいる担当者の負担を目に見える形で軽減できます。
• 必要なもの: CRM で管理する未対応リード項目、「未対応リード」に何を含めるかを合意するための約1週間、そしてリードがいつ未対応ではなくなるのかを判断する常設の調整役です。
• うまくいかない場合: 「リード」ごとに必要な労力が大きく異なり、順番制の場合と同じように、件数を均等にしても業務量の不均衡が隠れてしまう場合です。

ランク3 - 重み付け順番制。 重み2の担当者は、重み1の担当者のおよそ2倍のリードを受け取ります。公平とは、立ち上がり期間、勤続年数、または役割に応じて配分することです。

• 得られるもの: 立ち上がり中の担当者やパートタイムの担当者を保護できます。ただし、実際に誰かが立ち上がり中である期間に限られる、限定的な効果です。
• 必要なもの: 重みの設定、根拠、見直し時期を定める常設の重み管理プロセスと、前述の報酬プラン承認です。
• うまくいかない場合: 見直しの責任者が不在で、昨年の立ち上がり時の重み付けが、検証されないままパフォーマンス評価として使われ続ける場合です。

ランク4 - 完全な多層構成。 対象条件でプールを絞り込み、対応可能数または重み付けをベースに配分し、その上に稼働状況の確認を重ねます。公平とは、すべての定義を同時に満たすことです。

• 得られるもの: 4つの選択肢の中で最も優れた成果であり、2つの公平性の定義を同時に採用しているチームの要件を満たせる唯一の選択肢です。
• 必要なもの: 3つすべてのコストに加え、それらの相互作用への対応も必要です。常設の業務が発生し、ここで最も元に戻しにくい選択肢です。
• うまくいかない場合: 特定のリードがなぜその担当者に割り当てられたのか、誰も一言で説明できない場合です。その時点で、チームは安全に設定を元に戻すこともできません。

現在のランクの失敗条件がカナリアデータで確認された場合に限り、一度に1ランクだけ上げます。事前に見越して上げてはいけません。

• 未対応リードの滞留が続いたら、ランク1からランク2に上げます。
• 本当に立ち上がり中の担当者グループが生まれたら、ランク2からランク3に上げます。

この順序で選ばれにくいもの。 ランク4はどのラウンドでも負けます。価値が最も高い一方、常設コストも最も高いため、比率による選択では選ばれません。

次の3つをすべて満たす場合は、それでもランク4に上げます。

• CRM の日常的な運用を担う人がいる
• 経済性が実質的に異なるプールが複数ある
• 公平性をめぐる争いがすでに表面化している

ランク4を導入した担当者3人のチームは、変更できないシステムを構築したことになります。

格下げではなく、削除します。

• 未対応リード項目がなく、追加する意向もない CRM では、ランク2を完全に削除し、それに伴ってランク4も削除します。格下げした選択肢は、3か月後にスコープとしてひそかに再浮上します。
• 重み管理の責任者がいない場合は、ランク3を削除します。
• 稼働状況のデータがない場合は例外です。これは何も削除しません。最初に構築すべきなのは稼働状況のデータ源であり、その不在を前提に選んだ順番制のバリエーションではないからです。

回答に基づいて順位を付け直します。

• 期限が厳しい場合はランク1を上げ、ランク4を削除します。期限までに常設プロセスを立ち上げることはできません。

• 将来にわたって資産を蓄積することが求められる場合は、ランク2を上げます。業務負荷の項目はチームの成長に伴って役立ちますが、順番リストにはその効果がありません。

• 「常設の業務」未満の労力上限がある場合は、ランク3とランク4を一度に削除します。 この順序はデフォルトであり、絶対的なルールではありません。状況や実行する人によって変わるため、何かを提案する前に、このユーザーについてすでに分かっている情報をすべて踏まえて順位を付け直してください。

• CRMをフルタイムで担当する管理者がいれば、段階4が実行可能な選択肢になります。

• 同じタイムゾーンにいる営業担当者が3人なら、偏りは自然に是正され、段階2～4は不要になります。

• 既存のテリトリーモデルですでに適格性を絞り込めている場合は、どのような配分方法を追加しても効果が小さくなります。

B2BとB2C／大量処理／PLG

段階構成、キャッチオールの設計、テスト方法、測定方法は、どちらの営業形態でも同じです。異なるのはルーティングキーとカバレッジモデルです。

• B2Bのアカウントベース：まずアカウントの担当者に基づいてルーティングします。同じアカウントのすべてのコンタクトは、1人の担当者に割り当てます。購買委員会が3件のフォームを送信しても、3人の営業担当者に分散させてはいけません。指名アカウントの例外措置と、パートナー案件登録の保護期間は、必ず優先されるルールとして適用します。ターゲットアカウントに対する24時間のSLAは、実務でよく使われる初期設定です。
• B2C／大量処理／PLG：地域、言語、対応時間に基づいてルーティングします。プロダクト適格シグナル（利用しきい値への到達、チームメイトの招待など）は、トリガー発生から24～48時間以内にルーティングし、単なるスコアではなく、その元となるシグナルを営業担当者に渡します。カバレッジモデル自体は、以下の優先順位で選択します。
• 混合型の営業形態：1つの段階構成の中で両方の分岐を運用します。まずアカウントベースの段階を配置し、その下に全般的なプールとして大量処理向けの配分を配置します。

大量処理向けのカバレッジ方式：

• 効率：タッチ不要の下限設定 ＞ シフト制プール ＞ スキルベースのキュー ＞ 追跡型の時間帯カバレッジ

• 工数：追跡型の時間帯カバレッジ（四半期単位の取り組みであり、採用判断が必要）＞ スキルベースのキュー（1週間で構築し、その後は常設のスキルマトリックスを維持）＞ シフト制プール（チームがすでに管理している勤務表を使い、1時間で構築）＞ タッチ不要の下限設定（ほぼゼロ）

• まず、タッチ不要の下限設定：価値の低いセルフサービスのセグメントを営業対象から完全に除外する適格性ルールを1つ設けることが、大量処理向け設計の中で最も費用対効果の高い施策です。追加するのは段階1つだけですが、その下にあるすべてのルールの処理量を減らせるため、後続のどの方式も導入しやすくなります。

• 次に、シフト制プール：既存の勤務表を使って、営業時間内の対応を確保します。

• スキルベースのキュー：言語や製品に関する要件によって対応できる担当者が実際に制限される場合にのみ導入し、各営業担当者のスキルを示すフィールドを用意して、最新の状態に保つ必要があります。

チームに対象地域外の人員がいない場合は、追跡型の時間帯カバレッジを完全に削除してください。これはルーティングルールの形をした採用判断であり、順位を下げると「段階的に導入しよう」という話にされかねません。同じギャップは、即時自動応答付きの営業時間外キュー（段階7）でほぼゼロのコストでカバーできます。代わりに構築するのはこちらです。

失敗パターンと修正方法

意図的に順位付けはしていません。実際に観測された症状を修正してください。症状に応じた修正を比率で順位付けするのは、精度を装うだけです。

症状が現れる前に用意する例外が2つあります。設計上、症状が見えないためです。

• ソースごとの無信号アラート
• null の割り当てに対するハードフェイル分岐

症状	考えられる原因	修正
取り込み経路によって担当者が異なる	ある経路が割り当てルールを迂回している（API で作成されたレコードでよく発生します）	同一の合成パックをすべての経路に通し、割り当てが null の場合に担当者へ通知するハードフェイル分岐を追加します
リードが誤ったルールに一致する	時間の経過とともに条件が重複し、先にあるエントリが暗黙的に優先される	重複する条件を監査して統合し、ルールセットをバージョン管理します。2つのルールが一致した事案の後は、優先順位を再文書化します
空欄のフィールドでルールが誤った振り分けを行う	テリトリー／セグメントのデータが古い、または空です	振り分け前に検証または補完し、ハードタイムアウトと明示的なフィールド欠損時の分岐を設けます。誤った振り分けを黙って行わないでください
不在の担当者にリードが割り当てられる	PTO／祝日のスキップロジックがありません。プラットフォームによっては、稼働状況を設定したことのない担当者を常時対応可能として扱います	稼働状況に応じたローテーション、カバレッジプール、既知の期間に適用する専用の祝日ルールを用意します
週末／営業時間外のリードが放置される	タイムゾーンや営業時間を考慮した分岐がありません	フォロー・ザ・サン方式のプール、または次の営業時間開始までのSLAと即時の自動確認応答を設定した営業時間外キューを用意します
担当者が公平性に異議を唱える	件数が同じでもリードの価値が異なる、または（より多く割り当てられるよう即座にクローズするなどの）不正が行われている	透明性の高い割り当てログを用意し、スコアの高いリードは標準プールとは別に配分します。不正のパターンを監視します
キャッチオールに気付かないうちに案件が蓄積する	手動のオーバーフローレビューが行われていません	担当者を明確にし、当日中のSLAを設け、実効性のある週次レビューを実施します。繰り返し発生する例外の種類は新しいルールにします
ダッシュボードは緑色なのにパイプラインにデータがない	ソースからのデータ送信が止まってもアラートが発生しません	ソースごとの量を監視し、エラーだけでなく無信号もアラート対象にします

測定指標と合格基準

スピード・トゥ・リードを、捕捉 → 適格判定 → 意思決定 → 割り当て → 通知 → 受諾 → 初回アクションという一連の時間として分解します。受諾ギャップ（受諾から割り当てを差し引いた時間）を報告します。これは、キューでの滞留や通知の失敗が隠れている区間です。

併せて、以下も追跡します。

• 一度も対応されていないリードの件数
• 担当者ごとの分布の偏り
• リードとアカウントのマッチ率
• 受け皿キューのボリュームと滞留時間

リリース前に、以下のすべての基準を満たす必要があります。満たすまで反復してください。

• インバウンドボリュームに対するリードとアカウントのマッチ率が90％以上であること。これを下回る場合は、分配に進む前にマッチングに戻ります。
• すべての取り込み経路が少なくとも1つのテストケースでカバーされ、同一の合成レコードがすべての経路で同一の担当者に割り当てられること。
• 監視されていないキューがゼロであること。受け皿キュー（および競合キューがあればそのキュー）には、担当者、SLA、定期レビューが設定されている必要があります。
• カナリア期間中、受諾SLAを超えてキューに残るリードがゼロであり、ソースごとのボリューム監視と、データ受信が途絶えた際のアラートが稼働していること。
• チームの公平性の定義で許容される範囲内に分配の偏りが収まっていること。アルゴリズムの選択から推測するのではなく、カナリア期間を通じて検証します。

応答SLAは、ユーザー自身の応答時間別コンバージョン履歴がある場合、それに基づいて設定します。有名な緊急性に関する統計（5分／21倍／100倍という数値）は、電話が主流だった時代の2007年のInsideSales/MITの調査と、2011年のHBRによる監査に由来し、広く誤って引用されています。また、示しているのは緊急性であり、ルーティングの投資対効果ではありません。関係者に数値を提示する前に、references/speed-to-lead-evidence.mdを参照してください。

任意のインテグレーションに関する注記

ユーザーが以下のプラットフォームのいずれかを指定していない場合、このセクションは省略してください。

• Salesforce： オブジェクトごとに有効にできるリード割り当てルールは1つで、エントリは上から順に評価され、最初に一致したものが適用されます。APIで作成されたリードには、割り当てルールのヘッダーが設定されていない限り、ルールは適用されません。また、標準のテリトリー管理はリードやラウンドロビンには対応していません。
• HubSpot： ローテーションの公平性は全体の所有状況ではなく、ローテーションの実行ごとにカウントされるため、個別には公平な2つのワークフローでも、合計では偏りが生じることがあります。担当者を追加または削除すると、ローテーションがリセットされます。
• Dynamics 365： 稼働可能時間を一度も設定しない営業担当者は、常に対応可能として扱われ、気づかれないままフォールバック先になります。

参考資料

• 優先順位の階層とルーティングマトリックス（B2BおよびPLGのバリエーション）、および否定的な例については、references/precedence-ladder-example.mdを参照してください。
• 合成テストパックのテンプレートと、サンドボックス → シャドー → カナリアのロールアウト手順については、references/test-pack-and-rollout.mdを参照してください。
• 出典、発行年、信頼性に関する注記を含む、引用可能なスピード・トゥ・リードおよびマッチングの統計については、references/speed-to-lead-evidence.mdを参照してください。
• mbfinotti/revops-skills@crm-data-governance：ルーティングで参照するフィールドの所有権と信頼できる情報源のルール。