官网リードからCRMへ：連携方法、フィールドマッピング、重複排除

官网リードからCRMへ：連携方法、フィールドマッピング、重複排除

一、断点はフォームではなく、受信後に誰もフォローしないことにある

まず本記事の範囲を明確にします。フォームの信頼性とスパム対策フォームが受信できるか、スパム問い合わせをどう防ぐかを扱う。リードアトリビューション1件の問い合わせの貢献をどう計算するかを扱う。本記事はその中間部分だけを扱う：リードがサイトからCRMに流れ込む経路の構築方法、フィールドの対応、重複の統合、失敗時の補完。フォームは受口、アトリビューションは基準、本記事はパイプライン——パイプラインが漏れれば、前の2つがどれだけ良くても意味がない。

私たちが調査したリード流失事例の中で、「フォームが受信できない」ケースは極めて少なく、ほとんどは受信したリードがメールとスプレッドシートで止まっている。

最後の行が最も危険：最初の3つは目に見えるが、サイレント損失は「失った」というシグナルすらない。だから本記事の第5節では失敗時のフォールバックを專門に扱う。これはオプションではない。

二、まずリードのライフサイクル状態を定義する

パイプラインを構築する前に状態を定義する。連携方法は状態の書き戻しが必要であり、状態定義がなければ何を書き戻すか設計できないからだ。最小限のライフサイクルは5つの状態。

設計上の要点は2つ。第一に、「無効」は削除せず記録として残すこと。3か月前に無効と判定された問い合わせも、担当者が変われば再び動き出す可能性があり、履歴が再アプローチの根拠になる。第二に、各ステータスに滞留期限を設けてこそCRMの価値が本当に発揮される。期限を過ぎても動いていないリードは自動でリマインドされ、営業が記憶だけでフォローするよりはるかに確実だ。ステータスの定義は一文のドキュメントにまとめてCRMに保存し、新しい営業が入社したらまずこれを読ませ、次に初回フォローメールの書き方を読ませる。

三、3つの連携方式の比較

結論としては、月間問い合わせ10〜100件なら中間層がおすすめ。構築が最も速く、フォームのフィールドを変更しても修正は1か所で済む。100件以上、あるいはフォームが多く、中国語と英語の2言語サイトでそれぞれ問い合わせを受けているなら、プラグインでAPIに直接接続し、中間の工程を減らすのがよい。多言語サイトは言語ごとの子サイトが1つ増えるたびに、メンテナンスが必要なフィールドマッピングも1つ増える。その隠れたコストは多言語プラグインの隠れたコストの記事で詳しく解説している。CSVインポートはあくまで過渡的な手段にすぎない。遅延が日単位なのに対し、B2Bの問い合わせは初回対応が24時間以内とされており、桁が1つ違う。

四、フィールドマッピングとソースデータ

連携で最もミスが起きやすく、発覚も最も遅れるのがフィールドマッピングだ。ミスの現れ方は「データが送れない」ではなく、送れたものの汚いデータばかりで、数か月後に顧客分析をして初めて一斉に露呈する。

最も多く、最も影響が大きいマッピングミスは3つ。国を自由テキストにすると、同じ国がCRM内で5通りに表記され、国別の集計がすべて狂う。電話番号に国コードがないと、かけ直しの失敗率が極めて高くなる。特にヨーロッパの顧客で顕著だ。送信日時にタイムゾーンがないと、タイムゾーンをまたぐチームで「今日の何時に来た問い合わせか」の認識が食い違う。フィールドマッピング表は作成して保管し、CRMかフォームのどちらかでフィールドを変更する際は、まず表を突き合わせてからリリースする。

ソースデータをどこまで引き継ぐか、もう一枚の表で整理します：

線引きの考え方はこうです。CRM の営業が「この人は誰か、どこから来たか、何を求めているか」を判断するために使うデータは、リードと一緒に流す必要があります。一方、ページごとの閲覧履歴は行動分析の領域なのでサイト上に残します。CRM に押し込んでも記録画面が膨らむだけで、誰も見ません。

五、重複排除と失敗時の補償

重複排除のルール

同じ顧客が何度も入ってくるのは例外ではなく日常です。先に見積もりフォームで問い合わせ、次に技術フォームを送信するかもしれません。日本語サイトと中国語サイトの両方で一度ずつ問い合わせることも、2 週間後に別のメールアドレスで再来することもあります。重複排除のルールは 4 つのシナリオで決めます。

