AI受付への不満は、AIが電話を取ったことではなく、受付した後に状況が途切れることで生まれます。折り返しに出られず再度代表番号へ電話した人へ、最初から名前と用件を聞き直す運用は、顧客に「もうメールでよい」と思わせます。
悪いCallback LoopとCase Continuity
良い設計では、AI受付でCaseを保存し、担当者の折り返し・不在・再入電を同じCaseに連結します。再入電時は「先ほどのお問い合わせですね」と文脈を確認し、担当への接続、折り返し予定、追加情報の取得を選べるようにします。
Continuity Keyは単一の識別子に頼らない
| 候補 | 使いどころ | 注意点 |
|---|---|---|
| 発信者番号 | 同一端末からの再入電 | 共用電話・番号変更 |
| Case ID | SMSやメールで案内済み | 発信者が手元にない |
| 予約番号・顧客ID | 本人確認を伴う照会 | 復唱や追加確認が必要 |
| 直近Time Window | 直後の再入電 | 似た問い合わせの誤結合 |
既存Caseを見つけても、録音や個人情報を読み上げないことが重要です。最小限の確認を行い、誤照合なら新規Caseへ戻る逃げ道を用意します。
Callback State Machine
状態を持つと、担当者には折り返し期限、AIには次に案内してよい選択肢、顧客には現在の状況を示せます。状態だけを増やさず、誰がどの状態を更新するかも決めます。
AIに戻す場面と人を優先する場面
| 状況 | 最初の対応 | 理由 |
|---|---|---|
| 新規問い合わせ | AIが受付 | 必要項目を短く取得 |
| 既存Caseの再入電 | 文脈確認して選択肢提示 | 聞き直しを減らす |
| クレーム再入電 | 人間優先 | 感情と判断を扱う |
| 担当者指定 | Routing・不在案内 | 責任の所在を明確化 |
| 営業電話 | AIで分類 | 担当者の集中を守る |
折り返し運用を電話だけで閉じない
折り返しが必要な案件は、担当者名、期限、連絡先、試行回数を見える状態にします。電話に出られなかった場合に、次にいつ連絡するのか、別経路を案内するのかを決めずに放置すると、AIの受付品質に関係なく不満が残ります。再入電した人が選べる選択肢を短く提示し、担当者の判断が必要なところだけ人へ引き渡すと、同じ説明を繰り返す負担を減らせます。
Case 1：折り返し成功
AIは氏名・用件・希望連絡時間をCaseへ保存し、担当者へ期限付き通知を送ります。担当者はCaseを開いて発信し、接続できたら対応内容を追記してCLOSEDへ移します。顧客は同じ説明を繰り返さず、担当者はAI取得情報を確認してから質問できます。
Case 2：不在後に顧客が再入電
担当者の発信結果をNO_ANSWERとして保存します。再入電時は「先ほどのお問い合わせについてでしょうか」と確認し、Caller IDだけで氏名や相談内容を読み上げません。本人確認後、担当者の状況、再折り返し、接続可能な代理担当を提示します。
Case 3：不在後にSMSを送信
不在記録の後、Case IDと安全な再開URLをSMSで案内します。SMS本文へ機微な用件を直接書かず、再入電時はCase IDまたは追加情報で照合します。SMS送信失敗も状態として残し、送った前提で受付を終了しません。
再入電で何を言うべきか
最初から「お名前をお願いします」と聞くと、保存したCaseの価値が伝わりません。まず「先ほどのお問い合わせについてでしょうか」とYes/Noで確認し、必要な本人確認後に文脈を復元します。Caller IDだけで氏名、予約、相談内容を読み上げてはいけません。共用携帯、法人代表番号、家族電話では別人の可能性があります。
SLAとCallback Ownership
| 項目 | 決める内容 |
|---|---|
| Owner | 担当部署・当番・代理担当 |
| Deadline | 営業時間と緊急度別の期限 |
| Attempts | 何回・どの時間帯に試すか |
| No answer | SMS・Email・再入電案内 |
| Reassignment | 休暇・不在・期限超過時の変更 |
| Closed | 接続、辞退、別経路完了などの終了条件 |
SLAは顧客へ約束する時間と、社内で通知を受け取る時間を分けます。CaseがWAITING_CALLBACKのまま残る場合、管理画面で期限超過を検出し、個人の記憶へ依存させません。
電話だけで閉じないContinuity
SMSはCase IDと安全な再開導線、Emailは長い資料、管理画面は状態と担当、担当者通知は期限と要点を持ちます。チャネルごとの役割を決め、SMS失敗やEmail未達もCaseへ記録します。電話番号、Case ID、予約番号、直近時間帯を組み合わせても誤照合が残る場合は、本人確認を追加するか新規Caseへ戻します。
実務判断台帳
| 判断点 | 実装・運用の考え方 | 検証方法 |
|---|---|---|
| 初回受付 | Case ID、受付時刻、希望連絡時間、用件分類を保存する。 | 顧客へ折り返し主体と期限を過剰に断定せず案内する。 |
| 担当割当 | 個人名だけでなく部署・当番・代理担当を持たせる。 | 休暇やシフト変更でもCaseが滞留しないことを確認する。 |
| 発信開始 | 担当者がCaseを開いてから発信し、発信時刻を自動または手動記録する。 | 別担当が同時発信する競合を防止する。 |
| 不在判定 | 呼出中、話中、拒否、留守電、接続失敗を同じNO_ANSWERに潰さない。 | 次の試行条件を結果別に設定する。 |
| SMS案内 | 機微な用件を書かず、Case IDと安全な再開方法だけを送る。 | 配信失敗・期限切れリンクを状態へ反映する。 |
| 再入電照合 | Caller ID、直近時間、Case ID、予約番号を組み合わせる。 | 共用電話で別人なら新規受付へ戻れるようにする。 |
| 代理担当 | 元担当の期限超過時に代理へ移し、顧客へ内部事情を詳述しない。 | Ownership変更履歴と現在の責任者を一つにする。 |
| 完了条件 | 接続しただけで閉じず、顧客の用件が処理済みか、次工程が合意されたかで閉じる。 | 再開条件と保存期間を運用ルールにする。 |
再入電設計で確認したい8項目
| 確認場面 | 設計の要点 | 確認方法 |
|---|---|---|
| 新規Case作成 | 受付の一意キーを先に発行 | 二重送信でも一件にする |
| 担当受領 | Ownerを明示的に引き受ける | 未受領を自動検知 |
| 留守電 | 機微情報を残さない | 再連絡方法だけ案内 |
| 話中 | 短時間の再試行条件を持つ | 無制限再発信を防ぐ |
| 顧客再入電 | 既存Case候補を提示 | 本人確認前に内容を開示しない |
| 期限超過 | 管理画面で赤旗を出す | 上長・代理へEscalation |
| SMS送信 | Case IDと安全なURLだけ | 配信結果を保存 |
| 接続成功 | 会話開始だけでCloseしない | 処理結果を追記 |
確認した一次情報
- Twilio Voice Webhooks（2026年8月26日確認）
- Twilio Call Status Callback（2026年8月26日確認）
関連論点を自社の受付へ落とし込む
AI電話受付、人間への転送、AI電話の失敗例、代表電話のAI化も併せて確認し、入口の会話だけでなく受付後の担当・記録・例外対応をつなげてください。
よくある質問
電話番号だけで案件を復元できますか？
誤照合の危険があるため、電話番号だけで重要情報を開示せず、時間帯・用件・予約番号などを組み合わせます。
再入電は必ず人へつなぐべきですか？
新規と既存案件、緊急性、クレーム、担当者指定などで分けます。