kintone顧客管理の設計方法｜顧客マスタ・案件・対応履歴が崩れない構成

kintoneで顧客管理を作る相談では、「顧客管理アプリを1つ作ればよいか」という話になりがちです。

会社名、担当者名、電話番号、メール、住所、営業担当、メモ、ステータス。

これらを1つのアプリに並べれば、たしかに顧客台帳は作れます。

ただし、営業、問い合わせ、保守、契約更新、請求確認まで使う顧客管理では、1つの顧客管理アプリだけでは長く持ちません。

実務で困るのは、顧客情報を登録できないことではなく、次のような状態です。

• 同じ会社が別名で複数登録される
• 会社と担当者が混ざり、異動や退職に対応できない
• 商談ステータスを顧客マスタに直接上書きして、過去商談が追えない
• 面談メモ、電話メモ、問い合わせ履歴がページ本文やコメントに散らばる
• 営業、サポート、経理のどこが顧客情報を直すべきか決まっていない
• 問い合わせ、契約、請求、入金の情報が顧客アプリに混ざる
• フォーム、MA、メール、freeeなど外部サービスとの責任範囲が曖昧になる

kintoneで顧客管理を作るなら、最初に設計すべきなのは「顧客管理アプリ」ではありません。

顧客マスタ、担当者、案件、活動履歴、問い合わせ、契約・請求確認を、どの単位のデータとして分けるかです。

kintone顧客管理で最初に決めるべきなのは、フィールド名ではなく、「顧客情報の正本をどこに置き、案件・対応履歴・問い合わせをどう分けるか」です。

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

Excelからkintoneへ移行する考え方はこちら

先に結論：顧客管理は1アプリで完結させない

kintoneで顧客管理を作るとき、最初は1つのアプリにまとめたくなります。

顧客名、担当者、メール、電話番号、営業担当、メモ、ステータス。

この程度なら1アプリでも始められます。

しかし、顧客管理で扱う情報には、性質の違うものが混ざっています。

分けるもの	1レコードの意味	役割
顧客マスタ	1社、または1顧客	正式名称、顧客コード、担当責任、契約状態を持つ
担当者マスタ	1人	顧客側の窓口、決裁者、利用者、連絡先を持つ
案件	1商談、1相談、1プロジェクト	提案、見積、受注、失注、次回アクションを持つ
活動履歴	1回の接点	面談、電話、メール、資料送付、フォローを残す
問い合わせ	1件の問い合わせ	受付、担当、対応状態、解決、再発を追う
契約・請求確認	1契約、1請求対象	契約状態、更新日、請求対象、確認状態を見る
連携ログ	1回の外部連携	フォーム、MA、会計、メール連携の成否を追う

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

案件は、営業や導入の流れです。

活動履歴は、接点の記録です。

問い合わせは、対応すべき業務イベントです。

契約や請求は、正式な台帳や会計処理とつながります。

これらを1アプリに混ぜると、顧客情報を直したいだけなのに案件履歴まで触れてしまう、問い合わせ対応だけを見たいのに営業メモが混ざる、といった状態になります。

kintoneでは、アプリ同士をルックアップ、関連レコード一覧、アプリアクションなどで連携できます。

kintoneヘルプ：アプリ間でデータを連携する

この特徴を使って、顧客管理を「1つの大きな表」ではなく「役割の違うアプリ群」として設計します。

kintone顧客管理が向く業務と向かない業務

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

向いているのは、顧客情報を軸に、営業、問い合わせ、サポート、契約確認、社内申請などをつなぎたい業務です。

kintoneに向く顧客管理	理由
Excel顧客台帳の置き換え	重複、最新版、閲覧権限、入力履歴を整えやすい
BtoBの顧客・担当者管理	会社、担当者、案件、履歴を分けて持てる
問い合わせ管理と顧客情報の連携	顧客別に対応履歴を見られる
契約更新や保守期限の管理	期限一覧、通知、担当者変更を作りやすい
営業とサポートの情報共有	部署ごとに必要な一覧を作れる
外部フォームからのリード登録	入力内容を顧客・問い合わせ・案件に分けられる

