kintone CRMの設計方法｜顧客データを営業・問い合わせ・請求につなぐ構成

kintoneをCRMとして使いたい相談では、最初に「顧客情報を一元管理したい」という話になりがちです。

会社名。

担当者名。

電話番号。

メールアドレス。

住所。

営業担当。

商談状況。

問い合わせ履歴。

契約状態。

請求状態。

これらをkintoneに集めれば、CRMらしい画面はできます。

ただし、CRMで実務上困るのは、顧客情報を登録できないことだけではありません。

本当に崩れやすいのは、次のような状態です。

• 同じ会社が複数の表記で登録される
• 会社、部署、店舗、担当者の単位が混ざる
• 営業、サポート、経理が同じ顧客情報を別々に直す
• 案件履歴、問い合わせ履歴、契約情報、請求メモが顧客アプリに混ざる
• 接触履歴がコメントやメモ欄に埋もれ、次回連絡やクレーム履歴が追えない
• 顧客ごとの閲覧権限や編集責任が決まっていない
• CTI、MA、メール、会計ソフトとの正本が曖昧になる
• 専用CRMが必要な領域までkintoneで抱え込み、運用が重くなる

CRMは、顧客一覧ではありません。

顧客、担当者、接触履歴、案件、問い合わせ、契約、請求参照をつなぎ、部門をまたいで同じ顧客状態を見られるようにする仕組みです。

kintone CRMで最初に決めるべきなのは、顧客管理アプリの項目ではなく、「顧客データの正本・更新責任・参照範囲」です。

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

kintone顧客管理の設計方法はこちら
kintone SFAの設計方法はこちら
kintone案件管理の設計方法はこちら
kintone問い合わせ管理の設計方法はこちら
kintone請求書管理の設計方法はこちら

先に結論：CRMは顧客一覧ではない

kintoneでCRMを作るとき、顧客管理アプリ1つから始めることはできます。

ただし、営業、サポート、管理部門が同じ顧客データを使うなら、最初から次の情報を分けます。

分けるもの	1レコードの意味	役割
顧客マスタ	1社、1顧客、1請求先	顧客ID、正式名称、担当部署、契約状態を持つ
担当者マスタ	1人	窓口、決裁者、利用者、連絡先、異動状態を持つ
接触履歴	1回の接点	面談、電話、メール、訪問、クレーム、フォローを残す
案件	1商談、1提案	提案、見積、受注、失注、次回アクションを持つ
問い合わせ	1件の問い合わせ	受付、分類、担当、対応、解決、再発を追う
契約	1契約、1サービス利用	契約状態、開始日、更新日、担当責任を持つ
請求参照	1請求状態の参照	請求済み、入金済み、未入金、会計連携を確認する
名寄せ候補	1つの重複候補	統合判断、却下理由、統合履歴を残す
連携ログ	1回の取込・出力	MA、CTI、会計、専用CRM連携の成否を追う

顧客マスタは、顧客の現在状態です。

担当者マスタは、顧客側の人の情報です。

接触履歴は、過去のやり取りです。

案件は、営業上の提案単位です。

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

契約は、提供中の約束です。

請求参照は、経理や会計ソフト側の状態を営業やサポートが見るための情報です。

この分け方ができていないと、顧客情報は集まっているのに、誰が何を更新すべきか分からないCRMになります。

CRMで大事なのは、全部を1つに集約することではありません。

データの意味を分けた上で、顧客画面から必要な情報を見られるようにすることです。

kintoneでは、ルックアップ、アプリアクション、関連レコード一覧を使って、複数アプリの情報を連携できます。

公式ヘルプでも、複数アプリ間の連携機能として、ルックアップ、アプリアクション、関連レコード一覧が説明されています。

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

CRMでは、この特徴を使って、データは分け、画面ではつないで見せる設計にします。

CRMと顧客管理の違い

顧客管理とCRMは近い言葉です。

ただし、実務では分けて考えた方がよいです。

顧客管理は、顧客情報を正しく保つことです。

