滞留している問い合わせを毎日洗い出して、止まっている理由と次の一手を出す

処理の起点を決める

毎朝の決まった時刻（8:30）を起点にします。始業前に配信が届き、朝会のときには全員が自分の一覧を見ている状態を作ります。

朝会の直前ではなく、始業の直後にしてください。 配信が届いてから読む時間がないと、結局その場で開くことになります。

もう1つの起点として、チケットのステータスが「他部門確認中」に変わったときに、一定日数後の催促を予約する形が考えられます。滞留してから気づくより、そもそも滞留させないほうが良いという考え方です。ただし、これは問い合わせ管理システムのステータス設計に依存するため、最初は朝の一括処理だけで始めてください。

入力データを集める

データの取得方法を決める

チケットと対応履歴： 問い合わせ管理システムのAPIで取得します。対応履歴の全文が取れるかを先に確認してください。 件名とステータスだけでは、止まり方は判定できません。

履歴が長い場合、直近の10往復程度に絞ります。 3か月前のやり取りまで渡しても、今なぜ止まっているかの判断には効きません。ただし、最初の1往復（顧客が最初に何を聞いたか）だけは必ず含めてください。 途中から読むと、何の話か分からなくなります。

顧客情報： 優先度の判定に使います。契約金額の大きい顧客、解約の検討が出ている顧客の滞留は、同じ経過日数でも重みが違います。ただし「大口だけ優先する」運用にすると、小口の顧客の滞留が固定化します。 経過日数との組み合わせで見てください。

他部門への依頼： ここが取れるかどうかで、この構成の価値が変わります。チケットの社内メモに「開発へ確認中（Slackスレッド:リンク）」と書かれていれば、そのスレッドの最終更新を見て「返事が来ているのに気づいていない」を検出できます。 メモにリンクを残す運用が前提になります。

営業日カレンダー： 「3営業日」の判定に使います。土日祝を数えると、連休明けに全件が滞留判定になります。

AIへ渡す前に整形する

1. 除外の適用 … クローズ済み、顧客の希望で保留にしているもの、次回の連絡日が設定されているものを除きます。この除外がないと、正常に管理されているチケットまで並びます
2. 履歴の整形 … 署名、引用、定型のフッターを落とします。引用を残すと、同じ内容を何度も読ませることになり、判定が鈍ります
3. 直近の往復への絞り込み … 最初の1往復と、直近の10往復を残します
4. 社内メモと顧客向けメッセージの区別 … どちらかが分からないと、「顧客に伝えたつもりで伝わっていない」を検出できません。この区別は必須です
5. 添付ファイルの扱い … ログファイルやスクリーンショットは、ファイル名と添付日だけを渡します。中身は開きません

AIに処理させる

「実は完了している」の区分が効きます。 顧客の「ありがとうございました、解決しました」でやり取りが終わっているのに、クローズし忘れているチケットが一定数あります。これを機械的に拾うだけで、滞留の一覧が2割減ることがあります。

顧客への返信文を完成させません。 催促の下書きまでです。苛立ちが表れている顧客への返信を、AIの文面そのままで送ってはいけません。

指示内容を固定する

あなたはカスタマーサポートのチームリーダーを支援する担当者です。
下のチケットの対応履歴を読み、なぜ今動いていないのかを判定してください。

【厳守事項】
- 履歴に書かれていることだけを根拠にしてください。
  顧客の事情や他部門の状況を推測しないでください。
- 止まり方は、下の区分からのみ選んでください。判断できない場合は "unknown" にし、
  何が分からないかを reason に書いてください。
- 「最後に動いたのは誰か」を必ず特定してください。
  顧客からのメッセージが最後なら、こちらが返していないということです。
  こちらの返信が最後なら、顧客が返していないということです。**ここを取り違えないでください。**
- 社内メモと顧客向けメッセージを区別してください。
  社内メモに書いただけで顧客に伝わっていない場合、それを指摘してください。
- 催促の下書きは、事実の確認を依頼する形にしてください。
  「お忙しいところ恐れ入りますが」のような定型の前置きだけで終わらせず、
  何を待っているのかを1文で明示してください。
- 顧客の温度感は、履歴の文面に表れている範囲でのみ判定してください。
  書かれていない感情を読み取らないでください。
- 対応の内容（技術的な回答、仕様の説明）を書かないでください。
  ここでは「誰が次に何をするか」だけを扱います。

【止まり方の区分】
waiting_customer ... 顧客の返信を待っている
waiting_internal ... 他部門への確認を待っている
waiting_agent ... 担当者の作業・調査が止まっている
needs_decision ... 判断が必要でリーダーの関与が要る
already_resolved ... 実質的に解決しており、クローズすればよい
unknown ... 判定できない

【チケット】
{ticket_meta}