一方で、次の条件が強い場合は、kintoneだけで完結させるより、専用CRMや会計ソフト、MAツールを正本にした方がよいことがあります。

kintoneだけでは重い顧客管理	理由
大規模な営業パイプライン管理	高度な予測、商談分析、営業活動管理は専用CRMが強い
メール配信やスコアリング中心	配信停止、到達率、スコアリングはMAの責任範囲になる
請求、入金、会計処理まで正式管理	税務、会計、請求書発行は会計ソフトを正本にするべき
コールセンター型の大量問い合わせ	SLA、通話、ナレッジ、キュー管理が必要になる
厳密な個人情報管理が必要	閲覧範囲、監査、保持期間、削除ポリシーの設計が重くなる

ここで無理に「全部kintoneでやる」と決めない方がよいです。

kintoneは、現場が業務に合わせてアプリを作り、複数部門で顧客情報を見られる状態を作るには強いです。

ただし、営業CRM、MA、会計、メール配信、問い合わせ管理のすべてを抱え込むと、責任範囲が曖昧になります。

kintoneを顧客情報の正本にするのか、顧客に紐づく業務の入口にするのかを先に分ける ことが重要です。

最初に分けるアプリ構成

kintone顧客管理で最初に作るべきアプリは、顧客管理アプリ1つではありません。

最低限、次の単位に分けて考えます。

アプリ	1レコードの意味	主なフィールド
顧客マスタ	1社、1顧客	顧客コード、正式名称、種別、担当部署、担当者、契約状態
担当者マスタ	1人	氏名、所属顧客、役職、役割、メール、電話、利用状態
案件	1商談、1相談	顧客、担当者、フェーズ、金額、確度、次回アクション
活動履歴	1接点	日時、種別、顧客、担当者、案件、要点、原本URL
問い合わせ	1問い合わせ	受付日、顧客、内容、担当、状態、期限、解決内容
契約・請求確認	1契約、1請求対象	契約開始、更新日、請求対象、請求状態、会計連携先
連携ログ	1連携処理	連携元、対象、結果、エラー、再実行状態

小さく始める場合でも、顧客マスタと活動履歴は分けます。

なぜなら、顧客マスタは「今の顧客状態」を見る場所で、活動履歴は「過去に何があったか」を残す場所だからです。

顧客マスタのメモ欄にすべてを書き足すと、最後に誰が何をしたかは見えても、接点ごとの履歴や次回アクションが拾えません。

顧客マスタは「会社名の一覧」ではない

顧客マスタで最初に決めるべきなのは、会社名の入力欄ではありません。

「何を1顧客として扱うか」です。

法人単位なのか、事業所単位なのか、店舗単位なのか、部署単位なのか。

ここを曖昧にすると、あとで同じ会社が複数登録されたり、逆に別拠点を同じ顧客として扱ってしまったりします。

論点	例	設計判断
顧客単位	法人、店舗、事業所、部署	請求、契約、対応責任の単位で決める
顧客コード	C-0001、取引先コード	表記揺れと重複を防ぐキーにする
正式名称	株式会社、支店名、屋号	請求書や契約書と揃える
表示名	略称、通称	現場が探しやすい名称を別に持つ
種別	リード、見込み、既存、休眠、パートナー	営業やサポートの扱いを分ける
担当責任	営業担当、CS担当、管理部署	誰が更新するかを決める
契約状態	未契約、契約中、更新待ち、終了	案件や契約アプリと連動させる

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

会社名、顧客コード、住所、業種、担当部署、契約状態、社内担当。

反対に、日々変わる商談メモ、問い合わせ詳細、電話内容、請求メモは別アプリに分けます。

