CRMカスタムフィールド:追加すべきものと避けるべきもの

CRMカスタムフィールド:追加すべきものと避けるべきもの

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

あるSaaS企業がHubSpot CRMを80のカスタムフィールドで立ち上げました。RevOpsのリードは、Go-live前に営業、マーケティング、経営陣からのすべての要求を満たそうとしていました。6週間後、採用率は40%でした。担当者から最も多かった不満:「案件を作成するのに10分かかる。」

22のフィールドに削減しました。1か月以内に採用率は85%に達しました。CRMの価値実現に関するGartnerの調査では、過剰な必須フィールドと肥大化したデータ入力が、最初の90日間にCRMの採用が低迷する主な要因であると指摘されています。

これは珍しい話ではありません。ほとんどのCRMは、立ち上げから90日以内に肥大化します。悪意からではなく、「とりあえずフィールドを追加しよう」という文化から。すべてのフィールドにはコストがあります。担当者が入力しなければならないフィールド(摩擦)か、無視できるフィールド(ノイズ)のどちらかです。どちらも中立ではありません。

このガイドでは、導入前、導入中、導入後のすべてのフィールド要求に対する意思決定の枠組みを提供します。

ステップ1:フィールドを追加する前に3つの質問テストを適用する

すべてのフィールド要求に3つの質問をします。3つすべてにノーであれば、フィールドはCRMに入りません。この規律は、旧システムからデータを移行する場合に特に重要です。フィールドリストが肥大化していると、移行はすぐに悪夢になります。

質問1:レポートを作成しますか? このデータはダッシュボード、週次レポート、または経営層へのビューに表示されますか?このフィールドが重要な具体的なレポートを名前で挙げられない場合、おそらくCRMには必要ありません。「知れたら面白い」はレポートの要件ではありません。

質問2:セグメント分けに使いますか? このフィールドはコンタクト、企業、または案件のフィルタリング、ソート、グルーピングに使用されますか?例:予測通話のための案件タイプ別のすべての案件のフィルタリング、マーケティングキャンペーンのためのIndustry別のコンタクトのセグメンテーション、テリトリー割り当てのための従業員数による企業のクエリ。

質問3:ワークフローやオートメーションがそれに依存しますか? CRMのオートメーションはこのフィールドの値に基づいてトリガーされますか?例:テリトリーによるリードのルーティング(テリトリーフィールドが必要)、リードステータスが変わったときのフォローアップシーケンスの送信(リードステータスピックリストが必要)、案件がステージに入ったときのタスク作成(ステージがフィールド)。

フィールドが少なくとも1つにイエスと答えれば、CRMに場所があります。3つすべてにノーと答えれば、別の場所を提案してください:メモフィールド、外部スプレッドシート、または保存なし。

1つの例外:インテグレーションで必要なフィールド(例えば、マーケティングツールがメールパーソナライゼーション用に特定のフィールドを取得する)は内部レポートに役立たなくても許可されます。ただし、所有者が必要です。

ステップ2:適切なフィールドタイプを選択する

間違ったフィールドタイプを選ぶと、事後に修正が難しいデータ品質の問題が生じます。このテーブルを使って決定してください:

フィールドタイプ 使用する場合 使用しない場合
テキスト(1行) 固有識別子、固有名詞、ID 集計またはグループ化するもの
テキスト(複数行) 記述的なコンテキスト、ミーティングメモ、ディスカバリーのサマリー 繰り返しパターンがあるもの
ピックリスト グループ化、フィルタリング、またはトリガーに使用する値 レコードごとに真に固有な値
数値 数量、カウント、測定値 通貨(通貨タイプを使用)、パーセンテージ
通貨 案件金額、契約金額、MRR 比率またはパーセンテージ
日付 クローズ日、契約開始日、最終活動日 期間(日付フィールドを2つ使用)
チェックボックス はい/いいえのブールフラグ 2つ以上の状態があるもの
ルックアップ / アソシエーション 1つのオブジェクトを別のオブジェクトに接続する場合 関連レコードの名前をテキストとして保存する場合
数式 他のフィールドから派生した計算値 手動入力が必要なもの

最も一般的な間違い:ピックリストが必要な場合にテキストフィールドを使用すること。Industryに自由入力テキストを使うと、「SaaS」、「Software as a Service」、「B2B SaaS」、「Tech」がすべて同じ意味で使われます。この4つのバリエーションがIndustryレポートを無意味にします。

有限の意味のある値セットがあるフィールド(Industry、案件タイプ、失注理由、リードソース、顧客層、地域)はピックリストであるべきで、テキストではありません。

ステップ3:必須フィールドを10以下に保つ

