ウォームトランスファーは、最初の担当者が次の担当者に発信者を紹介してからつなぐ転送方法です。「Danaさん、Samさんからのお電話です。注文4471の代金が二重に請求されていて、本人確認は済んでいます」。そのあと最初の担当者は抜けます。コールドトランスファーでは、紹介なしで次の担当者やキューに直接つながり、Samさんはすべてをもう一度説明することになります。
違いはひとつだけです。電話に出る人が、発信者の用件をすでに知っているかどうか。このガイドでは、電話システム上でそれぞれの転送がどう動くか、どちらを使うべきか、そのまま使えるウォームトランスファーのスクリプト、そして最初の担当者がAI音声エージェントになると何が変わるかを説明します。コンタクトセンターの責任者と、通話フローを構築するエンジニアに向けた内容です。
ウォームトランスファーとコールドトランスファーの比較
| ウォームトランスファー | コールドトランスファー | |
|---|---|---|
| 別名 | 取次転送、アナウンス付き転送、相談転送 | ブラインド転送、直接転送 |
| 発信者に聞こえるもの | 保留のあと紹介 | 呼び出し音のあと新しい声 |
| 受け手が知っていること | 最初の担当者から聞いた用件 | 画面に表示される情報(何もないことも多い) |
| 最初の担当者の時間 | 相談通話と紹介で、1分以上かかることが多い | 数秒 |
| リスク | 担当者同士が話す間、発信者が保留で待つ | 発信者がすべてを繰り返す、または違うキューに入る |
| 向いている場面 | エスカレーション、苦情、営業の引き継ぎ、複雑な案件 | 単純な振り分け:請求、営業時間、決まった部署 |
3つ目の方法もあります。カンファレンス転送では、最初の担当者が次の担当者を発信者との通話に加え、その場で紹介してから抜けます。これもウォームトランスファーと呼ぶチームがあります。発信者は引き継ぎを直接聞けるので安心感がありますが、3つの中で最も担当者の時間がかかります。
電話システム上でのそれぞれの仕組み
コールドトランスファーは、電話システムへのひとつの指示です。「この通話をあの宛先に送れ」。SIPベースのシステムでは、担当者側がSIP REFERリクエストを送り、通信事業者やPBXに発信者を別の宛先へつなぐよう依頼し、最初の担当者の通話区間は終わります。宛先が応答しない場合にどうなるかは、宛先側のルール次第です。留守番電話、キュー、または切断です。
ウォームトランスファーは3つのステップです。
- 最初の担当者が発信者を保留にします。
- 最初の担当者が次の担当者に2本目の電話(相談通話)をかけ、要件を伝えます。
- 最初の担当者が転送を完了します。電話システムが発信者を2本目の通話につなぎ、最初の担当者を外します。
SIPシステムでは、ステップ3はReplacesヘッダー付きのREFERで、相談通話を発信者の通話に置き換えるよう指示します。RFC 5589にはブラインド転送と取次転送の両方の流れが載っています。コンタクトセンターの運営にRFCは必要ありませんが、テストでは動いた転送が別の通信事業者で失敗するときに役立ちます。
次の担当者が相談通話に出なければ、最初の担当者は発信者のもとに戻って別の選択肢を案内します。これがウォームトランスファーの隠れた利点で、誰も沈黙の中に放り出されません。
ウォームトランスファーを使うべき場面
詳細を繰り返させると発信者が怒りそうなとき、または次の担当者がその情報なしでは動けないときに使います。
- エスカレーションと苦情。 一度説明した人は、スーパーバイザーに同じ話をしたくありません。
- 営業の引き継ぎ。 見込み度の高い顧客を営業担当に渡すときは、「お待ちください」ではなく「40台の配送車両のことはPriyaに伝えてあります」と聞こえるべきです。
- 本人確認済みの発信者。 本人確認が済んでいるなら、そう伝えて、次の担当者が繰り返さないようにします。
- 少数の専門担当者。 宛先が1人だけなら、発信者を送る前に対応できるか確認します。
宛先が予測でき、文脈があまり重要でないときはコールドトランスファーを使います。請求窓口、店舗、ひとつの用件だけを扱う部署などです。受け手のソフトウェアがすでに発信者の情報を表示する場合も、システムが紹介役になるのでコールドトランスファーで十分です。
ウォームトランスファーのスクリプト
要件は短くまとめます。受け手に必要なのは4つ。誰からか、何を求めているか、すでに何をしたか、何が残っているかです。
保留の前に、発信者へ:
「請求担当の部署なら直接返金できます。請求担当のDanaにつないで、状況を説明しておきますので、もう一度お話しいただく必要はありません。1分もかからない短い保留になりますが、よろしいですか?」
相談通話で、受け手の担当者へ:
「Danaさん、Sam Ortizさんからのお電話です。注文4471の代金86ドルが2回請求されています。本人確認と二重請求の確認は済んでいます。2回目の請求の返金をご希望です。対応できますか?」
発信者のもとに戻って:
「Samさん、請求担当のDanaにつながりました。詳細はすでに伝えてあります。Danaさん、お願いします」
Danaさんが対応できない場合は、Samさんを一般のキューに送るのではなく、折り返しの時間を伝えましょう。
最初の担当者がAI音声エージェントの場合
最初の応対を音声エージェントが担う割合が増えているため、多くのコールセンターでは今やAIから人への転送が最も一般的です。ウォームトランスファーの考え方はそのまま通用しますが、仕組みは変わります。
人がウォームトランスファーをするとき、相談通話の大半は文脈を伝えることに費やされます。音声エージェントは会話全体をすでにテキストとして持っているので、文脈をデータとして送り、相談通話を省けます。こうすれば、ウォームトランスファーの主な利点である「事情を知っている担当者」を、保留時間なしで得られます。ただし、受け手が実際にその文脈を目にする場合に限ります。チケット、CRMの記録、担当者デスクトップのポップアップなど、受け手が見る場所に置きましょう。
AIから人への良い引き継ぎは、次の4つを行います。
- 何が起きるかを発信者に伝える。 「請求担当におつなぎします。要約を送ってありますので、最初から説明し直す必要はありません」
- 先に要約を書く。 電話の用件、確認済みの事項、発信者がまだ必要としていること。要約は転送の後ではなく前に送ります。
- 用件に応じて振り分ける。 請求の質問は請求担当へ、怒っている発信者はスーパーバイザーのキューへ。間違った宛先への転送は、転送しないより時間を無駄にします。
- 代わりの手を用意する。 転送に失敗した場合やキューが閉まっている場合、エージェントは通話を続け、折り返しを提案します。
転送は、発信者があきらめやすい場面でもあります。月に約300万件のAI通話を処理する2X Solutionsは、Cartesiaに切り替えたあと、転送前の切断率を3.4%から1%未満に下げました。同時に音声のレイテンシーも500〜900ミリ秒から100ミリ秒未満になっています。引き継ぎの前に遅い応答を待たされた発信者は、人につながる前に電話を切ってしまうことがよくあります。
Cartesia Managed Agentsで転送を設定する方法
Cartesia Managed Agentsでは、転送にtransfer_to_numberシステムツールを使います。転送そのものはSIP REFERによるコールドトランスファーで、先に文脈を送ることで引き継ぎをウォームにします。
- 転送ルールを追加する。 PlaygroundでToolsを開き、Transfer callを有効にします。各ルールには宛先(E.164形式の電話番号、SIP URI、または
{{transfer_number}}のような動的変数)と、いつ使うかをモデルに伝える条件(例:「The caller has a billing or payment question.」)を設定します。 - エージェントに先に話させる。 転送ツールの
pre_tool_speechをforceに設定すると、エージェントは黙って呼び出し音を鳴らすのではなく、必ずこれから何が起きるかを発信者に伝えます。 - Webhookツールで要約を送る。 通話の要約をチケットシステムやCRMに投稿するWebhookツールを作成します。エージェントのプロンプトで、転送の前にそのツールを呼び出すよう指示します。
- 必要なら発信者ごとに振り分ける。 動的変数を使えば、通話ごとに宛先を設定できます。たとえば、通話開始時にCRMから取得した、その顧客の担当アカウントマネージャーです。
- 失敗時の動きをテストする。 転送にはTwilioまたはSIPトランク経由の電話通話が必要で、SIP URIの宛先にはSIPトランクが必要です。通信事業者が宛先の種類に応じたREFERを受け付ける必要があります。SIPトランクでは、通信事業者が転送を拒否してもCartesiaは元の通話をつないだままにするので、その場合にエージェントが何と言うべきかをプロンプトに書いておきましょう。
{
"config": {
"system_tools": {
"transfer_to_number": {
"pre_tool_speech": "force",
"transfers": [
{
"destination": { "type": "phone", "phone_number": "+14155550100" },
"condition": "The caller has a billing or payment question."
},
{
"destination": {
"type": "phone",
"phone_number": "{{account_manager_number}}"
},
"condition": "The caller asks for their account manager."
}
]
}
}
}
}
設定したら、実際の電話からその番号にかけ、人と話したいと伝え、電話に出た担当者の画面に何が表示されるかを確認しましょう。画面が空なら、設定がどうであれ、その転送はコールドです。
発信者を失う転送のミス
| ミス | 発信者が経験すること | 対策 |
|---|---|---|
| 予告なしに転送する | 沈黙のあと呼び出し音 | 転送先と理由を毎回伝える |
| 受け手に文脈が届かない | 最初から話し直す | 受け手が見る場所に要約を書く |
| 閉まっているキューに転送する | 留守番電話か切断 | 転送前に営業時間や空き状況を確認する |
| 失敗時の代わりの手がない | 無音の回線 | 通話を続け、折り返しを提案する |
| 相談通話が長い | 数分間の保留 | 要約を「誰が・何を・済んだこと・次」に絞る |
| 早すぎる転送 | エージェントで解決できた用件を人が対応する | 用件ごとの転送率を測り、上位から改善する |
転送も通話の他の部分と同じように測定しましょう。転送された通話の割合、転送がつながる前の切断、そして受け手が発信者に何かを繰り返してもらう頻度です。最後の指標が、転送が本当にウォームかどうかを最も直接的に示します。
試すには、Cartesiaのplaygroundでエージェントを作成し、転送ルールを追加して電話をかけてみてください。AI電話エージェントのページでは、電話番号、発信、転送について説明しています。