CRMは、その顧客情報を使って、営業、問い合わせ、契約、請求、フォローをつなげることです。

観点	顧客管理	CRM
主な目的	顧客情報の整備	顧客との関係と業務の接続
中心データ	顧客マスタ、担当者	顧客、接触履歴、案件、問い合わせ、契約
主な利用者	営業、管理部門	営業、サポート、経理、管理者
重要な論点	重複防止、表記統一、更新責任	部門横断、履歴共有、権限、外部連携
失敗しやすい点	顧客台帳が古くなる	部門ごとの情報が混ざり、誰も信用しなくなる

kintoneでCRMを作るなら、顧客マスタを作るだけでは足りません。

顧客に紐づく業務イベントを分けます。

営業案件。

問い合わせ。

契約。

請求。

接触履歴。

そして、それぞれの更新責任を決めます。

顧客・担当者・接触履歴を分ける

CRMの土台は、顧客、担当者、接触履歴です。

この3つを混ぜると、後からほぼ必ず苦しくなります。

データ	1レコードの意味	混ぜると起きる問題
顧客	1社、1組織、1請求先	部署や担当者の情報が会社情報に混ざる
担当者	1人	異動、退職、複数窓口に対応できない
接触履歴	1回のやり取り	履歴がメモ欄に埋もれ、次回対応や分析に使えない

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

フィールド	型	設計意図
顧客ID	文字列、採番	外部連携や名寄せのキーにする
正式名称	文字列	契約・請求と揃える
表示名	文字列	現場が探しやすい名称を持つ
顧客単位	選択肢	法人、店舗、部署、事業所などを分ける
顧客種別	選択肢	リード、見込み、既存、休眠、パートナーなど
営業担当	ユーザー選択	営業上の責任者を明確にする
サポート担当	ユーザー選択	問い合わせ対応の責任者を明確にする
契約状態	選択肢	契約中、更新待ち、終了などを表示する
請求参照ID	文字列	会計ソフト側の取引先と照合する

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

フィールド	型	設計意図
担当者ID	文字列、採番	同姓同名や外部連携に備える
所属顧客	ルックアップ	顧客マスタと紐づける
氏名	文字列	担当者を識別する
部署・役職	文字列	商談や問い合わせの文脈を持つ
役割	選択肢	窓口、決裁者、利用者、経理担当など
メール	リンク、文字列	連絡先として使う
電話	文字列	CTIや架電履歴との照合に使う
状態	選択肢	有効、異動、退職、不明などを分ける

接触履歴は、1回のやり取りを1レコードにします。

フィールド	型	設計意図
接触日	日時	いつ接点があったかを残す
顧客	ルックアップ	顧客に紐づける
担当者	ルックアップ	誰と話したかを残す
関連案件	ルックアップ	商談に関係する接点を分ける
関連問い合わせ	ルックアップ	サポート対応と紐づける
種別	選択肢	面談、電話、メール、訪問、クレームなど
要点	文字列複数行	長文ではなく要約を残す
次回アクション	文字列、関連タスク	次に何をするかを残す
原本URL	リンク	メール、録音、議事録などへ戻れるようにする

接触履歴は、営業だけのものではありません。

サポートの問い合わせ対応。

経理の請求確認。

カスタマーサクセスの定例。

これらも顧客との接点です。

ただし、全部を同じ見え方にするとノイズが増えます。

営業用の接触履歴一覧、サポート用の対応履歴一覧、管理部門用の請求確認履歴を分けて表示します。

案件・問い合わせ・契約・請求との接続

CRMでは、顧客に紐づく業務を分けて持ちます。

案件、問い合わせ、契約、請求は、それぞれ目的が違います。

業務	1レコードの意味	CRMでの見せ方
案件	1商談、1提案	顧客別の進行中案件、失注、受注履歴として見る
問い合わせ	1問い合わせ	未対応、対応中、解決済み、再発として見る
契約	1契約、1サービス利用	契約中、更新待ち、終了予定として見る
請求	1請求、1入金予定	請求済み、未入金、差額ありとして見る

