ランディングページにMakeを
Makeは、リードの振り分けを目で見える形にしてくれます。左にWebhook、真ん中にRouter、右に買い手、スプレッドシート、チャンネルごとの分岐。LanderLabに接続すれば、ランディングページやクイズファネルからのリードはどれも、訪問者が入力したすべての項目とLanderLab独自の項目を並べて、シナリオを開始します。
インストールするMakeアプリはありませんし、必要もありません。MakeのカスタムWebhookがシナリオにアドレスを割り当て、ページのWebhook連携が各リードをそこへ送ります。Makeのどのプランでも使え、同じアドレスで好きなだけ多くのページのリードを受け取れます。
リードごとにMakeのシナリオを開始
各リードは、JSONとしてシナリオに届きます。キーは自分で付けた名前なので、シナリオはフォームのラベルではなくfirst_nameやemailで動きます。ページのURL、訪問者のIP、送信日時といったLanderLab独自の項目も届き、絞り込み、振り分け、コンプライアンスの記録に使えます。
Makeでは、回答、UTM、バリエーションも含めて、その項目のどれもが次のモジュールで使える変数になるので、振り分けも整形も、リードの実データをもとに動きます。
多くのページに、1つのMakeのシナリオ
同じMakeのWebhook URLを、複数のランディングページに設定できます。ページのURLやクイズの回答で絞り込むフィルター付きのRouterを追加すれば、各リードがそれぞれの経路を通ります。あるページのリードは買い手へ、別のページのリードはスプレッドシートとSlackチャンネルへ。
リード獲得事業者にとっては、オファー全体が1枚の図になります。買い手が上限に達したり、新しい州が開いたりしても、5つの別々の自動化ではなく、キャンバス上のフィルターを1つ変えるだけです。
Makeのアプリがなくても、どんなAPIにも
送り先のアプリがMakeになくても、HTTPモジュールがそのAPIへ直接リードを送れます。配信に失敗したら、MakeのHistoryタブとLanderLabの配信ログで、送ったリクエストと返ってきたレスポンスがわかります。買い手に「リードが届いていない」と言われたときに必要なのは、まさにそれです。
Makeか、LanderLabのワークフロー（ベータ版）か？
LanderLabのワークフロー（ベータ版）だけでも、多くの振り分けをこなせます。1つまたは複数のページのリードトリガー、フィルター、条件分岐、スイッチ、待機の各ノード、そしてGoogleスプレッドシート、HubSpot、Klaviyo、GoHighLevel、LeadProsper、Meta CAPIのアクションとHTTPリクエストノード。振り分けがそこに収まるなら、ツールも請求も1つ減ります。
Makeが活きるのは、シナリオがその先まで広がるときです。何十ものアプリ、データの変換、ほかのシステムでの検索、あるいはすでにMakeで業務を回しているチーム。