顧客マスタに置く	別アプリに分ける
正式名称	面談メモ
顧客コード	電話履歴
顧客種別	商談フェーズの変更履歴
社内担当	問い合わせ内容
契約状態の概要	請求書番号、入金消込
利用状態	サポート対応の詳細

顧客マスタで避けたいのは、会社名を自由入力で各アプリに散らすことです。

案件アプリにも会社名、問い合わせアプリにも会社名、請求確認アプリにも会社名を手入力すると、表記揺れが必ず起きます。

顧客マスタを作り、他のアプリはルックアップや関連レコードで参照する。

これが顧客管理の基本です。

担当者は顧客マスタに直接書き込まない

顧客管理では、会社と人を分けます。

1社に担当者が1人だけなら、顧客マスタに担当者名を持たせても始められます。

しかし、実務ではすぐに次の状態になります。

• 窓口と決裁者が違う
• 経理担当と現場担当が違う
• 担当者が異動、退職する
• 同じ会社の別部署から別案件が来る
• サポート窓口と営業窓口が違う
• メール配信してよい人、してはいけない人が分かれる

この時点で、担当者マスタを分けた方が安定します。

フィールド	型	設計意図
氏名	文字列	担当者を識別する
所属顧客	ルックアップ、関連レコード	顧客マスタとつなぐ
部署・役職	文字列、選択肢	意思決定や連絡経路を把握する
役割	ドロップダウン	窓口、決裁者、利用者、経理、紹介者などを分ける
メール	メール	連絡先として使う
電話	電話番号	必要な場合のみ持つ
連絡可否	チェック、選択肢	メール配信、営業連絡の可否を管理する
利用状態	ドロップダウン	現役、異動、退職、不明などを分ける

担当者を削除するのは慎重にします。

退職や異動があっても、過去の商談や問い合わせ履歴にはその人が関わっていた事実が残ります。

削除ではなく、利用状態を「退職」「異動」「連絡不可」に変える方が安全です。

個人情報を扱うため、閲覧権限も設計対象です。

全社員が担当者の電話番号やメールを見られる必要がない場合は、アプリやフィールドのアクセス権を使って制御します。

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

案件は顧客マスタのステータスに混ぜない

顧客管理と案件管理は近いですが、同じではありません。

顧客マスタは、顧客という相手の情報です。

案件は、その顧客との特定の商談、相談、プロジェクトです。

同じ顧客から、複数の案件が発生することがあります。

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

このとき、顧客マスタに「商談中」「受注」「失注」といったステータスを1つだけ持たせると、過去の経緯が消えます。

混ぜた設計	起きる問題
顧客マスタに商談ステータスを持つ	複数案件を扱えない
顧客マスタに見積金額を持つ	どの案件の金額か分からない
顧客マスタに失注理由を書く	過去案件と現在案件が混ざる
顧客マスタに次回アクションを書く	担当者別、案件別のタスクが見えない

案件アプリは、1商談または1相談を1レコードにします。

フィールド	型	設計意図
案件名	文字列	商談や相談を識別する
顧客	ルックアップ、関連レコード	顧客マスタとつなぐ
主担当者	ルックアップ、関連レコード	顧客側担当者をつなぐ
社内担当	ユーザー選択	営業責任者を決める
フェーズ	ステータス、ドロップダウン	初回接点、提案中、見積中、契約待ち、受注、失注
見込み金額	数値	売上見込みを見る
確度	選択肢、数値	受注可能性を揃える
次回アクション日	日付	放置を防ぐ
失注理由	ドロップダウン、文字列	振り返りに使う

フェーズは作りすぎない方がよいです。

営業担当ごとに「提案中」「確認中」「検討中」「折り返し待ち」の意味が違うと、一覧やグラフが信用できなくなります。

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

フェーズ	意味
新規	問い合わせ、紹介、流入直後
ヒアリング中	課題や条件を確認している
提案中	提案内容を整理している
見積中	金額、範囲、条件を詰めている
契約待ち	発注、稟議、契約の待ち
受注	発注または契約済み
失注	見送り、競合負け、時期不一致

