kintone案件管理の設計方法｜進捗・見積・売上予測までつながる業務アプリ構成

kintoneで案件管理を作るとき、最初に作りたくなるのは案件一覧です。

案件名、顧客名、担当者、金額、ステータス、受注予定日、メモ。

これだけでも、個人のExcelやスプレッドシートよりは見やすくなります。

ただし、営業チームで使う案件管理にするなら、案件一覧だけでは足りません。

案件管理で本当に困るのは、案件を登録できないことではなく、次のような状態です。

• 顧客名が自由入力で、顧客管理とつながらない
• ステータスの意味が人によって違う
• 活動履歴がコメントやメモ欄に散らばり、最終接点が分からない
• 見積金額が更新されても、どの版が最新か追えない
• 受注確度が感覚で入力され、売上予測に使えない
• 次回アクションが空欄のまま案件だけ残る
• 失注理由が残らず、同じ負け方を繰り返す
• 帳票、契約、請求、会計との責任範囲が曖昧になる

案件管理は、営業の一覧ではありません。

顧客、案件、活動履歴、見積、売上見込み、失注理由、請求前確認がつながる業務DBです。

kintone案件管理で最初に決めるべきなのは、案件ステータスの名前ではなく、「案件を何とつなぎ、どの情報を正本にするか」です。

この記事では、案件管理アプリの作成手順ではなく、kintoneで案件管理を崩れにくい営業システムとして設計する方法を整理します。

kintone顧客管理の設計方法はこちら
Excelからkintoneへ移行する考え方はこちら

先に結論：案件管理は案件一覧だけで作らない

kintoneで案件管理を作るとき、1つの案件アプリだけでも始めることはできます。

ただし、実務で使うなら、最初から次の情報を分けて考えます。

分けるもの	1レコードの意味	役割
顧客マスタ	1社、1顧客	顧客コード、正式名称、担当責任を持つ
案件	1商談、1相談、1提案	進捗、金額、確度、受注予定、担当を持つ
活動履歴	1回の接点	面談、電話、メール、資料送付、フォローを残す
見積確認	1見積、1条件変更	見積金額、版、条件、提出日を残す
売上見込み	1案件の予測値	予定月、金額、確度、担当別集計に使う
次回アクション	1作業	次回連絡、資料作成、社内確認、期限を追う
失注理由	1失注の記録	理由、競合、時期、再提案候補を残す
連携ログ	1回の外部連携	フォーム、帳票、契約、請求連携の成否を追う

案件アプリは、営業プロセスの中心です。

ただし、案件アプリにすべてを書き込む場所ではありません。

顧客情報は顧客マスタへ置く。

接点は活動履歴へ残す。

見積や契約は版と条件を残す。

請求や会計は会計ソフトを正本にする。

この分け方にすると、案件の現在状態だけでなく、なぜその状態になったのか、次に何をすべきかまで追えます。

kintone公式の用途ページでも、顧客や案件データの一元管理、案件進捗の見える化、対応漏れ防止、活動履歴の蓄積が顧客・案件管理の使い方として紹介されています。

kintone公式：顧客・案件管理にkintone

重要なのは、この機能を「案件一覧」ではなく、営業プロセス全体の設計として使うことです。

kintone案件管理が向く業務と向かない業務

kintoneは、すべてのSFAを置き換えるツールではありません。

向いているのは、案件を顧客、活動履歴、見積、社内タスク、契約確認とつなげたい業務です。

kintoneに向く案件管理	理由
Excel案件表の置き換え	最新版、担当者、進捗、履歴を共有しやすい
BtoBの商談管理	顧客、担当者、活動履歴とつなぎやすい
見積前後の社内確認	承認、差し戻し、条件確認をプロセス化できる
案件から作業へつなぐ業務	次回アクション、資料作成、社内確認を見える化できる
受注後の導入・請求確認	契約、請求対象、引き継ぎをつなげやすい
小規模チームの営業管理	自社の営業プロセスに合わせて変更しやすい

一方で、次の条件が強い場合は、kintoneだけで完結させるより、専用SFAやMA、会計ソフトと役割分担した方がよいです。