必須フィールドは最も速い採用を低下させる方法です。すべての必須フィールドは案件作成を遅らせるゲートです。案件を60秒以内に作成できない担当者はCRMを回避します。この摩擦の問題は、総所有コストの実態分析でも一貫して表れています。必須フィールドの数が多いと、サポートチケットやシャドースプレッドシートが増え、プラットフォームの真のコストを押し上げます。CRM展開と採用ガイドには、必須フィールド数と30日時点の採用率との直接的な相関が示されています。

誘惑はデータ品質を強制するためにすべてを必須にすることです。しかしそうは機能しません。答えを知らない必須フィールドを埋めることを強いられた担当者はランダムな値を選ぶか「不明」と入力します。悪いデータは欠損データよりも悪いです。

必須フィールドを、作成時にレコードを有用にする絶対最小限に抑えてください:

コンタクトの場合: メール(または電話番号、少なくとも1つ)、名、姓、オーナー。

案件の場合: 案件名、Pipelineステージ、クローズ日、案件金額(概算でも)、主担当コンタクト。

企業の場合: 企業名、オーナー。IndustryとサイズはEnrichmentで補完できます。

グローバルに必須にするのではなく、条件付きで追加フィールドを必須にしてください。HubSpotでは、案件が特定のステージに達したときにのみフィールドを必須にできます。Salesforceでは、別のフィールドが特定の値に設定されたときにフィールドを必須にするバリデーションルールを使用できます。Salesforceのバリデーションルールに関するドキュメントでは、数式の構文とエラー処理を解説しています。グローバルな必須条件の代わりにこれらの条件付き必須条件を使用してください。

例:失注理由は、Pipelineステージが「クローズロスト」に設定されたときに必須になります。案件作成時には必須ではありません。それが正しいアプローチです。

ステップ4:初日からピックリストの衛生管理を行う

ピックリストは誰も所有していなければ時間とともに劣化します。8つのクリーンなIndustry値から始め、1年間のチェックなし追加の後には24つになります。

立ち上げ前にこれらのガバナンスルールを設定してください:

命名規則:規則を選び、適用してください。タイトルケースか文章ケース。「Financial Services」であり、「financial services」や「FinancialServices」ではありません。1人の管理者が唯一の情報源となります。

誰が値を追加できるか:Salesforceでは、ピックリスト値は管理者レベルで管理されています。担当者は追加できません。HubSpotとPipedriveでは、デフォルトはよりオープンです。これをロックしてください。定義された所有者とともにリクエストプロセスを必要にしてください。

アーカイブ vs. 削除:ピックリスト値が廃止されたとき、アーカイブしてください。削除しないでください。削除すると既存のレコードから削除されます。アーカイブすると履歴データはそのままで、値が新しいレコードに表示されなくなります。HubSpotでは「プロパティ値を無効化」です。Salesforceでは古い値を非アクティブにできます。

レビューの頻度:四半期ごとに、未使用または重複している値について各ピックリストをレビューしてください。過去6か月に0または限りなく0に近い使用回数の値はアーカイブ候補です。

ステップ5:CRMフィールドとEnrichmentフィールドの違いを理解する

これにより多くのフィールドの肥大化を節約できます。データには2種類あります:担当者だけが知っていることと、Enrichmentツールがすでに知っていること。

Enrichmentツールが知っていること(Clearbit、Apollo、ZoomInfo、6senseから):ForresterのB2Bデータ品質に関する調査によると、データEnrichmentを使って企業属性フィールドを自動入力する企業は、手動のデータ入力時間を30〜50%削減しつつ、データの正確性も向上させています。

  • 企業の従業員数
  • 企業の売上規模
  • 企業の資金調達ステージ
  • コンタクトのLinkedURL
  • 企業の本社所在地
  • 技術スタック
  • Industry(多くの場合)

CRMにネイティブのEnrichmentインテグレーションがある場合、これらのカスタムフィールドは必要ありません。HubSpotは特定の層でClearbitが内蔵されています。HubSpotのデータEnrichmentに関するドキュメントでは、どのフィールドが自動入力されるか、上書きの挙動をどう制御するかを説明しています。SalesforceはZoomInfoなどに接続します。Enrichmentがこれらのフィールドを自動入力すると、担当者の入力なしに一貫した清潔なデータが得られます。

担当者だけが知っていること(フィールドを構築する価値があるもの):

  • コンタクトとの関係の強さ
  • 社内チャンピオンと経済的バイヤーの区別
  • 顧客固有の要件や制約
  • タイムライン変更の理由
  • 購買委員会との次のステップ

これらが構築する価値のあるフィールドです。データベースからスクレイピングできない洞察をキャプチャします。

経験則:フィールドを構築する前に、ApolloやClearbitがすでに答えを知っているかどうかを聞いてください。はいならEnrichmentを使用してください。いいえならフィールドを構築してください。

ステップ6:四半期ごとのスケジュールで既存フィールドを監査する

