kintone SFAの設計方法｜顧客・案件・活動履歴・売上予測をつなぐ構成

kintoneをSFAとして使いたい相談では、最初に「どんなアプリを作るか」が話題になりがちです。

顧客管理アプリ。

担当者管理アプリ。

案件管理アプリ。

活動履歴アプリ。

日報アプリ。

見積管理アプリ。

売上予測のグラフ。

このあたりを作れば、SFAらしい画面はできます。

ただし、営業チームで使い続けるSFAにするなら、アプリを並べるだけでは足りません。

実務で崩れやすいのは、次のような状態です。

• 顧客、担当者、案件の関係が曖昧で、同じ会社や同じ人が重複登録される
• 案件ステータスの意味が人によって違い、パイプラインが信用できない
• 活動履歴が自由記述だらけで、次回アクションや温度感を集計できない
• 営業日報と案件履歴が二重入力になり、現場が入力しなくなる
• 見積金額と案件金額のどちらが最新か分からない
• 受注確度が担当者の感覚だけで入り、売上予測に使えない
• フォーム、MA、メール、カレンダー、会計ソフトとの境界が曖昧になる
• 専用SFAでやるべき高度な分析までkintoneに抱え込んでしまう

SFAは、営業活動を記録する箱ではありません。

顧客、案件、接点、次回アクション、見積、売上予測をつなぎ、営業チームが次に何をすべきか判断するための業務システムです。

kintone SFAで最初に決めるべきなのは、アプリ名ではなく、「顧客・案件・活動履歴・売上予測のどれをkintoneの正本にするか」です。

この記事では、SFA製品比較ではなく、kintoneをSFAとして使うための業務設計を整理します。

kintone案件管理の設計方法はこちら
kintone顧客管理の設計方法はこちら
kintone売上管理の設計方法はこちら
kintone見積書作成の設計方法はこちら

先に結論：kintoneは完成品SFAではなく営業DBとして設計する

kintoneはSFAとして使えます。

ただし、最初から営業管理の完成品が用意されている専用SFAとは性質が違います。

kintoneは、自社の営業プロセスに合わせて、顧客、案件、活動履歴、見積、売上予測を組み立てる業務アプリ基盤です。

この前提を外すと、判断を誤ります。

「SFAを導入したい」と考えているのに、案件一覧だけを作って終わる。

「kintoneなら自由に作れる」と考えて、項目を増やしすぎる。

どちらも失敗しやすいです。

kintoneでSFAを作るなら、最初から次の単位に分けます。

分けるもの	1レコードの意味	役割
顧客マスタ	1社、1顧客	会社情報、営業担当、契約状態を持つ
担当者マスタ	1人	窓口、決裁者、利用者、連絡先を持つ
案件	1商談、1提案	フェーズ、金額、確度、受注予定を持つ
活動履歴	1回の接点	面談、電話、メール、資料送付を残す
次回アクション	1つの営業タスク	期限、担当、内容、完了状態を追う
営業日報	1日、1担当の活動まとめ	訪問、学び、課題、相談事項を残す
見積	1提出条件、1版	金額、条件、提出日、承認状態を持つ
売上予測	1月、1担当、1案件の見込み	予定月、確度、金額を集計する
連携ログ	1回の取込・出力	フォーム、MA、帳票、会計連携の結果を追う

顧客マスタは会社の辞書です。

担当者マスタは人の辞書です。

案件は営業プロセスの現在地です。

活動履歴は過去の接点です。

次回アクションは未来の行動です。

見積は顧客へ提示した条件です。

売上予測は営業判断のための集計です。

この分け方ができていると、案件の状態だけでなく、なぜその状態なのか、次に何をすべきか、どの金額を見込むべきかまで追えます。

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

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

重要なのは、これを「便利な顧客台帳」としてではなく、営業チームが毎日使う営業DBとして設計することです。

専用SFAとの違い

kintone SFAと専用SFAの違いは、機能数だけではありません。

設計思想が違います。

専用SFAは、営業管理の型が先にあります。

リード、取引先、商談、活動、パイプライン、予測、レポートなどが、最初から一定の前提で用意されています。

kintoneは、自社でその型を作ります。

この違いは、強みにも弱みにもなります。