案件フェーズをプロセス管理で扱う場合は、一覧、通知、アクセス権と組み合わせると運用しやすくなります。

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

活動履歴は1回の接点を1レコードにする

顧客管理で一番散らばりやすいのが、活動履歴です。

メールした。

電話した。

面談した。

資料を送った。

問い合わせに回答した。

次回連絡を約束した。

これらを顧客マスタのメモ欄に書くと、履歴は残りますが、業務では使いづらくなります。

活動履歴は、1回の接点を1レコードにします。

フィールド	型	設計意図
件名	文字列	何の接点かを識別する
日時	日時	いつ対応したかを残す
種別	ドロップダウン	電話、メール、面談、オンラインMTG、資料送付など
顧客	ルックアップ、関連レコード	顧客マスタとつなぐ
担当者	ルックアップ、関連レコード	顧客側の誰と話したかを残す
関連案件	関連レコード	どの案件に紐づく接点かを残す
社内対応者	ユーザー選択	誰が対応したかを残す
要点	テキスト	会話や対応の要点
決定事項	テキスト	決まったこと
次アクション	文字列、関連レコード	次にやることへつなぐ
原本URL	URL	メール、議事録、録画、チャットへ戻れるようにする

活動履歴を分けると、次のような一覧が作れます。

一覧	条件	見る人
今週の接点	日時が今週	営業、CS
30日接点なし	最終活動日が30日以上前	担当者、管理者
次アクション未設定	次アクションが空	営業責任者
決定事項あり	決定事項が空でない	プロジェクト担当
原本未添付	原本URLが空	対応者

ここで重要なのは、活動履歴を「日報」にしすぎないことです。

営業日報として長文を書くより、顧客、案件、日時、種別、要点、次アクションを構造化して残す方が、あとで使えます。

問い合わせは案件と分ける

顧客管理に問い合わせを混ぜる会社は多いです。

既存顧客からの質問、トラブル、追加依頼、契約前の相談。

これらをすべて案件として扱うと、営業パイプラインが汚れます。

逆に、すべてを顧客マスタのメモ欄に書くと、対応漏れが見えません。

問い合わせは、1件の問い合わせを1レコードにします。

フィールド	型	設計意図
問い合わせ番号	自動採番、文字列	受付番号として使う
受付日	日時	いつ受けたか
顧客	ルックアップ、関連レコード	顧客マスタとつなぐ
担当者	ルックアップ、関連レコード	問い合わせ元を残す
種別	ドロップダウン	質問、障害、追加依頼、契約相談など
優先度	ドロップダウン	通常、重要、緊急など
状態	ステータス	未対応、対応中、確認待ち、解決、保留
期限	日付	対応期限を持つ
対応担当	ユーザー選択	誰が対応するか
解決内容	テキスト	どう解決したか
関連案件	関連レコード	商談化した場合につなぐ

問い合わせで見るべき一覧は、全件一覧ではありません。

一覧	条件	見る人
未対応	状態が未対応	サポート、営業
期限超過	期限が過ぎて未解決	管理者
確認待ち	状態が確認待ち	対応担当
緊急	優先度が緊急	責任者
商談化候補	種別が追加依頼、契約相談	営業

問い合わせが商談に変わることはあります。

その場合も、問い合わせレコードを案件レコードに上書きするのではなく、関連案件としてつなぎます。

問い合わせは問い合わせとして、いつ何を受け、どう対応したかを残す。

案件は案件として、提案、見積、受注、失注を追う。

この分け方にすると、サポートと営業が同じ顧客を見ても、情報が混ざりにくくなります。

契約・請求はkintoneだけで抱え込まない

顧客管理では、契約や請求の情報も見たくなります。

契約中かどうか。

契約更新日はいつか。

請求対象かどうか。

入金済みかどうか。

これらを顧客マスタに持たせることはできます。

ただし、正式な請求書、売上、入金消込、会計処理までkintoneを正本にするのは慎重に考えるべきです。

