crm-hygiene

CRM のデータ品質管理

CRM のデータ品質に関する問題を体系的に特定して解決し、予測精度、レポート、オートメーションの信頼性を向上させます。

このスキルを使用するタイミング

• 四半期ごとの CRM 監査
• 主要なレポート期間の前
• オートメーションのワークフローが失敗したとき
• チームの変更や移行の後
• CRM 連携の準備

方法論の基盤

Salesforce Data Quality Best Practices と RevOps Co-op Data Governance frameworks に基づき、以下に焦点を当てます。

• 完全性（必須フィールドに値が入力されている）
• 一貫性（値が標準化されている）
• 正確性（データが正しく、最新である）
• 適時性（最近更新されている）

Claude が行うことと、あなたが決めること

Claude が行うこと	あなたが決めること
監査基準を定義する	必須フィールド
データの問題を特定する	修正の優先順位
問題を種類別に分類する	クリーンアップ作業の担当者
修正手順を提案する	オートメーションで修正するか、手動で修正するか
クリーンアップレポートを作成する	適用ポリシー

このスキルでできること

1. 監査の設計 - 必須フィールドと検証ルールを定義します
2. 問題の特定 - 欠落、矛盾、重複のあるデータを見つけます
3. 優先順位付け - ビジネスへの影響に基づいて問題に順位を付けます
4. 修正計画 - 問題を修正するための手順を示します
5. ガバナンスに関する推奨事項 - 将来の問題を防ぎます

使用方法

監査を設計する場合：

Help me create a CRM hygiene audit for [CRM System].

Key objects to audit:
- [Leads, Contacts, Accounts, Opportunities]

Critical fields for each:
- Leads: [list required fields]
- Opportunities: [list required fields]

Our main issues:
- [Describe known problems]

データを監査する場合：

Audit this opportunity data for hygiene issues:

[Paste export or describe data]

Required fields:
- [List fields that must be populated]

Validation rules:
- [List rules like "Stage must match Amount > $0"]

手順

ステップ 1：監査範囲を定義する

オブジェクトの優先順位（一般的な例）：

1. 商談 - 売上への影響
2. 取引先 - 関係構築の基盤
3. 取引先責任者 - コミュニケーションの正確性
4. リード - パイプラインの流入元

フィールドのカテゴリ：

• 必須 - 欠落するとプロセスが停止します
• 重要 - レポートやセグメンテーションに影響します
• あると望ましい - 情報を充実させますが、必須ではありません

ステップ 2：完全性を監査する

オブジェクトごとに必須フィールドを確認します。

商談：

フィールド	重要度	必須である理由
金額	必須	予測、パイプラインの金額
完了予定日	必須	予測のタイミング
フェーズ	必須	パイプラインのレポート
所有者	必須	説明責任
取引先	必須	会社との関連付け
主担当者	重要	コミュニケーション
次のステップ	重要	商談の進展
競合他社	重要	受注／失注の分析
失注理由	必須（失注の場合）	改善に役立つ知見

取引先：

フィールド	重要度	必須である理由
業種	重要	セグメンテーション
従業員数	重要	ICP との適合性
Web サイト	重要	調査、情報の充実
請求先住所	必須	請求処理
取引先所有者	必須	説明責任

ステップ 3：一貫性を監査する

標準化に関する問題を確認します。

問題の種類	例	影響
選択リストの表記ゆれ	「US」と「USA」と「United States」	レポートが機能しなくなります
大文字・小文字の不一致	「ACME」と「Acme」と「acme」	重複が発生します
形式のばらつき	「(555) 123-4567」と「5551234567」	オートメーションが失敗します
NULL と空欄の違い	NULL と "" と "N/A"	フィルターが機能しません

ステップ 4：正確性を監査する

誤っている可能性が高いデータを特定します。

確認項目	基準	対応
古い完了予定日	日付が過去で、商談がオープンのまま	更新またはクローズする
金額の不一致	後半フェーズで金額が $0	価格を確認する
フェーズの後退	フェーズ 4 → フェーズ 2	調査する
不可能な値	確度が 200%	検証ルールを修正する
バウンスしたメール	無効としてマークされている	削除または更新する

ステップ 5：重複を検出する

重複の可能性があるデータを見つけます。

一致の種類	基準	確度
メールアドレスの完全一致	メールアドレスが同じ	重複の確度 99%
ドメインの一致	会社のドメインが同じ	重複の確度 80%
あいまいな名前の一致	会社名が類似	調査が必要
電話番号の一致	電話番号が同じ	重複の確度 90%