主キーは「メールアドレス＋会社ドメイン」の組み合わせにします。メールアドレスは個人単位の一意キーであり、会社ドメインは「同じ会社の複数人がそれぞれ問い合わせる」ケースを拾えます。メールアドレスだけを主キーにすると同社の複数担当者を取りこぼし、会社名だけを主キーにすると同名の別会社を誤って統合します。境界は 2 つあります。フリーメール（gmail など）の会社ドメインには重複排除の価値がないため、メールアドレスのみに戻します。買収・合併によるドメイン変更は、機械では企業関係を判断できないため、手動で一度マージを実行します。

失敗時の補償

経路のどこでも失敗は起こり得ます。フォールバック設計の原則はただ一つ、どんな失敗でもリードを黙って失ってはいけないということです。

共通の土台となるのはローカルへの記録です。リードはサイトを離れる前にサイト内のデータベースまたは表に書き込まれ、その後の同期が成功しても失敗しても確認できます。さらに日次の突合を追加します。サイト上の送信数、中間層の送信数、CRM の登録数という 3 つの数字を比べ、合わなければその日のうちに調べます。パイプラインの信頼性は設計で生まれるものではなく、突合で生まれるものです。

六、リリーステストと初週の突合

リリースとは設定を終えて保存を押すことではなく、5 つのテストケースで経路を一通り叩くことです。

各ユースケースは両側で同時に確認する。サイト上では送信成功と表示され、CRM ではフィールドごとに一致するか照合し、特に国、電話の市外局番、タイムゾーンの3つの常習犯フィールドに注目する。

公開後1週目は毎日突合を実施する。退勤前にフォーム送信数、中間層の送信数、CRM の登録数を照合し、3つの数字が一致して初めてその日の作業完了とする。1週目に洗い出した問題——通常はあるフォームが接続されていない、あるフィールドのマッピングが漏れている——はこの1週間に集中して修正するのが最もコストが低い。1週目以降は週1回の突合に下げ、安定稼働が1四半期続いたら月1回に下げ、月次メンテナンスのリズムに合わせて実施すればよい。

七、CRM を使わないのはどんなときか

連携方案はフォローアップの流れに奉仕するものだ。問い合わせ量がフォローアップの流れを支えられないなら、まずパイプラインは作らない。

つなぎの方案は間に合わせではない。オンライン表の列構成は第四節のフィールドマッピングにそのまま従って設計し、国はプルダウン、時間はタイムゾーン付き、ソースフィールドは通常どおり記録し、将来 CRM に移行するときは列ごとにインポートすればほぼ手戻りはない。本当に避けるべきなのは逆の道筋だ——先に CRM を買い、リードは依然として手書きで、パイプラインはいつまでも組まれず、CRM が高価な連絡先帳に成り下がる。時期の判断は1つの数字で見る。手作業でのリード処理時間が週2時間を超えたとき、あるいは初めて「休暇中にフォローが漏れて失注」が起きたときが、パイプラインに着手するときだ。サイトの状況に応じてリードの保存方案を設計する必要がある場合は、次からお問い合わせ現状をご説明ください。

FAQ よくある質問

最後に

リードパイプラインは、独立系サイトにおいて投資対効果が最も確実な改善の一つです。フォームは毎日問い合わせを受け取っていますが、パイプラインが決めるのは、その問い合わせを24時間以内にフォローできるか、それともメールボックスに眠ったまま期限切れになるかです。高度な技術は不要で、必要なのは次の3つをきちんと揃えることです。フィールドマッピングを先に突き合わせる、失敗時には必ずフォールバックを用意する、公開前にまず突合確認を行う。

導入の順序としては、まずリードのライフサイクルステータスを決め、次に問い合わせ量に応じて連携方法を選び、最後に5つのテストケースと毎日の突合確認をリリースチェックリストに書き込みます。量が少ないうちはスプレッドシートでつなぐのも恥ずかしくありません。量が増えても手作業に頼るほうが、むしろお金を失います。覚えておくべきことは一言だけです。パイプラインの価値は自動化そのものではなく、どのリードも黙って消えることを許さない点にあります。