フォーム回答をSlackに流すと、最初は便利です。
でも全件通知のままだと、すぐに読まれなくなります。
営業メールも、テスト送信も、軽い問い合わせも、重要な相談も同じチャンネルに流れるからです。
Slack通知を運用に効かせるなら、status と owner を使って条件分岐を作ります。通知するかどうかだけでなく、どこへ出すか、誰が見るか、通知後にどの状態へ戻るかまで決めます。
Slack通知の役割を分ける
Slackは「気づく場所」です。
回答の正本ではありません。対応完了の証拠でもありません。全件ログの置き場所でもありません。
役割を分けると、設計しやすくなります。
| 役割 | 置き場所 |
|---|---|
| 気づく | Slack |
| 全件ログ | Sheets、DB、回答一覧 |
| 状態管理 | 回答一覧、ダッシュボード |
| 詳細確認 | 元回答URL |
| 週次確認 | ダッシュボード、レポート |
Slackに全部を載せようとすると、通知は読まれなくなります。Slackには「今見るべき回答」だけを出します。
全件通知は観察用
公開直後は全件通知でも構いません。
どんな回答が来るかを観察するためです。
新規回答が届いたら #form-inbox に通知する
回答種別、要約、回答URLを載せる
初期statusは new にする
ただし、全件通知をずっと続けるとノイズになります。
フォーム回答が増えたら、条件付き通知に移します。
通知条件の例
条件付き通知は、通知量ではなく「見た人が次に動けるか」で決めます。
category = pricing
or priority = high
or score <= 2
or status = new and owner is null
or first_response_due_at < now()
or next_action is null and priority in (high, medium)
これなら、Slack通知は「読むべき回答」になります。
全件ログはSheetsや回答一覧へ残し、Slackには動くべき回答だけを出します。
条件テーブルとして管理する
通知条件は、コードに直書きする前に表にします。
| condition_id | 条件 | channel | mention | reason | suppress_when |
|---|---|---|---|---|---|
| high_priority | priority = high | #ops-alert | ownerまたはops | 高優先度 | status in done/excluded |
| owner_missing | owner is null | #ops-triage | ops | 担当者未設定 | owner is not null |
| sales_pricing | category = pricing | #sales-triage | sales lead | 料金相談 | sales_or_legitimate = sales_pitch |
| low_score | score <= 2 | #support-inbox | support lead | 低評価 | followup_permission = false |
| overdue | due_at < now | #ops-alert | owner | 期限超過 | last_activity_at updated |
この表を先に作ると、「なぜこの通知が飛んだのか」を説明できます。
通知は、送るだけではなく、後で調整されます。理由と停止条件がない通知は、増えたときに消せません。
ownerで通知先を変える
担当者が決まっている場合は、その担当者やチームへ出します。
owner = sales -> #sales-inbox
owner = support -> #support-inbox
owner = recruiting -> #recruiting-inbox
owner is null and priority = high -> #ops-alert
owner is null and category = pricing -> #sales-triage
ただし、AIが出した owner_candidate と、確定済みの owner は分けます。
AI候補だけで強いメンションを飛ばすと、誤通知が増えます。
owner_candidate: sales
owner: null
status: triaged
この状態なら、まずOpsへ確認依頼を出す方が安全です。
notify #ops-triage:
owner_candidate = sales
owner is null
status = triaged
候補は確認へ。確定は担当チャンネルへ。ここを分けます。
通知されたことを対応済みにしない
Slack通知でよくある失敗は、通知されたことを対応済み扱いすることです。
notified_at はある
status は new のまま
owner は空
next_action も空
これは、通知済みの未対応です。
通知はイベントです。対応済みは状態です。
Slack通知の後に、回答一覧やSheetsへ戻れるようにしておきます。
通知イベントとしては、次のように残します。
notification_status = sent
notification_channel = #sales-inbox
notification_reason = priority_high
notified_at = 2026-06-23 10:00
これと status = done は別です。
止める条件
通知は、送る条件だけでなく止める条件も決めます。
status in (done, excluded)
or is_test = true
or sales_or_legitimate = sales_pitch
or notification_suppressed = true
or exclude_from_report = true
止める条件がないと、同じ回答が何度も流れます。
重複通知は、通知疲れを作ります。
再通知条件
一方で、再通知が必要な場合もあります。
status not in (done, excluded)
and first_response_due_at < now()
and last_notification_at < now() - interval '24 hours'
重要なのは、再通知を時間だけで出さないことです。
状態が進んでいない回答だけを再通知します。last_activity_at が動いているなら、誰かが対応中かもしれません。
実装前にテストする通知ケース
Slack通知は、正常系だけでなく止まるケースを確認します。
送るべき:
- priority = high, status = new
- owner is null, category = pricing
- first_response_due_at を過ぎていて status != done
送らないべき:
- status = done
- status = excluded
- is_test = true
- sales_or_legitimate = sales_pitch
- last_notification_at が直近で重複通知になる
確認へ回すべき:
- owner_candidate はあるが owner が空
- AI要約はあるが human_review_status = unreviewed
- followup_permission が不明
このテストを先に作ると、Slack通知が「鳴るか」ではなく「正しく鳴らないか」まで確認できます。
通知文に入れる項目
Slack通知に入れる項目は絞ります。
優先度
未対応理由
カテゴリ
要約
担当者または担当候補
期限
次アクション
元回答URL
例です。
[high][owner_missing] 料金相談の問い合わせ
category: pricing
owner_candidate: sales
due: 2026-06-23 12:00
next: 担当者を確定して返信方針を確認
url: ...
本文全文や個人情報をSlackに載せすぎないほうが安全です。Slackは気づく場所、元回答は確認する場所です。
まとめ
Slack通知は、フォーム回答が届いたことを知らせるだけでは足りません。
status, owner, priority, first_response_due_at を使って、通知条件、通知先、停止条件、再通知条件を作ります。
通知はイベントです。対応済みは状態です。
Slack通知設計の全体像は、FORMLOVA側の記事にまとめています。