アカウント階層管理: CRM の親子組織

営業担当者がフォーチュン 500 企業のヒューストン オフィスと契約を結びました。 3 か月後、別の営業担当者が、既存の関係を知らずに、まったく新しい見込み客として同じ会社のダラス オフィスを追求しました。ヒューストンの取引の価格、条件、得られた教訓は目に見えない。会社は組織化されていないように見え、営業活動は重複して行われ、顧客は信頼を失います。

これは、階層型組織ではなくフラットな連絡先リストとしてアカウントを管理する B2B 企業で日常的に発生しています。エンタープライズ B2B では、顧客は個人や単一の企業ではありません。顧客は親会社、子会社、部門、拠点からなる組織構造であり、それぞれに独自の連絡先、要件、注文パターンがあります。

重要なポイント

• B2B アカウントは組織階層であり、フラットな連絡先ではありません --- CRM は親子関係を正確にモデル化する必要があります
• 子会社レベルで個別の注文を維持しながら、親レベルで一括請求することが最も一般的な複数エンティティの要件です
• テリトリーの割り当ては、適用範囲の重複を防ぐために、個別の連絡先ではなく、アカウント階層に従う必要があります。
• 親レベルでのアカウント健全性スコアリングにより、子会社データが集計され、関係全体の正確な状況が得られます。

---

アカウント階層を理解する

B2B 組織構造

B2B 顧客にはいくつかの構造パターンがあり、それぞれに異なる CRM モデリングが必要です。

例: アカウント階層

中規模市場の製造複合企業を考えてみましょう。

この構造では、価格は L0 レベルで交渉され、注文は L1 レベルで行われ、出荷は L2 の場所に配送されます。 CRM はこれらすべての関係をモデル化し、各レベルで異なるワークフローをサポートする必要があります。

---

Odoo での階層のモデリング

親会社の構成

Odoo の連絡先モジュールは、連絡先レコードの「会社」フィールドを通じて親子関係をネイティブにサポートします。連絡先を親会社にリンクして、階層構造を作成できます。

設定手順:

1. 親会社を会社タイプの連絡先として作成し、すべてのマスターデータ (クレジット条件、価格表、支払条件) を設定します。
2. [会社] フィールドで親会社との会社タイプの連絡先として 子会社を作成します。
3. 連絡先を作成 それぞれの会社に関連付けられた個人タイプの連絡先として
4. 継承の構成 --- どのフィールド (価格、条件、クレジット) を親から継承するか、独立して設定するかを決定します。

フィールド継承戦略

すべてのフィールドが親から継承する必要があるわけではありません。継承ポリシーを明示的に定義します。

複数エンティティの連絡先管理

階層内の各エンティティには、異なる役割を持つ独自の連絡先があります。

---

一括請求と分散請求

請求モデル

請求モデルは、請求書の受信者と請求書の編成方法を定義します。

Odoo での一括請求の実装

Odoo で一括請求を行うには、販売注文の「請求書住所」が親会社を指し、「配送先住所」が子会社または支店の場所を指すように構成する必要があります。これにより、実際の受け取り場所の配送詳細が記載された親宛の請求書が作成されます。

3 つの子会社を持ち、それぞれが月に 20 件の注文を行う持株会社の場合、一括請求により、請求書の量が 60 件の請求書から 1 つの連結計算書に減り、双方の買掛金が大幅に簡素化されます。

ステートメントの調整

請求が統合される場合、親会社の AP チームは、各請求を元の子会社にマッピングする明細書を必要とします。 Odoo の顧客明細は、子会社ごとにトランザクションをグループ化するように構成でき、次のように表示されます。

• 子会社の名称と参照先
• 注文番号と日付
• 項目と金額
• 受領および適用された支払い
• 子会社ごとの残高
• 未払い残高合計

これにより、親会社は内部コスト配分に必要な詳細を得ることができると同時に、効率性を高めるための単一の支払いポイントが提供されます。

---

テリトリーの割り当てとアカウント チーム

テリトリーモデル