案件は、営業の業務です。

問い合わせは、サポートや運用の業務です。

契約は、提供中の約束です。

請求は、会計や経理の業務です。

CRMでは、これらを顧客画面で見られるようにします。

しかし、顧客アプリにすべてを詰め込むわけではありません。

設計	向いている使い方	注意点
顧客アプリに関連レコード一覧を置く	顧客画面から案件や問い合わせを見たい	表示条件を絞らないと重くなる
各業務アプリから顧客をルックアップする	顧客情報の表記揺れを防ぐ	顧客IDや正式名称のキー設計が必要
請求状態だけをCRMへ戻す	営業やサポートが未入金を把握する	会計データの正本にしない
契約情報を別アプリにする	更新日や契約状態を追う	契約原本の保存先を決める

案件管理の詳しい設計は、案件管理の記事で分けて扱います。

kintone案件管理の設計方法はこちら

問い合わせ管理も、顧客マスタとは別に設計します。

kintone問い合わせ管理の設計方法はこちら

請求書や入金確認は、会計ソフトとの境界が重要です。

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

CRMでは、顧客画面に情報を集めて見せます。ただし、案件、問い合わせ、契約、請求のデータまで顧客アプリに混ぜないことが重要です。

名寄せと重複防止

CRMで最初に問題になるのは、重複です。

同じ会社が複数登録されます。

株式会社の有無。

全角半角。

支店名。

部署名。

旧社名。

フォームから入った略称。

名刺データの表記。

これらが揺れると、同じ顧客の案件や問い合わせが分散します。

重複防止では、次の項目を設計します。

項目	役割
顧客ID	内部の一意キー
正式名称	契約・請求と揃える名称
表示名	現場が検索しやすい名称
法人番号・取引先コード	外部照合に使える場合のキー
メールドメイン	法人顧客の候補照合に使う
電話番号	店舗や事業所の照合に使う
住所	複数拠点の判定に使う
統合元ID	名寄せ後も過去参照できるようにする

重要なのは、重複をゼロにしようとしないことです。

フォーム、名刺、問い合わせ、営業入力がある限り、重複候補は出ます。

そのため、重複を見つける一覧と、統合する判断フローを作ります。

状態	処理
重複候補	名称、メールドメイン、電話番号などで候補化する
確認中	管理者や営業担当が同一顧客か確認する
統合する	正本顧客を決め、案件や問い合わせの紐づけを直す
統合しない	別顧客として理由を残す
保留	判断に必要な情報を追加する

名寄せは、技術だけで解決しません。

営業上は同じ企業グループとして扱いたいが、請求上は別法人として扱う。

サポート上は店舗単位で分けたいが、契約は本部単位で見る。

このような判断があるからです。

kintone CRMの名寄せは、重複候補を自動で消す作業ではなく、「どの単位を1顧客として扱うか」を業務側で判断する作業です。

部門別権限と更新責任

CRMを部門横断で使うと、権限と更新責任が重要になります。

営業が見たい情報。

サポートが見たい情報。

経理が見たい情報。

経営が見たい情報。

これらは同じではありません。

顧客情報を共有することと、すべての情報を全員が編集できることは別です。

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

公式ヘルプでも、レコードごとに閲覧、編集、削除を制限できることが説明されています。

kintoneヘルプ：レコードにアクセス権を設定する

CRMでは、次のように分けます。

情報	閲覧	編集
顧客基本情報	営業、サポート、経理、管理者	顧客管理担当、営業責任者
担当者情報	営業、サポート	営業担当、サポート担当
案件情報	営業、マネージャー	営業担当、営業責任者
問い合わせ情報	サポート、営業の一部	サポート担当
契約情報	営業、サポート、管理者	契約管理担当
請求状態	営業、サポート、経理	経理、会計連携
請求金額や入金詳細	経理、管理者	経理
クレーム・要注意情報	必要な担当者、管理者	管理者、サポート責任者

