제안서를 보낸 뒤 열람 알림이 올 때마다 담당자가 바로 연락하면 빠르게 대응하는 팀처럼 보일 수 있습니다. 하지만 같은 사람이 짧은 시간에 여러 번 열거나, 내부 검수와 익명 열람까지 한 채널에 몰리면 알림은 곧 소음이 됩니다. 담당자는 중요한 알림을 구분하기보다 받은 순서대로 반응하게 됩니다.
열람 알림은 구매 의도를 판정하는 점수가 아니라 사람이 맥락을 확인할 queue에 사건을 넣는 장치로 보는 편이 안전합니다. 정책의 목적도 알림을 가장 많이 받거나 가장 적게 받는 것이 아니라, 어떤 사건을 누구에게 언제 다시 보여 줄지 합의하는 데 있습니다.
먼저 링크의 스위치와 스페이스 규칙을 나눕니다
FeatPaper에서는 링크별 공유 설정에서 문서 열람 알림을 켜거나 끌 수 있습니다. 실제 알림은 이 링크별 스위치와 스페이스의 기본 알림 규칙을 함께 봅니다. 링크에서 켰더라도 알림 받을 대상, 관심도 하한이나 재알림 cooldown 조건에 맞지 않으면 오지 않을 수 있습니다.
따라서 정책표의 첫 칸은 채널이 아니라 범위입니다. 어떤 문서의 어떤 링크를 운영 queue에 넣을지, 그 링크의 owner는 누구인지 적습니다. 모든 링크를 일괄적으로 켜는 대신 신규 제안, 갱신 안내, 공개 자료처럼 대응 방식이 다른 배포를 구분합니다.
대상은 “누구인지 아는 정도”로 선택합니다
알림 받을 대상은 정보 입력폼 제출자, 개인별 추적 링크 수신자, 알 수 없음으로 표시되는 익명 열람으로 나눌 수 있습니다. 세 범주를 모두 받아야 하는 것은 아닙니다. 담당자가 알림 뒤에 실제로 할 수 있는 행동을 기준으로 고릅니다.
예를 들어 개인별 추적 링크는 수신자 맥락을 이미 알고 있어 기존 약속과 함께 검토할 수 있습니다. 익명 열람은 상대를 특정할 수 없으므로 개별 연락보다 공개 자료의 반응을 살펴보는 용도에 가깝습니다. 정보 입력폼 제출자는 제출 기록이 있지만, 제출했다는 사실만으로 구매 준비가 됐다고 보지는 않습니다.
하한은 의도가 아니라 queue의 입구입니다
관심도 하한은 전체, Warm 이상, Hot만 중에서 선택할 수 있습니다. 이 이름은 알림을 거르는 제품 설정값입니다. Warm이나 Hot이 MQL·SQL, 구매 의도 또는 계약 가능성과 같은 뜻은 아닙니다.
하한을 정할 때는 “어느 등급이 진짜 고객인가”가 아니라 “담당자가 하루에 몇 건을 어떤 맥락과 함께 검토할 수 있는가”를 묻습니다. 새 정책을 시작한다면 한정된 문서에서 전체를 받아 실제 분포를 보고, 놓쳐서는 안 될 사건과 반복 소음을 구분한 뒤 하한을 조정합니다. 기준을 바꾼 날짜와 이유도 남겨 서로 다른 기간을 같은 조건처럼 비교하지 않습니다.
재열람 예외와 cooldown은 다른 결정입니다
재열람은 항상 알림 옵션을 켜면 관심도 하한에 못 미치더라도 다시 열린 경우 알림을 받을 수 있습니다. 반복 열람을 별도 검토 대상으로 볼지 결정하는 장치입니다. 다만 재열람이라는 사실 역시 관심 이유를 알려 주지는 않습니다.
재알림 cooldown은 같은 열람에서 알림이 이어지는 속도를 조절합니다. 공식 설정에는 사용 안 함, 30분, 6시간, 24시간이 있습니다. 가장 짧은 주기가 가장 민첩한 정책은 아닙니다. 담당자가 회의 사이에 queue를 확인한다면 30분 단위 알림이 같은 사건을 여러 업무처럼 보이게 할 수 있습니다. 반대로 중요한 자료의 재방문을 일 단위로만 검토한다면 24시간이 맞을 수 있습니다.
정책표에는 “재열람 예외 사용 여부”와 “cooldown”을 별도 칸으로 둡니다. 그래야 하한을 넘지 못한 재방문을 살릴지, 반복 알림을 얼마나 묶을지 각각 설명할 수 있습니다.
채널과 처리 책임을 연결하되 적재로 오해하지 않습니다
알림 채널은 이메일과 연결된 Slack을 사용할 수 있습니다. 채널을 고른 뒤에는 queue owner, 확인 주기, 부재 시 대체 담당자, 처리 상태를 정합니다. 알림 본문을 받았다는 사실과 누군가 검토했다는 사실은 다르므로 “새 항목·검토 중·확인 질문 준비·종료”처럼 최소 상태를 둡니다.
Slack 알림은 연락처 저장소와 같지 않습니다. 알림을 받는 일과 정보 입력폼 제출자를 Notion이나 Google Sheets로 보내는 일도 별도 흐름입니다. 이번 정책에서는 CRM 저장이나 자동 영업 단계 변경까지 확대하지 않고, 알림 사건을 검토 가능한 queue로 만드는 데 범위를 고정합니다.
내부 열람이 섞이지 않았는지 먼저 시험합니다
운영을 시작하기 전에 내부 QA 열람과 외부 control 열람을 각각 한 번 실행해 알림 대상과 제외 규칙이 기대대로 작동하는지 확인합니다. 내부 열람 제외 설정을 쓴다면 owner와 적용일을 기록합니다. 과거 알림이 소급해서 사라지거나 과거 통계가 자동으로 다시 계산된다고 가정하지 않습니다.
일주일 뒤에는 알림 수만 보지 말고 중복 사건, 담당자 없는 사건, 하한 아래에서 놓치기 아쉬웠던 사건을 함께 검토합니다. 정책은 한 번 정하고 끝내는 필터가 아니라 queue 용량과 업무 맥락을 맞추는 운영 기준입니다.
알림이 많다는 문제는 더 강한 신호를 찾는다고 해결되지 않습니다. 링크 범위, 대상, 하한, 재열람 예외, cooldown과 owner를 한 표에 놓으면 알림은 의도를 대신하는 판정이 아니라 다음 질문을 준비할 수 있는 검토 순서가 됩니다.