観点	kintone SFA	専用SFA
初期の自由度	高い	製品の型に合わせる
営業以外との接続	問い合わせ、契約、請求、作業管理につなぎやすい	製品や連携設定に依存する
入力画面	自社向けに絞りやすい	標準項目が多くなりやすい
高度な営業分析	設計と追加実装が必要	標準で強い製品が多い
自動記録	工夫や連携が必要	メール、通話、カレンダー連携が強い製品が多い
運用変更	現場に合わせて変えやすい	権限や設定変更の設計が必要

kintoneが向くのは、営業プロセスがまだ固まり切っておらず、現場の運用に合わせて小さく作りながら改善したいケースです。

たとえば、次のような段階です。

• Excelの案件表をやめたい
• 顧客と案件と活動履歴を分けたい
• 次回アクションの漏れを防ぎたい
• 見積や請求前確認と営業管理をつなげたい
• 営業、サポート、管理部門で同じ顧客情報を見たい
• 専用SFAを入れる前に営業プロセスを整理したい

一方で、次の要件が強い場合は、最初から専用SFAやBIを検討した方がよいです。

専用SFAへ寄せる条件	理由
営業人数が多く、部門階層が複雑	権限、承認、レポートが重くなる
メール、通話、商談ログを自動記録したい	専用CRMの自動連携が強い
精緻な売上予測やパイプライン分析が必要	専用SFAやBIの分析機能が向く
マーケティング施策から商談化まで一体管理したい	MAとCRMの標準連携が重要になる
グローバル営業や複数法人で使う	通貨、言語、組織階層の要件が重い

kintone SFAは、専用SFAの廉価版として考えるより、「営業周辺業務までつながる自社用の営業DB」として考えた方が設計しやすいです。

顧客・担当者・案件・活動履歴を分ける

kintone SFAで最初に崩れやすいのは、顧客、担当者、案件、活動履歴を1つのアプリに混ぜることです。

これらは似ていますが、レコードの意味が違います。

データ	1レコードの意味	混ぜたときの問題
顧客	1社、1組織	商談ごとの変化を顧客情報に上書きしてしまう
担当者	1人	異動、退職、複数窓口に弱くなる
案件	1商談、1提案	同じ顧客の複数案件を扱いにくい
活動履歴	1接点	メモ欄に埋もれて、最終接点や次回予定が見えない

最低限、次のアプリ構成を考えます。

アプリ	主なフィールド	設計意図
顧客マスタ	顧客コード、正式名称、業種、担当部署、営業担当	顧客情報の正本にする
担当者マスタ	氏名、所属顧客、役職、役割、メール、電話	窓口や決裁者を分ける
案件	顧客、担当者、案件名、フェーズ、金額、確度、予定月	営業プロセスを管理する
活動履歴	日時、種別、案件、顧客、担当者、要点、次回予定	接点の履歴を残す
次回アクション	期限、担当、案件、内容、完了状態	放置案件を減らす

顧客マスタには、比較的変わりにくい情報を置きます。

会社名、顧客コード、業種、担当営業、契約状態、与信メモ、主要部署。

担当者マスタには、人に紐づく情報を置きます。

氏名、役職、メール、電話、窓口種別、決裁関与、退職・異動フラグ。

案件には、営業プロセスの現在状態を置きます。

フェーズ、金額、確度、受注予定月、次回アクション日、提案商品、失注理由。

活動履歴には、過去の接点を置きます。

面談、電話、メール、資料送付、デモ、社内確認、次回約束。

kintoneでは、関連レコード一覧を使って、顧客詳細画面に案件や問い合わせ履歴を表示できます。

サイボウズの関連レコード一覧ガイドでも、別アプリや同一アプリの関連レコードを表示し、条件で絞り込めることが紹介されています。

kintone：関連レコード一覧の基本を学ぶ

顧客画面に案件一覧を表示する。

案件画面に活動履歴を表示する。

担当者画面に接点履歴を表示する。

このように、データは分け、画面では集めて見せる設計にします。

営業ステータスと受注確度

SFAの中心は、案件ステータスです。

ただし、ステータス名を作るだけでは営業管理になりません。

各ステータスの意味、次に進む条件、戻る条件、失注条件を決めます。

