ヨミ管理のやり方｜A・B・C・Dを顧客事実で揃える実践手順

ヨミ管理とは｜案件の「確度・金額・時期」を揃える方法

ヨミ管理とは、進行中の営業案件について、受注する可能性・金額・時期を共通の基準で見立て、対象期間の着地予測と次の行動に使う管理方法です。「この案件はA」「今月はBまで」といった記号は目的ではありません。経営者、営業責任者、担当者が同じ事実を見て、採用、外注、供給準備、提案支援の判断を早めるための共通言語です。

Salesforceの公式ヘルプでも、標準のForecast CategoryとしてPipeline、Best Case、Commit、Omitted、Closedが示されています（出典：Salesforce Help）。名称は違っても、「まだ予測に入れにくい案件」「上振れ候補」「本命」「除外」「確定」を分ける考え方はA〜D管理と近いものです。

商談ステージとヨミは分けます。「見積提出済み」は営業側の作業であり、「今月中に発注する」という顧客の意思ではありません。同じ提案段階でも、決裁者の合意と期限があればA、比較条件が残ればB、予算時期が未確認ならCになり得ます。

ヨミ管理はパイプライン管理の一部を使って近い期間の着地を見立て、その結果を予実管理へ渡す位置づけです。ヨミだけで営業プロセス全体の改善や事業予算の管理を代替することはできません。

A・B・C・Dヨミの基準は「顧客が何をしたか」で決める

A〜Dの判断基準は、営業担当者の感触ではなく、顧客側で観測できた行動と合意で決めます。割合を先に当てはめると、「担当者が自信を持っているからA」という循環が起きます。まず判定条件を言葉にし、実際の受注・失注履歴が貯まってから各ランクの実績確率を確認します。

Aヨミ｜対象期間内の受注意思と残作業が確認できる

Aヨミは、対象期間内に受注する意思を決裁者側で確認でき、主要条件が合意され、残る手続きと期限が特定できる案件です。「好感触」「たぶん大丈夫」では足りません。契約書確認、稟議、発注書送付など、受注までの残作業を誰がいつまでに行うかが言葉になっている状態です。期限を過ぎたのに更新がなければ、自動的にAを維持しないルールもセットにします。

Bヨミ｜価値は合意したが未確認条件が残る

Bヨミは、提案価値や解決したい課題への合意はある一方、決裁・予算・比較・条件・時期のいずれかが未確認の案件です。「何が確認できればAへ上がるか」を一文で書けることがBの条件です。書けない場合、実態はCかDに近い可能性があります。

Cヨミ｜課題と次回接点はあるが購買条件が足りない

Cヨミは、顧客の課題と次の接点は確認できたものの、予算、決裁者、導入時期など購買判断の骨格が揃っていない案件です。ここで提案書を急ぐより、次回面談で確認する条件を絞ります。「検討します」で止まって次回日時も決まらない場合は、CではなくDへ戻すほうが予測は健全です。

Dヨミ｜情報収集・長期保留として当期予測から分ける

Dヨミは、関心はあり得るものの、対象期間内に購買が進む事実をまだ確認できない案件です。Dは「価値がない案件」ではありません。当期の売上予測から外し、将来の再接触へ置くための区分です。商談化前・長期保留リードの接点設計は、リードナーチャリングの基本で詳しく整理しています。

エイギョウブの実務では「証拠・不足・約束・期限」を一組で残す

エイギョウブ編集部が営業支援の案件レビューで使う考え方は、ヨミの一文字に「証拠・不足・約束・期限」の4点を必ず対応させることです。顧客名、担当者名、案件金額、内部KPIを公開せずに再利用できる運用部分だけを、ここでは公開版の判断票として示します。これは実務プロセスの開示であり、成果数値や成功事例を装うものではありません。

実務では、まず証拠だけを記録し、その証拠で満たせない条件を不足欄へ置きます。次に、不足を確認する共同作業と期限を決め、最後にA〜Dを選びます。先にランクを選んで理由を後付けしない順番がポイントです。レビュー後は、ヨミ、変更日、変更理由を履歴として残します。この4点のどれかが空欄なら、会議で確度を上げるのではなく、空欄を埋める行動を決めます。