更新責任も決めます。

更新対象	主担当	補足
顧客名、住所、請求先	管理部門、経理	契約・請求と合わせる
営業担当	営業責任者	担当変更の履歴を残す
担当者の役職や連絡先	営業、サポート	接点がある部門が更新する
案件ステータス	営業担当	マネージャーが確認する
問い合わせ状態	サポート担当	解決条件を決める
契約更新日	契約管理担当	通知対象にする
請求・入金状態	会計ソフト、経理	kintoneは参照に寄せる

CRMが壊れる理由の多くは、更新責任が曖昧なことです。

誰でも直せるが、誰も責任を持たない。

この状態になると、CRMの顧客情報は信用されなくなります。

CTI・MA・会計連携

kintone CRMは、外部サービスとつなげることで便利になります。

ただし、外部連携は「何でもkintoneに集約する」ためではありません。

どの情報をkintoneへ持ち、どの情報を外部サービスに残すかを決めるために使います。

連携先	kintoneに持つ情報	外部側に残す情報
Webフォーム	リード情報、問い合わせ要約、受付日	送信原本、フォーム設定
MA	流入元、スコア、主要行動、配信停止状態	詳細な行動履歴、配信ログ
CTI	架電日時、相手、要点、録音URL	通話録音、通話ログ詳細
メール	送受信日、要点、原本URL	メール本文、添付、スレッド
会計ソフト	請求状態、入金状態、未入金フラグ	請求書、入金消込、仕訳
専用CRM	連携ID、商談要約、移行対象	高度分析、自動記録、詳細レポート

MAの行動履歴をすべてkintoneへコピーすると、レコードが増えすぎます。

CTIの通話ログをすべてkintoneへ持つと、検索や権限が重くなります。

会計ソフトの請求・入金・仕訳をkintoneへ複製すると、どちらが正しいか分からなくなります。

CRMでは、顧客対応に必要な状態をkintoneに持ち、原本や詳細ログは外部へ戻れるようにします。

会計ソフトとの境界では、特に注意が必要です。

請求書、入金、仕訳は会計ソフトを正本にするケースが多いです。

kintone CRMでは、営業やサポートが知るべき「請求済み」「未入金」「入金済み」「連携エラー」などの状態を参照します。

これにより、営業は未入金の顧客へ不用意に追加提案しない、サポートは契約状態を確認して対応する、といった運用ができます。

専用CRMへ逃がすケース

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

ただし、すべてのCRM要件をkintoneで抱えるべきではありません。

次の要件が強くなったら、専用CRMや周辺サービスへ逃がす判断をします。

要件	逃がす先	理由
メール・通話の自動記録	専用CRM、CTI	自動同期と検索が重要になる
大量のリードスコアリング	MA	行動履歴や配信ログの正本になる
高度な営業分析	専用CRM、BI	パイプライン、予測、目標管理が重い
コールセンター型対応	問い合わせ管理、CTI	キュー、SLA、通話履歴が必要
厳密な個人情報管理	専用CRM、ID基盤	保持期間、削除、監査、同意管理が重い
多拠点・多法人の顧客管理	専用CRM	組織階層や権限が複雑になる

Bitlightとしては、kintone CRMは中小規模の営業・サポート・管理部門が、顧客情報を中心に業務をつなぐ用途に向いていると考えます。

特に、顧客管理、案件、問い合わせ、契約更新、請求参照を同じ基盤で見たい場合は相性がよいです。

一方で、メールや通話の自動記録、リードスコアリング、大規模な営業分析が中心なら、専用CRMやMAを正本にする方が安定します。

大事なのは、逃げ道を残すことです。

顧客ID、担当者ID、案件ID、外部連携IDを整理しておけば、将来専用CRMへ移行する場合でも、データを渡しやすくなります。

監査ログと個人情報の扱い

CRMでは、個人情報や顧客情報を扱います。

そのため、誰が、いつ、どの情報を更新したかを確認できる設計が必要です。

