第4章 MAとSFAが持つべきデータ構造 ―― 何を、どの単位で、どう定義して記録するか

第3章では、同じ顧客が複数のシステムでばらばらにならないよう、企業と担当者を一つに確定する仕組み（SSOTSSOTSingle Source of Truth項目ごとに「どこが正か」が一意に定まった状態。全データを1箇所に集めることを意味しない。用語集で見る →）を述べた。これで「この顧客は誰か」は確定する。だが、その顧客について、どんな情報を、どんな単位で、どんなルールでデータとして持つかは、まだ決まっていない。たとえば「商談」と一口に言っても、何をもって商談と呼ぶかは会社ごと、担当者ごとに違う。本章では、MAMAマーケティングオートメーションマーケティングの実行と管理のための業務アプリケーション。用語集で見る →とSFASFAセールスフォースオートメーション営業の実行と管理のための業務アプリケーション。用語集で見る →がどんなテーブルを持つべきか、そして接点接点タッチポイント顧客と自社の間で起きる相互作用のすべて。マーケティング接点・営業接点・カスタマーサクセス接点・パートナー接点があり、商談も接点の一つである。用語集で見る →・活動・商談といった単位をどう定義すべきかを述べる。定義が揃っていなければ、データは集まらない。集まったとしても、比べることも、数えることもできない。

4-1. データ構造が、見える顧客の姿を決める

CRMCRMCustomer Relationship Management顧客との関係と取引履歴を管理する仕組み。GTMの4レイヤーでは、SFA・MAと並ぶ業務アプリケーション層に位置づけられる。用語集で見る →に何を記録するかは、そのCRMがどんなデータ構造を持っているかで決まる。

個人単位のリードしか持たない構造であれば、見えるのは「誰が資料を請求したか」までである。その人がどの企業のどの部門に属し、同じ部門の誰と一緒に検討しているかは見えない。企業と担当者を紐付けていても、商談を担当者一人にしか紐付けられない構造であれば、その商談に関わる他の関与者は記録されない。

CRMには、あらかじめ用意されたテーブルと項目にしか、データを入れることができない。用意されていない情報は、どこにも残らず、後から取り出すこともできない。第1章で述べた「相手を深く知り、理解する」ためには、知りたいこと、理解したいことをデータとして持てるテーブルと項目を、先に設計しておく必要がある。本章の前半では「どんなテーブルを持つか」を、後半では「各テーブルにどんな項目を、どんな定義で持つか」を述べる。

4-2. 基本の単位：企業、パーソン、購買グループ、商談、接点

本書が提案するデータ構造の基本単位は、次の5つである。

• 企業（アカウント）：顧客となる法人。事業所や部門はパーソンの属性として持つ
• パーソン：企業に属する一人ひとりの人物
• 購買グループ購買グループユニット企業内部にある検討の単位。所属と行動の同一性から認定する。BtoBの購買は一人では決まらないため、リードではなくこの単位で捉える。用語集で見る →：一つの検討案件について、購買の判断に関わる人物の集まり
• 商談：特定の購買グループに対する、自社の受注機会
• 接点：上記のいずれかと自社との間で起きた相互作用の記録

このうち、企業・パーソン・商談・接点は、多くのSFAが標準で持っている単位である。また、一つの商談に複数の担当者を役割付きで紐付ける機能も、主要なSFAには標準で備わっている。その意味では、「商談に関わる複数の人物」を持つこと自体は新しくない。

本書が加えるのは、購買グループという「見方」を、商談が立つ前から持つことである。標準の機能では、関与者は商談に紐づく。つまり、商談が立って初めて関与者を登録できる。だが、4-8で述べるとおり、商談が立つのは検討がある程度進んでからである。商談が立つ前の段階で、誰と誰が同じ検討に関わっているのかを見る手段が、標準の構造にはない。

ただし、そのために購買グループ専用のテーブルを新たに作る必要はない。専用のテーブルを作ると、誰がいつそれを更新するのかという運用の問題が生じ、結局は商談と同じものを二重に持つことになりかねない。現実的な実装は、パーソンに「どの部門・どの検討テーマに関わっているか」を示す項目と「役割」を持たせ、同じ企業の同じ部門・同じ検討テーマに属するパーソンを一つのまとまりとして扱い、それを購買グループとして見る、というものである。商談が立った後は、SFAが標準で備える商談への関与者の紐付けを使えばよい。購買グループは、独立したテーブルというより、パーソンを検討テーマごとにまとめて見るための見方である。