顧客情報や未公開の案件記録は掲載せず、複製できる空欄テンプレートを示します。「証拠：＿＿／不足：＿＿／約束：顧客＿＿・自社＿＿／期限：＿＿／現在ヨミ：＿＿／変更理由：＿＿」の順で一行にすると、商談へ同席していない責任者も判断根拠を確認できます。

ヨミ管理を始める5ステップ

ヨミ管理は、定義を決め、案件を一つに集め、顧客事実で初期判定し、更新責任を決め、週次で意思決定する順に始めます。先にSFAを導入しても、入力する言葉の意味が人ごとに違えば、見た目が整うだけで判断は揃いません。

ヨミ管理の対象期間とA〜Dの判定基準を決める

最初に「今月」「今四半期」など予測する期間を決め、A〜Dの昇格・降格条件を一枚にします。Oracleの公式ドキュメントも、商談を受注予定日によって期間へ配置し、Forecast Categoryで集計する考え方を示しています（出典：Oracle Help Center）。確度が高くても受注予定日が次期なら、当期の着地には入れません。

ヨミ管理の進行中案件を一つの表へ集める

案件名簿を一か所へ集めます。表計算でも構いません。ただし担当者の手元メモ、会議用の表、経営報告用の表を別々に持つと、どれが最新か分からなくなります。入力元は一つ、表示方法は複数という設計にします。完了・失注・対象期間外も消さず、状態として残すと後の精度検証に使えます。

ヨミ管理の全案件を顧客事実で初期判定する

各案件について「顧客が言ったこと・行ったこと」「まだ確認できていないこと」を分けて書きます。Sansanも、受注確度のランクが担当者の主観に依存すると、現状把握や次の行動、改善点の特定が難しくなると説明しています（出典：Sansan 営業DX Handbook）。最初の判定で迷う案件は、上位ではなく不足条件が示す下位ランクへ置きます。

ヨミ管理の更新責任と期限超過時のルールを決める

数週間から数か月かけて進むBtoB商談では、案件担当者が顧客事実の変化を当日更新し、責任者が週次で例外を確認する形を、編集部は初期運用として推奨します。短期商談や年単位の大型案件では、商材の速度に合わせて頻度を調整します。「次回行動の期限を過ぎたら再判定」「決裁者の合意が撤回されたらAから下げる」「受注予定日が期をまたいだら対象期間を移す」など、悪化したときのルールを先に決めます。

ヨミ管理の週次会議を報告ではなく意思決定に使う

会議では全案件を順番に読み上げません。前週からランク・金額・予定日が変わった案件、期限超過、A・Bなのに未確認条件がある案件、責任者の支援が必要な案件に絞ります。営業担当は更新、責任者は障害除去、経営は供給や投資の判断という役割に分けると、ヨミ表が報告資料から意思決定の道具へ変わります。

ヨミ表に必要な11項目｜表計算でも始められる

小規模チームのヨミ表は、案件の基本情報に「顧客事実・未確認条件・次回行動・期限・更新日」を加えれば十分に始められます。項目を増やしすぎるより、会議で使う列だけを必須にし、空欄を放置しないほうが運用は続きます。

最初から全11項目を埋めにくい場合は、案件名・担当、対象期間、ヨミ、顧客事実、未確認条件、次回行動、期限の7項目を開始時の必須列にします。想定金額、商談ステージ、判定日・変更理由、最終更新日は運用開始後に追加します。ただし、着地金額を経営判断へ使う段階では想定金額を必須へ移してください。

ヨミ管理の導入初週に行う更新手順

初週は、全案件を一度に精緻化するより、対象期間に入っている案件から順に「証拠・不足・約束・期限」を埋めます。担当者が入力した後、責任者が同じ事実から同じヨミを選べるか確認します。判断が分かれた箇所は担当者の説得で決めず、定義表へ例外条件を追記します。週末に空欄と期限超過だけを一覧化し、次週はその解消から始めます。