営業業務の設計・CRM構築・定着支援
CRMを、営業が使える道具に。
入力項目は増えたのに、商談の状況がつかめない。 KNOTは、営業の進め方とCRMの設定を一緒に見直し、 日々の商談管理に使える仕組みをつくります。
CRM支援の内容を見る業務の整理 / 構築・データ移行 / 運用の定着

よくある課題
CRMはある。
でも、営業が回らない。
KNOTは、営業業務の設計とシステム構築を支援する会社です。顧客情報の持ち方、商談の進め方、会議で見る数字。業務上のルールを整理し、CRMの設定やデータ連携に落とし込みます。
たとえば、こんな状態になっていませんか。
- 商談の「確度」が、担当者によって違う。
- ステージの意味と、次へ進める条件を揃えたい。
- 営業会議の前に、毎回Excelを作り直している。
- 会議で必要な数字を、CRMから確認できるようにしたい。
- 入力項目は増えた。でも、更新されない。
- 何のための項目かを整理し、入力する場面から決め直したい。
KNOTの支援内容
営業の進め方から、
CRMを組み直す。
CRM・営業基盤の構築
商談ステージ、入力項目、営業会議の見方を揃え、CRMに反映します。新規導入にも、既存環境の見直しにも対応します。
- 01
業務を整理
商談の進め方・判断基準
- 02
CRMに実装
項目・画面・データ移行
- 03
現場で運用
担当・更新ルール・改善
成果物のサンプル
「提案中」の意味を、
チームで揃える。
見積書を送ったら「提案中」なのか。顧客の反応まで確認したら「提案中」なのか。まず、その違いを言葉にします。
決めたルールをCRMの項目や入力画面に反映し、実際の商談で使えるか確かめます。
支援範囲と進め方商談ステージ定義書
v0.3ステージは営業担当の感触ではなく、顧客との確認事項で判定する。金額や受注予定月が変わった場合は、その根拠も活動履歴に残す。
表は横にスクロールできます →
| ステージ/内部値 | このステージへ進める条件 | CRMの必須項目・記録 | 更新担当/タイミング |
|---|---|---|---|
| 10|要件確認 qualification | 初回商談を実施。顧客の課題と検討時期を確認した。問い合わせ受付のみでは商談を作らない。 | 課題:customer_issue 次回対応日:next_action_at 次の対応:next_action | 営業担当 商談実施の翌営業日まで |
| 20|提案・見積 proposal | 対象範囲・要件を確認し、提案内容を顧客に説明済み。見積の送付だけでは移行しない。 | 見積額(税抜):amount 受注予定月:close_month 提案資料URL:proposal_url | 営業担当 提案説明の翌営業日まで |
| 30|稟議・契約 approval | 提案内容に合意し、決裁者・稟議手順・判断予定日を確認。予算未確認の場合は20のまま。 | 決裁者:decision_maker 判断予定日:decision_due 残課題:open_issues | 営業担当が申請 営業責任者が内容確認 |
| 90|受注 closed_won | 契約締結または注文書の受領を確認。口頭内諾は含めない。 | 受注日:won_at 確定額(税抜):amount 契約書URL:contract_url | 営業担当 証憑確認の翌営業日まで |
| 91|失注 closed_lost | 見送り・競合決定など、顧客の意思を確認。連絡が取れないだけでは失注にしない。 | 失注日:lost_at 失注理由:lost_reason 確認内容:loss_note | 営業担当 顧客の意思確認後に更新 |
| 80|保留 on_hold | 時期未定・予算凍結などで検討が中断。再確認日と中断理由を記録する。 | 保留理由:hold_reason 再確認日:review_at 再開先:resume_stage | 営業担当 再確認日に継続・再開を判断 |
運用上の注意保留・失注は通常の進行順に含めない。ステージ変更履歴と変更理由を保存し、受注後の取消は履歴を消さず営業責任者へ確認する。
記入例・判定理由と運用ルールを見る
案件 DEMO-024 の記入・判定例
- 顧客/案件
- サンプルA社/営業管理の再設計
- 現在のステージ
- 20|提案・見積
- 見積額/受注予定月
- 2,400,000円(税抜)/2026年11月
- 確認できていること
- 10/08 提案説明済み。対象業務・導入時期は合意。
- 未確認事項
- 最終決裁者、予算枠、稟議の締切
- 次の対応/担当
- 10/14 顧客担当者へ決裁手順を確認/営業担当A
判定:ステージ20を維持。提案への好意的な反応だけでは30へ進めず、決裁者・予算・判断日を確認してから更新する。
役割分担・検証時の確認事項
- 営業責任者
- 週次会議で次回対応日の超過・空欄を確認。確度の感触ではなく、顧客に確認した事実を聞く。
- CRM管理者
- ステージごとの必須項目と履歴保存を設定。責任者による代理更新も、変更者が追えるようにする。
- 検証時の確認事項
- 進行中・失注・保留を含む10件で試し、必須項目の入力負担と例外処理を確認してから定義を確定する。
テンプレート用の架空資料です。記載の社名・案件・金額・運用条件は説明用の設定であり、実在顧客の情報ではありません。
お渡しするもの
- 01商談ステージ・入力項目の定義書
- 02CRMの設定・検証記録
- 03営業会議用のレポート
- 04入力ガイド・管理者向け引き継ぎ書
支援の具体例
営業の管理を、
どう見直すか。
法人向けサービス企業を想定した支援例です。
相談内容から、設計・検証の進め方まで紹介します。

営業と顧客情報の管理を見直し、商談の判断基準を揃える。
CRMと営業会議用のExcelを併用している法人向けサービス企業を想定した、業務設計の例です。
相談時の状態
CRMの「提案中」には、見積書を送っただけの案件と、決裁待ちの案件が混在。マネージャーは毎週、担当者に確認し直してExcelの一覧を更新している状態を想定しています。
最初に取り組むこと
営業会議で確認している事項を洗い出し、「顧客がどこまで判断できているか」でステージを定義。次回アクション・実施日・懸念点の入力タイミングも揃えます。
- 01
現在の運用を伺う
利用中のCRM、担当者、会議や報告の流れを確認します。
- 02
対象業務と役割を決める
変更する範囲、確認いただく内容、費用と期間を整理します。
- 03
一部の商談で試す
少人数で確認し、入力の負担や判断の迷いを修正します。
業務設計ノート
営業とCRMの困りごとを、
ひとつずつ。

KNOTについて
運用する人が決まって、 はじめて引き継げる。
設定の説明だけでは、運用は引き継げません。項目を追加するのは誰か。データが重複したら誰が直すのか。営業担当が迷ったら誰に聞くのか。 日常の判断を担当できる人と、確認する手順まで決めてから引き継ぎます。
KNOTについて