ステータス	意味	次に進む条件
リード	接点はあるが案件化前	課題、予算、時期、担当者のいずれかが確認できた
初回接触	初回面談やヒアリング前後	課題と次回アクションが決まった
要件確認	課題、現状、関係者を確認中	提案方針を出せる状態になった
提案準備	提案書、見積、デモを準備中	顧客へ提案日が決まった
提案済み	提案や見積を出した	顧客側の検討状況を確認した
契約調整	条件、稟議、契約を調整中	契約条件が合意された
受注	契約や注文が確定した	導入・請求へ引き継ぐ
失注	受注しないことが確定した	理由と再提案可能性を残す

ステータスは、営業担当が気分で選ぶものではありません。

営業チームが同じ判断をするための共通言語です。

受注確度も同じです。

30%、50%、80%という数字だけを置いても、担当者ごとの感覚が違えば使えません。

確度	判断基準の例
10%	接点はあるが、課題・時期・予算が未確認
30%	課題は確認済みだが、決裁者や予算が未確認
50%	提案済みで、予算・時期・関係者が見えている
70%	条件調整中で、競合や稟議の論点が明確
90%	契約・注文の具体手続きに入っている

確度は営業担当の期待値ではありません。

案件の客観条件です。

そのため、確度を選ぶときは、確認済み情報に基づくようにします。

確認項目	見る理由
課題	本当に提案すべき理由があるか
予算	提案金額が現実的か
時期	いつまでに決める必要があるか
決裁者	誰が最終判断するか
競合	比較対象は何か
社内稟議	顧客側の意思決定プロセスを把握しているか
次回アクション	次の接点が決まっているか

kintoneのプロセス管理は、ステータスとアクションを設定して、業務の流れを管理できます。

公式ヘルプでも、事前に業務の流れを整理し、ステータスやプロセスを設定する手順が説明されています。

kintoneヘルプ：基本的なプロセス管理の設定

SFAでは、すべての案件ステータスをプロセス管理にする必要はありません。

ただし、受注、失注、見積承認、引き継ぎなど、責任が切り替わる場面には使いやすいです。

入力負荷を下げる項目設計

kintone SFAで一番失敗しやすいのは、入力項目を増やしすぎることです。

営業管理をきれいにしたい側は、たくさんの項目を作りたくなります。

流入経路。

業種。

部署。

商品カテゴリ。

予算。

競合。

検討時期。

課題。

決裁者。

提案内容。

次回アクション。

失注理由。

これらはすべて重要です。

しかし、初回入力で全部求めると、現場は入力しなくなります。

入力設計では、項目を3つに分けます。

項目の種類	例	扱い方
最初から必須	顧客、案件名、担当者、フェーズ、次回アクション日	登録に必要な最小項目にする
フェーズで必須	予算、決裁者、競合、提案日、見積金額	進捗に応じて埋める
受注・失注時に必須	受注理由、失注理由、競合、次回提案可能性	結果確定時に入力する

初回登録で必要なのは、案件を見失わないための情報です。

顧客。

案件名。

担当者。

フェーズ。

次回アクション日。

この5つが入れば、最低限の管理はできます。

逆に、次回アクション日が空欄なら、SFAとしては危険です。

案件は登録されても、次に何をするかが分からないからです。

kintone SFAでは、最初から詳細項目を埋めさせるより、「次回アクションが空欄の案件を作らない」ことを優先します。

入力負荷を下げるには、自由入力を減らします。

項目	避けたい形	推奨する形
フェーズ	自由入力	選択肢、ステータス
受注確度	担当者の感覚	判断基準つき選択肢
活動種別	メモ欄	面談、電話、メール、デモなど
次回アクション	コメント	期限つきタスク
失注理由	長文メモだけ	選択肢と補足
商品カテゴリ	手入力	マスタ参照

選択肢を作ると、集計できます。

ただし、選択肢を増やしすぎると選べません。

初期は少なく始め、実データを見ながら増やします。

日報・見積・売上予測とのつなぎ方

SFAは、案件管理だけではありません。

営業日報、見積、売上予測とつながって初めて、営業チームの判断に使えます。

営業日報との関係

日報を作る場合は、案件や活動履歴と二重入力にしないことが重要です。

日報は、1日の活動のまとめです。

活動履歴は、顧客や案件に紐づく接点です。

この2つを混ぜると、同じ面談内容を日報と案件履歴の両方に入力することになります。

データ	役割
活動履歴	顧客・案件ごとの接点を残す
日報	1日の活動量、気づき、相談事項を残す
次回アクション	期限つきの営業タスクを残す

日報には、活動履歴の件数や主な内容を集約します。