テリトリーの割り当てによって、どの販売およびサポート リソースがどのアカウントを担当するかが決まります。階層的なアカウント構造では、さまざまなレベルでテリトリーを割り当てることができます。

アカウントチームの役割

大規模な B2B アカウントには、1 人の営業担当者ではなく、チームが必要です。アカウント チームの明確な役割を定義します。

Odoo では、セールス チーム機能を通じてアカウント チームの割り当てを管理でき、チーム メンバーは適切な階層レベルで特定のアカウントにリンクされます。

---

アカウントの健全性スコアリング

親レベルの健康状態の集計

個々の補助指標は誤解を招く可能性があります。別の子会社が業績を伸ばしているため、アカウント全体が増加しているにもかかわらず、ある子会社の注文が減少している可能性があります。アカウントの健全性は、すべての子会社からのデータを集計し、親レベルでスコアリングする必要があります。

ヘルススコアのコンポーネント

スコアが 5.0 未満の場合は、アカウントのレビューがトリガーされます。スコアが 4.0 未満の場合は、管理者にエスカレーションする必要があります。 3.0 未満のスコアは、即時介入が必要な解約リスクです。

実践例

合計スコア 6.9 は、Apex Plastics の問題を覆い隠します。健全性ダッシュボードには、集計スコアと個別の補助スコアの両方が表示され、しきい値を下回るエンティティに注意を払うようフラグが立てられる必要があります。

複数エンティティ アカウントの価格設定の管理については、顧客固有の価格設定と段階的割引 に関するガイドを参照してください。

完全な B2B e コマース戦略については、当社の主要なガイドを参照してください: B2B e コマース プレイブック。

---

よくある質問

買い手でもあり供給者でもある顧客にどのように対応すればよいでしょうか?

Odoo は、二重役割の連絡先をネイティブにサポートします。 1 つの会社レコードに顧客とベンダーの両方のプロパティを含めることができます。重要なのは、売買のためのアカウント階層が正しくモデル化されていることを確認することです。 Apex Chemicals がお客様から原材料を購入し、お客様が Apex Chemicals から特殊化学品を購入する場合、両方の関係が同じ連絡先レコード上に存在し、別個の AR 残高と AP 残高が存在します。

子会社が所有権を変更するとどうなりますか?

子会社が別の会社に買収されるか分社化される場合、CRM レコードを更新する必要があります。 Odoo で、子会社の連絡先の親会社フィールドを変更します。これにより、新しい所有権が反映されながら、注文履歴と連絡先データが保存されます。契約条件は再交渉が必要な場合があり、新しい親会社の条件に基づいて価格が変更され、テリトリーの割り当てが変更される場合があります。これを単純なフィールド更新ではなく、チェックリストを使用した管理された移行として扱います。

同じ組織の重複アカウントを防ぐにはどうすればよいですか?

重複防止はアカウント作成時に始まります。新しい会社レコードを作成する前に、会社名、納税者 ID、ドメイン名、および主要な連絡先名で既存のレコードを検索します。 Odoo の重複検出は、連絡先の作成中に潜在的な一致にフラグを立てるように構成できます。名前にさまざまなバリエーションがある大規模な組織 (Apex Industries、Apex Industries Inc.、Apex Industries Holdings LLC) の場合は、既知の別名のリストを親レコードに保持します。

---

次は何ですか

アカウント階層管理は、企業の B2B 関係の基礎です。これがなければ、あらゆる対話が切断され、あらゆる洞察がサイロ化され、全体的な関係を活用するあらゆる機会が失われます。

ECOSIRE の Odoo CRM 実装 には、アカウント階層構成、テリトリー設計、ヘルス スコアリング ダッシュボードが含まれています。私たちは、B2B 企業が顧客の実際の運用状況を反映した CRM 構造を構築できるよう支援します。

お問い合わせ してアカウント管理の課題について話し合い、Odoo が最も複雑な顧客関係をどのようにモデル化できるかを確認してください。

---

ECOSIRE によって発行 --- Odoo ERP、Shopify eCommerce、OpenClaw AI にわたる AI を活用したソリューションで企業のスケールアップを支援します。