kintoneだけでは重い案件管理	理由
大規模な営業予測	高度なパイプライン分析、予測モデル、目標管理が必要になる
商談活動の自動記録が中心	メール、通話、カレンダーの自動同期は専用CRMが強い
MAスコアリングが営業起点	流入、行動履歴、配信結果はMA側を正本にしやすい
見積、契約、請求を厳密に管理	帳票、電子契約、会計の正式台帳が必要になる
営業人数が多く、権限階層が複雑	部門、役職、地域、商品別の権限設計が重くなる

ここで大事なのは、kintoneでできるかどうかだけで判断しないことです。

kintoneは、自社の営業プロセスに合わせてアプリを作り、現場で改善しながら使うには向いています。

ただし、営業分析、スコアリング、契約、会計まで抱えると、責任範囲が曖昧になります。

kintoneを案件管理の正本にするのか、営業周辺業務の入口にするのかを先に分ける ことが重要です。

案件管理で正本にするデータ

案件管理で最初に決めるべきなのは、ステータス名ではありません。

どのデータを正本にするかです。

データ	正本にする場所	理由
顧客情報	顧客マスタ	表記揺れと重複を防ぐ
案件の現在状態	案件アプリ	フェーズ、金額、確度、受注予定を見る
接点の履歴	活動履歴アプリ	いつ誰が何をしたかを残す
見積の版と条件	見積確認アプリ、帳票ツール	提出版、金額、条件変更を追う
次回作業	次回アクション、タスクアプリ	放置を防ぐ
受注後の請求	freeeなど会計ソフト	請求書、入金、会計処理の正式台帳にする
流入とスコア	フォーム、MA	リードソースや行動履歴を持つ

案件アプリには、最新の状態を置きます。

過去のメール、面談、電話、見積変更を案件アプリのメモ欄に積み上げると、あとで使えません。

案件アプリに置くべき項目は、次のようなものです。

フィールド	型	設計意図
案件名	文字列	提案や相談を識別する
顧客	ルックアップ、関連レコード	顧客マスタとつなぐ
顧客側担当者	ルックアップ、関連レコード	窓口、決裁者をつなぐ
社内担当	ユーザー選択	営業責任者を決める
フェーズ	ステータス、ドロップダウン	営業プロセスの現在地を示す
見込み金額	数値	売上予測の基礎にする
確度	選択肢、数値	受注可能性を揃える
受注予定月	月、日付	月別見込みに使う
次回アクション日	日付	放置を防ぐ
失注理由	選択肢	失注時に必須化する
引き継ぎ状態	ステータス	受注後の導入や請求へ渡す

案件アプリを「なんでもメモ」にしないことが大事です。

案件の現在状態は案件アプリ。

経緯は活動履歴。

見積版は見積確認。

請求は会計。

この分担を決めると、あとから集計や連携がしやすくなります。

顧客・案件・活動履歴・見積を分ける

案件管理で崩れやすいのは、顧客、案件、活動履歴、見積を混ぜることです。

混ぜているもの	起きる問題
顧客と案件	同じ顧客の複数案件を扱えない
案件と活動履歴	何度接点があったか追えない
案件と見積	条件変更や版管理ができない
見積と請求	提案段階と正式請求が混ざる
活動履歴と次回タスク	実施済みの記録と未来の作業が混ざる

顧客と案件は、1対多です。

1社から複数案件が出ることがあります。

過去に失注した案件があっても、別の相談で受注することがあります。

そのため、顧客マスタに「商談中」「受注」「失注」のようなステータスを1つだけ持たせると、すぐに無理が出ます。

活動履歴も別にします。

1案件に、複数の接点があります。

初回面談、追加ヒアリング、資料送付、見積提出、条件調整、社内確認、契約待ち。

これらを案件のメモ欄に積むと、最終接点日、接点回数、次回アクション、担当者別の活動量が見えません。

見積も分けます。

案件に見込み金額を持つことはできます。

しかし、見積書を複数回出す、条件を変える、値引きする、提案範囲を分ける場合は、見積確認アプリや帳票ツールとの連携が必要になります。