「2025年度版 BtoB購買プロセス白書」は、提言⑤として「企業→部門・プロジェクト→個人→役割という階層で顧客データを持ち直す」ことを挙げた。企業と個人の間に、部門・プロジェクトという単位を置く。これが購買グループである。個人は、ある検討案件についての購買グループの一員として、役割とともに捉えられる。

図4-1に示すとおり、企業の下にパーソンがあり、パーソンは所属する部門・検討テーマと役割を持つ。同じ部門・同じ検討テーマのパーソンをまとめたものが購買グループであり、商談はその購買グループに対して立つ。接点は、パーソンまたは商談に紐づき、購買グループの接点は、そこに属するパーソンの接点を合わせて見る。この構造によって、「この商談には誰が関わっていて、それぞれがどんな役割で、自社とどんな接点を持ってきたか」が一続きに見える。

4-3. 企業の単位：グループと法人は企業として、事業所と部門は人に持たせる

企業という単位は、一段ではない。第3章で述べたとおり、法人番号法人番号国税庁が全法人に付番する13桁の番号。企業の名寄せに使える公的キー。用語集で見る →は法人単位に振られるが、実質的な顧客の単位は法人より細かいことも、大きいこともある。これを、次のように持つ。

• グループ：親会社と子会社、持株会社と事業会社のまとまり。法人に、どのグループに属するかを持たせる
• 法人：法人番号で識別される単位。企業のテーブルはこの単位で持つ
• 事業所・事業部・部門：独立したテーブルとしては持たない。パーソンの属性として、所属する事業所・事業部・部門を持たせる

大手企業を顧客とする場合、商談が立つのは事業部や部門の単位であり、決裁が上がるのは法人やグループの単位である。法人を企業として持ち、事業部や部門をパーソンの所属として持っておけば、「ある会社の第一事業部と第二事業部に別々の商談がある」ことも、「その会社全体としての取引額」も、両方を見ることができる。

事業所や部門をマスタマスタその目的において正とするデータの置き場所。目的別に定義する。用語集で見る →ーとして持たないのは、管理の複雑さを避けるためである。組織改編のたびにマスターを作り直す必要はなく、パーソンの所属を更新すれば足りる。パーソンの所属は、第3章で述べた名刺やメールの署名からの自動更新で保てる。

4-4. 企業の分類と、パーソンの役割を持たせる

企業とパーソンには、識別と属性に加えて、自社にとっての位置づけを持たせる。

企業には、第3章で触れたターゲットアカウントターゲットアカウントABMで狙いを定めた企業。選定した「その先」にいる誰に何をいつ届けるかを設計するのが購買グループの考え方。用語集で見る →マトリクス9象限のような分類を持たせる。企業の規模や業種、自社との取引状況によって、その企業が自社にとってどの区分にあたるかを記録する。この分類は、どの企業にどれだけの資源を投じるかを決める根拠になり、第9章で述べる大規模組織での資源配分の基準にもなる。

パーソンには、購買グループにおける役割を持たせる。当社では、BtoBの購買に関わる人物の役割を4つに整理している。検討を始める着火役着火役現状への問題意識を持ち、検討の起点となる人。Webで調べ、資料をダウンロードし、ウェビナーに参加する。売り手のデータベースに最初に現れるシグナルの多くは、この役割が発している。用語集で見る →、社内で推進する旗振り役旗振り役社内をどう説得するかを考え、検討を推進する人。着火役に材料を集めさせ、自身も調べ、上に上げていく。探しているのは「社内説得の材料」。用語集で見る →、条件や仕様を審査する門番門番リスクはないか、要件を満たすかを審査する人。情報システム部門・法務・購買、あるいは現場の専門家として、比較情報やリスク情報を求める。用語集で見る →、予算と最終決裁を握る金庫番金庫番投資に見合うかを判断し、予算を握る人。決裁者本人のことも、その右腕として判断材料を精査する人のこともある。関心は投資対効果に集中する。用語集で見る →である。一人のパーソンが一つの購買グループで持つ役割を記録し、複数の購買グループに関わる場合はそれぞれの役割を記録する。役割の詳細と、役割をどう見極めるかは第5章で述べる。