【対応履歴（最初の1往復＋直近10往復・社内メモは [社内] を付与）】
{conversation}

【顧客情報】
{customer_context}

【他部門への依頼の状況】
{internal_requests}

【対応の基準】
{sla_rules}

「最後に動いたのは誰か」を明示させる指示が、この構成の要です。 これを外すと、AIは「顧客の返信を待っています」と書きがちです。実際には、こちらが返していないだけ、というケースが少なくありません。 取り違えると、放置されているチケットが「顧客待ち」として放置され続けます。

「社内メモに書いただけで顧客に伝わっていない」の検出も効きます。 「調査結果を社内メモに書いて安心してしまい、顧客へ返信していない」というのは、よく起きる止まり方です。

出力形式を固定する

{
  "ticket_id": "",
  "subject": "",
  "assignee": "",
  "days_since_update": 0,
  "days_since_created": 0,
  "last_actor": "customer | agent | system",
  "last_action_summary": "",
  "stall_type": "waiting_customer | waiting_internal | waiting_agent | needs_decision | already_resolved | unknown",
  "next_actor": "customer | internal | agent | leader",
  "next_action": "",
  "draft_message": "",
  "internal_request_target": "",
  "customer_sentiment": "calm | concerned | frustrated | unknown",
  "sentiment_evidence": "",
  "priority": "high | medium | low",
  "priority_reason": "",
  "can_wait": false,
  "can_wait_reason": "",
  "reason": ""
}

JSON Schema を指定して出力を固定します。Claude API では output_config.format に json_schema を渡すことで、応答をスキーマに沿った形に制約できます。

can_wait は、待っていることに問題がない場合の印です。顧客が「来週まとめて確認します」と言っている、他部門の回答期限がまだ来ていない、といったケースです。ここが true のチケットを配信から外すことで、通知が現実的な量に収まります。

sentiment_evidence は、温度感を判定した根拠になる文です。根拠が示せない感情判定は使えません。 「frustrated」とだけ書かれても、担当者は確かめようがありません。

システムへ連携する

配信は2系統に分けます。

担当者個人へ（Slack のDM）：

自分が担当するチケットのうち、can_wait が false のものだけを並べます。1件あたり4行程度にまとめます。

[チケット番号] 件名
止まり方：他部門への確認待ち（開発チーム・5営業日経過）
次の一手：#dev-support で進捗を確認。回答がなければリーダーへ
顧客の状況：苛立ちの表れあり（「いつまでかかりますか」2回）

リーダーへ（チャンネル）：

次の3つだけを並べます。

全件をリーダーに送らないでください。 45件が毎朝届くと読まなくなります。

問い合わせ管理システムへの書き戻しは、限定的に行います。 判定結果をチケットのカスタム項目に書き込むのは構いませんが、ステータスの自動変更はしません。 特に already_resolved の自動クローズは避けてください。誤ってクローズされた顧客の心証は、滞留より悪くなります。

人が確認する

顧客への送信は、必ず人が行います。

理由は、滞留しているチケットが「何かがうまくいっていない案件」だからです。そこへ機械的な催促が届くと、状況が悪化します。 特に customer_sentiment が frustrated のチケットでは、催促ではなく謝罪と状況説明が先になることがあります。その判断は人にしかできません。

確認の深さは分けます。

• priority が high のチケット … 判定と一手を読み、対応する
• can_wait が true のチケット … 一覧に出さない。週1回まとめて目を通す
• already_resolved のチケット … 履歴を確認してからクローズする。判定を信じてそのまま閉じない
• stall_type が unknown のチケット … 人が履歴を読む

確認を速くするための設計が効きます。

• 担当者ごとに分けて配信する（自分の分だけ見ればよい状態にする）
• 止まり方ごとにまとめる（催促する相手が同じものをまとめて処理できる）
• sentiment_evidence を必ず併記する
• 前日と同じ判定が続いているチケットに印を付ける（動いていないことが分かる）

最後の項目が効きます。 3日連続で「他部門への確認待ち」と出ているなら、催促が効いていないということです。別の手が要ります。

例外に対処する

記録を残す

この記録は、滞留がなぜ起きるかを分析する材料になります。

• 日ごとの判定結果（止まり方、次の動き手、優先度）
• 判定してから実際に動くまでの日数
• 人が判定を訂正した場合、その前後の値
• 催促の下書きと、実際に送った文面
• クローズまでの経過日数

「止まり方の区分ごとの件数の推移」を月次で見てください。 waiting_internal が多いなら、他部門との連携の仕組みに問題があります。waiting_agent が多いなら、担当者の作業量か知識が足りていません。個別の催促を続けても、原因が変わらなければ件数は減りません。

下書きと実際に送った文面の差分も残してください。 「毎回冒頭を書き直している」なら、プロンプトを直せます。