ステップ 6：鮮度監査

古くなったレコードにフラグを付けます：

オブジェクト	古さのしきい値	アクション
商談中のオポチュニティ	30 日間アクティビティなし	担当者と確認
リード	14 日間接触なし	再割り当てまたは育成
アカウント	90 日間連絡なし	再エンゲージメント
連絡先	バウンスから 30 日経過	アーカイブ

例

例 1：オポチュニティ監査

入力：

Audit these opportunities:

1. Acme Corp - Stage: Proposal, Amount: $0, Close: Jan 15 (past), Owner: Empty
2. Beta Inc - Stage: Closed Won, Amount: $50K, Close: Feb 1, Loss Reason: "Price"
3. Gamma LLC - Stage: Discovery, Amount: $100K, Close: Mar 30, No activity 45 days
4. Delta Co - Stage: Negotiation, Amount: $75K, Close: Feb 28, Next Step: Empty
5. Echo Systems - Stage: Closed Lost, Amount: $200K, Loss Reason: Empty

出力：

## CRM Hygiene Audit: Opportunities

### Summary
- **Total Records**: 5
- **Critical Issues**: 4
- **Warnings**: 2
- **Clean Records**: 0

### Critical Issues (Fix Immediately)

#### 1. Acme Corp - 3 Critical Issues
| Issue | Field | Current | Required |
|-------|-------|---------|----------|
| 🔴 Missing | Owner | Empty | Assigned rep |
| 🔴 Missing | Amount | $0 | Deal value |
| 🔴 Stale | Close Date | Jan 15 (past) | Future date |

**Action**: Assign owner, verify if deal is active, update amount and close date.

#### 2. Beta Inc - Logic Error
| Issue | Field | Current | Problem |
|-------|-------|---------|---------|
| 🔴 Inconsistent | Loss Reason | "Price" | Stage is "Closed Won" |

**Action**: Either change stage to Closed Lost, or clear Loss Reason.

#### 3. Echo Systems - Missing Required
| Issue | Field | Current | Required |
|-------|-------|---------|----------|
| 🔴 Missing | Loss Reason | Empty | Required for Closed Lost |

**Action**: Rep must document why deal was lost.

#### 4. Delta Co - Missing Next Step
| Issue | Field | Current | Impact |
|-------|-------|---------|--------|
| 🟠 Missing | Next Step | Empty | No clear action |

**Action**: Rep should define next step for Negotiation stage.

### Warnings (Review This Week)

#### 5. Gamma LLC - Stale Deal
| Issue | Indicator | Value |
|-------|-----------|-------|
| 🟡 Stale | Last Activity | 45 days ago |

**Action**: Review with rep - is this deal still active? If yes, update. If no, close lost.

### Hygiene Score: 20/100 (Poor)

### Recommended Actions by Priority

1. **Today**: Fix Acme Corp (no owner = orphaned deal)
2. **Today**: Fix Beta Inc logic error (affects win rate)
3. **This Week**: Get Echo Systems loss reason
4. **This Week**: Update Gamma LLC status
5. **This Week**: Add Delta Co next step

### Process Recommendations
- Add validation rule: Amount required when Stage > Discovery
- Add validation rule: Owner required on all opportunities
- Add validation rule: Loss Reason required when Closed Lost
- Create stale deal report (no activity 30+ days)

例 2：重複の検出

入力：

Check these accounts for duplicates:

1. Acme Corporation, acme.com, San Francisco
2. ACME Corp, acme.com, SF
3. Acme Inc, acme-inc.com, San Francisco
4. Beta Technologies, beta.io, New York
5. Beta Tech, betatech.com, NYC
6. Beta Technologies Inc, beta.io, New York

出力：

## Duplicate Detection Report

### High Confidence Duplicates (Merge)

#### Duplicate Set 1: Acme Corporation
| Record | Name | Domain | Location | Confidence |
|--------|------|--------|----------|------------|
| #1 | Acme Corporation | acme.com | San Francisco | Master |
| #2 | ACME Corp | acme.com | SF | 99% - Same domain |

**Recommendation**: Merge #2 into #1
- Same domain (acme.com)
- Same location (SF = San Francisco)
- Name variation only (Corp vs Corporation)