ここで重要なのは、分類も役割も「企業やパーソンそのものの属性」ではなく「自社との関係における位置づけ」だという点である。同じ企業でも、自社にとっての分類は事業部によって違うことがある。同じパーソンでも、案件によって役割が変わることがある。

ただし、この違いをどこまで厳密にデータとして持つかは、運用できる範囲で決める。企業の分類は、法人に持たせることを基本とする。事業部によって自社にとっての位置づけが大きく違う場合も、事業部のテーブルを新たに作るのではなく、パーソンの所属事業部ごとに分けて判断する。パーソンの役割は、基本的にはパーソン自身に持たせる。一人の人物が自社との関係で担う役割は、案件が変わっても大きくは変わらないことが多く、パーソンに持たせておけば、営業もマーケティングも常にそれを参照できる。案件によって役割が異なる場合は、商談が立った時点で、商談への関与者の紐付けの側で役割を上書きすればよい。パーソンに基本の役割を持ち、商談で例外を扱う。この二段構えが、更新の負荷を抑えながら役割を活かす現実的な構造である。

4-5. 接点を定義する

構造が決まったら、次はそこに何を記録するかの定義である。まず接点から始める。

第2章で、接点とは顧客と自社の間で起きる相互作用のすべてだと述べた。これをデータとして記録するには、次の3点を定義する。

第一に、顧客発か自社発か。 顧客がWebサイトを閲覧した、資料を請求した、問い合わせをした。これらは顧客発の接点であり、顧客の関心を示す。自社がメールを送った、営業が訪問した、提案書を提示した。これらは自社発の接点であり、自社の働きかけを示す。両者を区別して記録しなければ、「接点が多い」ことが「関心が高い」ことなのか「自社がたくさん働きかけた」ことなのか分からない。

第二に、自社のどの部門の、誰が対応した接点か。 その接点を担当したのが、マーケティング、インサイドセールスインサイドセールス訪問せずに電話やメールで見込み客と接点を持つ営業機能。聞き取りで得た情報は、フォームからは分からない購買グループの手がかりになる。用語集で見る →、営業、カスタマーサクセス、パートナーのどの部門で、具体的に誰なのかを記録する。メールを送ったのはどの事業部のマーケティングか、訪問したのはどの営業担当者か。これが分かれば、同じ顧客に対して、自社の誰が、いつ、どんな接点を持っているかを部門をまたいで見られる。第2章で述べた重複アプローチを防ぐには、この見え方が欠かせない。

第三に、どの単位に紐付けるか。 その接点は、パーソン一人のものか、購買グループ全体のものか、特定の商談のものか。ウェビナーへの参加はパーソンの接点である。提案書の提示は商談の接点である。購買グループ全員が参加した打ち合わせは、購買グループの接点であり、同時に商談の接点でもある。紐付け先を定めておかなければ、接点を積み上げても「この商談で、これまで何が起きたか」を取り出せない。

4-6. MQLを再定義する

接点の次は、リードの定義である。ここではMQLMQL／SQLMarketing Qualified Lead／Sales Qualified LeadMQLはマーケティングが有望と判定したリード、SQLは営業が対応対象として受理したリード。用語集で見る →（Marketing Qualified Lead）を取り上げる。

MQLは従来、「マーケティングが営業に渡す価値があると判定したリード」と定義されてきた。Webの行動やメールの反応にスコアをつけ、閾値を超えたら営業に渡す。この考え方は、個人単位のリードを前提としている。

だが、購買はグループで行われる。1人のスコアが閾値を超えたことは、その人の関心が高まったことを示すにすぎず、その企業の購買グループが検討を始めたことを示すとは限らない。逆に、購買グループの複数人が少しずつ関心を示していても、一人ひとりのスコアは閾値に届かず、営業に渡らないこともある。

本書では、MQLを次のように再定義する。MQLとは、購買グループが検討を始めたことを知らせる信号の一つである。営業に渡すかどうかの合格ラインとして扱うものではない。 1人のスコアが上がったことは、その人が属する購買グループに何かが起きている可能性を示す。それを受けて、同じ企業の同じ部門の他の人物に何が起きているかを確認し、購買グループとしての判定を行う。

この再定義に伴い、判定は2段階で持つ。個人の判定（このパーソンの関心が高まった）と、購買グループの判定（この購買グループが検討を始めた）である。営業に渡すのは後者であり、前者は後者を判断するための手がかりになる。

