mcpField
D
deal-red-flags

deal-red-flags

github.com/mbfinottiマーケティング・グロース327.7k 回インストール2 日前に更新
リポジトリ

deal-red-flags について

営業担当者向けに、通話メモ、CRMの自由記述、メールなど単一案件の記録を確認し、根拠とともに案件適格性のリスクを示すスキルです。深刻度と確信度を別々に評価し、記録に記載がない場合は問題と決めつけず「不明」とします。

主な機能

  1. 01単一案件の記録レビュー
  2. 02所見ごとの原文引用
  3. 03深刻度と確信度の個別評価
  4. 04記載なしを不明として扱う
  5. 05反証となる情報の確認
  6. 06ギャップごとに診断質問を1つ提示

活用シーン

  1. 01予測会議前の通話メモ確認
  2. 02CRM記録にある未解決の適格性ギャップの発見
  3. 03買い手の発言と営業担当者の推測の区別
  4. 04案件の次のフォローアップ質問の選定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mbfinotti/sales-skills --skill deal-red-flags

インストール後、Claude Code で/deal-red-flagsを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

evals/
evals.json
references/
example-review.md
red-flag-catalog.md

詳細

商談の警戒サイン

1件の商談に関する記録(通話メモ、商談レコードのテキストフィールド、CRMのアクティビティログ、メールのやり取り)を確認し、各項目の根拠となる証拠とともに、商談の評価に関する警戒サインを示します。自由記述のメモは情報が抜け落ちやすいため、メモに記載がないことは、問題が確認されたことと同じではありません。

各警戒サインは、決して1つのスコアにまとめず、独立した2つの軸で評価します。

  • 重大度:リスクが現実のものだった場合、この商談にどれほどの損害をもたらすか。
  • 確信度:メモがそのリスクをどの程度裏付けているか。

重大度は高いものの証拠が不十分なギャップは、重大度は低くても確実なギャップとは異なる方法でエスカレーションします。最も一般的で有用な判定は「不明」です。メモにはどちらとも書かれていない、という意味です。不明な項目を次の通話での質問に変えられるためです。構造化されたスコアカードでは、入力がすでに構造化されているため、正直に「不明」と判定することはできません。この非対称性こそ、このスキルが存在する理由です。

提案ではなく、厳守すべきルールです。

  • 「確認済み」または「推定」と評価するすべての所見には、根拠となったメモの正確な一節を引用してください。引用できる証拠がない所見は、定義上「不明」です。
  • すべての警戒サインについて、それを解消する具体的な反証を確認してください。リスクを記録する前に確認し、どの商談も必ず失敗するように見える一方通行の評価にならないようにします。

このスキルを使う場合、または関連スキルを使う場合

ユーザーが1件の商談に関する記録を持っていて、文章からリスクを洗い出したい場合は、このスキルを使います。次の場合は、別のものを使います。

  • ユーザーがMEDDPICCの基準に沿って、項目ごとに構造化された評価を求めている場合 — mbfinotti/sales-skills@meddpicc-scorecard。このスキルは構造化された回答を評価しますが、こちらは整理されていない文章を読み、その文章からは裏付けられないことを報告します。このスキルが手法のスコアを出すことはありません。
  • ユーザーがステークホルダーマップ(チャンピオン、経済的意思決定者、阻害者が誰か)の作成を求めている場合 — mbfinotti/sales-skills@deal-champion-mapping。このスキルはチャンピオンの証拠が不足している、または弱いことを指摘するだけで、候補となるペルソナを特定したり、マップを作成したりはしません。
  • ユーザーがディスカバリー質問一式を求めている場合 — mbfinotti/sales-skills@sales-discovery-questions。このスキルはギャップごとに診断質問を1つだけ出します。
  • ユーザーがROIやビジネスケースの説明を求めている場合 — mbfinotti/sales-skills@deal-value-calc。
  • ユーザーが同じメモをフォローアップメールにしたい場合 — mbfinotti/sales-skills@sales-meeting-recap。
  • ユーザーが複数の商談を含むパイプラインのエクスポートを持っている場合。これはパイプラインレベルの作業(データの整備、予測)であり、ここでの対象外です。このスキルは、1件の商談に関する記録を深く読み込みます。

ヒアリング