見積で残すもの	理由
見積版	どの見積が最新か分かるようにする
提出日	顧客に出したタイミングを追う
金額	売上見込みと差異を見る
条件	納期、範囲、支払条件を残す
有効期限	再提案や失効を判断する
原本URL	PDF、帳票、電子契約へ戻る

案件を中心にしつつ、情報の性質ごとにアプリを分ける。

これが、kintone案件管理の基本です。

ステータスと受注確度の設計

案件管理でよく起きるのが、ステータスの意味が人によって違う問題です。

「提案中」と言っても、提案資料を作っている段階なのか、顧客に提出済みなのか、社内見積を待っているのか、人によって解釈がずれます。

まずは、フェーズを少なく始めます。

フェーズ	意味	次に必要な行動
新規	問い合わせ、紹介、流入直後	初回確認、対象外判定
ヒアリング中	課題や条件を確認している	要件整理、次回日程設定
提案準備	提案内容を社内で整理している	提案資料、見積条件の整理
提案済み	顧客へ提案済み	反応確認、追加質問対応
見積中	金額、範囲、条件を調整している	見積作成、承認、提出
契約待ち	発注、稟議、契約の待ち	契約確認、開始準備
受注	発注または契約済み	導入、請求、引き継ぎ
失注	見送り、競合負け、時期不一致	理由登録、再提案時期確認

フェーズは「いま何をすべきか」が分かる粒度にします。

細かすぎるフェーズは、入力されません。

粗すぎるフェーズは、次の行動が分かりません。

受注確度も同じです。

「A/B/C」だけでは、人によって感覚がずれます。

確度	目安	売上予測での扱い
A	条件合意済み、契約待ち	見込みに大きく反映する
B	提案済み、具体的な検討あり	中程度に反映する
C	初期相談、時期未定	低く見る
D	情報収集、対象外の可能性あり	参考値にする

数値で管理する場合も、10%、30%、50%、80%のように意味を決めます。

「担当者の感覚」ではなく、フェーズや顧客の行動と結びつけることが重要です。

確度	条件例
10%	問い合わせ直後、まだ課題未確認
30%	課題は確認済みだが予算や時期が不明
50%	提案済みで、条件調整が始まっている
80%	稟議、契約、発注手続きに進んでいる
100%	受注済み

受注確度は、売上予測のためだけではありません。

次に何を確認すべきかを揃えるためにも使います。

次回アクションと通知

案件管理で一番避けたいのは、案件が登録されているのに放置されることです。

進捗が止まる理由は、たいてい次回アクションが決まっていないことです。

案件アプリには、次回アクションに関する項目を持たせます。

フィールド	型	設計意図
次回アクション	文字列、選択肢	次にやることを明確にする
次回アクション日	日付	期限を持たせる
次回担当	ユーザー選択	誰が動くかを決める
次回アクション種別	選択肢	連絡、資料作成、見積、社内確認など
アクション状態	ステータス	未着手、対応中、完了、保留

次回アクションは、案件とは別にタスクアプリとして分けてもよいです。

小規模なら案件アプリ内のフィールドで十分です。

ただし、1案件に複数タスクが並ぶ、営業以外の担当者も作業する、期限管理を横断で見たい場合は、タスクアプリを分けます。

設計	向いているケース
案件アプリ内に次回アクションを持つ	1案件につき次の作業が1つで足りる
タスクアプリを分ける	資料作成、見積、社内確認、契約準備が並行する
活動履歴から次回アクションを作る	面談後の宿題を確実に残したい

通知は、全更新ではなく例外に絞ります。

通知する状態	通知しすぎない方がよい状態
次回アクション日を過ぎた	案件名の軽微な修正
見積提出期限が近い	活動履歴の追加すべて
契約待ちのまま一定日数経過	メモ欄の追記
金額が一定以上の案件が進んだ	担当者の通常更新
連携エラーが発生した	連携成功ログ

kintoneでは、条件通知やリマインダー、プロセス管理と組み合わせた通知を設計できます。

kintoneヘルプ：プロセス管理と組み合わせると便利な設定

通知の目的は、情報共有ではなく、対応漏れを防ぐことです。

売上予測と見積・請求を分ける

案件管理では、売上見込みを見たくなります。

月別の見込み金額。

担当者別の見込み。

