問い合わせフォームの回答をSlackに通知すると、最初はかなり便利です。
新しい問い合わせに気づける。
チーム全員に見える。
メールボックスの奥で埋もれにくい。
ただ、Slack通知だけでは問い合わせ対応管理にはなりません。
通知が流れたことと、誰かが対応したことは別だからです。
通知されたことと対応中は違う
よくある状態です。
問い合わせが届く
Slackに通知される
誰かがリアクションを付ける
他の人は「誰かが見た」と思う
担当者は決まっていない
返信も終わっていない
週末に未返信が見つかる
この失敗は、Slack通知の失敗ではありません。
通知を対応状態として扱ったことが問題です。
Slack通知は、気づくための仕組みです。
問い合わせ対応管理は、状態を進めるための仕組みです。
この2つは分けます。
notification_stateとresponse_statusを分ける
最低限、次の2つを別に持ちます。
notification_state
response_status
通知状態は、Slack投稿の状態です。
pending
sent
failed
skipped
回答状態は、問い合わせ対応の状態です。
new
triaged
assigned
in_progress
waiting_customer
done
excluded
たとえば、Slack通知が成功していても未対応ならこうです。
notification_state = sent
response_status = new
Slack投稿が失敗しても、問い合わせ自体は存在します。
notification_state = failed
response_status = new
この分離がないと、通知成功を対応成功と勘違いします。
ownerがない通知は流れて終わる
Slack通知文に本文だけを載せても、担当者は決まりません。
新しい問い合わせが届きました
カテゴリ: 料金相談
本文: 料金プランについて相談したいです
これだけだと、誰が見るべきか分かりません。
少なくとも、担当者候補か担当チームを持ちます。
owner_candidate = sales
owner = null
response_status = triaged
AIを使うなら、担当者候補と理由を出すのは有効です。
ただし、候補と確定は分けます。
owner_candidate
owner
owner_assigned_by
owner_assigned_at
owner_candidate はAIやルールが出す候補です。
owner は実際に責任を持つ人またはチームです。
Slackリアクションを完了にしない
Slackのリアクションは便利です。
でも、リアクションを対応完了の正本にするのは危険です。
リアクションには意味が複数あります。
見た
あとで対応する
担当する
確認した
完了した
人によって解釈が違います。
どうしても使うなら、リアクションはイベントとして記録し、最終状態は別に持ちます。
event_type = slack_reaction_added
response_status = assigned
完了にするなら、明確な操作にします。
response_status = done
done_by = user_123
done_at = 2026-06-23T18:30:00+09:00
AI要約通知でも状態は必要
AIで問い合わせ本文を要約してSlackに流すと、通知は読みやすくなります。
要約: 料金プランと今月中の導入可否についての相談
優先度候補: high
担当者候補: sales
確認ポイント: 契約条件、導入時期
これは有効です。
ただし、AI要約通知だけでも対応管理にはなりません。
AI要約は、判断材料です。
状態更新ではありません。
ai_summary_status = done
response_status = new
human_review_status = unreviewed
AIが読んだこと、人間が確認したこと、返信が終わったことを分けます。
最小データモデル
問い合わせ対応管理として持つなら、最低限このくらいです。
response_id
submitted_at
message
category
priority
owner_candidate
owner
response_status
notification_state
last_event_at
next_action
excluded_reason
通知文には、本文だけでなく状態も入れます。
新しい問い合わせ
カテゴリ: 料金相談
優先度候補: high
担当者候補: sales
現在状態: new
次アクション: 担当者確認
これだけで、Slack通知は「見たら終わり」から「次の状態へ進める入口」に変わります。
チェックリスト
[ ] notification_state と response_status を分けた
[ ] owner_candidate と owner を分けた
[ ] Slackリアクションを完了扱いにしていない
[ ] AI要約と人間確認を分けた
[ ] done には done_by / done_at を持つ
[ ] excluded には excluded_reason を持つ
[ ] 通知失敗時も回答レコードは残る
[ ] 通知文に現在状態と次アクションを入れた
Slack通知は必要です。
ただ、通知は入口です。
問い合わせ対応管理として必要なのは、担当者、状態、次アクション、確認ログです。
問い合わせ対応をAIで要約、分類、担当者候補、未対応確認へつなげる設計は、こちらに整理しています。