レビューの前に質問します。1回のメッセージにつき質問は1つとし、できるだけ選択式にします。メモですでに回答されている項目は省略します。

  • B2Bですか、それともB2Cですか。(ここでいうB2Cは、リフォーム、金融商品、高額なコーチングなど、実際の営業対話を伴う検討型の購入を指します。衝動買いの小売は含みません。)
  • おおよその商談規模と想定されるサイクル期間はどれくらいですか。(重大度の調整に使います。6か月のエンタープライズ案件では相互合意済みのアクションプランがないことは重大ですが、2週間のトランザクション型案件では関係ありません。)
  • 営業担当者は現在どのステージにいると考えていますか。予測リストまたはコミットリストに載っていますか。回答はいつまでに必要ですか。予測会議、ステージゲート、または買い手側のイベントのどれでしょうか。(コミット済みの案件では、あらゆるギャップの重要性が増します。その日付の後に解消するギャップは、どんな代償を払っても追いかける価値はありません。)
  • メモはどの期間を対象としていて、完全なものですか。(1回の通話メモでは傾向を裏付けられません。「失敗モード」を参照してください。)
  • 目的はこの商談を成立させることですか、それともその背景にある習慣を改善することですか。(今サイクルで商談を成立させることが優先なら、買い手向けの依頼を先にします。評価の仕方やメモの整理を改善することが優先なら、その後のすべての商談に効果が及ぶ記録作業を優先します。)
  • 次のゲートまでにかけられる労力の上限はどれくらいですか。関係を損なわずに何件の依頼ができ、マネージャーやエグゼクティブスポンサーは対応可能ですか。(どの追跡方法や対応段階がそもそも選択可能かを決めます。)
  • ユーザーがすでに疑っていることはありますか。(検証する仮説として扱い、証拠をもとに検討します。確認すべき結論として扱うことはありません。)

インテーク

案件に関するあらゆる文章を受け付けます。

  • 通話メモの生データ。
  • 貼り付けられた活動ログ。
  • 案件レコードの自由記述フィールド。
  • メールやチャットのスレッド。
  • 振り返りメール。
  • 文字起こしの抜粋。

どの CRM や会話録音ツールからエクスポートされたメモでも入力として使えます。ワークフローは、どのツールが作成したかに依存しません。環境がファイルを読み取れる場合は、ファイルパスまたはエクスポートを受け付けます。それ以外の場合は、テキストを貼り付けるようユーザーに依頼してください。

不完全で整理されていない、または情報の少ないメモでも問題ありません。不足している情報を伝えることも、このスキルの重要な役割です。レビューで確認できることとできないことを、ユーザーにはっきり伝えてください。評価するのはメモであって案件そのものではないため、メモの情報が少ないと Unknown が多くなります。それ自体が案件管理の健全性に関する所見です。

ワークフロー

  1. Interview を実施し、ユーザーが持っている情報をすべて入力に含めたか確認します(メールのスレッドがひとつ残っていて、そこに唯一の買い手本人の発言が含まれていることもよくあります)。
  2. メモを、日付順の出来事のタイムラインに整理します。実施した会議、参加者、行われた約束、変更された日付を記録します。記録が乏しい箇所も記録してください。それも証拠です。
  3. 証拠となる候補を抽出します。カタログ内の項目を肯定または否定する逐語的な断片を抜き出してください。買い手本人の発言と、営業担当者自身の推測、さらに伝聞を区別します。「経済的決裁者から書面で受け取っています」は、「自分のチャンピオンから聞きました」より優先されます。
  4. references/red-flag-catalog.md の各グループを、タイムラインと証拠に照らして確認します。すべてのグループのすべてのフラグを状態に分類します。グループをひとつも飛ばしてはいけません。
  5. リスクを記録する前に、各フラグを否定する証拠を確認します。解消を裏付ける証拠がメモに引用されているフラグは、Red ではなく Cleared です。
  6. Cleared ではないすべてのフラグに重大度を割り当てます。固定の表ではなく、Interview で得た案件規模、販売サイクルの長さ、販売形態を考慮して調整します。
  7. 証拠があるものと、単に情報がないものを区別します。Unknown の各フラグについて、診断質問を正確にひとつ記載します(カタログには各フラグにひとつずつ質問があります)。その後、以下の対応の優先順位に従って Gaps を並べ替えます。営業担当者が次にできる接触はひとつであり、12 個ではありません。
  8. 以下の出力形式でレポートを作成し、Red と Amber の各フラグに対して、カタログから改善策をひとつ添え、その改善策が該当する対応段階を明記します。
  9. Quality ゲートを実行し、すべての項目に合格するまで再評価と書き直しを繰り返します。
  10. ハーネスに永続メモリがある場合は、提起したフラグ、その状態、証拠を記録し、同じ案件を次にレビューする際に、どのギャップが解消されたか確認できるようにします。それ以外の場合は、ユーザーが保存できる簡潔な引き継ぎリストをレポートの末尾に記載します。