営業マネージャーが見るべきなのは、すべての面談メモではありません。

重点案件、未対応、相談事項、次に詰まっていることです。

見積との関係

案件金額と見積金額も分けます。

案件金額は、営業上の見込みです。

見積金額は、顧客へ提示した条件です。

見積書の設計では、版管理、承認、帳票出力、受注・請求連携が重要になります。

kintone見積書作成の設計方法はこちら

SFA側では、案件に最新見積の概要を戻します。

案件に戻す情報	理由
最新見積番号	どの提案が最新か分かる
最新見積金額	売上予測に使う
提出日	顧客への提示状況を見る
有効期限	フォロー期限に使う
承認状態	提出してよい条件か判断する

見積明細や帳票PDFそのものを案件に詰め込む必要はありません。

案件では、営業判断に必要な要約を見る設計にします。

売上予測との関係

売上予測は、案件一覧の金額を足すだけでは作れません。

見込み金額、受注予定月、確度、フェーズ、営業担当、商品カテゴリを揃える必要があります。

予測に使う項目	注意点
見込み金額	見積金額と混同しない
受注予定月	請求月や売上計上月と分ける
確度	判断基準を揃える
フェーズ	進捗別に集計する
担当者	引き継ぎ時の扱いを決める
商品カテゴリ	集計軸をマスタ化する

kintone公式の顧客・案件管理用途ページでも、営業担当別の案件数、進捗具合、売上予測などをグラフ化できることが紹介されています。

ただし、グラフを作る前に、元データを揃えます。

元データが揺れている状態でグラフを作ると、見た目は整っていても判断には使えません。

MA・フォーム・会計連携

kintone SFAは、単体で閉じるより、周辺サービスとの境界を決めると強くなります。

特に、フォーム、MA、メール、帳票、会計ソフトとの関係を整理します。

連携先	kintoneに渡すもの	kintoneから渡すもの
Webフォーム	リード情報、問い合わせ内容	対応状態、担当者
展示会・セミナー	名刺、参加情報、興味テーマ	フォロー状態
MA	流入元、スコア、閲覧履歴	商談化、受注、失注
メール・カレンダー	接点の原本、予定	案件ID、顧客ID
帳票ツール	見積データ、提案条件	出力結果、PDF
freee・会計	受注後の請求対象	請求状態、入金状態

ここで重要なのは、すべてをkintoneへ集約しようとしないことです。

MAの行動履歴をすべてkintoneにコピーする必要はありません。

メール本文をすべてkintoneに複製する必要もありません。

会計ソフトの請求・入金・仕訳をkintoneで再実装する必要もありません。

kintoneに持つのは、営業判断に必要な要約と状態です。

データ	kintoneに持つ粒度
MAスコア	最新スコア、主要行動、流入元
メール	原本URL、送受信日、要点、次回予定
カレンダー	面談日、参加者、案件紐づけ
帳票	最新見積番号、金額、提出日、出力結果
会計	請求済み、入金済み、未入金、連携エラー

会計ソフトとの連携では、kintoneを正式な会計台帳にしない方がよいケースが多いです。

受注後の請求、入金、仕訳は、freeeなどの会計ソフトを正本にし、kintoneには営業や管理が見るべき状態を戻す設計にします。

kintone請求書管理の設計方法はこちら

通知・リマインダーの設計

SFAで重要なのは、入力された情報を見ることだけではありません。

次に動くべきタイミングで通知することです。

kintoneの通知では、レコード追加、更新、ステータス変更、条件通知、リマインダー条件通知などを使えます。

公式ヘルプでも、条件に合致したレコードに対する通知や、日時を条件にしたリマインダー通知が説明されています。

kintoneヘルプ：通知が送信されるタイミングと宛先

SFAでは、次の通知を設計します。

通知	条件	通知先
次回アクション前日	次回アクション日が明日	担当営業
放置案件	活動履歴が一定期間ない	担当営業、マネージャー
提案後フォロー	提案日から一定日数経過	担当営業
見積期限切れ	見積有効期限が近い	担当営業
大型案件更新	金額が一定以上	マネージャー
失注登録	失注になった	営業責任者
受注登録	受注になった	導入担当、管理部門

通知は多ければよいわけではありません。

通知が多すぎると、誰も見なくなります。

営業担当に送る通知と、マネージャーに送る通知は分けます。

営業担当には次回行動。