そして、どの状態になったら、誰が判定し、どの部門へ渡すかは、マーケティングと営業の間で明文化された合意として持つ。これをSLASLAService Level Agreementリードの引き渡し条件・対応期限・差し戻し基準など、部門間で交わす合意。用語集で見る →（Service Level Agreement）と呼ぶ。SLAがなければ、第2章で述べた「数字の不一致」は解消しない。

4-7. 活動を定義する

活動とは、営業やインサイドセールスが、意図を持って顧客に働きかける行為である。訪問、電話、メール、Web会議、提案。接点のうち、自社から働きかけたもので、営業やインサイドセールスが対応したものが活動にあたる。

活動を記録の単位として定義するには、次の3点を決める。

• 種別：訪問、電話、メール、Web会議、提案書提示、見積提示など
• 目的：課題のヒアリング、提案、条件交渉、関係構築など、その活動で何を狙ったか
• 結果：相手の反応、決まったこと、次のアクション

そして、一つの活動に複数の顧客が関わることを前提に設計する。1回の打ち合わせに、顧客側から三人が出席することは珍しくない。活動を一人のパーソンにしか紐付けられない構造だと、残りの二人は記録から消える。活動は、複数のパーソンに紐付けられる構造にしておく。これは第5章で述べる購買グループの発掘にも直結する。

4-8. 商談を定義する

商談の定義は、CRMの中で最も重要であり、最も曖昧にされてきた定義である。

同じ「提案」というステージでも、提案書を送った時点で入れる担当者もいれば、相手の前向きな反応を得てから入れる担当者もいる。見積を出すまで商談を作らない担当者もいる。定義が担当者ごとに違えば、パイプラインパイプライン商談化から受注までの案件の連なり。ステージ定義が曖昧なままだと、数字は積み上がっても予測には使えない。用語集で見る →の数字は実態を表さない。

本書では、商談を次のように定義する。商談とは、買い手、ニーズ、ソリューションの3つが特定され、金額と時期を記載できる状態になった受注機会である。 誰が（買い手）、何に困っていて（ニーズ）、自社の何で解決できるか（ソリューション）が分かり、いくらで（金額）、いつ（時期）という見込みが書ける。この4つが揃ったとき、商談が立つ。

次に決めるのは、商談の入口をどこに置くかである。当社では、買い手の検討の進み方を「購買心理変容購買心理変容8フェーズ買い手の心理が購買に至るまでの変わり方を、8つの段階で捉えたもの。各段階の心理状態・次へ移るきっかけ・売り手のとるべきアプローチを定義し、役割との掛け合わせで「いつ・何を届けるか」を決める。用語集で見る →8フェーズ」という枠組みで捉えている。課題に気づく段階から、情報を集め、要件をまとめ、候補を比較し、決める段階までを8つに分けたものである。商談の入口を、この8フェーズのどこに置くかは、次の4つで決まる。

• 競合状態：競合が多いほど、早い段階で商談を立て、関与を始める必要がある
• コモディティ化の度合い：差別化が難しい商材ほど、早い段階での関係構築が効く
• 単価と検討期間：高単価で検討期間が長いほど、早い段階から商談として追う価値がある
• 営業リソース：早く商談を立てるほど追う件数は増える。追い切れる範囲で決める

そして、商談の入口を前に出すときに変えるのは、その手前で営業が活動を始めるタイミングである。「情報収集の段階から商談を立てる」と決めたなら、情報収集の段階の顧客に対して営業が活動を始める仕組みを作る。起票の基準だけを変えても、活動が伴わなければ、中身のない商談が増えるだけである。

データが知らせるのは、商談として判定を始めるタイミングである。関心の兆しが見えたら、判定を始める。判定して商談が立てば追い、立たなければ育成に戻す。この判断は営業が行い、データはその判断を始める合図を出す。

商談が立った後、それを追い、見通しを立て、組織として管理するのがパイプライン管理である。パイプライン管理を機能させるには、商談に次の項目を持たせ、それぞれの定義を揃える。

ステージ（フェーズ）。 商談が今どの段階にあるかを示す区分である。多くの企業では、ステージを「初回訪問」「提案」「見積」「交渉」のように、営業の行動で区切っている。だが、営業が提案書を出したからといって、顧客の検討が進んだとは限らない。ステージは、顧客の買い方のプロセスで区切る方がよい。顧客が今、課題を整理しているのか、要件をまとめているのか、候補を比較しているのか、社内の承認を得ようとしているのか。4-8で述べた購買心理変容8フェーズは、この区切りの基準になる。

