朝の業務を始めると、チームのSlackチャンネルに文書が開かれたという通知が届きます。少し後には、情報入力フォームを送信した人の連絡先が運用データベースに追加されます。どちらも同じ文書から生じた記録でも、同じイベントではありません。一方は文書が開かれたという通知で、もう一方は誰かが情報を直接送信したという記録です。
連携を設計するときにサービス名から決めると、この違いが見えにくくなります。「SlackとZapierをつなぐ」と考える前に、どのイベントを誰に知らせ、どの送信データをどこに残すのかを決めます。通知と記録を分けることで、担当者と次の行動を過大に解釈せず設定できます。
通知と記録では目的が異なります
通知は、確認すべきイベントが発生したことをチームに知らせます。長期保存の台帳でも、顧客情報を管理する仕組みでもありません。一方、連絡先の送信は、情報入力フォームに入力された値を後の業務で再び参照できる指定先に残すことです。通知がすぐ届いても連絡先データになるわけではなく、連絡先が保存されても直ちに営業対応が必要になるわけではありません。
FeatPaperの現在の接続範囲も、この二つを分けています。Slackはアカウントまたはワークスペース単位で文書閲覧通知を受け取る経路です。情報入力フォーム送信者の連絡先は、アカウント接続後、文書ごとに選択したNotionデータベースへ送ることができます。Slackを文書別の連絡先保存先やCRM同期のように説明すると、実際の範囲を超えてしまいます。
最初にイベント名を固定します
接続画面を開く前に、運用表へイベントを二つの行に分けて書きます。
| イベント | 確認できた事実 | まだ分からないこと | 適した目的 |
|---|---|---|---|
| 文書閲覧通知 | 共有した文書が開かれた | 購買意向、予算、連絡希望の有無 | 担当チームに確認の必要性を知らせる |
| 情報入力フォーム送信 | 送信者が設定項目を入力した | 情報の正確性、相談の準備状況、意思決定権限 | 送信値をフォロー業務用に保管する |
イベント名に「関心の高い顧客が発生」のような解釈を含めると、その後の自動化も同じ過大解釈を繰り返します。「文書が開かれた」「情報入力フォームが送信された」のように観察できる事実で名付ければ、次の担当者が確認すべきことを残せます。
送信先ごとに担当者と許可する行動を付けます
通知チャンネルでは、誰が確認し、どの条件で別の記録を作るかを決めます。たとえばSales Opsが通知フローを点検し、アカウント担当者は既に合意した日程や会話の文脈がある場合にだけ次の質問を準備できます。通知が届いたという事実だけで、すぐに連絡したり優先順位を上げたりするルールは作りません。
連絡先の送信先には、データ所有者と利用目的を付けます。どの文書のどのフォームから届いた値か、欠損や重複を誰が確認するか、送信時に案内したフォロー範囲は何かを一緒に確認します。情報を送信した事実だけで、相談依頼や連絡同意の範囲を広げてはいけません。保存先だけを決めて責任者を置かなければ、行が増えても業務は続きません。
接続名ではなく境界文を残します
連携文書には、対応する動作と同じくらい、しない動作も明確に書きます。
- Slack通知は文書が開かれたイベントを伝えます。連絡先を保存する文書別の送信先としては使いません。
- この記事で確認した連絡先送信の範囲は、情報入力フォーム送信者を文書ごとに選んだNotionの送信先へ送る動作です。他の送信先や範囲も同じように対応すると推測しません。
- 情報入力フォームを送信していない匿名閲覧や受信者リンクの閲覧を、連絡先送信記録に変えません。
- このフローをSalesforceやHubSpotのネイティブ同期とは呼びません。
- 閲覧や送信を、購買意向、MQL・SQL判定、契約可能性に置き換えません。
これらの文は機能説明を弱める制約ではありません。チームが同じ記録を別の意味で使うことを減らす運用ルールです。
良い連携は速さより誤解を減らします
接続ポリシーを見直すときは、ツールの数より次の四つの質問を確認します。
- どのイベントが発生したか。
- そのイベントは通知と保管のどちらの目的に近いか。
- 送信先で誰が何を確認するか。
- 記録だけでは何を断定しないか。
Slack通知を受け取ることと、フォーム送信者の連絡先を送ることは同時に運用できます。ただし二つのフローの価値は、一つにまとめたときではなく、イベント・送信先・担当者・解釈の境界を別々に説明できるときに生まれます。