評価基準

確信度の状態 — メモがフラグの根拠をどのように示しているか:

状態意味根拠の要件
クリア済みメモにフラグを否定する根拠が記載されているクリアした内容の逐語引用
検証済みリスクを裏付ける、買い手本人の引用可能な発言があるメモからの逐語引用
仮定営業担当者の推測、伝聞、または二次情報の伝達だけが根拠となっている推測または伝達内容の逐語引用
不明このフラグについてメモに記載がないなし — 記載がないことが判断材料

重大度 — 高・中・低:リスクが現実のものだった場合に、この案件が受ける損害の程度です。固定の表ではなく、案件規模と営業サイクルの長さに照らして判断します。確信度が検証済みか仮定かを基準にフラグを赤・黄・緑に評価する方法は、案件精査における標準的な慣行です(MEDDPICCの系譜を引く資料に記載されています)。上記の状態名では、この用語体系に「不明」を加え、メモのレビューに対応しています。

意図的に順位付けしていない項目:重大度と確信度はリスク評価の基準であり、比較する選択肢ではありません。2つの軸を互いに順位付けしたり、1つのスコアに統合したりしてはいけません。この基準でメモの内容を評価し、その結果をもとに、以下の2つの順位付けで次に行う作業を選びます。後のレビューでも、この評価基準には手を加えないでください。

レポート上の評価 — 表示上の分類にすぎません。すべての指摘事項で、2つの軸をそれぞれ明示します。

  • 赤:検証済みのリスクで、重大度は高。
  • 黄:検証済みのリスクで、重大度は中または低。または仮定のリスクで、重大度は高。
  • 要確認:仮定のリスクで、重大度は中または低 — 確認または解消につながる内容を明記します。
  • 未確認事項:不明な項目すべて — 診断用の質問を1つ付けます。是正策は提示しません(是正が必要だと確認された事項がないためです)。
  • クリア済み:次のレビュアーが再び問題として取り上げないよう、解消した引用とともに簡潔に記載します。

追跡順序:どの未確認事項について次に確認するか

評価では、すべてのグループに含まれるすべてのフラグを判定します。追跡は、それとは別の、より小さな選択です。営業担当者が次に行える接触は1回だけなので、答えによって次の行動が変わる場合にのみ、未確認事項を追う価値があります。計画を変えられないフラグは、どれほど深刻に見えても追跡する価値はありません。フラグではなく、確認手段を順位付けします。同じ未確認事項でも、営業担当者がどう解決するかによって、負担は軽くも重くもなります。

ここでの負担とは、営業担当者の作業時間、依頼によって消費する買い手の好意、そして回答が得られるまでのカレンダー上の遅延です。金額ではありません。

  • 効率(標準の順序):desk check > one question > access ask > second data point > record repair
  • 価値:access ask > one question > desk check > record repair > second data point
  • 負担、重い順から軽い順:record repair > access ask > second data point > one question > desk check | 段階 | 解消できるもの | 労力 | 回答によって変わること | | ----------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | | デスクチェック - 営業担当者がすでに持っている記録(カレンダー、送信済みメール、CRM のフィールド履歴、参加者リスト)から確認します | スレッドの網羅性、クローズ日の延期、営業担当者が管理するタイムライン、遅延と出席の傾向、メモの不足 | ほぼゼロ。好意を求める必要はありません。回答はすでに営業担当者自身の記録にあります | 根拠そのものを再評価します。記録が不十分または誤っていれば、ほかのすべての調査結果が損なわれるため、これが以降の判断の前提になります | | スレッド内で一つ質問する - メール、またはすでに予定されている通話で回答してもらう診断的な質問を一つだけします | 意思決定プロセス、予算責任者自身の言葉、阻害要因となっている人物の実際の異議、日付の決まった次のステップ、定量化された影響 | 準備に1時間、好意を一つ求める負担、数日の遅延 | 通常は予測カテゴリーが変わり、次回の会議が明確になります | | アクセスを依頼する - 紹介、共同意思決定者、関係する不足機能、共同で所有する計画など、買い手自身の影響力を使ってもらうよう依頼します | 経済的な意思決定者と一度も会っていない、共同意思決定者に未相談、権限を持つ人物に対する推進者の影響力、一つの機能からしか得ていない要件 | 1週間以上の遅延、相応の好意、断られる可能性 | どの段階よりも影響が大きくなります。依頼自体が確認と改善の両方を兼ねており、断られたこと自体も検証済みの調査結果となります | | 2つ目のデータポイント - 次の返信の遅れ、催促、または参加者リストを待ちます | 2点だけの記録ではまったく評価できない傾向の兆候 | 作業時間はほぼゼロですが、カレンダー上の遅延が四半期分あります | 現時点での影響はわずかです。回答が得られるのは、通常、情報を届けるはずだった予測会議の後です | | 記録の修復 - この案件のログを補完し、その後は評価可能な基準に沿ってメモを残します | この案件では現時点で何もありません | 継続的な作業 | 次回の通話には何ももたらしませんが、その後のすべての案件レビューで効果が積み重なります |

