在你的登陸頁上使用 Notion
很多小團隊在 Notion 裡經營銷售管道：律師事務所的案件受理看板、代理商的客戶追蹤表、從沒買過 CRM 的業務團隊。他們缺的是乾淨的入口。名單以電子郵件或匯出檔進來，再有人把它們重打進資料庫，又晚又有錯字。
LanderLab 的 Webhook 把每筆名單發送到 Notion 的 API，每次送出都會成為你資料庫中的一個頁面，答案填進它的屬性。你的團隊只會注意到看板上多了新卡片，每張都帶著產生它的廣告活動與版本。
從你的表單填入 Notion 資料庫屬性
Notion 對屬性類型很嚴格，而對名單資料來說這是好事。名單的姓名成為頁面標題，電子郵件進到可點擊的電子郵件屬性，電話號碼進到電話屬性，登陸頁進到 URL 屬性。沒有任何東西會以一大段文字送達，要人手動拆開。
因為每筆名單都是真正的 Notion 頁面，你的團隊可以就在表單填好的屬性下方寫通話紀錄、附上文件、提及同事。紀錄和關於它的討論都在同一個地方。
團隊實際在用的受理看板
加一個「狀態」屬性，每個新頁面就會從你選擇的欄開始，例如「新名單」。依「狀態」分組的看板檢視，早上的名單就是一欄卡片，你的受理團隊把它們移到「已聯絡」、「合格」與「已簽約」。以回電日期建立的行事曆檢視，則顯示今天該打給誰。
不同的人可以看同一個資料庫的不同切面：受理團隊看「新名單」的看板，律師看「合格」案件的表格，老闆看依廣告活動分組的檢視。
用簽約案件評判廣告組合，而不是表單填寫
命名為 utm_source、utm_campaign 與 gclid 或 fbclid 的隱藏欄位會從廣告網址填入並隨名單送出，LL Variant ID 則記錄訪客看到的是哪個版本的頁面。在 Notion 中，這些就是一組可以分組與篩選的屬性。
把資料庫篩選到某個廣告活動，數一數「已簽約」卡片，你就知道那個廣告組合真正帶來了什麼。對分流測試的兩個版本做同樣的篩選，就能留下帶來案件的頁面，即使它帶來的表單填寫比較少。
名單進到 Notion 前先套規則
不是每筆名單都屬於同一個資料庫。LanderLab 工作流程（Beta 版）可以放在前面：只放行完成問卷的「篩選」節點，把人身傷害名單送到一個資料庫、職災名單送到另一個的「多分支」節點，各自透過自己的「HTTP 請求」節點。執行紀錄檢視會顯示每筆名單的路徑，失敗的傳送一眼就看得出來。