kintoneの監査ログでは、kintone上の操作を確認できます。

公式ヘルプでも、監査ログの閲覧とダウンロード画面で、必要に応じて絞り込み条件を指定してログを確認できることが説明されています。

kintoneヘルプ：監査ログの確認方法

ただし、監査ログがあるからといって、CRMの運用ルールが不要になるわけではありません。

次のようなルールを決めます。

ルール	決めること
閲覧範囲	誰がどの顧客情報を見られるか
編集範囲	誰が基本情報、連絡先、契約情報を編集できるか
保持期間	退職者、失注顧客、問い合わせ履歴をいつまで持つか
削除判断	誰が削除できるか、削除前に何を確認するか
エクスポート	CSV書き出しを誰に許可するか
外部連携	どの外部サービスへどの情報を渡すか

CRMは便利なほど、情報が集まります。

情報が集まるほど、権限、保持、削除、外部連携のルールが必要になります。

よくある失敗パターン

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

失敗1：顧客アプリにすべてを詰め込む

顧客情報、案件、問い合わせ、契約、請求、メモを1つのアプリに入れると、最初は簡単です。

しかし、部署ごとの一覧、権限、履歴、通知が複雑になります。

CRMは、顧客を中心に複数アプリをつなぐ方が長く使えます。

失敗2：顧客名だけで紐づける

顧客名は揺れます。

株式会社の有無、略称、支店名、旧社名、フォーム入力の表記揺れがあります。

顧客IDや取引先コードを作り、顧客名だけをキーにしない方がよいです。

失敗3：担当者と会社を混ぜる

担当者は異動します。

退職します。

複数の役割を持つこともあります。

会社情報と人の情報を混ぜると、後から履歴が壊れます。

失敗4：接触履歴をコメントに埋める

コメントは便利ですが、履歴の構造化には向きません。

接触日、種別、相手、要点、次回アクションを使うなら、接触履歴を1レコードにします。

失敗5：更新責任がない

CRMは誰でも見られるだけでは足りません。

誰が直すのかを決めないと、情報が古くなります。

顧客基本情報、担当者情報、案件、問い合わせ、契約、請求状態の更新責任を分けます。

失敗6：外部サービスの詳細ログを全部持ち込む

MA、CTI、メール、会計ソフトの詳細ログをすべてkintoneへ持つと、CRMが重くなります。

kintoneには顧客対応に必要な要約と状態を持ち、原本へ戻れるリンクを残します。

失敗7：専用CRMが必要な要件まで抱える

自動記録、高度分析、大量リード管理、複雑な権限階層が主目的なら、kintoneだけで抱えると重くなります。

その場合は、kintoneを周辺業務の基盤にし、専用CRMを正本にする選択もあります。

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

最初からCRM全体を作ろうとすると、アプリが増えすぎます。

まずは、顧客データの正本を決め、部門横断で見られる最小構成から始めます。

1日目：顧客単位を決める

法人単位なのか、部署単位なのか、店舗単位なのか、請求先単位なのかを決めます。

CRMの土台はここです。

2日目：顧客IDと名寄せルールを決める

顧客ID、正式名称、表示名、外部取引先コードを決めます。

重複候補をどう確認するかも決めます。

3日目：顧客マスタと担当者マスタを分ける

会社情報と人の情報を分けます。

担当者の役割、状態、所属顧客を持たせます。

4日目：接触履歴を設計する

面談、電話、メール、問い合わせ、クレームなどの接点をどう残すかを決めます。

コメント欄だけにしないようにします。

5日目：案件・問い合わせ・契約を接続する

顧客画面から、進行中案件、未対応問い合わせ、契約更新予定を見られるようにします。

データは各アプリに置き、顧客画面では関連情報として表示します。

6日目：権限と更新責任を決める

営業、サポート、経理、管理者で、閲覧範囲と編集範囲を分けます。

更新責任が曖昧な項目は、最初から作らない方がよいです。

7日目：請求・会計の参照範囲を決める