#### Duplicate Set 2: Beta Technologies
| Record | Name | Domain | Location | Confidence |
|--------|------|--------|----------|------------|
| #4 | Beta Technologies | beta.io | New York | Master |
| #6 | Beta Technologies Inc | beta.io | New York | 99% - Same domain |

**Recommendation**: Merge #6 into #4
- Same domain (beta.io)
- Same location (New York)
- Name variation only (Inc suffix)

### Investigate (Possible Duplicates)

#### Possible Set 1: Acme variations
| Record | Name | Domain | Location | Confidence |
|--------|------|--------|----------|------------|
| #1 | Acme Corporation | acme.com | San Francisco | - |
| #3 | Acme Inc | acme-inc.com | San Francisco | 40% |

**Recommendation**: Investigate manually
- Same location, similar name
- BUT different domains (acme.com vs acme-inc.com)
- Could be: subsidiary, different company, or typo

#### Possible Set 2: Beta variations
| Record | Name | Domain | Location | Confidence |
|--------|------|--------|----------|------------|
| #4 | Beta Technologies | beta.io | New York | - |
| #5 | Beta Tech | betatech.com | NYC | 50% |

**Recommendation**: Investigate manually
- Same location (NYC = New York)
- Similar names (Beta Tech vs Beta Technologies)
- Different domains - likely different companies

### Summary
- **Definite Duplicates**: 2 sets (4 records → 2)
- **Possible Duplicates**: 2 sets (need research)
- **Unique Records**: Pending investigation

### Merge Checklist
Before merging, verify:
- [ ] All opportunities moved to master record
- [ ] All contacts linked to master
- [ ] Activity history preserved
- [ ] Custom fields compared
- [ ] Integration IDs noted (for external systems)

スキルの適用範囲

このスキルが得意なこと

• 監査基準を体系的に定義する
• よくあるデータ品質の問題を特定する
• ビジネスへの影響に基づいて修正の優先順位を付ける
• 実行可能な是正計画を作成する

このスキルでできないこと

• 実際の CRM データにアクセスする
• クリーンアップを自動で実行する
• 個別のビジネスルールを把握する
• すべての意味上のエラーを検出する

人間にエスカレーションする場合

• マージの判断（データ損失のリスク）
• ビジネスルールの定義
• 適用ポリシーの判断
• オブジェクト間の関連に関する問題

反復ガイド

フォローアップ用プロンプト

• 「月次のデータ衛生レポートのテンプレートを作成してください。」
• 「こうした問題を防ぐには、どのような検証ルールが必要ですか？」
• 「収益への影響に基づいて、上位 10 件の問題に優先順位を付けてください。」
• 「これらのルールを適用するデータ入力フォームを設計してください。」

継続的な改善サイクル

1. 監査 → 問題を特定する
2. 修正 → データをクリーンアップする
3. 予防 → 検証ルールを追加する
4. 監視 → データ衛生スコアを毎週追跡する
5. 反復 → ルールを四半期ごとに見直す

チェックリストとテンプレート

週次データ衛生レポートのテンプレート

## CRM Hygiene Report - Week of [Date]

### Hygiene Score: X/100

### Critical Issues (Fix Today)
| Object | Record | Issue | Owner |
|--------|--------|-------|-------|

### Warnings (Fix This Week)
| Object | Count | Issue Type |
|--------|-------|------------|

### Trends
- Issues closed this week: X
- New issues this week: X
- Net change: +/- X

### Action Items
1.
2.
3.

データガバナンスのチェックリスト

• オブジェクトごとに必須フィールドを定義済み
• 検証ルールを実装済み
• 重複ルールを有効化済み
• 古いレコードのレポートをスケジュール済み
• 所有者の割り当てが最新
• 統合のマッピングを文書化済み

参考資料

• Salesforce データ品質のベストプラクティス
• RevOps Co-op データガバナンスフレームワーク
• Marketo データベース健全性ガイド
• Gartner データ品質マーケットガイド

関連スキル

• pipeline-forecasting - クリーンなデータは予測の精度を向上させます
• lead-scoring - 完全なリードデータが必要です
• deal-risk-scoring - アクティビティデータに依存します

スキルのメタデータ

• ドメイン：RevOps
• 複雑さ：中級
• モード：centaur
• 価値を実感できるまでの時間：監査は 30～60 分、クリーンアップの所要時間は状況によって異なります
• 前提条件：CRM データのエクスポート、フィールド要件リスト