マネージャーには放置、停滞、大型案件、失注。

管理部門には受注後の引き継ぎ。

このように、通知の目的を分けます。

専用SFAへ逃がすケース

kintoneでSFAを作るとき、どこまでkintoneでやるかを決めておく必要があります。

すべてをkintoneで作ることはできます。

しかし、作れることと、運用すべきことは違います。

次の要件が強くなったら、専用SFA、MA、BI、会計ソフトへ逃がす判断をします。

要件	逃がす先	理由
メール・通話の自動記録	専用CRM、SFA	自動同期と検索が重要
リードスコアリング	MA	Web行動、配信、スコアの正本になる
高度なパイプライン分析	専用SFA、BI	予測、目標、部門別分析が重い
複雑な営業組織	専用SFA	権限階層、テリトリー、承認が重い
正式な請求・入金管理	会計ソフト	売掛金、入金消込、仕訳が必要
契約書の締結管理	電子契約、契約管理	契約原本、締結状態、更新管理が必要

Bitlightとしては、kintone SFAを最初の営業基盤として作るのは現実的だと考えます。

特に、営業プロセスがまだ固定されておらず、問い合わせ、見積、請求前確認、導入作業まで周辺業務とつなげたい会社には合います。

ただし、営業組織が大きくなり、予測精度、活動自動記録、高度な権限、複雑なレポートが主目的になったら、専用SFAへ寄せた方がよいです。

大事なのは、最初から逃げ道を設計しておくことです。

顧客ID、案件ID、担当者ID、商品カテゴリ、フェーズ、確度の定義を整理しておけば、将来別ツールへ移すときも破綻しにくくなります。

よくある失敗パターン

kintone SFAでは、次の失敗がよく起きます。

失敗1：案件一覧だけでSFAだと思う

案件名、金額、担当者、ステータスだけでは、SFAとして弱いです。

顧客、担当者、活動履歴、次回アクション、見積、売上予測とつながって初めて営業判断に使えます。

失敗2：活動履歴をメモ欄に積む

メモ欄は簡単ですが、活動種別、接点日、次回予定、担当者、顧客反応を集計できません。

活動履歴は1接点1レコードで残す方が後で使えます。

失敗3：ステータスの定義がない

「提案中」「見込み」「契約調整」の意味が人によって違うと、パイプラインが信用できません。

ステータスごとに、進む条件と戻る条件を決めます。

失敗4：入力項目を増やしすぎる

管理側が見たい項目を全部必須にすると、営業は入力しません。

最初は少なく始め、フェーズごとに必須項目を増やします。

失敗5：日報と活動履歴が二重入力になる

日報は1日のまとめ、活動履歴は顧客・案件ごとの接点です。

両方に同じ内容を書かせると定着しません。

失敗6：売上予測の元データが揺れる

見込み金額、見積金額、受注金額、請求金額を混ぜると、予測が崩れます。

どの金額をどの集計に使うかを決めます。

失敗7：外部連携の正本が曖昧

フォーム、MA、メール、帳票、会計ソフトと連携する場合、どちらが正本かを決めます。

両方で編集できる状態にすると、どちらが正しいか分からなくなります。

2週間で始めるならこの順番

最初から完璧なSFAを作ろうとすると、現場がついてきません。

まずは、案件の放置を減らし、営業チームで同じ状態を見られる構成から始めます。

1日目：営業プロセスを書き出す

現在の営業の流れを、実際の言葉で書き出します。

• 問い合わせはどこから来るか
• 初回接触後に何を確認するか
• いつ案件化するか
• 誰が見積を作るか
• どの条件で提案済みにするか
• いつ失注にするか
• 受注後に誰へ引き継ぐか

ここで、理想の営業フローではなく、今の実態を見ます。

2日目：最小アプリを決める

最初は、顧客、担当者、案件、活動履歴、次回アクションから始めます。

日報、見積、売上予測、MA連携は、最初から作り込みすぎない方がよいです。

3日目：案件ステータスを定義する

ステータス名と進む条件を決めます。

「提案中」の意味を曖昧にしないことが重要です。

4日目：入力項目を削る

初回登録で必須にする項目を絞ります。

顧客、案件名、担当者、フェーズ、次回アクション日。

まずはこれで十分です。

5日目：活動履歴を設計する

活動種別、接点日、要点、顧客反応、次回アクションを決めます。