複数のギャップを一度に埋める完全な再ディスカバリー通話は、候補から除外しており、順位を下げたわけではありません。このスキルではギャップごとに質問を一つ提示します。通話で質問を5つすると尋問のように受け取られ、アクセス依頼に必要な好意を損なってしまいます。本格的な質問セットが必要な場合は、mbfinotti/sales-skills@sales-discovery-questions に依頼してください。

この順序で後回しになるもの:

  • アクセス依頼:価値が最も高い一方で、労力も最も大きいため、効率を優先する判断では毎回後回しになります。ここで比率思考に頼ると失敗します。終盤の案件を台無しにするのは権限の不足であり、労力の少ない段階は進捗を報告するだけだからです。案件がコミット段階にある場合、または次のステージゲートが意思決定会議である場合は、これを最初にしてください。デスクチェックでは拒否権を取り除けません。
  • 記録の修復も同様です。同じ案件のレビューで Unknowns が2回連続して大半を占める場合は、優先順位を上げてください。

この案件とこの営業担当者についてすでに把握していることに基づいて順位を付け直し、どの事実によってどの段階の順位が変わったかをレポートに記載してください:

  • 週の途中で予測確認の電話をすると、アクセス依頼が優先され、2つ目のデータポイントは意味を失います。
  • その日のうちに返信するチャンピオンがいる場合、1つの質問をする段の待ち時間がなくなり、デスクチェックより優先されます。
  • 30件の案件を抱える営業担当者は最初の2段にとどまり、3件の案件を抱える営業担当者なら、それぞれにアクセスを依頼できます。
  • Interviewで「習慣を直す」という回答があった場合、記録の修正は最後から最初に繰り上がります。
  • 1回の電話しかカバーしていないメモでは、デスクチェックをしてもUnknownしか返ってきません。1つの質問をする段から始めてください。

確認済みのフラグへの対応順序

Red と Amber のみに適用されます。Unknown には対応すべき確認済みの項目がないため、上記の追跡順序に戻ります。

  • 効率(デフォルトの順序):trade it > work it > re-forecast it > escalate it > disqualify
  • 価値(停滞が解消された商談、または取り戻せるサイクル時間で評価):escalate it > trade it > work it > disqualify > re-forecast it
  • 労力(多い順):escalate it > work it > trade it > re-forecast it == disqualify

この同順位は実際のものです。再予測と失格処理はどちらも、担当者の工数はほぼゼロ、買い手からの信頼は損なわず、社内向けの更新が1回必要なだけです。担当者が費やすものという点では本当に同じで、異なるのは可逆性だけです。可逆性は価値の軸で考慮されるため、労力だけでどちらかを選んではいけません。

