紹介元が二つある相談は？発見経路と紹介関係を分ける記録

青葉商会の佐藤は森製作の相談D19を受けました。岡は会社を検索で知り、取引先の橋商事と社内の山田にも相談して紹介されたと話しています。

流入元を紹介へ上書きすると最初に知った検索経路が消えます。紹介元二件を相談二件として数えると受付が増えて見えます。

最初に知った経路、問い合わせした接点、紹介関係を別欄へ記し、一相談の履歴として関連付けます。 参照資料「HubSpot: Associate records」で確認した範囲は、会社・人物・商談を別記録として関連付ける概念。 この節の会社・担当・社内基準は架空の教材です。

この章の根拠：出典1

「発見経路」の入力は、岡の発言では検索です。ここでは実際の検索語は未確認です。記録の判断欄には「自己申告の発見経路」と残します。

「問い合わせ接点」の入力は、WebフォームからD19です。ここでは一件の相談IDを使います。記録の判断欄には「受付経路」と残します。

「紹介関係」の入力は、橋商事と社内山田です。ここでは紹介者数は受付件数と別に集計します。記録の判断欄には「二つの関係」と残します。

比較表は横に動かして全ての列を確認できます。

佐藤はどの時点の経路を聞いているかを分けます。検索の自己申告とサイト計測の流入元は一致しない場合があるため、取得方法を欄の定義へ添えます。

流入元一欄は単純ですが、発見・紹介・受付を同じ意味にしてしまいます。三つを分ければ検索で見つけて紹介後にフォームへ進んだという経路を説明できます。相談は一件のままです。

発見、紹介、受付は一つの相談の前後に起こる違う出来事です。相談IDで結べば、検索と紹介の関係を保持しても受付件数は増えません。取得できていない経路は不明と残します。

紹介者が具体的に分からない場合は紹介あり・詳細未確認と記します。会社名を推測して関係を作らず、記録目的に必要な範囲で窓口へ確認します。

接点履歴は施策の因果効果を証明しません。複数紹介が分かっても、どの紹介が受注を生んだかはこの記録だけでは決められません。

紹介の詳細が分からない場合は佐藤が確認目的を整理します。名前が似た既存会社を紹介者として登録するのではなく、確認できた説明だけを保留欄へ置きます。

佐藤がD19へ発見経路と受付接点を記し、G19へ確認済みの紹介関係を結びます。田中は受付集計で相談IDが一件、関係一覧では紹介元が二つになるか確認します。

フォーム受付件数と紹介関係件数を足した値が相談総数へ使われていないか点検します。経路の根拠が自己申告なのか計測なのかを後任が読めるようにします。

田中は紹介関係が二つあっても受付IDが一つであるか点検します。自己申告を計測値として登録した誤りは取得方法を訂正し、本人の説明の履歴は消しません。

最初に知った経路、相談へつながった紹介、実際の受付方法を分けて記します。同じ流入という欄にまとめる前に、何を分析するか決めます。

自己申告と計測は異なる根拠です。一致しない場合も片方を偽と決めず、時点と取得方法を確認します。

佐藤は未確認の紹介情報を残し、田中は受付数の重複を点検します。相談一件へ複数の関係が結び付く形で保存します。