そのうえで、顧客がそれぞれの段階にいるとき、自社が何をしなければならないかをルールとして決めておく。たとえば次のような形である。

• 顧客が要件をまとめている段階：要件をヒアリングし、購買グループの関与者を特定する
• 顧客が候補を比較している段階：提案書を提示し、門番に向けて仕様や条件の資料を届ける
• 顧客が社内の承認を得ようとしている段階：金庫番に向けて投資対効果と会社の信頼性の資料を用意し、見積を提示する

ステージの数や名前より重要なのは、各ステージに入る条件が、顧客の状態として担当者以外にも確認できる事実で定義されていること、そして各ステージで自社がやるべきことが決まっていることである。顧客の段階が分かれば、次に何をすべきかが分かる。何をすべきかが決まっていれば、それができているかどうかで商談の進み具合を確かめられる。条件が曖昧なままステージだけ増やしても、担当者ごとの解釈が入り込み、パイプラインは実態を表さない。

金額。 受注した場合の金額の見込みである。商談が立った時点では概算でよいが、ステージが進むにつれて精度を上げていく。金額はパイプライン全体の見通しの基礎になるため、更新のルール（いつ、誰が、何をもとに見直すか）を決めておく。

受注予定時期（クローズ予定日）。 いつ受注する見込みかを示す日付である。パイプラインの見通しを四半期や月で切るための軸になる。同時に、この日付が延びる（スリップする）ことは、商談が停滞している最も分かりやすい兆しでもある。予定日の変更履歴を残しておけば、何度も延びている商談を早期に見つけられる。

確度と見通しの区分。 その商談が受注に至る確からしさである。ステージに連動した確度を基本としつつ、営業の判断で見通しの区分を持たせる。一般的には、確実に受注できると判断した「コミット」、受注の可能性が高い「ベストケース」、まだ見通しが立たない「パイプライン」、そして今期の見通しから除外する「オミット」といった区分を使う。この区分によって、営業組織としての受注予測を、担当者の楽観や悲観に左右されずに集計できる。オミットは失注とは違う。今期は動かないと判断した商談を、パイプラインの見通しから外しつつ、商談としては残しておくための区分である。

次のアクション。 この商談を前に進めるために、次に誰が何をいつまでに行うかである。次のアクションが空欄の商談は、実質的に止まっている。これを必須項目にすることで、止まっている商談が可視化される。

失注・中断の理由。 商談が受注に至らなかった場合、その理由を分類して残す。競合に負けたのか、予算が付かなかったのか、検討そのものが止まったのか。理由によって、その顧客を次にいつ、どう追うかが変わる。4-10で述べる差し戻しのルールは、この理由の分類を前提にしている。

これらの項目は、営業担当者が商談を進めるために持つものであると同時に、営業組織が見通しを立て、資源を配分するために持つものである。定義が揃って初めて、担当者をまたいで商談を比べ、組織全体のパイプラインを一つの数字として語れる。

4-9. 4つのファネルは、数える対象が違う

商談を定義すると、パイプラインの数字が実態を表すようになる。だが、パイプラインだけがファネルファネルリード獲得から受注までを一方向の絞り込みとして捉える従来モデル。レベニューサイクルと対になる考え方。用語集で見る →ではない。BtoBの収益プロセスには、数える対象が異なる4つのファネルがある。

マーケティングファネルは、人を数える。 認知した人、関心を示した人、MQLになった人。数えているのはパーソンの数であり、絞り込みの過程で人数が減っていく。

セールスファネルは、活動を数える。 架電した数、面談した数、提案した数。数えているのは活動の回数であり、次の段階に進む活動が絞り込まれていく。

パイプラインは、商談を数える。 立った商談の数と金額、ステージごとの分布、受注に至った数。数えているのは受注機会であり、受注に向けて絞り込まれていく。

カスタマーファネルは、顧客を数える。 受注した顧客が、導入し、活用し、定着し、追加で導入し、他部門や他社に推奨する。数えているのは契約数、利用の広がり、関与する人物の数であり、受注後に広がっていく。前の3つが絞り込みのファネルであるのに対し、これだけは拡張のファネル、いわば逆ファネルである。

