在你的登陸頁上使用 Make
在 Make，名單分派變得視覺化：左邊是 Webhook，中間是 Router，右邊是每個買家、試算表或頻道各一條分支。把它連接到 LanderLab，登陸頁或問卷漏斗的每筆名單都會啟動你的情境，附上訪客填寫的每個欄位，以及旁邊 LanderLab 自己的欄位。
不需要安裝 Make App，也用不到：Make 的 custom webhook 會給你的情境一個網址，頁面的 Webhook 整合會把每筆名單送到那裡。這在任何 Make 方案上都能用，同一個網址也能接收任意多個頁面的名單。
每筆名單都啟動一個 Make 情境
每筆名單都會以 JSON 進入你的情境。鍵名由你決定，所以情境處理的是 first_name 與 email，而不是表單上的標籤；LanderLab 自己的欄位，例如頁面網址、訪客 IP 與送出時間，也會一起帶上，供篩選、分派與合規紀錄使用。
在 Make 中，這些欄位每一個都是後續模組能使用的變數，答案、UTM 與版本都包括在內，所以分派與格式化都依名單的真實資料運作。
一個 Make 情境處理多個頁面
同一個 Make Webhook 網址可以放在多個登陸頁上。加上一個依頁面網址或問卷答案篩選的 Router，每筆名單就會走自己的路徑：一個頁面的名單送給買家，另一個頁面的送到試算表與 Slack 頻道。
對名單開發業者來說，整個優惠就在一張圖裡。買家額度滿了或開放新的州時，你改的是畫布上的一個篩選條件，而不是五個各自獨立的自動化。
任何 API，即使沒有 Make App
當目的地在 Make 中沒有 App 時，HTTP 模組可以直接把名單送到它的 API。如果傳送失敗，Make 的 History 分頁與 LanderLab 的傳送紀錄會顯示送出的請求與收到的回應，當買家說某筆名單沒收到時，你需要的正是這個。
Make，還是 LanderLab 工作流程（Beta 版）？
LanderLab 的工作流程（Beta 版）本身就能處理很多分派：一個或多個頁面上的名單觸發器，「篩選」、「條件判斷」、「多分支」與「延時」節點，以及 Google Sheets、HubSpot、Klaviyo、GoHighLevel、LeadProsper、Meta CAPI 的動作和「HTTP 請求」節點。如果你的分派在這裡就做得到，就少一個工具、少一張帳單。
當情境超出這個範圍時，Make 才值得：數十個 App、資料轉換、在其他系統中查詢資料，或團隊本來就在 Make 上營運。