請求書や入金消込は会計ソフトを正本にし、CRMには状態だけ戻す設計を検討します。

営業やサポートに見せるべき情報だけを戻します。

8日目以降：外部連携と例外一覧を作る

フォーム、MA、CTI、メール、会計ソフトとの連携は、まず要約と原本URLから始めます。

未反映、重複候補、連携エラーの一覧を作ります。

CRMで大事なのは、きれいな顧客台帳を作ることだけではありません。

顧客に紐づく業務が、部門をまたいで止まらない状態を作ることです。

実装前チェックリスト

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

チェック項目	確認内容
顧客単位	法人、部署、店舗、請求先のどれを1顧客にするか
顧客ID	内部ID、外部取引先コード、会計ソフトIDをどう持つか
顧客名	正式名称と表示名を分けるか
担当者	窓口、決裁者、利用者、経理担当を分けるか
接触履歴	1接点1レコードで残すか
案件	顧客から進行中案件を見られるか
問い合わせ	顧客別の未対応、再発、解決済みを見られるか
契約	更新日、契約状態、終了予定を見られるか
請求参照	請求済み、未入金、入金済みをどの粒度で戻すか
名寄せ	重複候補、統合判断、却下理由を残すか
権限	部門ごとの閲覧、編集、削除を分けるか
更新責任	顧客情報を誰が直すか
外部連携	MA、CTI、メール、会計のどれを正本にするか
監査	誰が更新したかを確認できるか
専用CRM	高度分析や自動記録を外へ逃がす条件があるか

この表が埋まらないままCRMを作ると、顧客情報は集まっても、誰も信用しない台帳になりやすいです。

特に、顧客単位、顧客ID、更新責任、名寄せ、請求参照は先に決めます。

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

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

用意してほしいもの	見る理由
現在の顧客台帳	顧客単位、項目、重複状態を見る
案件表	顧客と営業活動のつながりを見る
問い合わせ一覧	サポート側の顧客情報を確認する
契約・請求の管理表	会計や経理との境界を見る
フォーム項目	リード登録時の表記揺れを見る
メール・CTI運用	接点の原本をどこに残すかを見る
権限の希望	部門ごとに見せる情報を整理する

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

むしろ、実際に使っているExcel、スプレッドシート、フォーム項目、問い合わせ一覧、請求管理の流れが分かる方が、実務に合う設計にできます。

Bitlightでは、kintoneに顧客一覧を作るだけではなく、CRMとして次の論点を整理します。

• 顧客単位と顧客IDの設計
• 顧客、担当者、接触履歴の分け方
• 案件、問い合わせ、契約、請求参照との接続
• 名寄せ候補と統合判断の運用
• 営業、サポート、経理の権限と更新責任
• CTI、MA、メール、会計ソフトとの正本分担
• 専用CRMへ移行する可能性を残すデータ設計

ここまで決めると、kintoneは単なる顧客一覧ではなく、顧客に関係する業務を部門横断で見るCRMになります。

まとめ

kintoneはCRMとして使えます。

ただし、顧客情報を一か所に集めるだけでは、CRMとしては弱いです。

顧客と担当者を分ける。

顧客と接触履歴を分ける。

案件、問い合わせ、契約、請求を分ける。

名寄せ候補を管理する。

部門別の権限と更新責任を決める。

MA、CTI、メール、会計ソフトとの正本を分ける。

専用CRMへ逃がす条件を決める。

これらを整理すると、kintone CRMは顧客一覧ではなく、営業、サポート、経理が同じ顧客状態を見ながら動ける業務システムになります。

kintone CRMは、顧客情報を登録するためではなく、顧客に紐づく営業・問い合わせ・契約・請求の状態を、部門をまたいで共有するために設計します。

最初に作るべきなのは、顧客項目を増やしたアプリではありません。

顧客単位、顧客ID、担当者、接触履歴、更新責任の分け方です。

その土台ができてから、案件、問い合わせ、契約、請求参照、外部連携を足していく方が、長く使えるCRMになります。