ほとんどのチームはフィールドを削除しません。ただ追加し続けます。2年間稼働しているHubSpotポータルのコンタクトオブジェクトには、60から120のカスタムプロパティがあり、その多くについて誰も説明できません。MIT Sloan Management Reviewのデータガバナンスに関する調査は、フィールドのガバナンス不足が、営業組織で分析施策が失敗する主な原因の上位3つに入ると指摘しています。新しいCRMへの移行を計画している場合は、先にこの監査を実施してください。移行前のデータ準備ガイドでは、フィールドの肥大化が後工程でどのようにインポートの問題を生むかを具体的に示しています。

これらのステップで四半期ごとの監査を実施してください:

  1. フィールド使用レポートを取得してください。HubSpotでは:設定 → プロパティ → オブジェクトを選択 → 「データがあるレコード数」でソート。Salesforceでは:AppExchangeのField Tripアプリまたはフィールド使用に関するカスタムレポートを使用。Pipedriveでは:サンプルをエクスポートして手動で入力率を確認。

  2. レコードの10%未満にデータがあり、オートメーションが依存していないフィールドをフラグ立てしてください。これらが削除候補です。

  3. フラグ立てされた各フィールドについて、それをリクエストした人に確認してください:まだこれを使っていますか?それに依存するレポートはありますか?いいえならアーカイブしてください。

  4. 保持しているが値が一貫していないフィールドのデータをクリーニングしてください。ピックリストであるべきテキストフィールドで重複排除を実行してください。

  5. 削除したものとその理由をドキュメント化してください。6か月後に誰かが尋ねても記録があります。

フィールドの監査は地味な作業ですが、CRMがデータの不整合と無視の場所にならないようにします。プラットフォームを移行する場合にも、クリーンなフィールド構造は非常に重要です。データ移行のためのフィールドマッピングガイドでは、フィールドの衛生管理を怠った場合にどれほど混乱するかを具体的に解説しています。

よくある失敗

「将来の」レポートのためにフィールドを構築する。 「これをいつか追跡したいかもしれない」では不十分です。使われないフィールドに2つの方法でコストを支払います:データ入力での担当者の摩擦とレコードを開くときの認知的オーバーヘッドです。そのフィールドに依存するレポートやオートメーションを誰かが示すまで、フィールドの構築は先送りしてください。

オブジェクト間でフィールドを複製する。 「リードソース」がコンタクトと案件の両方に存在し、時々一致しない場合、どちらが正しいですか?一度定義し、ルックアップを使用してください。案件にリードソースが必要な場合は、2つの別々のフィールドを維持するのではなく、数式またはワークフローでコンタクトから取得することを検討してください。

ピックリストが必要な場合にフリーテキスト。 上で説明しましたが、繰り返す価値があります:数えたり、グループ化したり、フィルタリングしたりすることがあるフィールドはピックリストであるべきです。テキストは記述のため、ピックリストは分類のためです。

導入中盤で必須フィールドを追加する。 Go-live後にフィールドを必須にすると、そのフィールドが欠けているすべての既存レコードでバリデーションエラーが発生します。必須フィールドはGo-live前に計画してください。担当者の不満が出始めます。後から要件を追加する必要がある場合は、段階的なロールアウトを使用してください。

新しいフィールドを追加する前に既存のフィールドリストを確認しない。 誰も既存のものを確認しなかったために重複フィールドを作成することはよくあります。「契約署名日」を作成する前に、フィールドリストを検索してください。「クローズ日」または「契約実行」として既に存在するかもしれません。

次のステップ

立ち上げ後、30日間のフィールドフリーズを実施してください。最初の30日間は新しいカスタムフィールドを作成しません。入ってくるすべての要求はキューに入ります。30日後、一緒にキューをレビューしてください。多くの要求は自然に解決されます(フィールドは必要なかった)、一部は既存フィールドを別の方法で使うことで満たせます。そして本当に新しいフィールドが必要なのはほんの一握りです。

これにより、複雑さを加える前にCRMが安定する時間が生まれ、フィールドの要求には正当な理由が必要だとチームに教えることにもなります。また、現在のステージのチームにとってリーンなCRMプラットフォームの費用がどの程度であるべきかを検討している場合は、Reworkの料金の詳細が参考になります。

その後、作成したフィールドに依存するワークフローオートメーションを構築してください。それらのピックリストとトリガーは実際に何かを行う必要があります。

関連記事

About the author

Calvin D.

Calvin D.

Head of Enterprise Solutions

Calvin D. is Head of Enterprise Solutions at Rework, writing for sales directors and CROs. Calvin covers how B2B companies choose and implement software, buy SaaS, migrate data, and run the sales process, plus deal closing and pipeline management, with a focus on decisions that still hold up as the sales organization grows.