領域	kintoneで持ちやすいもの	外部システムを正本にしやすいもの
契約	契約状態、更新日、担当者、注意事項	契約書原本、電子契約の締結履歴
請求	請求対象の確認、請求依頼、例外メモ	請求書番号、税区分、正式な請求書
入金	入金確認依頼、未入金の社内共有	入金消込、会計仕訳、残高管理
会計	請求前確認、顧客別メモ	売上、仕訳、税務処理

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

kintoneは、営業やサポートが見る「この顧客は請求対象か」「契約更新が近いか」「未請求の作業がないか」を確認する画面に寄せる方が安全です。

会計ソフトとの連携を作る場合も、先に決めることがあります。

決めること	例
顧客の正本	kintoneの顧客マスタか、会計ソフトの取引先か
同期方向	kintoneから会計へ送るか、会計からkintoneへ戻すか
更新タイミング	受注時、請求依頼時、月次締め前など
修正ルール	締め後の顧客名変更、請求先変更をどう扱うか
エラー対応	連携失敗、重複、必須項目不足を誰が直すか

顧客管理で契約・請求を見せることと、請求・会計の正本をkintoneに置くことは別です。

この線引きをしないと、営業はkintoneを見て、経理は会計ソフトを見て、どちらが正しいか分からなくなります。

フォーム・MA・メール連携の境界

顧客管理は、外部から情報が入ってきます。

問い合わせフォーム、資料請求、セミナー申込、メール配信、名刺交換、紹介、広告流入。

これらをkintoneに入れる場合、最初から顧客マスタへ直接登録しない方がよいことがあります。

未確認の流入情報を、そのまま正式な顧客マスタに入れると、重複や表記揺れが増えるからです。

流入元	まず置く場所	顧客マスタへ反映する条件
問い合わせフォーム	問い合わせアプリ	会社名、連絡先、重複確認後
資料請求	リードアプリ、問い合わせアプリ	営業対象として確認後
セミナー申込	参加者アプリ	既存顧客との照合後
メール返信	活動履歴、問い合わせ	対応者が内容を確認後
名刺	担当者候補アプリ	会社・担当者の重複確認後

フォームやMAから入る情報は、便利ですが、正しいとは限りません。

会社名の表記が揺れる。

メールアドレスが個人アドレスになる。

既存顧客が別名で登録される。

営業対象ではない問い合わせも混ざる。

そのため、外部入力は「受付アプリ」に置き、確認してから顧客マスタ、担当者マスタ、案件、問い合わせへ振り分ける設計が安定します。

更新責任と権限を決める

顧客管理は、複数部署が見るからこそ便利です。

しかし、複数部署が自由に直せると壊れます。

顧客マスタは誰が直すのか。

担当者情報は誰が更新するのか。

案件フェーズは誰が変えるのか。

問い合わせ状態は誰が完了にできるのか。

ここを決めずに始めると、正しい情報が分からなくなります。

役割	閲覧	追加	編集	削除
営業	顧客、担当者、案件、活動履歴	案件、活動履歴	自分の案件、担当顧客	原則不可
サポート	顧客、問い合わせ、活動履歴	問い合わせ、活動履歴	自分の問い合わせ	原則不可
経理	顧客、契約・請求確認	請求確認	請求関連項目	原則不可
管理者	全体	全体	全体	制限付き
外部連携ユーザー	連携対象のみ	API対象のみ	API対象のみ	原則不可

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

顧客、担当者、案件、活動履歴を削除できると、あとで説明できない空白が生まれます。

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

顧客マスタの編集権限も、全員に渡さない方がよいことがあります。

営業は活動履歴や案件を追加できる。

ただし、正式名称、顧客コード、請求先、契約状態は管理者や責任部署だけが編集する。

このように項目ごとに更新責任を分けます。

一覧・通知は例外を拾うために作る

kintone顧客管理で作るべき一覧は、きれいな全件一覧ではありません。

