Concepts
エスカレーションフロー
エスカレーションフロー
定義
AI 一次応対から人間エージェントへ、または Agent A から Agent B へ通話を引き継ぐ仕組み。TwiML 更新 + Twilio <Dial> で物理転送を実行しつつ、session_id / transcript / 事前通知を連続させて引継コストを最小化する。
現在の理解
AI → Agent A (FR-ESC-1〜7)
- AI 判定またはダッシュボード操作でエスカレーション指令を発行
- Backend が available 状態の Agent を選定 (→ Dispatcher)
- Twilio REST API で CallSid に対する TwiML を更新、
<Dial>で Zoom Phone 直通番号に発信 - Bridge 完了後も caller leg の Media Stream は継続、Backend は Agent 音声も受信
- Scribe に別ストリームで送って話者分離 transcript を生成
- Agent 不応答時は fallback (別 Agent 試行 or 留守電) を TwiML で制御
- Agent のブラウザに WebSocket で事前通知 (session_id + 履歴 + 推定着信タイミング)
Agent A → Agent B (FR-ESC-8〜13)
- Agent A または管理者が Web UI から Agent B を指定
- Backend が TwiML 更新、caller leg を Agent B へ再
<Dial>(cold transfer) - Agent B に Web UI 経由で事前通知
- Agent A の Zoom Phone は自動切断
- 転送前後で session_id 不変、transcript 連続蓄積
- (将来拡張) Warm transfer は Conference 方式で Agent A・B・caller が一時同席
エスカレーション記録
escalations テーブル (§6.1) で以下を追跡:
from_actor/to_actor(ai → agent_a / agent_a → agent_b 等)reason(判定理由)triggered_by(ai_auto / admin_manual / agent_request)twiml_update_status(pending / applied / failed)
非機能要件
- NFR-PF-4: 事前通知 — エスカレーション判定から Agent ブラウザ通知まで 1 秒以内
- NFR-PF-5: TwiML 更新による転送指示 — 指示発行から Twilio 実行開始まで 1 秒以内
論点
- Cold transfer のみ (MVP): Agent A → B で引継会話ができない。Warm transfer 要件が出たら Conference 方式に拡張 (§11.1)
- 事前通知の粒度: 履歴サマリの自動生成は未定義。transcript 全文か要約かの選択
- Agent 不応答時の fallback: 別 Agent 試行→留守電の順だが、回数・間隔の具体値は未定
- TwiML 更新失敗時の挙動: 指数バックオフで規定回数リトライ → 失敗で管理者通知 + 通話は継続 (§7.4)
根拠となる資料
関連する entity
未解決の問い
- 事前通知に含める履歴サマリの自動生成方式 (Claude に要約させるか、生 transcript か)
- 転送実行失敗のユーザー体験 (発信者は何を聞くか)
- Warm transfer 移行時の課金・実装影響
更新メモ
- 2026-04-19: v3.0 要件定義書から初版作成