確度別の見込み。

受注予定月別の集計。

kintoneの一覧やグラフで、こうした集計を作ることはできます。

ただし、売上予測と正式な売上を混ぜてはいけません。

領域	kintoneで持ちやすいもの	外部システムを正本にしやすいもの
売上見込み	見込み金額、確度、受注予定月	正式な売上、会計処理
見積	見積条件、版、提出状況	見積書PDF、承認済み見積
契約	契約待ち、開始予定、引き継ぎ	契約書原本、電子契約履歴
請求	請求対象の確認、請求依頼	請求書、税区分、入金消込
会計	営業側のメモ、請求前確認	仕訳、売上計上、残高管理

たとえばfreeeなどの会計ソフトを使っているなら、請求書、入金、会計処理はfreee側を正本にします。

kintoneは、営業や導入担当が見る「この案件は請求対象か」「どの条件で受注したか」「請求前に確認すべきことが残っていないか」を扱う場所に寄せます。

見積も同じです。

kintoneに見積金額を持つことはできます。

ただし、見積書の正式版、PDF、承認、電子契約まで含めるなら、帳票ツールや契約管理サービスと連携する方が自然です。

案件管理で見る売上見込みと、会計上の売上は別物です。kintoneには営業判断のための見込みを置き、請求・会計の正本は外部システムに分けるべきです。

失注理由をナレッジにする

案件管理で軽視されやすいのが、失注理由です。

失注した案件を「失注」にして終わるだけでは、次に活かせません。

失注理由は、営業改善のためのデータとして残します。

フィールド	型	設計意図
失注理由	ドロップダウン	価格、時期、競合、機能不足、予算なしなどを分類する
詳細理由	テキスト	顧客の言葉や具体的な背景を残す
競合	文字列、選択肢	比較された相手を残す
再提案可能性	選択肢	あり、時期未定、なしなどを分ける
再接触時期	日付	半年後、来年度などの再提案候補にする
失注確認者	ユーザー選択	理由が妥当か確認する

失注理由は、入力しやすくしすぎると雑になります。

「その他」ばかりになると意味がありません。

一方で、選択肢を細かくしすぎると入力されません。

最初は次の程度で十分です。

失注理由	意味
価格	金額が合わなかった
時期	今すぐではなかった
競合	他社、別ツール、内製に決まった
要件不一致	必要な機能、体制、条件が合わなかった
予算なし	予算化されていなかった
連絡途絶	顧客側の反応が止まった
対象外	自社で対応すべき案件ではなかった

失注理由を残す目的は、担当者を責めることではありません。

提案対象、価格、タイミング、競合、商品設計を見直す材料にすることです。

一覧やグラフで見るなら、失注理由別、担当者別、流入元別、業種別に分けます。

同じ理由が増えているなら、営業トークではなく、提案前の対象選定やサービス設計を見直すべきかもしれません。

一覧・グラフは意思決定に使う単位で作る

kintoneでは、一覧やグラフを作れます。

ただし、全案件一覧をきれいに作るだけでは、営業管理にはなりません。

見るべきなのは、次に判断が必要な案件です。

一覧	条件	見る人
自分の未対応案件	担当が自分、次回アクション未完了	営業担当
次回アクション期限超過	次回アクション日が過去、未完了	営業責任者
見積提出待ち	フェーズが見積中、見積未提出	営業、管理者
契約待ち滞留	契約待ちのまま一定日数経過	営業責任者
高額案件	見込み金額が一定以上	経営、管理者
受注予定月別	受注予定月が今月、来月	営業責任者
失注理由未入力	フェーズが失注、理由が空	管理者
連携エラー	帳票、会計、MA連携が失敗	システム担当

グラフも、作る前に目的を決めます。

グラフ	目的
フェーズ別案件数	パイプラインの詰まりを見る
担当者別見込み金額	営業負荷や偏りを見る
受注予定月別見込み	月次売上見込みを見る
確度別見込み	強い見込みと薄い見込みを分ける
失注理由別件数	負け方の傾向を見る
流入元別受注率	フォーム、紹介、広告などの質を見る

一覧とグラフは、見栄えのためではなく、会議やレビューで使うために作ります。

