ランディングページにNotionを
パイプラインをNotionで回している小さなチームはたくさんあります。法律事務所の相談受付ボード、代理店のクライアント管理、CRMを買ったことのない営業チーム。足りないのは、きれいな入り口です。リードはメールやエクスポートで届き、誰かがそれをデータベースに打ち直します。遅れて、打ち間違いとともに。
LanderLabのWebhookが各リードをNotionのAPIへポストするので、すべての送信が、回答をプロパティに埋めたページとしてデータベースに入ります。チームが気づくのは、ボードに新しいカードが増えていることだけ。どのカードにも、それを生んだキャンペーンとバリエーションが付いています。
フォームからNotionのデータベースのプロパティを埋める
Notionはプロパティの型に厳格で、リードのデータにとってはそれが好都合です。リードの名前はページのタイトルに、メールアドレスはクリックできるメールのプロパティに、電話番号は電話のプロパティに、ランディングページはURLのプロパティに入ります。誰かが手で分けなければならない長いテキストのかたまりで届くものはありません。
各リードは本物のNotionのページなので、チームは、フォームが埋めたプロパティのすぐ下に、通話のメモを書き、書類を添付し、同僚をメンションできます。記録と、それについてのやりとりが同じ場所にまとまります。
チームが仕事をする相談受付のボード
「ステータス」プロパティを追加すれば、新しいページはどれも、選んだ列、たとえば「新規」から始まります。ボードビューを「ステータス」でグループ化すれば、朝のリードがカードの列になり、相談受付チームはそれを「連絡済み」「見込みあり」「契約済み」へ動かします。折り返しの日付でカレンダービューを作れば、今日電話すべき相手がわかります。
同じデータベースを、人によって違う切り口で見られます。相談受付チームには「新規」のリードのボードを、弁護士には「見込みあり」の案件の表を、オーナーにはキャンペーンでグループ化したビューを。
広告セットを、フォーム送信数ではなく契約した案件で判断
utm_source、utm_campaign、gclidやfbclidという名前の隠しフィールドに広告のURLから値が入ってリードと一緒に届き、LL Variant IDが、訪問者が見たページのバージョンを記録します。Notionでは、それがグループ化や絞り込みに使えるプロパティになります。
データベースを1つのキャンペーンで絞り込み、「契約済み」のカードを数えれば、その広告セットが実際に何を生んだかがわかります。スプリットテストの2つのバリエーションで同じ絞り込みをすれば、フォーム送信数が少なくても、案件を連れてくるページを残せます。
Notionに届く前にルールを
すべてのリードが同じデータベースに合うわけではありません。LanderLabのワークフロー（ベータ版）を前に置けます。完了したクイズだけを通すフィルターノード、人身傷害のリードをあるデータベースへ、労災を別のデータベースへ、それぞれ専用のHTTPリクエストノードで送るスイッチノード。実行履歴ビューで各リードの経路がわかるので、送信の失敗もすぐに見つかります。