業務で見るべきなのは、対応が必要な顧客、放置されている案件、期限が近い契約、未解決の問い合わせです。

一覧	条件	見る人
新規問い合わせ	状態が未対応	営業、サポート
期限超過問い合わせ	期限が過ぎて未解決	管理者
次回アクションなし案件	次回アクションが空	営業責任者
30日接点なし顧客	最終活動日が30日以上前	担当者
契約更新90日前	更新日が近い	営業、管理者
請求確認待ち	請求状態が未確認	経理、営業
重複疑い	顧客名、電話、ドメインが近い	管理者
連携エラー	外部連携結果が失敗	システム担当

通知も同じです。

すべての更新を通知すると、誰も見なくなります。

通知するのは、行動が必要な状態だけです。

通知する状態	通知しすぎない方がよい状態
新規問い合わせが入った	顧客名の軽微な修正
問い合わせ期限を過ぎた	活動履歴の追加すべて
次回アクション日が近い	参考メモの追記
契約更新日が近い	住所表記の修正
連携エラーが発生した	連携成功ログ

顧客管理の通知は、情報共有ではなく、対応漏れを防ぐために設計します。

全員に全部知らせるのではなく、担当者、責任者、確認者へ必要なときだけ届ける。

この考え方にしないと、kintone通知もメール通知もすぐに見られなくなります。

名寄せと重複防止を最初に決める

顧客管理で避けられないのが、名寄せです。

同じ会社が、次のように登録されることがあります。

• 株式会社ビットライト
• ビットライト
• （株）ビットライト
• bitlight
• Bitlight Inc.
• ビットライト 東京支店

これを人力であとから直すのは大変です。

最初に、重複を防ぐキーを決めます。

キー候補	向いているケース	注意点
顧客コード	社内で採番ルールを作れる	採番責任者が必要
法人番号	法人顧客中心	個人事業主や部署単位には使いにくい
メールドメイン	BtoBの問い合わせ	大企業やフリーメールでは曖昧
電話番号	店舗、事業所単位	代表番号、部署番号の扱いが必要
請求先コード	会計連携が中心	会計ソフト側との同期ルールが必要

顧客コードを作る場合は、顧客名から自動生成しすぎない方がよいです。

社名変更、表記修正、統合、分社が起きるためです。

顧客コードは、名前ではなく内部IDとして扱います。

重複が見つかった場合の処理も決めます。

状態	処理
同一顧客が2件ある	片方を正本にし、もう片方を重複として無効化する
担当者が重複している	所属顧客、メール、役割を確認して統合する
別拠点だった	顧客単位を見直し、親顧客・拠点を分ける
社名変更だった	旧社名を履歴として残し、正式名称を更新する
グループ会社だった	別顧客として残し、親子関係や関連会社として紐づける

名寄せは地味ですが、顧客管理の信用を決めます。

ここを曖昧にしたままアプリを増やすと、案件、問い合わせ、請求、活動履歴もすべて重複します。

kintone顧客管理で崩れやすい失敗パターン

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

失敗	起きること	設計で直すこと
顧客管理アプリ1つに全部入れる	案件、問い合わせ、契約、履歴が混ざる	アプリを役割別に分ける
顧客名を自由入力にする	同じ会社が複数登録される	顧客マスタと顧客コードを使う
担当者を顧客マスタに直書きする	複数担当者、異動、退職に対応できない	担当者マスタを分ける
商談ステータスを顧客に持たせる	過去商談と現在商談が上書きされる	案件アプリを分ける
活動履歴をメモ欄に書く	接点、次回アクション、担当者別集計ができない	活動履歴を1接点1レコードにする
問い合わせを案件に混ぜる	サポート対応と営業進捗が混ざる	問い合わせアプリを分ける
請求情報をkintoneだけで持つ	会計ソフトと数字がズレる	freee等を正本にし、kintoneは確認画面に寄せる
権限を後回しにする	誰でも正式名称や請求先を直せる	更新責任とアクセス権を決める
通知を増やしすぎる	重要な未対応通知まで埋もれる	期限、未対応、例外だけ通知する
外部フォームから直接顧客マスタに入れる	重複、表記揺れ、営業対象外が混ざる	受付アプリで確認してから反映する

