CRMに入れたデータが検索しても出てこない。原因は「命名規則」だった

CRM導入プロジェクトで最も地味だが、最も後から効いてくるのが「プロパティ（項目）の命名規則」だ。営業部は「初回アポ日」、マーケ部は「初回接触日」、カスタマーサクセスは「オンボーディング開始日」。同じ概念を3つの名前で呼んでいる状態でCRMに突っ込むと、半年後にはプロパティが200個に膨れ上がり、誰も正しいデータがどこにあるかわからなくなる。

部門ごとのExcel管理→CRM統一で起きる問題

従業員30〜100名のBtoB企業でありがちなのが、営業・マーケ・CSがそれぞれ独自のExcelやスプレッドシートで顧客情報を管理しているパターン。各部門のExcelは、その部門にとって最適化されているが、用語体系がバラバラだ。

この状態のままCRMにデータを移行すると、「初回アポ日」と「初回接触日」が別プロパティとして作成され、片方にしかデータが入っていない。レポートを作ろうとすると、どちらを参照すべきかわからない。この混乱は、CRM導入後3ヶ月で必ず表面化する。

命名規則テンプレート：カテゴリ_項目名_属性

プロパティ名は「カテゴリ_項目名_属性」の3層構造で統一する。英語のスネークケース（小文字+アンダースコア）が基本。

日本語のラベル名（CRM上の表示名）は自由に設定してよい。重要なのは、内部名（API名）が統一されていること。HubSpotの場合、プロパティの「内部名」は後から変更できないので、最初に正しく設定する必要がある。

HubSpotのプロパティ設計で避けるべき5つのアンチパターン

1. 同じ概念を複数プロパティで持つ

「初回アポ日」と「初回接触日」を別プロパティで作るパターン。データが分散し、レポートの信頼性が落ちる。1つの概念は1つのプロパティに統一する。部門ごとに「表示名」を変えたい場合は、ビューのカスタマイズで対応する。

2. 自由記述フィールドを乱発する

「備考」「メモ」「その他」のような自由記述フィールドは便利だが、集計・分析ができない。失注理由を自由記述にすると「価格が高い」「高い」「コスト的に難しい」「予算超過」が全て別データになる。選択式にして、選択肢に「その他（自由記述）」を設けるのが正解。

3. 日本語の内部名を使う

HubSpotのプロパティ内部名に日本語を使うと、API連携やワークフローでの参照が煩雑になる。外部ツールとの連携時にエンコード問題が発生するケースもある。内部名は必ず英語のスネークケースで統一する。

4. プロパティグループを整理しない

HubSpotはプロパティをグループ単位で管理できる。グループを使わずにプロパティを作り続けると、100個を超えたあたりから「どこに何があるか」がわからなくなる。最低限、以下のグループ分けをしておく。

5. 削除せずにプロパティを増やし続ける

使われなくなったプロパティを放置すると、データ入力時に「どれに入れればいいかわからない」状態になる。四半期に1回、プロパティの利用状況を確認し、過去90日間で1回も更新されていないプロパティは非表示にするか削除する。HubSpotの場合、プロパティの「最終更新日」でフィルタリングできるので、この棚卸し作業は30分程度で完了する。

10名以上の営業チームでの運用ルール

命名規則を決めただけでは、運用は回らない。10名以上の営業チームで統一的にCRMを使い続けるには、以下の3つのルールが必要になる。

まとめ：命名規則は「CRMの基礎工事」

プロパティの命名規則は、CRMの設定の中で最も地味な作業だ。しかし、ここを手抜きすると半年後に「データがぐちゃぐちゃでレポートが信用できない」「どのプロパティを見ればいいかわからない」という状態になる。CRM導入の最初の1〜2週間で命名規則とプロパティ辞書を整備する。この「基礎工事」が、1年後のデータ活用の可否を決める。