ランディングページにSalesforceを
Salesforceを使うほとんどの企業では、マーケティングはSalesforceの中で成果を証明しなければなりません。有料広告のリードが、キャンペーンの情報を落とされたCSVで1日遅れで届いたり、1年前に誰かがページに貼り付けたWeb-to-リードのフォーム経由で届いたりすると、それは難しくなります。LanderLabのリードをSalesforceへ送れば、どの送信もリアルタイムで、ページ、バリエーション、キャンペーンを、管理者がレポートにできる項目に持ったリードになります。
Salesforceを基幹システムにしているチームのための連携です。LinkedInやGoogleでのB2Bの需要創出、営業担当が電話で対応する保険や融資のチーム、クライアントの組織に向けて広告を運用する代理店。インストールするSalesforceのコネクタはありません。ページのWebhookが、組織IDを付けて、サーバー間で各リードをSalesforceのWeb-to-リードのエンドポイントへ送り、リードは営業担当がすでに使っているキューとリストビューに入ります。
フォームの送信を、Salesforceのリードに
フォームの送信はどれも、フォームが送信された瞬間に、Webhookがマッピングしたリードの項目に回答を入れて、Salesforceのリードとして作成されます。
Salesforceは、デフォルトですべてのリードに姓と会社名を求めます。B2Bのページなら自然なことです。消費者向けのオファーなら、Webhookの固定値で会社名を埋められるので、住宅所有者に勤務先を聞かなくてもリードを保存できます。
営業担当がすでに使っているビューにリードを
ページからのリードは、通常のSalesforceのリードです。チームがすでに使っているリストビュー、キュー、レポートに表示され、営業担当がいつもの方法で見込みを判断し、取引先、取引先責任者、商談に変換します。広告でお金を払って獲得したリードを探すために、2つ目の受信トレイや共有シートを確認する人はいません。
ページのすべてのリードで、Salesforceのフローが動く
管理者が新しいリード向けに作ったものは、これらのリードでも動きます。レコードトリガーフローなら、リードができた時点で、訪問者がクリックした広告の記憶が新しいうちに、所有者の割り当て、電話のタスクの作成、最初のメールの送信を行えます。
安全策も同じです。入力規則と必須項目は、ほかのリードと同じようにページのリードにも適用されるので、Salesforceに届くデータは、チームがすでに決めた基準を満たします。
Web-to-リードかREST APIか：実用的なのはどちらか
Salesforceへの入り口は2つあります。REST APIにはOAuthのアクセストークンが必要で、トークンには有効期限があり、ページのWebhookの固定ヘッダーではそれを更新できません。Web-to-リードは、組織IDを付けた普通のフォーム送信を受け付け、トークンは不要なので、誰かが付きっきりで見ていなくても動き続ける経路です。上限はSalesforce側のもので、Web-to-リードの1日あたりの送信数の上限もあるので、購入する予定の量と照らし合わせて確認しましょう。
APIのすべての機能が必要なら、トークンを管理する中間ステップを挟むのが実用的です。ZapierのLanderLabのNew Leadトリガーや、ページのWebhookから始まるMakeのシナリオが、そのステップになります。
リードから成立まで、キャンペーンとバリエーションを
キャンペーン、クリックID、ランディングページ、ページのバリエーションは、隠しフィールドとLanderLab独自の項目から埋まり、すべてリードとともに運ばれます。営業担当がリードを変換すれば、取引先責任者と商談にも引き継がれます。
あとは、成立した商談をキャンペーン別にまとめたレポートが、来月の予算を決める問いに答えてくれます。どの広告費が売上になり、どのバージョンのページがそれを売ったのか。