特に危ないのは、顧客マスタを便利なメモ帳にしてしまうことです。

顧客マスタは正本です。

そこに案件進捗、問い合わせ内容、請求メモ、日報、次回アクションを詰めると、どの情報が最新で、誰が直すべきか分からなくなります。

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

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

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

日	やること	成果物
1日目	顧客単位を決める	法人、店舗、部署、請求先のどれを1顧客にするか
2日目	顧客マスタを作る	顧客コード、正式名称、種別、担当責任
3日目	担当者マスタを作る	窓口、決裁者、経理、利用者を分ける
4日目	案件と活動履歴を作る	フェーズ、次回アクション、接点履歴
5日目	問い合わせを作る	状態、期限、優先度、解決内容
6日目	一覧、通知、権限を設定する	未対応、期限超過、30日接点なし、更新責任
7日目	外部連携の境界を整理する	フォーム、MA、メール、freee、CRMの役割分担

この段階で、複雑な自動化まで入れなくて構いません。

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

• 顧客名が重複しにくい
• 顧客と担当者が分かれている
• 案件が顧客マスタから独立している
• 活動履歴が1接点1レコードで残る
• 問い合わせの未対応と期限超過が見える
• 契約・請求の正本がどこか説明できる
• 誰がどの情報を更新するか決まっている
• 重要な例外だけ通知される

ここまでできれば、次にフォーム連携、メール連携、MA連携、freee連携、専用CRMとの連携へ進めます。

逆に、この状態を作らないまま自動化すると、間違った顧客情報が速く広がります。

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

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

質問	決めること
1顧客の単位は何か	法人、店舗、部署、請求先、グループ会社
顧客コードは誰が採番するか	自動採番、管理者採番、外部システムコード
顧客名の表記揺れをどう防ぐか	正式名称、表示名、旧社名、重複確認
担当者はどこまで持つか	窓口、決裁者、経理、利用者、退職者
案件をどう分けるか	1相談、1見積、1プロジェクト、1契約
活動履歴を何として残すか	メール、電話、面談、資料送付、問い合わせ対応
問い合わせと案件をどう分けるか	サポート対応、追加依頼、商談化候補
契約・請求の正本はどこか	kintone、freee、契約管理、会計ソフト
誰が顧客マスタを編集できるか	営業、CS、経理、管理者、外部連携ユーザー
何を通知するか	未対応、期限超過、次回アクション、契約更新、連携エラー
何をkintoneに持たないか	会計処理、正式請求、メール配信停止、CRM高度分析

このチェックリストに答えられない状態でアプリを作ると、あとからフィールド追加、アプリ分割、権限変更、重複統合が続きます。

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

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

顧客コード、担当者、案件、活動履歴、問い合わせ、契約・請求の責任範囲は、最初に決めた方がよいです。

まとめ

kintoneで顧客管理を作るときは、「顧客管理アプリを1つ作る」と考えない方がよいです。

顧客マスタ、担当者マスタ、案件、活動履歴、問い合わせ、契約・請求確認、連携ログを分けます。

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

kintone顧客管理の設計で大事なのは、顧客名を一覧化することではなく、顧客、担当者、案件、接点、問い合わせ、契約・請求がそれぞれ説明できる状態にすることです。

Excel顧客台帳の置き換え、BtoBの顧客・担当者管理、問い合わせ管理、契約更新の確認なら、kintoneで十分に始められます。

一方で、大規模な営業CRM、MA、メール配信、会計、入金消込まで含むなら、kintoneは周辺業務と確認画面に寄せ、専用システムを正本にする判断も必要です。

テンプレートやアプリパックを選ぶ前に、まず顧客情報の正本と業務の分け方を決める。

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