多くのCRMは、受注で終わっている。パイプラインが受注に至った時点で、その顧客の記録は止まる。それは、カスタマーファネルを持っていないということである。第1章で述べたとおり、受注はエンゲージメントエンゲージメント顧客が自社との接触に価値を感じ、関係を続けたいと思っている状態。接触の量ではなく関係の深さを表し、企業・購買グループ・パーソンの3つの単位で捉える。CRMの目的はこれを高めることにある。用語集で見る →の通過点にすぎない。受注後の活用、定着、拡大を記録する構造を持って初めて、CRMはエンゲージメントを扱える。カスタマーファネルの拡張は、クロスセル・アップセルの実績と、購買グループの広がりで測る。第8章と第9章で詳しく述べる。

4つのファネルを分けて持つ意味は、打ち手と責任部門が違うからである。人が減っているのか、活動が減っているのか、商談が減っているのか、顧客が広がっていないのか。どこが細いかによって、動くべき部門と打ち手が変わる。一つのファネルに混ぜて数えると、どこに問題があるかが分からなくなる。

4-10. レベニューサイクルを循環として持つ

4つのファネルを一続きにすると、顧客との関係の全体像になる。ただし、それは一方向の流れではない。

顧客は、ウォーターフォールでは買わない。検討は行きつ戻りつする。一度止まった検討が半年後に再開する。購買グループの中で、着火役は情報収集の段階にいるが、金庫番はまだ関与していない、というように、人によって段階が違う。既存顧客も、追加導入や更新のたびに、新たな検討の段階に入る。

一方向のファネルでは、これらの動きがすべて「失注」や「停滞」として扱われ、機会が消えていく。当社では、獲得、育成、商談、受注、活用、拡大、再検討がつながる循環として収益プロセスを捉え、これを「レベニューサイクルレベニューサイクルリード獲得から受注後の拡大・再購買までを、一つながりの循環プロセスとして捉える収益モデル。用語集で見る →モデル」と呼んでいる。

CRMのデータ構造としては、次の3点を持つ。

第一に、状態は企業・購買グループ・パーソンの各単位で持つ。 「この企業は商談中」という一つの状態では足りない。この購買グループは提案評価の段階、このパーソンは情報収集の段階、というように、単位ごとに状態を持つ。

第二に、差し戻しのルールを持つ。 商談化商談化リードが営業の対応する案件になること。ここで購買グループの関心・懸念が一人分に縮むと、以降の設計が効かなくなる。用語集で見る →しなかった購買グループを、どの状態に戻し、誰が追うのか。失注した商談を、いつ再検討の対象にするのか。戻す先と担当が決まっていなければ、戻された顧客は誰のものでもなくなる。

第三に、状態の履歴を持つ。 商談のステージが後戻りしたこと、クローズ予定日が延びたこと、最終更新から時間が経っていること。現在の状態だけでなく履歴を持つことで、パイプラインが崩れる兆しを捉えられる。ステージ移行の実績から算出した確度は、担当者の主観による確度より、予測の精度が高い。

4-11. 定義はシステムに実装する

ここまで述べた定義は、定義書やマニュアルに書いただけでは機能しない。現場は定義書を読まない。定義は、システムに実装して初めて守られる。

実装の手段は、次のとおりである。

• 必須項目：商談を立てるには買い手・ニーズ・ソリューション・金額・時期の入力を必須にする。入力できなければ商談は立たない
• 入力規則：活動には種別・目的・結果を必ず持たせる。接点には、対応した部門と担当者、紐付け先を持たせる
• ステージの進行条件：次のステージに進むには、そのステージで満たすべき条件が入力されていることを求める
• 権限：定義の変更は限られた担当者だけが行える。現場が自由にステージを追加したり、項目の意味を変えたりできないようにする

ただし、必須にするのは、担当者以外が確認できる事実だけにする。「顧客の温度感が高い」といった主観的な項目を必須にすると、入力のための入力が増え、第2章で述べた入力不定着の問題が再燃する。「提案書を提示した日」「出席者の氏名」のような、事実として確認できることを必須にし、判断は営業に委ねる。

データ構造と定義が揃うと、顧客について「何を記録するか」が決まる。次章では、その構造の中心にある購買グループについて、どう捉え、どう発掘し、顧客内の関係性をどう可視化するかを述べる。