週次営業会議で見る一覧。

毎朝担当者が見る一覧。

月末に売上見込みを確認するグラフ。

このように、利用タイミングから逆算します。

権限と更新責任

案件管理は、営業チームだけで閉じないことがあります。

営業、マネージャー、導入担当、サポート、経理、経営が同じ案件を見ることがあります。

だからこそ、誰がどこを更新できるかを決めます。

役割	閲覧	追加	編集	削除
営業担当	自分の案件、関連顧客、活動履歴	案件、活動履歴	自分の案件、次回アクション	原則不可
営業責任者	担当部門の案件	案件、活動履歴	フェーズ、確度、金額の確認	制限付き
導入担当	受注後案件、引き継ぎ情報	活動履歴	導入関連項目	原則不可
経理	受注、請求対象、顧客情報	請求確認	請求関連項目	原則不可
管理者	全体	全体	全体	制限付き
外部連携ユーザー	連携対象のみ	API対象のみ	API対象のみ	原則不可

削除権限は慎重に扱います。

案件や活動履歴を削除できると、あとで営業経緯が説明できません。

間違えた場合は、削除ではなく、取消、無効、重複統合で扱う方が安全です。

kintoneでは、アプリ、レコード、フィールド単位でアクセス権を設定できます。

kintoneヘルプ：アクセス権の設定

案件管理では、特に金額、確度、受注予定、請求関連項目の編集権限を絞ります。

営業担当が自由に直せる項目と、責任者が確認する項目を分けると、売上予測の信用が上がります。

フォーム・MA・帳票・freee連携の境界

案件管理は、外部サービスとつながりやすい領域です。

問い合わせフォームから案件候補が入る。

MAでスコアが上がったリードを案件化する。

見積書を帳票ツールで出す。

受注後にfreeeへ請求情報を渡す。

これらは便利ですが、先に責任範囲を決めないと崩れます。

連携先	kintoneで持つもの	外部に任せるもの
フォーム	受付内容、案件候補、流入元	入力画面、外部公開、本人確認
MA	リードの確認、案件化判断	配信履歴、スコアリング、行動ログ
帳票ツール	見積条件、出力依頼、原本URL	PDF生成、テンプレート、版管理
電子契約	契約待ち、契約完了確認	契約書原本、締結履歴
freee等	請求対象、請求依頼、営業メモ	請求書、入金消込、会計処理
専用SFA	周辺業務、社内確認	高度な営業分析、活動自動記録

フォームやMAから入った情報を、直接案件アプリに入れるかどうかは慎重に決めます。

未確認の問い合わせをすべて案件にすると、案件一覧が薄いリードで埋まります。

まずは受付アプリやリードアプリに入れ、営業対象と確認したものだけ案件化する方が安定します。

会計連携も同じです。

受注したからといって、即請求とは限りません。

開始日、検収、納品、契約条件、請求タイミングを確認してから会計側に渡す必要があります。

kintone案件管理で崩れやすい失敗パターン

kintone案件管理の失敗は、機能不足より設計不足で起きます。

失敗	起きること	設計で直すこと
案件アプリだけ作る	顧客、履歴、見積、請求が混ざる	役割別にアプリを分ける
顧客名を自由入力にする	同じ顧客の案件が分散する	顧客マスタとルックアップを使う
ステータスの意味が曖昧	担当者ごとに進捗判断がずれる	フェーズ定義を明文化する
活動履歴をメモ欄に書く	最終接点、接点回数、次回行動が見えない	活動履歴を1接点1レコードにする
確度が感覚入力になる	売上予測が信用できない	フェーズや顧客行動と確度を結びつける
次回アクションが空欄	案件が放置される	期限、担当、通知を持たせる
見積版を残さない	最新条件や値引き理由が分からない	見積確認や帳票連携を分ける
失注理由を入れない	営業改善に使えない	失注時に理由入力を必須化する
通知を増やしすぎる	重要な滞留通知が埋もれる	期限超過、未対応、例外だけ通知する
請求までkintoneで抱える	会計ソフトと数字がズレる	請求・会計の正本を外部に分ける

特に危ないのは、案件ステータスだけをきれいに整えることです。