段階内容労力得られるもの
交換する買い手がすでに望んでいる次のこと、たとえば提案、スコープ策定セッション、価格提示の条件として、問題の解決を盛り込みます構成に1時間。買い手自身の要望が原資となるため、新たな信頼の消費はありませんいずれにせよ実施する予定だったステップの中で、フラグを解消できます
対処するカタログの施策を独立した接点として実行します準備に1時間、信頼を1回分消費し、数日間の遅延が発生しますフラグを1つ解消します。交換できるものがない場合のデフォルトです
再予測する商談を確度の高い期間から外し、何のフラグが原因だったかを明示します工数はほぼゼロ、買い手からの信頼は損なわず、社内の信用を多少消費します商談の進展ではなく、予測の正確さです。解消できる手段がない緊急性や予算のフラグに対する、誠実な回答です
エスカレーションする担当者には開けられない扉を開くため、マネージャーまたはエグゼクティブスポンサーを招きます社内政治上の信用を使い、調整に1週間かかります。商談ごとにおよそ1回だけ使える手段です障害がアクセスにある場合はすべて解決できますが、情報にある場合は何も解決しません
失格とする残りのサイクルにかかる時間を、パイプラインの他の商談に振り向けますほぼゼロ残りのサイクル全体を取り戻せます。ただし取り消せないため、回復可能なフラグに対して実行するのは誤りです

削除された対応であり、優先順位を下げたものではありません。つまり、要求を添えずに懸念事項としてフラグを買い手に伝えることです。これは信頼を消費するだけで、証拠は得られません。だからこそ、カタログのすべての施策には具体的な要求が伴います。

この順序によって後回しになるもの:

  • エスカレーション:費用と社内政治上の負担が大きいように見えるため、効率を重視すると選ばれません。その結果、エスカレーションでしか解決できないフラグ(経済的な決裁者に一度も会えていない、障害が未解決)が、商談の終盤で失注を招きます。障害が情報ではなくアクセスにあり、チャンピオンに少なくとも2回依頼しており、ステージゲートが現期間内に来る場合は、交換と対処よりも上位にします。
  • 失格処理も同じ理由で後回しになります。回復不可能なフラグが1つ特定された場合に優先します。フラグの数を基準にしてはいけません。

どちらの順序も絶対ではありません。商談、四半期、実行する人によって変わります。関与しているエグゼクティブスポンサーがいる担当者なら、低コストでエスカレーションできます。そうしたスポンサーがいない担当者は、それを前提に計画すべきではありません。また、四半期末には、1週間の遅延が伴うものよりも、交換と再予測を優先します。

呼び出しと出力形式

一般的な呼び出し例:

  • 「最重要案件について6週間分のメモがあります。見落としている危険信号はありますか?」(メモを貼り付けます)
  • 「この商談を案件化する前に、活動ログを確認してください。この案件は本物でしょうか?」
  • 「単一スレッドで確認してください。案件に関する情報はすべて、このメールスレッドにあります。」

レポートを1件作成してください(否定的な例を含む記入済みのサンプルは、references/example-review.md を参照してください)。

DEAL RED-FLAG REVIEW - <deal>, reviewed <date>, notes covering <period>
Snapshot   : size, stage, cycle age, motion (B2B/B2C) - as stated, or "not in notes"
Timeline   : dated events reconstructed from the notes; where the record thins
Red        : flag - severity - verbatim evidence quote - one remediation play -
             its response rung, and the fact that promoted or demoted it
Amber      : same shape as Red
Watch      : flag - verbatim evidence quote - what would confirm or clear it
Gaps       : flag - one diagnostic question - its chase rung; listed in chase
             order, highest value per unit of effort first
Cleared    : flag - the quote that cleared it
Risk check : the two pipeline-review questions (Armand Farrokh, 30MPC): is there
             risk in HOW the deal cleared its past stage criteria, and is there
             risk in the PLAN for the next ones - answered from the findings
Verdict    : what is evidenced vs what is merely absent; the single next action,
             which is the top of the chase order after re-ranking against the
             Interview answers. Never a win-probability or methodology score.

B2B と B2C

どちらでも同一で、暗黙にせず明示します。

  • エビデンスのルール:引用するか、不明とします。
  • 2軸での評価。
  • 反証となるエビデンスの確認。
  • 「課題と価値」「エンゲージメント」「緊急性と品質」のロジック全体。都合のよい解釈、定量化されていない影響、売り手側が設定したタイムライン、繰り返される先延ばし、返信の遅延の拡大は、どちらの販売形態でも同じように評価します。

