NPOの支援者CRMは、選定を間違えると
「データが散らかる → 引継ぎできない → メルマガが回らない → 寄付が伸びない」
という負のループに入ります。
ですが結論はシンプルです。年商3,000万以上のNPO・認定NPO法人が成果を出すなら、
「寄付者管理」と「ステークホルダー管理」を分けて設計するのが最短です。
① 結論｜支援者CRMは「目的」で分けるのが正解
支援者という言葉には、様々な属性の方が含まれますので、誰を対象にするかを明確に分けた上で、各属性ごとに適切なCRMがあることを抑えて下さい。
結論その1：寄付者“だけ”ならコングラント一択（＝寄付者管理）
- クレジットカード寄付者
- 銀行振込寄付者
- 賛助会員・正会員
- 物品寄付者
- クラウドファンディング支援者
→ 寄付の入金・履歴・名寄せまで最短で回る
結論その2：ボランティアまで含めるならキントーン一択（＝ステークホルダー管理）
- ボランティア応募者／継続ボランティア
- プロボノ・外部専門家
- 企業・学校・自治体
- 理事・評議員・OB
→ 関係性（接点・温度感・履歴）を育てられる
図解：支援者CRMの判断フロー（最短で失敗回避）
支援者CRMを整備したい
│
├─ 寄付者だけ管理したい？
│ │
│ ├─ YES → コングラント（寄付者管理マスタを作成する）
│ │
│ └─ NO
│
└─ ボランティア/関係者も含めたい？
│
├─ YES → キントーン（ステークホルダー管理のマスタをつくる）
│
└─ NO → 目的を再定義（寄付者 or 全体）
ツール選定の結論（この記事の要点）
| 結論 | 管理対象 | 最適ツール | ゴール | よくある失敗 |
|---|---|---|---|---|
| その1 | 寄付者・会員・物品寄付・クラファン支援者 | コングラント | 寄付データの一元化と名寄せ | Excel/スプレッドで重複・表記ゆれ地獄 |
| その2 | ボランティア・関係者を含む全ステークホルダー | キントーン | 関係性の蓄積と運用の自走 | 名簿が部署ごとに分断、引継ぎ不能 |
② 寄付者管理はコングラント一択
寄付者管理で最初に固めるべきは、「寄付データの正（マスター）」です。
ここがブレると、後工程のメルマガも分析もすべて崩れます。
図解：寄付者管理（コングラント）の設計思想
【寄付者管理＝お金の履歴】
寄付者データ（正） ──→ 寄付履歴 ──→ 分析/控除/継続施策
↑
名寄せ（マージ）
詳細は以下の記事で体系的に解説しています：
寄付DXを成功させる具体的方法｜NPOはコングラント×キントーン（kintone)で考えよう
③ ボランティアを含む管理はキントーン一択
年商3,000万を超える団体ほど、次に壁になります。
「ボランティア・企業・学校・理事・OBなど、関係者が増える」からです。
このとき必要なのは「寄付の履歴」ではなく、関係性の履歴（接点・温度感・次アクション）です。
それを現場運用で回せるのがキントーンです。
図解：ステークホルダー管理（キントーン）の設計思想
【ステークホルダー管理＝関係性の履歴】
人（支援者） ──→ 接点（イベント/面談/活動） ──→ 温度感（ファン度）
│ │
└── 属性（寄付/ボラ/企業/学校/OB） ──→ 次のアクション（連絡/依頼/お願い）
表：キントーンで管理すべきステークホルダー全体像
| 区分 | 対象例 | 管理の目的 | 次のアクション例 |
|---|---|---|---|
| 寄付者 | 単発/継続/高額 | 継続・増額・紹介 | お礼／活動報告／寄付導線 |
| ボランティア | 応募者/継続/リーダー | 定着・戦力化 | 役割提案／研修／参加案内 |
| プロボノ | デザイナー/士業/IT | 支援の高度化 | スポット依頼／継続化 |
| 企業 | CSR/協賛/寄付 | パートナー化 | 提案書／報告／共同企画 |
| 学校 | ゼミ/探究/連携 | 継続連携 | 受入設計／成果共有 |
| 組織内 | 理事/評議員/OB | ガバナンス | 定例連絡／資料共有 |
例えば、体系的にボランティア情報を管理する方法の詳細は以下の記事で解説しています：
ボランティア管理決定版｜脱エクセル、スラックでツール変えただけで人員増やさず200名ボランティア追加管理ができるように
④ 支援者管理活用歴15年のコンサルタントが語る運用ポイント
ここが核心です。
「両方入れたのに成果が出ない団体」は、たいてい“正（マスター）”が曖昧です。
その1：コングラントの運用ポイント
- 全ての支援者情報（寄付者データの正）はコングラントに集約する
- 物品寄付者やクラファン支援者もコングラントへインポートする
- 表記ゆれ・重複はマージ（名寄せ）で統合する
表：コングラント運用の“禁止事項”チェック
| NG | なぜダメか | 代替策 |
|---|---|---|
| Excelに寄付者を残す | 重複・更新漏れで全てが崩れる | コングラントに統合して一元化 |
| 担当者ごとに名簿がある | 引継ぎ不能、漏れが出る | 入口を一本化（コングラント） |
| 名寄せを後回し | 配信・分析が成立しない | 月1のマージ運用を固定 |
その2：キントーンの運用ポイント
- キントーンにはコングラント経由で寄付者情報を格納する
- 併せて寄付者を含んだ全てのステークホルダー情報を格納する
- 接点（面談・参加・相談・電話など）を履歴として残す
- 次アクション（お礼・依頼・案内・フォロー）をタスク化して回す
図解：データの流れ（事故が少ない設計）
寄付の入口（コングラント）
↓
寄付者データ（正：コングラント）
↓（連携）
キントーン（関係の正：接点/温度感/次アクション）
表：キントーンの最小アプリ構成（まずはこれだけ）
| アプリ名 | 主な項目 | 目的 |
|---|---|---|
| ステークホルダー台帳 | 氏名/区分/連絡先/所属 | 全員を一元管理 |
| 接点履歴 | 日付/種別/内容/次アクション | 関係性を蓄積 |
| イベント/活動 | 開催情報/参加者/担当 | 募集〜参加管理 |
| タスク/フォロー | 期限/担当/状況 | 放置ゼロ運用 |
⑤ 支援者CRMをどのように活用してファン度とリピートを高めるか？
答えは明確です。ドナーピラミッドを“運用に落とす”こと。
概念を知っているだけでは、寄付は増えません。
図解：ドナーピラミッドをCRMで回す
認知（見込み） → 参加（ボラ/イベント） → 初回寄付 → 継続寄付 → 高額/紹介
↑ ↑ ↑ ↑
発信/広報 CRMで関係記録 セグメント配信 個別対応
CRMがある団体／ない団体の差
| 状態 | できること | 結果 |
|---|---|---|
| CRMなし | 全員に同じ連絡、履歴が残らない | 反応率が落ち、寄付が伸びない |
| CRMあり | 属性別に出し分け、接点で温度感UP | 継続率・増額率が上がる |
実践の最短ルートはこの動画でOKです。
⑥ まとめ｜支援者CRMの最適化について知りたい方は、奏ワークスにお問い合わせを
最後にもう一度、結論です。
- 寄付者管理だけなら：コングラント一択
- ボランティア含む全体管理なら：キントーン一択
- 成果を最大化するなら：コングラント（寄付の正）×キントーン（関係の正）
そして重要なのは、ツール導入ではなく運用設計です。
支援者CRMを「増える仕組み」に変えたい団体へ
もし、以下のうち1つでも当てはまるなら、支援者CRMは“伸びしろ”です。
- 支援者データが散在している（Excel／担当者名簿）
- 引継ぎが属人化している
- 送付状やメルマガ発行時のリスト集約負荷が大変
- ボランティアが寄付につながらない
- メルマガが続かない／配信設計ができない
- ドナーピラミッドが実装できない
- 受益者のライントーク履歴を一元管理できていない
- 法人寄付と個人寄付のデータ格納方法が設計できていない
奏ワークス株式会社では、コングラント×キントーンを前提に、貴団体に最適な最短の運用設計をご提案します。
よくある質問（FAQ）
Q1. 支援者CRMはSalesforceでもできますか？
A. 可能ですが、年商3,000万規模のNPO現場運用（入力・引継ぎ・定着）を考えると、
費用・運用負荷が過剰になりやすいケースがあります。
目的が寄付者管理中心ならコングラント、関係者全体ならキントーンの方が現実的です。
Q2. コングラントとキントーンは二重管理になりませんか？
A. “正（マスター）”を分ければ二重管理になりません。
寄付＝コングラント、関係＝キントーンという役割分担が最も事故が少ない設計です。
Q3. 最初はどこから着手すべきですか？
A. まずコングラントで「寄付者の正」を作り、次にキントーンで
「ステークホルダー統合」と「接点履歴」を回すのが最短です。
