落地页上的 Notion
很多小团队在 Notion 里管理销售管道：律所的接案看板、代理商的客户追踪表、一个从来没买过 CRM 的销售团队。他们缺的是一个干净的入口。线索以邮件或导出文件的形式到达，再由某个人重新录入数据库，又慢又容易打错。
LanderLab 的 Webhook 把每条线索投递到 Notion 的 API，每次提交都会成为你数据库里的一个页面，答案都填在它的属性里。你的团队唯一会注意到的，就是看板上多了新卡片，每张都带着产生它的广告系列和变体。
用表单填写 Notion 数据库属性
Notion 对属性类型要求很严格，而对线索数据来说这是好事。线索的姓名成为页面标题，邮箱落进可点击的电子邮件属性，电话号码落进电话属性，落地页落进 URL 属性。没有任何东西会变成一大段需要有人手动拆分的文本。
因为每条线索都是一个真正的 Notion 页面，你的团队可以就在表单填好的属性下方写通话记录、附加文档、@同事。记录和围绕它的沟通都在同一个地方。
团队用来干活的接单看板
添加一个“状态”属性，每个新页面都会从你选择的那一列开始，比如“新线索”。按“状态”对看板视图分组，早上进来的线索就是一列卡片，接单团队把它们移到“已联系”“合格”和“已签约”。再按回电日期建一个日历视图，就知道今天该打给谁。
不同的人可以看到同一个数据库的不同切面：接单团队看“新线索”的看板，律师看“合格”案件的表格，老板看按广告系列分组的视图。
按签约案件而不是表单提交评判广告组
命名为 utm_source、utm_campaign 以及 gclid 或 fbclid 的隐藏字段会从广告 URL 中自动填入，并随线索一起传递，LL Variant ID 则记录访客看到的是哪个版本的页面。在 Notion 里，这就是一组可以分组和筛选的属性。
把数据库筛选到某一个广告系列，数一数 Signed 的卡片，你就知道这个广告组真正带来了什么。对 A/B 测试的两个变体用同样的筛选，你就能留下带来案件的那个页面，即使它的表单提交更少。
线索到达 Notion 之前先过规则
不是每条线索都属于同一个数据库。LanderLab 工作流（Beta）可以放在前面：一个只放行已完成测验的筛选步骤，一个把人身伤害线索发到一个数据库、工伤赔偿线索发到另一个数据库的多分支步骤，各自通过自己的 HTTP 请求步骤发送。运行视图显示每条线索的路径，发送失败一眼就能看出来。
