運用と改善
Agent の公開後、仕事は四つの運用判断を循環します。
- 利用者が実際に経験したことを観察する。
- 今対応が必要な会話、form、handoff を処理する。
- 重要な新しい判断を case として保存する。
- 限定した変更を検証してから次の version を公開する。
対応中の queue から始める
会話 を開き、通常の品質レビューより先に 有人返信待ち と表示された項目に対応します。AI下書き を利用しても、最終内容と delivery 判断は人が担当します。
→ 会話
→ 会話に返信
運用画面をつなげて使う
| 画面 | 支援する判断 |
|---|---|
| 会話 | 何が起き、何に返信が必要で、何を case にするか |
| 顧客 | 誰が体験にアクセスでき、どの customer-Agent pair が有人モードか |
| フォーム回答 | どの構造化された依頼に follow-up が必要か |
| 決済 | reconciliation、status 確認、internal note が必要な payment request |
| Workspace 通知 | handoff と submission の signal を運用担当者がどこで受け取るか |
| ダッシュボード | どの queue と最近の活動に注意が必要か |
| 評価と改善 | 限定した変更を公開してよいか |
各部分の責任者を決める
| 発生した状況 | 最初の責任者 | 判断または実行できること | エスカレーションする条件 |
|---|---|---|---|
| 承認済み範囲で利用者への即時返信が必要 | 運用担当者 | 確認、返信、有人モードの利用、結果の記録 | 新しい専門判断、リスクのある約束、制限情報へのアクセスが必要な場合は専門家または責任者へ渡す |
| テキストまたは付随アクションが完全に届いていない | 運用担当者 | 両方の delivery status を確認し、重複返信を避け、エラーを記録する | チャネル、認証情報、設定、繰り返す送信失敗が関係する場合は管理者へ渡す |
| 同じ動作問題が再発する可能性がある | 運用担当者 | Add Case を使い、観察した影響を記録する |
受け入れ可能な結果や新しい境界を決める必要がある場合は専門家または責任者へ渡す |
| 変更した Agent が公開可能に見える | Release reviewer | 影響する case、must-pass set、既知の制約を確認する | 証拠が不足する、または承認済み scope が変わる場合は専門家または責任者へ戻す。実際の公開操作は workspace admin または organization owner が行う |
| アクセス、チャネルの状態、公開範囲が正しくない | 管理者 | アクセス制限、チャネル確認、通知変更、チャネルの公開取り消し | 業務 scope、利用者への約束、許容リスクを変える必要がある場合は責任者へ渡す |
一人が複数の役割を担当しても、各判断には名前の付いた責任者が必要です。
有人引き継ぎを有効にする前に、queue owner、目標返信時間、エスカレーション先を決めます。Codeer がすべてのチームに共通の返信時間を設定するわけではありません。決めた時間を守れない場合は、pilot を狭め、通知を改善するか、その状況を Agent の対応範囲から外します。