提案書の閲覧通知が届くたびに担当者が連絡すれば、素早い対応に見えるかもしれません。しかし同じ人が短時間に何度も開き、社内確認や匿名閲覧まで同じチャネルに入ると、通知はすぐにノイズになります。担当者は文脈を確認するより、届いた順に反応するようになります。
閲覧通知は購入意向を判定するスコアではなく、人が文脈を確認するキューに出来事を入れる仕組みとして扱います。目的は通知を最大化・最小化することではなく、どの出来事を誰に見せ、同じ出来事をいつ再び表示するかを決めることです。
リンクのスイッチとスペース側の規則を分ける
FeatPaperでは、リンクごとの共有設定で文書閲覧通知をオン・オフできます。実際の配信には、このリンク側のスイッチとスペースの基本通知規則が関係します。リンクでオンにしていても、通知対象、関心度の下限、再通知のクールダウンによって届き方が変わる場合があります。
したがって、ポリシー表の最初の項目はチャネルではなく範囲です。どの文書のどのリンクを運用キューに入れるか、誰が担当するかを書きます。すべてを一括でオンにせず、新規提案、更新案内、公開資料など、対応方法が異なる配布を分けます。
対象は確認後にできる行動で選ぶ
通知対象は、情報入力フォームの提出者、個別追跡リンクの受信者、unknownとして表示される匿名閲覧に分けられます。すべてを受け取る必要はありません。通知を確認したあと、担当者が実際に取れる行動を基準に選びます。
個別追跡リンクは受信者の文脈があるため、既存の約束と一緒に確認できます。匿名閲覧では相手を特定できないため、個別連絡より公開資料の反応確認に向いています。フォーム提出者には提出記録がありますが、提出したという事実だけで購入準備が整ったとは判断しません。
下限は意向ではなくキューの入口
関心度の下限は、すべて、Warm以上、Hotのみから選べます。これは通知を絞る製品設定です。WarmやHotはMQL・SQL、購入意向、契約可能性と同じ意味ではありません。
下限を決めるときは「どのグレードが本当の顧客か」ではなく、担当者が一日に何件を、どの文脈とともに確認できるかを考えます。新しいポリシーは限定した文書から始め、分布を見て、見逃したくない出来事と反復ノイズを分けてから調整します。変更日と理由も記録し、条件の異なる期間を同じものとして比較しません。
再訪例外とクールダウンは別に決める
再訪時に常に通知する設定を使うと、関心度の下限に達していなくても、再び開かれた場合に通知対象となることがあります。再訪を別の確認対象にするための経路です。ただし、再訪した理由まで分かるわけではありません。
再通知のクールダウンは、同じ閲覧に関する通知の間隔を調整します。公式設定には、使用しない、30分、6時間、24時間があります。最短が最も迅速なポリシーとは限りません。会議の合間にキューを見る担当者にとって、30分内の複数通知は一つの出来事を複数の仕事に見せることがあります。重要資料を一日単位で確認するなら、24時間が合う場合もあります。
ポリシー表では「再訪例外」と「クールダウン」を別の項目にします。前者は下限未満の再訪を拾うか、後者は反復通知をどの程度まとめるかを決めます。
チャネルと担当を結び、保存先とは区別する
現在の公式情報で確認できる範囲では、通知はメールと接続済みのSlackで受け取れます。チャネルを選んだら、キュー担当者、確認頻度、不在時の代行者と、「新規・確認中・質問準備済み・終了」程度の状態を決めます。
Slack通知を受け取ることは、連絡先を保存することではありません。閲覧通知と、フォーム提出者をNotionやGoogle Sheetsへ送る流れも別です。このポリシーをCRM保存や営業段階の自動変更へ広げず、通知イベントを確認可能なキューにする範囲に限定します。
運用前に社内・社外の閲覧を試す
広く適用する前に、社内QA閲覧と社外コントロール閲覧を一度ずつ行い、通知対象と分析除外設定が意図どおりかを確認します。除外設定には担当者と適用日を記録します。規則を変えたからといって、過去の通知が消えたり、過去の分析が再計算されたりすると考えません。
一週間後は通知数だけでなく、重複した出来事、担当者のいない出来事、下限未満でも確認したかった出来事を見直します。通知ポリシーは一度決めて終わるフィルターではなく、キューの容量と実際の業務文脈を合わせる運用規則です。
通知が多い問題は、より強いシグナルを探しても解決しません。リンク範囲、対象、下限、再訪例外、クールダウン、担当者を一つの表に置けば、通知は意向判定ではなく、次の質問を準備するための確認順序になります。