ステータスが整っていても、活動履歴、次回アクション、見積版、受注確度、失注理由が説明できなければ、営業管理としては弱いです。

1週間で始めるなら、この順番で作る

最初から完全なSFAを作る必要はありません。

小さく始めるなら、1週間で次の順番で設計します。

日	やること	成果物
1日目	営業プロセスを決める	フェーズ、受注条件、失注条件
2日目	顧客マスタと案件アプリを作る	顧客コード、案件名、担当、金額、確度
3日目	活動履歴を作る	面談、電話、メール、次回アクション
4日目	見積・売上見込みを設計する	見積版、受注予定月、確度、金額
5日目	一覧と通知を作る	期限超過、見積待ち、契約待ち、失注理由未入力
6日目	権限と更新責任を決める	営業、責任者、導入、経理、管理者
7日目	外部連携の境界を整理する	フォーム、MA、帳票、freee、専用SFA

この段階で、高度な営業分析や自動スコアリングまで入れなくて構いません。

まず作るべき状態は、次です。

• 顧客と案件が分かれている
• 案件フェーズの意味が揃っている
• 活動履歴が1接点1レコードで残る
• 次回アクションと期限が見える
• 見積の版や条件が追える
• 受注確度の基準がある
• 失注理由が残る
• 請求・会計の正本がどこか説明できる

ここまでできれば、次に帳票、電子契約、freee、MA、専用SFAとの連携へ進めます。

逆に、この状態を作らないまま自動化すると、間違った進捗や売上見込みが速く広がります。

実装前に決めるチェックリスト

kintoneで案件管理を作る前に、最低限次の質問に答えます。

質問	決めること
1案件の単位は何か	1相談、1見積、1契約、1プロジェクト
顧客マスタとはどうつなぐか	顧客コード、ルックアップ、関連レコード
フェーズの意味は何か	新規、ヒアリング、提案、見積、契約待ち、受注、失注
受注確度の基準は何か	A/B/C、10/30/50/80%、フェーズ連動
活動履歴は何を1件にするか	面談、電話、メール、資料送付、フォロー
次回アクションはどこに持つか	案件内フィールド、タスクアプリ、活動履歴から作成
見積はどこまで持つか	見込み金額、見積版、PDF、帳票ツール
失注理由はどう残すか	選択肢、詳細理由、競合、再提案時期
誰が金額や確度を直せるか	営業、責任者、管理者
請求・会計の正本はどこか	kintone、freee、請求管理、会計ソフト
何を通知するか	期限超過、見積待ち、契約待ち、連携エラー
何をkintoneに持たないか	高度な営業分析、正式請求、入金消込、MAスコア原本

このチェックリストに答えられない状態で案件アプリを作ると、あとからフィールド追加、アプリ分割、権限変更、売上予測の作り直しが続きます。

小さく始めることはできます。

ただし、小さく始める範囲と、最初から設計しておく範囲は分けます。

顧客とのつなぎ方、案件フェーズ、活動履歴、次回アクション、見積、売上見込み、失注理由、請求・会計の境界は、最初に決めた方がよいです。

まとめ

kintoneで案件管理を作るときは、「案件一覧を1つ作る」と考えない方がよいです。

顧客マスタ、案件、活動履歴、見積確認、売上見込み、次回アクション、失注理由、連携ログを分けます。

そのうえで、どの情報を正本にするか、誰が更新するか、どの外部システムに責任を持たせるかを決めます。

kintone案件管理の設計で大事なのは、進捗を見える化することではなく、案件がなぜその状態にあり、次に誰が何をすべきか説明できる状態にすることです。

Excel案件表の置き換え、小規模なBtoB営業、見積前後の社内確認、受注後の引き継ぎなら、kintoneで十分に始められます。

一方で、大規模な営業予測、活動自動記録、MA、電子契約、請求、会計まで含むなら、kintoneは営業周辺業務と確認画面に寄せ、専用システムを正本にする判断も必要です。

ステータスやグラフを整える前に、まず顧客、案件、活動履歴、見積、売上見込み、失注理由の責任範囲を決める。

それが、kintone案件管理を崩れにくくする一番の近道です。