最終更新日: 2026-10-15
未対応は、未確認・担当未定・期限超過に分けると次の行動が決まります。まずnew/in_progressの回答を読み、担当と期限は運営台帳で照合してください。通知を受け取ったことと、誰かが対応を引き受けたことは別です。
まず結論 -- 未対応は3種類に分けます
以下の列や担当・期限は運用設計の例です。FORMLOVA標準のstatusは new（新規）、in_progress（対応中）、resolved（解決済み）、spam の4値です。担当者、確認待ち、返信期限、AI候補はnotes・既存タグを保持するタグ運用・用途に応じたフォーム項目、または別の運営台帳へ分けます。needs_review は確認用の印で、標準statusではありません。複数回答の状態変更は対象IDごとに実行し、再取得で確認します。
未対応をひとまとめにすると、何から手を付ければよいか分かりません。
最初に、次の3種類へ分けます。
| 未対応の種類 | 意味 | 最初に見ること |
|---|---|---|
| 未読/未確認 | 誰も内容を確認していない | 内容、カテゴリ、緊急度 |
| 担当者未設定 | 内容は見たが、誰が持つか決まっていない | owner、担当候補、部署 |
| 期限超過 | 担当者や期限はあるが、進んでいない | first_response_due_at、last_activity_at |
この3つは、同じ未対応でも原因が違います。
未読なら、通知や一覧確認が弱い。担当者未設定なら、振り分けルールが弱い。期限超過なら、リマインドやエスカレーションが弱い。
まず未対応を原因別に分けると、対策が見えます。
今日止まっている理由を分ける
次は未実行の提案例です。まず下書きや架空データで試し、実回答を使う場合はフォーム・期間・扱ってよい情報を決めます。
問い合わせフォームを下書きにし、カテゴリ、本文、希望日を置いてください。
指定フォームのnew/in_progressの回答と、私が渡す運営台帳だけを使って、未確認・担当未定・期限超過の候補を回答ID付きで出してください。担当、期限、活動履歴がない場合は「情報不足」とし、未読や期限超過を推定で確定しないでください。通知・返信・状態更新はしないでください。
未対応理由ごとに、次に確認する人と時刻を1つ決めます。完了していない回答をresolvedにせず、更新が必要なら対象IDごとに確認して変更し、再取得で確かめます。
この図は運用の考え方を示す既存の概念図です。実画面や動作成功の証拠ではありません。図の自動化範囲も、利用プラン・接続・設定後に成立する設計を示します。
フォーム作成・公開・回答受付・検索・標準status・書き出し・基本分析は無料で使えます。上のAIの整理は接続するAIクライアント側で行い、外部AIの利用条件や費用は別です。カスタム自動返信、リマインド、取り込み、詳細分析、添付、標準のSheets自動同期はスタンダード以上、一斉メールやシーケンスはプレミアム以上です。外部MCPを使うレシピはFreeからでも外部接続・権限・提供元条件がそろえば実行できますが、チャットへ貼るだけで常時監視は始まりません。
未対応を見直せる受付フォームを作る
上の下書きと確認から無料で試し、運用に必要になった機能を追加できます。
登録してメール確認後、対応AIチャットへ接続し、上の依頼文で下書きを作ります。公開前に内容を確認し、外部AIの利用条件・費用も確認してください。
ステータス管理との違い
未対応管理は、ステータス管理の一部です。
ただし、同じではありません。
フォーム回答のステータス管理では、標準4statusを使い、確認待ちや除外理由をnotes・タグ・台帳へ分けます。
この記事で扱うのは、その中でも「未対応をどう減らすか」です。
| 観点 | ステータス管理 | 未対応管理 |
|---|---|---|
| 主な問い | いまどの状態か | 何が止まっているか |
| 粒度 | 未対応、対応中、完了など全体 | 未対応、担当者未設定、期限超過 |
| 目的 | 状態を揃える | 放置を減らす |
| 見る頻度 | 日次/週次 | 日次 |
| 次アクション | 状態更新 | 担当者決定、返信期限、リマインド |
つまり、ステータス管理は土台です。
未対応管理は、その土台の上で「止まっている回答を毎日動かす」ための運用です。
未対応キューに入れる列
MCPのCSV/Excel書き出しはフォーム項目と送信日時で、回答ID・status・owner・notes・tags列は含みません。フォーム全件を書き出し、必要な絞り込みは管理した作業コピーで行います。IDや状態の分析は対応する回答取得で確認し、生メール照合や存在しないCSV列で結合しません。MCPのメール・電話はマスクされるため、マスク値を宛先やCRMの本人キーへ渡しません。標準Sheets自動同期も送信日時とフォーム項目で、owner/status等は別の作業台帳へ分けます。Freeの所有者向け通知は6時間ダイジェストでメール枠の対象外です。回答者向けメールや、チャットで作る未対応レポートとは別です。
未対応を減らすには、回答一覧に必要な列を持たせます。
最小構成はこれで十分です。
分析・運営台帳の提案例です。列は実際に用意したものだけを使い、不足は不明とします。実行結果や標準CSVの列ではありません。
submitted_at
category
summary
status
owner
priority
first_response_due_at
last_activity_at
unhandled_reason
next_action
特に重要なのは、owner、first_response_due_at、last_activity_at、unhandled_reason です。
status だけでは足りません。
たとえば、ステータスが未対応でも、担当者が決まっている未対応と、担当者が空の未対応は違います。どちらも同じ色で表示すると、誰が動くべきか分かりません。
unhandled_reason には、次のような値を入れます。
分析・運営台帳の提案例です。列は実際に用意したものだけを使い、不足は不明とします。実行結果や標準CSVの列ではありません。
unread
owner_missing
due_over
waiting_internal
needs_review
sales_or_spam_check
未対応の理由が分かると、日次チェックで迷いません。
問い合わせフォームでは初回返信期限を置きます
問い合わせフォームの未対応管理では、初回返信期限を置きます。
完了期限ではありません。
最初の返信または確認開始の期限です。
分析・運営台帳の提案例です。列は実際に用意したものだけを使い、不足は不明とします。実行結果や標準CSVの列ではありません。
first_response_due_at = submitted_at + 1営業日
urgent = 当日中
needs_review = 翌営業日午前
sales_or_spam_check = 週次除外
このように分けておくと、「完了していない回答」ではなく「最初の反応がまだない回答」を見つけられます。
問い合わせでは、最終解決まで時間がかかることがあります。社内確認、見積もり、調査、日程調整が必要な場合です。
それでも、初回返信がないまま放置されるのは避けるべきです。
だから、未対応管理ではまず初回返信期限を見ます。
ダッシュボードでは未対応を上に置きます
フォーム回答をダッシュボード化するとき、未対応は上に置きます。
きれいなグラフより先です。
フォーム回答をダッシュボード化する方法では、受付状況、未対応、担当者、内容分類、次アクションを最小構成にしています。その中でも、日々の運用では未対応キューが一番重要です。
たとえば、日次で見るなら次の順番です。
1. 期限超過
2. 高優先度の未対応
3. 担当者未設定
4. 24時間以上更新がない回答
5. 営業メール/除外候補
この順番なら、数が多いフォームでも先に動くべき回答が見えます。
ダッシュボードは、全体を眺めるためではなく、今日の未対応を減らすために使います。
担当者未設定を放置しない
未対応の中で一番危ないのは、担当者未設定です。
ステータスが未対応でも、担当者が決まっていれば、その人が動けます。
でも、担当者が空だと誰も責任を持ちません。
分析・運営台帳の提案例です。列は実際に用意したものだけを使い、不足は不明とします。実行結果や標準CSVの列ではありません。
status = new
owner = 空
priority = high
first_response_due_at = 今日
これは、すぐ拾うべき回答です。
担当者未設定を減らすには、カテゴリ、本文、送信元、優先度から担当者候補を出します。AIを使う場合も、担当者確定まで自動化しすぎない方が安全です。AIは担当候補と理由を出し、最終的なownerは人間または明示ルールで確定します。
FORMLOVAで最初に試すなら、問い合わせ担当者割り当てが近い入口になります。担当者候補、理由、返信期限を残すことで、未対応のまま浮いている回答を減らせます。
Workflowページは再利用できるチャット用プロンプトです。接続中のセッションで必要なツールとプランを確認して実行するもので、回答ごとの監視や定期実行が自動で設置されるわけではありません。定期レポート・リマインドは対応するスタンダード以上の設定か別途のスケジューラーが必要で、外部Slack/Sheets MCPは接続・権限・提供元条件も別に確認します。
Slack通知だけでは未対応管理になりません
Slack通知は便利です。
ただし、Slackに流れたことは未対応管理ではありません。
通知は「気づくためのもの」です。未対応管理は「進んだかを残すためのもの」です。
よくある失敗は、全件をSlackに流して満足してしまうことです。
最初は見ます。でも件数が増えると、チャンネルに流れた通知は追えなくなります。誰かが見たか、返信したか、担当者を決めたか、除外したかが残りません。
Slackを使うなら、通知文に次の情報を入れます。
未対応理由
担当者
初回返信期限
優先度
管理画面のURL
次アクション
そして、実際の進捗に応じて回答側の標準statusを更新し、ownerと活動時刻はnotesまたは台帳へ記録します。通知しただけでは進捗を更新しません。
Slack通知そのものの設計は、フォーム回答をSlack通知する設計で、全件通知、条件付き通知、担当者、Sheetsログの分け方として整理しています。
日次チェックの型
未対応管理は、毎朝5分でも効果があります。
見る順番を固定します。
今日の期限超過を出す
担当者未設定を出す
24時間以上動いていない未対応を出す
高優先度で未対応のものを出す
除外候補をまとめる
この確認でやることは、返信文を書くことではありません。
まず、止まっている回答を動かします。
| 見つけたもの | その場でやること |
|---|---|
| 担当者未設定 | owner候補を決める |
| 期限超過 | 担当者へリマインドする |
| 緊急そうな未対応 | 優先度を上げる |
| 営業メール候補 | 要確認または除外へ回す |
| 情報不足 | 確認待ちにして次アクションを残す |
毎日同じ形式で見て、未対応件数の変化を計測します。確認だけで減ると保証するものではありません。
週次チェックでは原因を見ます
日次チェックは、今日の未対応を減らすためにあります。
週次チェックは、未対応が生まれる原因を見るためにあります。
今週の未対応発生数
今週の期限超過数
担当者未設定で残った件数
カテゴリ別の未対応
営業メール/除外の割合
初回返信までの中央値
ここで大事なのは、個人の責任追及にしないことです。
未対応が多いカテゴリがあるなら、フォーム項目が足りないのかもしれません。担当者未設定が多いなら、カテゴリ設計やAI分類が弱いのかもしれません。期限超過が多いなら、担当者の負荷が偏っているのかもしれません。
週次では、運用を直します。
問い合わせフォーム全体の対応管理は、親ハブの問い合わせフォームの対応管理まとめに戻ると整理しやすいです。
AIを使うなら、未対応理由を出させます
AIを使う場合、未対応管理で効果が出やすいのは分類と理由付けです。
たとえば、次のように使います。
分析・運営台帳の提案例です。列は実際に用意したものだけを使い、不足は不明とします。実行結果や標準CSVの列ではありません。
この回答が未対応のまま残っている理由を分類してください。
出力:
unhandled_reason: unread / owner_missing / due_over / waiting_internal / needs_review / sales_or_spam_check
priority: high / medium / low
owner_candidate: sales / support / admin / recruiting / unknown
next_action: 次に人間がやること
reason: 判断理由
注意:
- 実送信はしない
- 除外確定はしない
- 判断に迷う場合はneeds_reviewにする
AIは、未対応理由を付けるには向いています。
ただし、実返信、除外確定、重要顧客への判断、外部連携は人間確認を残します。
回答データ全体に質問する考え方は、回答データとチャットするとはで整理しています。未対応管理では、AIに「何が止まっているか」を聞き、人間が「どう進めるか」を決めます。
FORMLOVAで試すなら、日次ダイジェストから始めます
未対応管理をいきなり大きな仕組みにする必要はありません。
まずは、毎日1回チャットで未対応の確認プロンプトを実行します。自動の定期通知を使う場合は、対応設定とプラン、実行結果を別に確認します。
未対応問い合わせダイジェストは、チャットで実行するときに未対応の問い合わせと入力した台帳情報を確認するプロンプトです。毎日見る場合は各回実行するか、対応する定期設定を別途行います。
フォローが必要な回答だけを拾い直したい場合は、未フォロー回答リマインドが向いています。
順番としては、次の流れが現実的です。
分析・運営台帳の提案例です。列は実際に用意したものだけを使い、不足は不明とします。実行結果や標準CSVの列ではありません。
1. 未対応問い合わせダイジェストで日次確認を作る
2. 問い合わせ担当者割り当てでowner未設定を減らす
3. 未フォロー回答リマインドで期限超過を拾う
4. 週次で未対応の原因を直す
この順番なら、AIや自動化を入れても、重要判断は人間が持ったままにできます。
未対応管理を、AI要約、担当者候補、返信下書きまで広げる場合は、問い合わせ対応をAIで自動化する方法で、AIに任せる範囲と人間確認を先に分けてください。
よくある失敗
フォーム回答の未対応管理でよくある失敗は、次の5つです。
| 失敗 | 起きること | 対策 |
|---|---|---|
| 未対応を1種類で見る | 原因が分からない | 未読、担当者未設定、期限超過に分ける |
| Slack通知で終わる | 進捗が残らない | status、owner、last_activity_atを更新する |
| 期限を完了期限だけにする | 初回返信が遅れる | first_response_due_atを置く |
| AIで除外確定する | 本物の問い合わせを落とす | needs_reviewを残す |
| 週次だけ見る | 重要な未対応が放置される | 日次キューを作る |
未対応管理は、厳しい監視を作るためのものではありません。
チームが毎朝迷わず動けるようにするためのものです。
まとめ
フォーム回答の未対応管理は、未対応件数を眺めることではありません。
未読、担当者未設定、期限超過に分け、担当者、初回返信期限、最終更新、未対応理由、次アクションを持たせることです。
ステータス管理で状態を揃え、ダッシュボードで未対応を上に置き、日次ダイジェストで止まっている回答を拾い、週次で原因を直す。
この流れができると、フォーム回答は受信箱ではなく、毎日動かせる仕事のキューになります。
まずは、今日の未対応を3つに分けてください。
未読なのか。担当者未設定なのか。期限超過なのか。
そこが分かれば、次にやることはかなりはっきりします。
関連記事
執筆・確認情報
- 2026-06-23に、FORMLOVA内の問い合わせフォーム対応管理、ステータス管理、回答ダッシュボード、回答一覧操作、問い合わせ管理システム/管理表の記事群を確認し、本記事を未対応キュー運用の受け皿として分離しました。
- 本記事は外部ヘルプデスクSLAやSlack/Google製品の細かな仕様を断定していません。未対応、担当者未設定、初回返信期限、リマインド、人間確認の境界は、FORMLOVAの既存運用設計とSEO棚卸しに基づいて整理しています。
改稿確認（2026-10-15）: 本文の回答操作、プラン境界、書き出し列、提案例を現行リポジトリと照合しました。過去日付の調査は当時の記録であり、架空例は実測成果ではありません。