長文メモだけにしないようにします。

6日目：一覧と通知を作る

営業担当向けには、自分の次回アクション一覧。

マネージャー向けには、放置案件、停滞案件、大型案件、失注理由一覧。

この2つを分けます。

7日目：見積・売上予測との接続を決める

見積を別アプリにするか、案件に要約だけ持つかを決めます。

売上予測では、どの金額とどの確度を使うかを決めます。

8日目以降：試験運用しながら削る

最初の2週間は、項目を増やすより削ります。

入力されていない項目。

誰も見ていない一覧。

多すぎる通知。

これらを減らします。

SFAは、作った瞬間ではなく、毎日入力される状態になって初めて価値が出ます。

実装前チェックリスト

kintone SFAを作る前に、次の項目を確認します。

チェック項目	確認内容
顧客単位	法人、部署、店舗、拠点のどれを1顧客にするか
担当者	窓口、決裁者、利用者を分けるか
案件化条件	どの段階から案件にするか
ステータス	各フェーズの意味と進む条件があるか
確度	10%、30%、50%などの判断基準があるか
活動履歴	1接点1レコードで残すか
次回アクション	空欄案件を許すか
日報	活動履歴と二重入力にならないか
見積	案件金額と見積金額を分けるか
売上予測	予定月、確度、金額の定義が揃っているか
通知	営業向けとマネージャー向けを分けているか
フォーム連携	リード登録と案件化のルールがあるか
MA連携	スコアや行動履歴をどの粒度で持つか
会計連携	受注後の請求、入金、仕訳をどこで持つか
専用SFAへの逃げ道	顧客ID、案件ID、商品カテゴリを整理しているか

この表が埋まらないままアプリを作ると、あとから運用で詰まります。

特に、ステータス、確度、次回アクション、見積金額の扱いは先に決めます。

Bitlightに相談するなら、最初に見たいもの

kintone SFAの相談では、最初に次の情報があると設計が早くなります。

用意してほしいもの	見る理由
現在の案件表	どの項目が実際に使われているかを見る
営業会議の資料	マネージャーが何を判断しているかを見る
見積書テンプレート	案件金額と見積金額の関係を見る
日報や活動報告	二重入力になっている場所を見る
問い合わせ・フォーム項目	リード登録と案件化の入口を見る
失注メモ	失注理由の分類を作る
会計ソフト運用	受注後の請求・入金との境界を見る

完成した要件定義書は不要です。

むしろ、今使っているExcel、スプレッドシート、営業会議資料、見積書、日報、フォーム項目がある方が、実務に合う設計にできます。

Bitlightでは、kintoneにSFA風のアプリを作るだけではなく、営業チームが毎日入力し、マネージャーが判断に使い、管理部門へ引き継げる構成まで整理します。

具体的には、次の論点を一緒に決めます。

• 顧客、担当者、案件、活動履歴の分け方
• 案件ステータスと受注確度の定義
• 初回入力で必須にする項目
• フェーズごとに必須にする項目
• 日報と活動履歴の役割分担
• 見積、売上予測、請求前確認とのつなぎ方
• フォーム、MA、帳票、会計ソフトとの境界
• 専用SFAへ移行する可能性を残すデータ設計

ここまで決めると、kintoneは単なる案件表ではなく、営業プロセスを動かすSFAになります。

まとめ

kintoneはSFAとして使えます。

ただし、専用SFAの完成品をそのまま期待するより、自社の営業プロセスに合わせて営業DBを作ると考えた方がうまくいきます。

顧客と担当者を分ける。

案件と活動履歴を分ける。

活動履歴と日報を分ける。

案件金額と見積金額を分ける。

受注予定と請求・入金を分ける。

MA、フォーム、帳票、会計ソフトとの正本を分ける。

これらを整理すると、kintone SFAは営業チームの入力箱ではなく、次回アクション、パイプライン、見積、売上予測、引き継ぎをつなぐ業務システムになります。

kintone SFAは、案件を登録するためではなく、営業チームが同じ顧客・案件・活動履歴を見て、次の行動と売上見込みを判断するために設計します。

最初に作るべきなのは、豪華なダッシュボードではありません。

顧客、担当者、案件、活動履歴、次回アクションの分け方です。

その土台ができてから、日報、見積、売上予測、フォーム、MA、会計連携を足していく方が、現場で使われるSFAになります。