B2C および高回転のトランザクション型案件で実際に異なる点です。B2B の一覧を単に言い換えるだけではありません。

  • 関係者が一人だけであること自体は危険信号ではありません。こうした案件は、設計上、単一の意思決定者が関わります。同等の関係者リスクは、相談されていない共同意思決定者(承認が得られると想定されているものの、その証拠がないパートナーや配偶者)と、支払い能力が確認されていないこと(融資や信用が未確認)です。
  • 購買のきっかけとなる出来事は、会計年度上の事情よりも、個人的または季節的なもの(引っ越し、人生の節目、世帯で設定した期限)であることが多いものの、日付が明確な実際のきっかけは、依然として「熱心そうだった」という印象に勝ります。
  • 調達、セキュリティ、法務の審査は通常ありません。「プロセス」グループで確認するのは、合意済みで日付の明確な次のステップがあるかどうかの1点です。カートやトライアルの放棄、返信間隔の長期化が、最も重要なエンゲージメント上の危険信号になります。
  • トランザクション型案件にエンタープライズ向けのヒューリスティックを適用すること自体が誤検知になります(後述)。逆の場合も同様です。長期サイクルのエンタープライズ案件をトランザクション型の返信速度基準で判断すると、実際には存在しない音信不通の危険信号を生み出します。

失敗パターンと誤検知

過剰反応修正
Unknown を Red として扱うUnknown はメモに記載がないという意味であり、商談が破綻しているという意味ではありません。エスカレーションではなく、質問の対象になります
エンタープライズ向けの基準で小規模なトランザクション型の商談にフラグを立てるInterview で調整します。マルチスレッド化と相互アクションプランに関するフラグは、適合する営業活動の段階より前では無効になります
メモが1回の通話についてしかないのに、商談が単一スレッドだと判断する1回の通話のメモが示すのは、その1回の通話だけです。関係者の範囲は Unknown とし、ほかに誰が関与しているかを尋ねます
返信のないメールが1通あっただけで、チャンピオンが離脱したと推測する間隔が広がるパターンは証拠になりますが、1回の沈黙は証拠ではありません。多くとも Assumed と評価し、その引用を添えます
フラグの数を理由に商談を不適格とする数を数えると2つの軸がひとまとめになり、件数は意思決定のルールではありません。どのような場合に不適格と判断するかは、対応の順序に示されています
一方通行のラチェット — リスクを記録する一方で、解消の確認をしないすべてのフラグについてステップ5を実行します。Cleared を出力できないレビューでは、常に見込みのない商談だと判断されてしまいます
意思決定に時間がかかる合意重視の購入を、関心の低下とみなす購買文化や規制対象のプロセスによっては、正当に時間がかかり、反応も少ない場合があります。普遍的な基準ではなく、そのセグメントの通常のペースと比較して評価します
メモではなく商談そのものを評価する結論では「根拠のあるリスク」と「記録の不足」を区別する必要があります。Unknown が大半を占める場合は、メモの記録方法の改善を提案します

品質ゲート

完成したレポートを、次の6項目すべてに照らして採点します。合格基準は6/6です。不合格項目がなくなるまで繰り返し改善してください。

  1. Red と Amber の調査結果には、すべてメモからの一字一句そのままの証拠引用が付いています。
  2. カタログの各グループで、すべてのフラグに状態が割り当てられています。Cleared と Unknown を含め、スキップされたものはありません。
  3. Unknown が Red、Amber、Watch として示されていません。すべての Unknown に、診断のための質問がちょうど1つ付いています。
  4. Red と Amber の調査結果には、それぞれ改善策がちょうど1つ付いています。
  5. すべての重大度は、この商談の規模、サイクル、営業活動に照らして正当化されています。固定表に基づく重大度はありません。
  6. ギャップが確認の優先順位順に並んでいます。また、Red/Amber の改善策では対応の段階を示し、Interview の回答に照らして両方の順序を見直したうえで、段階が変わった理由となる事実を明記しています。

KPI と測定

レビューした商談について、時間の経過とともに次のような変化があれば、レビューは効果を上げています。

  • スリップ率(合意した期間を超えて、クローズ予定日が先送りされる割合)が低下します。
  • フラグが立った商談のうち、次の段階に進む前にフラグを解消する割合が増加します。
  • レビュー対象の商談の予測精度が、未レビューの商談に対して向上します。
  • あるレビューでの Unknown が、次回までに Verified または Cleared に変わります。

同じ商談でレビューを重ねるたびに Unknown の数が増える場合、まず対処すべき問題は商談の質ではなく、メモの記録方法です。

コメント