対応できるスタッフがいない時間帯には、音声エージェントは発信者の情報を収集し、チケットを作成したうえで、具体的な時刻までの折り返し電話を約束すべきです。誰も出ない転送を試みるべきではありません。転送はチームが管理するルールによって無効化し、営業時間外にエージェントが転送を提案することが決してないようにします。唯一の例外は、オンコール担当者につなぐ緊急事態を記した、短い文書化されたリストです。
営業時間外に音声エージェントが通話を転送すると、何が問題になるのでしょうか？
転送先は閉じたキュー、営業時間外の録音メッセージ、または留守番電話につながり、発信者は問題の説明に費やした時間を無駄にします。その後どうなるかは転送の種類によって異なります：
- コールドトランスファー：エージェントは通話を引き継いだ時点で離脱します。転送先の留守番電話や営業時間外メッセージが応答した場合、エージェントはすでにおらず、収集した情報は何もチームに届きません。
- ウォームトランスファー（事前取次）：エージェントは回線に残り、担当者を待ちます。設定した待機時間（Retellではデフォルトで30秒）内に誰も応答しなければ、転送は失敗します。発信者は、エージェントが復帰するまで無意味に保留で待たされたことになります。
どちらの結果も、最初の1分で「チームは現在対応時間外です。この後の流れはこうなります」とエージェントが伝えるより悪いものです。
エージェントがつながらない転送を決して試みないよう、営業時間はどう設定すればよいですか？
営業中か時間外かはモデルの判断ではなくルールで決め、転送オプションは営業中の経路にのみ与えます。Retell AIでは、これを実現する方法が3つドキュメント化されています。
会話フロー内で。フローの先頭にロジック分岐ノードを配置します。このノードは通話が入った瞬間に条件をチェックし、何も発話せずに通話をルーティングします。Retellの組み込み時間変数に対して数式条件を使用します：
{{current_hour}}はエージェントのタイムゾーンにおける現在の時刻（時）を小数で表したもので、17.5は午後5時30分を意味します。営業中の条件は、たとえば{{current_hour}} >= 9 AND {{current_hour}} < 17のようになります。{{current_time}}には完全な日付と曜日名が含まれるため、{{current_time}}に「Saturday」が含まれる、という条件で週末を検出できます。- 数式条件はプロンプト条件より先に実行され、モデルを介さないため、どの通話でも同じ動作になります。
通話転送ノードにつながるのは営業中の分岐のみにします。時間外の分岐は、情報収集とチケット作成につなげます。
自社システムから。電話番号のインバウンドコールwebhookは、通話が接続される前に発火します。サーバー側で休日カレンダーや人員スケジュールを確認し、office_openのような動的変数を返すことができます。別のエージェントIDを返すことも可能で、営業時間外の通話を転送ツールを一切持たないエージェントに振り分けられます。エージェントのWorkflowページにある通話前関数（pre-call function）でも、自社のendpointに対して同じ照会を行えます。
プロンプトベースのエージェントの場合。プロンプトに{{current_time}}とルールを与えることもできますが、Transfer Callツールを持たない営業時間外専用のエージェントを別に用意するほうが安全です。エージェントは持っていないツールを使うことはできません。
チームがつまずきやすい3つのポイント：
| 落とし穴 | 対処法 |
|---|
| タイムゾーン | Retellの時間変数はエージェントのタイムゾーンを使用し、未設定の場合はデフォルトでAmerica/Los_Angelesになります。必ず設定するか、拠点ごとに{{current_hour_America/New_York}}形式の変数を使用してください。 |
| 休日 | 時計は自社の休日を知りません。カレンダーからoffice_openの値をインバウンドwebhook経由で渡してください。 |
| 終業時刻 | 午後4時58分に開始した転送は、誰もいないデスクを鳴らす可能性があります。電話受付終了の少し前に転送受付を締め切りましょう。 |
インバウンドwebhookでは通話を即座に拒否することもでき、Retellのドキュメントでは営業時間外のトラフィックをブロックする方法にも触れています。ただし顧客向け回線では、つながらない回線よりもチケットのほうが優れています。
営業時間外のチケットには何を含めるべきですか？
翌朝のチームが録音を聞かずに対応できるだけの情報です。折り返し先の番号を探すために通話を聞き直さなければならないなら、そのチケットは失敗です。
| 項目 | 重要な理由 |
|---|
| 発信者名（表記を確認） | 名前を間違えた折り返しを防ぐ |
| 折り返し番号（1桁ずつ復唱） | 発信者番号が、連絡を希望する番号とは限らない |
| アカウント番号、注文番号、または参照番号 | 電話をかける前にチームが情報を調べられる |
| 用件（固定リストから選択） | キューを分類・振り分けできる |
| 詳細（1〜2文） | 実際の問題を平易な言葉で |
| 緊急度（固定リストから選択） | 朝にキューを並べ替えられる |
| 折り返しに都合のよい時間 | 無駄な初回発信を防ぐ |
| エージェントが約束した内容 | チームが約束を守れるように |
| 通話ID | チケットを文字起こしと録音に紐づける |
Retellでは、エージェントはExtract Dynamic Variableツールを使って通話中に回答を保存でき、{{call_id}}はすべての通話で利用可能です。チケットの作成方法は2つあります：
- 通話中：Zendesk連携のCreate Ticketツール、Salesforce、HubSpot、Microsoft Dynamics 365、GoHighLevel、Zoho CRMのCreate Taskツール、または自社ヘルプデスクのAPIを呼び出すカスタム関数を使います。発信者が電話を切る前に、チケットが作成されたことをエージェントに確認させたい場合はこの方法を選びます。
- 通話後：エージェントのWorkflowページにある通話後関数（post-call function）はPost Call Extractionの後に実行されるため、通話の要約や抽出した項目を含めることができます。条件で実行を制御し、たとえば
ticket_needed項目がtrueの場合のみ実行するようにします。call_analyzed webhookを使えば、自社サーバーから同じ処理を行えます。
Post Call Extractionはテキスト、数値、はい/いいえ、固定選択肢の項目に対応しており、用件や緊急度の管理に適しています。トリガーと書き戻しのパターン全体については、CRMワークフローがAI通話をトリガーし、結果を書き戻す仕組みをご覧ください。
エージェントは発信者に何を約束すべきですか？
「近日中に担当者からご連絡します」ではなく、「明日の午前10時までに」のように、チームが実際に守れる折り返しの時間枠です。そのうえで詳細を復唱し、発信者が訂正できるようにします。
約束の範囲は狭く保ちます。Retell自身の営業時間外受付のサンプルでは、料金、予約時間、技術者の空き状況を約束しないようエージェントに指示しています。確認メッセージをテキストで送りたい場合は、RetellのSend SMSツールで通話中に送信できます。カスタムメッセージの本文を送るにはA2P申請を通じてSMSが有効化された番号が必要で、エージェントは事前に同意を得る必要があります。
朝のチームは営業時間外のキューをどう処理すべきですか？
キューには担当者1人と期限を設け、電話受付開始前に緊急のチケットを片付けます。始業時に電話が集中する回線の場合、夜間のキューがそれと競合しないようにすべきです。
効果的な運用ルーティン：
- 毎朝、営業時間外キューの担当者またはチームを1つ指名します。
- 緊急度順、次に経過時間順に並べます。緊急のものから、可能であれば回線が開く前に折り返します。
- エージェントが約束した時間枠内に電話します。守れなければ、発信者はその約束に意味がないと受け止めてしまいます。
- 折り返しに応答がなければ、メッセージを残し、試行をチケットに記録して、もう一度だけかけ直します。次の通話で発信者に最初から説明させないようにします。
- 結果を記録してチケットをクローズします。そうすれば、営業時間外のチケットのうち最初の折り返しで解決した割合を把握できます。
- 週に一度、用件を確認します。営業時間や注文状況など繰り返し寄せられる質問は、エージェントのナレッジベースや照会機能に組み込むべきです。そうすれば、エージェントが夜間にチケットなしで回答できます。
AIエージェントで折り返す場合は、チケットの項目を動的変数としてアウトバウンド通話に渡し、発信者が同じ質問を二度されないようにします。アウトバウンド通話には、同意と発信時間に関する独自のルールがあります。詳しくはアウトバウンドAI音声通話のためのTCPAガイドをご覧ください。
営業時間外でも、すぐに担当者につなぐべき電話はどんなときですか？
朝まで待つことで損害が生じる場合や、会社として受け入れないと決めたコストが発生する場合で、かつ事前に書き出した状況に限ります。発信者が生命に関わる緊急事態を訴えた場合、エージェントは電話を切って911または地域の緊急通報番号にかけるよう伝えるべきです。オンコール担当者は緊急サービスではありません。
営業時間外の呼び出しトリガーとして典型的なのは、物件での安全上のリスク（ガス臭、浸水、氷点下での暖房停止）、プロトコル上待てない臨床上の懸念、サービス契約の対象となる生産ラインや出荷の停止、または方針上必ず担当者が対応するアカウントです。それ以外はすべてチケットにします。
緊急分岐は、気づかれないまま失敗することがないよう構築します：
- 今夜のオンコール担当者にルーティングする。転送先を
{{on_call_number}}のような動的変数に設定し、インバウンドwebhook経由でオンコールスケジュールから値を入力します。番号はエージェントの編集ではなく、当番表に合わせて変わります。 - 確実に人が応答するようにする。人間検知を有効にしたウォームトランスファー（事前取次）を使い、人が検知された場合のみ発信者をつなぎます。公開前に、オンコール用電話の留守番電話に対してテストしてください。エージェント型ウォームトランスファー（agentic warm transfer）ではさらに一歩進み、転送エージェントがオンコール担当者に電話して状況を説明し、対応可能な場合のみ発信者をつなぎます。
- 応答がない場合に備える。会話フローでは、通話転送ノードに転送失敗時のエッジがあります。その経路で、緊急チケットを作成する、Send SMSでバックアップ番号に詳細を送る、またはカスタム関数で呼び出しツールを起動します。そのうえで、この後どうなるかを発信者に正直に伝えます。
Retellのアラート機能はこの用途には適していません。アラート機能は通話量や成功率などの集計指標を監視するものです。通話ごとのエスカレーションは、通話そのものかwebhookで処理すべきです。
公開前に、呼び出すべき通話と呼び出すべきでない通話のシミュレーションで緊急分岐をテストしてください。後者は前者と同じくらい重要です。日常的な電話で起こされるオンコール体制は、やがて応答しなくなるからです。どのような通話を人に引き継ぐべきかという広い問題についてはAIエージェントが人間のエージェントに引き継ぐタイミングを判断する仕組みを、転送の仕組みについてはAI音声エージェントと人間のチーム間で通話転送が機能する仕組みをご覧ください。
約束を守る営業時間外対応を構築する
優れた営業時間外対応は、ルール、チケット、そして短い緊急リストで構成されます。ルールは、誰も受けられない転送をエージェントが提案するのを防ぎます。チケットは、朝のチームに必要な情報をすべて提供します。緊急リストは、待てない数少ない電話が確実に人に届くようにします。Retell AIは、時間ベースの動的変数、インバウンドコールwebhook、チケットおよびタスクツール、人が応答するまで待つウォームトランスファーで、それぞれを支援します。詳しくは営業時間外のAI電話応答サービスのページをご覧ください。
