利用可能状況を管理する
電話を受け付ける準備ができたら、チャネルの利用可能状況をAllまたはPhoneに設定する必要があります。
通話が入っているのに応答できない場合は、その時点でAllまたはPhone以外のチャネルが選択されているためです。
左下のアバターをクリックし、Availabilityをクリックして、利用可能なチャネルを指定してください。
All: ワークスペースが提供するすべてのチャネルで利用可能になります。
Chat: Messenger、WhatsApp、Telegram、Instagram、Discord、その他の電話、メール、SMS以外のチャネル。
Email: メールの会話のみ。
SMS: SMSの会話のみ。
Phone: 着信電話のみ。
注意: チャネルの利用可能状況は、Load Balanced Assignment (LBA)を使用している場合のみルーティングに影響します。ラウンドロビン割り当ては既存の利用可能値を変更せずに使用し続けます。ドロップダウンには同じチャネルオプションが表示されますが、Email、SMS、Chatはそれぞれラウンドロビン割り当ての会話値にマッピングされます。そのため、ラウンドロビン割り当てではチャネルベースのルーティングは利用できません。
Inboxでステータスがアクティブで、電話またはすべてのチャネルに利用可能な場合、Inboxに割り当てられた通話の通知を受け取ります。その後、以下の選択が可能です。
応答 - 通話を受け入れ、顧客に接続します。
拒否 - 顧客を保留にし、別のチームメンバーに通話対応を通知します。
詳細を見る - Inboxで通話を表示し、顧客の詳細やワークフローで選択したオプションを確認します。
Inboxからの通話対応について詳しく学びましょう。
通話中はステータスが自動的にAwayに切り替わり、理由は「通話中」となります。Reassign repliesをオンにすると、通話中に会話の返信が再割り当てされます。
注意: これはMessengerのウェブ/ビデオ通話には適用されず、電話通話のみです。Messengerのウェブ/ビデオ通話の場合、チームメンバーのステータスは自動的に「Away」にはならず、現在その設定を変更する方法はありません。
あなたまたは顧客が通話を終了すると、ワークスペースの電話設定に応じて、Inboxで会話を処理するためのラップアップ時間が与えられることがあります。
ラップアップ時間中はステータスがAwayに更新され、理由は「通話ラップアップ」となります。Switch to activeを選択すると、ラップアップ時間を早期に終了し、新しい着信通話に対応可能になります。
バランス割り当て
電話のバランス割り当ては、通話を割り当てる適格なチームメンバーを見つけるために以下を確認します。
電話の利用可能状況（チャネルが「All」または「Phone」に設定されており、チームメンバーが「Active」でInboxがタブで開かれている）。
各チームメンバーの最後に割り当てられた会話の日付（電話またはその他の会話）。バランス割り当てでは会話数は考慮されません。
チームメンバーが通話中かどうかに関わらず、1件のアクティブな通話が割り当てられている場合、通話割り当ての上限に達していると見なされます。
重要:
電話通話はチームが別の割り当て方法に設定されていても、常にバランス割り当てを使用します。これは変更できません。
チームメンバーが通話を逃したり拒否した場合、その通話の再割り当てから5分間一時的に除外されます。この間、その通話に関するさらなる通知は届きません。このクールダウン期間は、既に逃したり拒否した通話の通知が繰り返されるのを防ぎます。
バランス割り当てはテストワークスペースでは機能しません。
チームメンバーの介入なしに着信通話を自動応答する
チームメンバーの介入なしに着信通話を自動応答したい場合は、Phoneチャネルのワークスペース設定で有効にしてください👇
重要: 自動応答モードが有効な場合、チームメンバーは着信通話を手動で拒否できません。通話はチームメンバーの操作なしに自動的に応答され、拒否オプションは利用できません。自動応答モードは通話回避を防ぐために設計されています。
会話ログの拒否イベントについての注意: 自動応答が有効でも、チームメンバーが通話割り当て直前にステータスをAwayに切り替えた場合、会話ログに「通話拒否」イベントが表示されることがあります。この場合、システムはステータス変更を拒否として記録しますが、これはチームメンバーが手動で拒否ボタンを押したわけではありません。これは期待される動作であり、自動応答が回避されたわけではありません。また、自動割り当て中にチームメンバーがInboxページから離れたり閉じたりした場合も同様に拒否として記録されます。離脱時に確認モーダルが表示されるため、拒否ボタンを押さずに通話を拒否する正当な方法と見なされます。
チームの利用可能状況を表示・管理する
特定のチームメンバーのPermissionを設定して、個別のチームメンバーやロールへの通話の割り当てや受信を制限・防止することはできません。通話を受け取る資格のある「active」ステータスのチームメンバーは、たとえ「Can listen on calls」権限が無効でも、Balanced Assignmentプロセスに含まれます。
Inboxのダッシュボードから、チームメンバーのステータスをリアルタイムで監視したり、チャネルの利用可能状況（All、Conversations、Phone）を変更したりできます。
このダッシュボードは、キュー内の通話、アクティブな通話、ボイスメール、折り返し通話など、電話のメトリクスをリアルタイムで表示し、チームの通話対応状況を把握できます。
チームテーブルには電話に関連する行もあり、興味のあるメトリクスだけを素早く表示するようカスタマイズできます。
Teammateタブに切り替えると、「Teammate talk time」メトリクスが表示されます。
通話キューが長い場合は、チームメンバーのChannel利用可能状況をPhoneまたはAllに変更して、より多くのメンバーを通話対応可能にできます。
過去の通話に対するチームの利用可能状況を表示する
通話が割り当てられた瞬間のチームの利用可能状況のスナップショットを確認できます。これにより、なぜ特定のチームメンバーに通話がルーティングされたのか、または見逃されたのかを理解できます。
注意: この設定Show team composition in conversation event logはデフォルトで無効になっており、手動で有効にする必要があります。
チームの利用可能状況ログを有効にする
設定 > チャネル > Phone > チーム構成情報に移動してください。
Show team composition in conversation event logをオンに切り替えます。
イベントログの理解
有効にすると、会話ログに以下の詳細イベントが表示されます。
何人のチームメンバーがAvailableだったか。
何人がAwayでした。
何人がアクティブでしたがInboxにいませんでした。
明示的な応答および拒否イベント
会話ログは手動操作と接続切断を明確に区別しているため、チームメンバーの行動を正確に追跡できます。拒否イベントは、チームメンバーが通話が割り当てられる直前にAwayステータスに切り替えた場合にもログに表示されることがあります。これはAuto-answerが有効で手動拒否がなかった場合でも同様です。これは活動ステータスの変更によるもので、通話の意図的な拒否ではありません。
明示的な拒否: チームメンバーがDeclineをクリックすると、特定のイベントとしてログに記録されます。これは接続エラーによる切断ではなく、通話が手動で拒否されたことを確認します。
明示的な応答: チームメンバーがAnswerをクリックすると、イベントは即座にログに記録されます。これは接続がすぐに失敗しても通話を取ろうとしたことを確認します。
通話ログのイベントタイプ
すべての通話は会話のタイムラインにイベントを生成します。各イベントの意味は以下の通りです。
主要な通話イベント
イベント | 意味 |
通話応答済み | チームメンバーが通話に応答しました。チームメンバーの名前が表示されます。 |
通話拒否 | チームメンバーが意図的にDeclineボタンを押しました。「Call declined by [name] using the Decline button.」として表示されます。 |
通話拒否（ビジー） | チームメンバーが別の通話中（ビジー信号）か接続障害がありました。どちらも「Call declined by [name]」として表示され、Declineボタンの表記はありません。タイムラインだけでは正確な原因は不明です。 |
通話不在 | 割り当てられたチームメンバーに通話が鳴りましたが、応答せずタイムアウトしました。「Call missed by [name].」として表示されます。 |
応答前に通話終了 | 顧客がキューで待機中または通話が鳴っている間に切断し、チームメンバーが応答する前に終了しました。「Call ended by customer before a teammate answered.」として表示されます。 |
通話転送 | システムが通話をキューに入れず自動的に転送しました。必ず転送理由が含まれます。以下参照。「Call deflected because [reason].」として表示されます。 |
チームメンバー参加 | スーパーバイザーがバージ機能を使い、監視や支援のために通話に参加しました。「[name] joined the call.」として表示されます。 |
手動応答要求 | チームメンバーが自動割り当て前に共有割り当てプールから通話を取得しました。「Manual answer requested by [name].」として表示されます。 |
放棄された通話割り当て | 顧客が既に切断した後にシステムが通話割り当てを試みました。「Started assignment after call ended without an assignee.」として表示されます。 |
注意: 「Call declined by [name]」に「using the Decline button」がない場合は意図的に曖昧にしており、ビジー信号と接続障害の両方を含みます。特定の通話の正確な原因を調査する場合はFinサポートに連絡してください。
通話転送理由
通話が転送されると、イベントには以下の理由のいずれかが含まれます。
理由 | 意味 |
キューが満杯 | インバウンドキューが設定された最大サイズに達しました。「Queue is longer than [max] calls.」として表示されます。 |
利用可能なチームメンバーなし | 通話を受けるためにオンラインで利用可能なチームメンバーがいませんでした。 |
ワークスペースが不在設定 | ワークスペース全体が不在設定または営業時間外でした。 |
チームが不在設定 | 通話がルーティングされた特定のチームが不在設定でした。「[team name] is out of office.」として表示されます。 |
保留タイムアウト超過 | 顧客が設定された最大保留時間を超えて待機しました。「Customer has been waiting on hold for more than [X] minutes.」として表示されます。 |
チームの利用可能性ログエントリ
ワークスペースでチームの利用可能性ログが有効な場合、通話が入った瞬間のチームメンバーの利用可能状況を示す3つの追加エントリが通話タイムラインに表示されます。
ログエントリ | 意味 |
チームメンバーがAway: N | 通話が入った時点でN人のチームメンバーが「away」ステータスでした。 |
電話クライアントがアクティブでないが利用可能なチームメンバー: N | N人のチームメンバーは「available」とマークされていましたが、ブラウザのタブが閉じられているかバックグラウンドになっており、通話を受け取ることができませんでした。 |
利用可能なチームメンバー: N | N人のチームメンバーがアクティブな電話クライアントでオンラインで、通話を受ける準備ができていました。 |
通話の指標と定義
以下の表を使用して、特定の通話指標と定義を確認してください。
名前 | 場所 | 定義 |
キュー内の着信通話 | Inboxesダッシュボード: サマリーカード＆テーブル | キューで保留中の着信通話の合計数 |
アクティブな着信通話 | Inboxesダッシュボード: サマリーカード＆テーブル | 現在アクティブな状態で進行中の通話の合計数。これには通話中（話している状態）およびチームメンバーによって保留にされた通話が含まれます。 |
完了した着信通話 | Inboxesダッシュボード: サマリーカード＆テーブル | チームメンバーが応答し、正常に完了した着信通話の合計数。 |
放棄された着信通話 | Inboxesダッシュボード: サマリーカード＆テーブル | ルーティング中、キュー内、保留中、またはボイスメール中に顧客が通話を放棄したために失われた着信通話の合計数。 |
応答なし | Inboxesダッシュボード: サマリーカード＆テーブル | チームメンバーの電話が鳴ったが応答されなかった通話、または外部番号に転送されたが応答されなかった通話。 |
ボイスメール通話 | Inboxesダッシュボード: サマリーカード＆テーブル | ボイスメールがある通話の合計数。ボイスメールで放棄された通話は含まれません。 |
通話時間 | Inboxesダッシュボード: サマリーカード | 顧客が通話をかけてから終了するまでの通話の合計時間。
着信通話の時間は、顧客が通話を開始してから終了するまでの時間（ルーティングおよびキューイング時間を含む）です。
発信通話の時間は、顧客が通話に応答してから終了するまでの時間です。 |
通話応答時間 | Inboxesダッシュボード: サマリーカード＆テーブル | 顧客が通話をかけてからチームメンバーが最初に応答するまでの時間。
これには、顧客がIVRワークフローで通話をルーティングされ、通話がチームに割り当てられた後にキューで保留される時間が含まれます。 |
電話対応可能なチームメンバー数 | Inboxesダッシュボード: サマリーカード＆テーブル | 電話対応可能、または電話通話を積極的に処理しているチームメンバーの数。
チームメンバーが電話対応可能である条件:
|
チーム通話のキュー時間 | Inboxesダッシュボード: テーブル | 顧客が割り当てられたチームのキューで過ごした時間。
各チームキューのセグメントは別々にカウントされます。例えば、同じ通話が同じチームに複数回転送された場合、それらのキュー時間は別々にカウントされます（通話ごとに合算されません）。 |
チーム通話の通話時間 | Inboxesダッシュボード: テーブル | チームに割り当てられている間、すべてのチームメイトが通話中に話している時間の合計。 |
チームメイトの通話トーク時間 | チームメイトダッシュボード：サマリーカード＆テーブル | 個々のチームメイトが通話中に話している時間。 |
チャネルの利用可能性 | チームメイトダッシュボード：テーブル | チームメイトのチャネル利用可能性を示します：All、Chat、Email、SMS、Phone、またはその組み合わせ。 |
Calls reportからさらに詳細なインサイトを得るか、通話メトリクスを使ってカスタムレポートを作成してください。
顧客側でボイスメールに繋がる発信通話は応答済みとみなされます。発信通話システムは顧客が通話に出たのかボイスメールが応答したのかを区別できないためです。
よくある質問
電話通話で「Inbox Assignment」と「Agent Assignment」の間に約40秒のギャップがあるのはなぜですか？
「Inbox Assignment」と「Agent Assignment」のタイムスタンプ間の約40秒のギャップは想定された動作です。このギャップはIntercomと電話サービスプロバイダー間の技術的なハンドシェイクを反映しており、IVR設定、録音された挨拶、または通話ルーティングの設定によるものではありません。
約40秒の内訳は通常以下の通りです：
約30秒 — システムが利用可能なチームメイトに接続を試みる着信タイムアウト時間
約10秒 — ルーティングロジックとシステムのタイムスタンプ更新の標準処理時間
注意：「Inbox Assignment」のタイムスタンプは通話が最初にInboxにルーティングされた時に記録されます。「Agent Assignment」のタイムスタンプは特定のチームメイトが通話を受け入れた時に記録されます。この間のギャップは通話ルーティングの正常な流れの一部です。