Zendesk Talkの不在着信通知：2026年版完全ガイド

すべての不在着信は、潜在的な顧客の喪失を意味します。誰かがあなたのビジネスに電話をかけ、ボイスメールに送られた（あるいは最悪の場合、話し中だった）瞬間から、カウントダウンが始まります。調査によると、電話に応答がなかった顧客の85%は二度とかけてきません。彼らはリストにある次の選択肢へと移ってしまいます。

コールセンターでZendesk Talkを使用している場合、不在着信を追跡し、対応するための信頼できる戦略が必要です。問題は何でしょうか？ 多くのサポートチームは、基本事項で苦労しています。「不在着信（missed call）」と「不在着信レグ（missed call leg）」の違いの理解、データの確認場所の特定、そして機会を逃さないためのプロアクティブな通知の設定です。

このガイドでは、2026年におけるZendesk Talkの不在着信通知について知っておくべきすべてのことを解説します。用語の混乱を解消し、ネイティブのZendeskツールを使用して不在着信を追跡する正確な方法を示し、基本的なレポート以上の機能を必要とするチームのためのより良いアプローチを探ります。

Zendesk Talkにおける不在着信の理解

ダッシュボードやレポートについて詳しく説明する前に、よくある混乱の原因を解消しておきましょう。Zendesk Talkでは、応答されなかった通話について話す際、「不在着信（missed calls）」と「不在着信レグ（missed call legs）」という、関連はあるものの異なる2つの用語を使用します。

不在着信通知とは何か？

不在着信通知とは、顧客が電話で連絡を取ろうとしたが繋がらなかったことを、あなた（またはあなたのチーム）に知らせるアラートです。理想的な世界では、これらの通知は即座にトリガーされ、顧客がまだあなたのビジネスのことを考えている間に折り返し電話をかけるチャンスを与えてくれます。

Zendesk Talkの課題は、ネイティブなプロアクティブの不在着信通知を提供していないことです。代わりに、パッシブな追跡が行われます。システムは何が起こったかを記録しますが、不在着信について知るには、ダッシュボードを能動的に確認するか、レポートを実行する必要があります。通話量が多いチームにとって、これは電話を逃してから誰かが実際に気づくまでの間にギャップを生じさせます。

不在着信と不在着信レグの違い

ここからが少し複雑になります。Zendeskは通話を2つのレベルで追跡します。

**通話（A call）**は、開始から終了までの電話のやり取り全体を表します。顧客がダイヤルしてから電話を切るまでに起こるすべてが含まれ、エージェントと話さなかった場合も含まれます。Zendeskの用語で「不在着信」とは、インタラクション全体が応答されなかったことを意味します。顧客が電話を切った、ボイスメールを残した、または誰にも繋がらずにキューを放棄した場合です。

**通話レグ（A call leg）**は、その通話の特定のセグメントです。システムがエージェントに通話をルーティングするたびに、新しい通話レグが作成されます。エージェントAが応答せず、通話がエージェントBにルーティングされた場合、それは2つの別々の通話レグになります。「不在着信レグ」は、最終的に別のエージェントが応答したとしても、特定の担当者にコールが提供された際に応答しなかったことを意味します。

この区別が重要なのは、1つの通話に複数の不在着信レグが存在する可能性があるからです。誰かが応答する前に4人の異なるエージェントに電話が鳴った場合、レポートには4つの不在着信レグが表示されますが、完了した通話は1つだけです。これが、エージェントが実際には呼び出し音を聞いていない通話を「逃した」という混乱を招く数字を目にする理由です。

あるZendeskコミュニティメンバーは次のように述べています。「私のチームでも同じ問題が発生しています。エージェントが応答した1つの通話レグに対して、20回以上の不在着信が記録されています。エージェントが一度も逃していない通話に対して、不在着信レグが複数回記録されているため、現在は手動でレポートを検証しなければなりません。」

この違いを理解することは、正確なレポート作成と公平なパフォーマンス評価のために不可欠です。

Zendesk Talkで不在着信を追跡する方法

Zendeskは不在着信時にプロアクティブな通知を送信しないため、どこを確認すべきかを知っておく必要があります。このデータを追跡する主な方法は2つあります。リアルタイムのTalkダッシュボードと、過去のExploreレポートです。

Talkダッシュボードの使用

Talkダッシュボードでは、コールセンターで今何が起きているかをライブで確認できます。管理者と権限を持つエージェントは、現在のキューのアクティビティ、その日のアカウント全体のメトリクス、個々のエージェントのステータスを確認できます。

ダッシュボードを表示するには：

1. 管理センターで、サイドバーの [チャネル] をクリックし、[Talkとメール] > [Talk] を選択します。
2. [ダッシュボード] タブをクリックします。
3. 表示したい電話番号を選択します。

ダッシュボードには、不在着信に関連するいくつかのメトリクスが表示されます：

• 不在着信の総数: その日のうちに応答されなかった通話の数
• キュー内の通話: 現在待機中の発信者数
• エージェントの対応可能状況: 誰がオンライン、オフライン、または離席中か
• 放棄された通話: エージェントに繋がる前に顧客が電話を切った通話

ここでの制限は明らかです。このデータを見るにはダッシュボードを注視している必要があります。不在着信が発生したときに自動的にアラートが出るわけではありません。迅速にフォローアップしたいチームにとって、これは誰かが常に画面を監視していなければならないという依存関係を生みます。

Exploreでの不在着信レポートの作成

過去の分析や詳細なレポート作成には、Zendesk Exploreが必要です。ここでは、どの通話が、誰によって、いつ逃されたかを正確に示すカスタムレポートを作成できます。

Zendeskは、拒否された通話と不在着信に関する構築済みのレシピを提供しています。作成方法は次のとおりです：

1. Zendesk Exploreで、[レポート] アイコンをクリックします。
2. [新規レポート] をクリックします。
3. [Talk] > [Talk - 通話] を選択し、[レポートを開始] をクリックします。
4. [メトリクス] セクションで、[追加] をクリックします。
5. [エージェントへのコールルーティング] > [拒否された通話レグ] と [不在着信レグ] を選択し、[適用] をクリックします。
6. [行] セクションで、[追加] をクリックします。
7. 次の属性を選択します：[チケット] > [チケットID]、[通話レグエージェント] > [レグエージェント名]、[時間 - レグ開始] > [レグ - タイムスタンプ]、[通話レグ] > [レグ完了ステータス]。
8. [レグ完了ステータス] を「エージェント不在」と「エージェント拒否」のみを表示するようにフィルタリングします。
9. わかりやすい名前を付けてレポートを保存します。

このレポートは、どのエージェントが通話を逃したか、または拒否したかを通話IDに関連付けて表示するため、Zendesk Talkの不在着信通知をフォローアップできます。これらのレポートを毎日または毎週メールで送信するようにスケジュールできます。これが、Zendeskにおける真の「不在着信通知」に最も近い機能です。

理解すべき主なメトリクス：

プロアクティブな不在着信アラートの設定

現実として、Zendesk Talkには不在着信に対する組み込みのプロアクティブ通知はありません。競合する一部のプラットフォーム（不在着信の自動メール通知を提供するTalkdeskなど）とは異なり、Zendeskではこの制限を回避するための工夫が必要です。

ネイティブなZendesk Talkの制限

標準機能では、Zendesk Talkは以下のことを行います：

• ボイスメールに送られた通話に対してチケットを作成する
• Talkダッシュボードに不在着信データを記録する
• Exploreに詳細な通話レグ情報を保存する

以下のことは行いません：

• 不在着信時に即座にアラートを送信する
• 特定の担当者に不在着信があったことを通知する
• 不在着信イベントに基づいて自動ワークフローをトリガーする

これは、迅速なフォローアップを望むチームにとって大きなギャップです。有望な見込み客から電話があり、誰も応答しなかった場合、誰かがダッシュボードを確認したりレポートを実行したりするのを待つことは、その機会を完全に失うことを意味しかねません。

不在着信通知の回避策

Zendeskのネイティブエコシステム内にとどまりたい場合、選択肢は以下のとおりです：

スケジュールされたExploreレポート: 不在着信レポートを定期的な間隔（1時間ごと、1日ごと）でメール送信するように設定します。リアルタイムではありませんが、手動で確認するよりはマシです。

サードパーティのダッシュボードウィジェット: Cynapse Numericsのようなツールは、外部ディスプレイやデバイスに不在着信数を表示できるダッシュボードウィジェットを提供しています。

ボイスメールチケットのZendeskトリガ: Zendeskはボイスメールに対してチケットを作成するため、これらのチケットが作成されたときに特定のグループやエージェントに通知するトリガを設定できます。これはボイスメールが残された通話のみを対象とし、純粋な不在着信はカバーしません。

カスタムAPIインテグレーション: 開発リソースがある場合は、Zendesk APIを使用して通話イベントを監視し、Slack、メール、またはSMS経由で通知を送信するカスタムソリューションを構築できます。

これらのソリューションのどれも、多くのチームが必要とする即時性を提供しません。プロアクティブな不在着信通知がワークフローにとって不可欠な場合は、Zendeskのネイティブ機能以外の検討が必要かもしれません。

不在着信を減らすためのベストプラクティス

通知は不在着信への対応に役立ちますが、本当の目標は、そもそも不在着信を減らすことです。Zendesk自身のカスタマーサービスチームによる実証済みの戦略をいくつか紹介します：

エージェントの対応可能状況の管理

不在着信を減らす最も簡単な方法は、エージェントが対応すべき時に確実に対応できるようにすることです。Zendesk Talkは、エージェントが離席しても自動的にオフラインにはならないため、不在のエージェントに通話がルーティングされてしまうことがあります。

• 業務外のときはオフラインにする: エージェントは休憩、昼食、またはシフト終了時に手動でステータスを変更する必要があります。
• 迅速に「拒否」を使用する: エージェントが電話に出られない場合は、30秒間鳴らし続けるのではなく、すぐに「拒否」をクリックすべきです。これにより、次の対応可能なエージェントに早く通話が回ります。
• 後処理時間を賢く設定する: エージェントが通話後のタスクを完了するのに十分な時間を与えつつ、次の通話の準備ができたらすぐに後処理ステータスを終了するようにします。

コールルーティングの最適化

コールルーティングの設定方法は、不在着信率に大きな影響を与えます：

• コールの提供時間を調整する: Enterpriseプランでは、次の人にルーティングされるまでに各エージェントで電話が鳴る時間を変更できます。デフォルトは30秒ですが、繁忙期には短縮を検討してください。
• オーバーフロールーティングを設定する: メインチームが対応しきれない場合に備えて、バックアップのグループや電話番号が着信を受けられるように設定します。
• IVRを使用して通話をフィルタリングする: 自動音声応答（IVR）メニューは、発信者がセルフサービスを利用したり、適切な部署に自分でルーティングしたりするのに役立ち、メインキューの負荷を軽減します。

モニタリングとコーチング

測定されるものは管理されます：

• 不在着信レポートを定期的に確認する: パターンを探します。不在着信は特定の時間帯に集中していませんか？ 特定のエージェントの不在率が高くなっていませんか？
• チームの目標を設定する: 応答率の目標を設定し、時間の経過とともに進捗を追跡します。
• データに基づいてコーチングする: 不在着信レグのデータを使用して、追加のトレーニングやサポートが必要なエージェントを特定します。

より良いアプローチ：eesel AIが不在着信を処理する方法

ここまでお読みいただいたなら、あるテーマに気づかれたはずです。Zendesk Talkは不在着信に関する生データを提供してくれますが、プロアクティブな対応は助けてくれません。不在着信を損失ではなく機会に変えたいチームにとって、より良い方法があります。

Zendesk向けeesel AIの紹介

eesel AIは、Zendeskと併用してカスタマーサービスをよりインテリジェントに処理するAIチームメイトです。単に不在着信を記録するだけでなく、即座のアクションを支援します。

違いは、問題へのアプローチ方法にあります。Zendeskは不在着信をデータポイントとして扱います。私たちは、即座の対応が必要な機会として扱います。不在着信が発生してチケットが作成されると、私たちのAIが動き出します。チケットのトリアージ、回答の下書き、そして適切な担当者への通知を行います。

通話管理の主な機能

Zendeskのネイティブ機能のギャップを埋める方法は以下のとおりです：

AIトリアージ: 不在着信からチケットが作成されると、設定した基準に基づいて自動的に分析します。VIP顧客ですか？ 即座にエスカレーションします。緊急の問題ですか？ 優先キューにルーティングします。営業の問い合わせですか？ 営業チームに送信します。ルールを普通の言葉（自然言語）で定義すれば、AIがそれに従います。

AIコパイロット: 折り返し電話のチケットに対してエージェントがゼロから始める代わりに、過去のチケット、ヘルプセンターの記事、マクロを学習データとして使用して、最初の回答を下書きします。エージェントは確認し、必要に応じて編集して送信するだけです。これにより、応答時間が劇的に短縮されます。

SlackおよびTeams通知: 優先度の高い着信を逃した際、チームチャットでリアルタイムのアラートを受け取れます。誰かがダッシュボードを確認するのを待つ必要はありません。

スマートなエスカレーション: 不在着信をいつ、どのようにエスカレーションするかを正確に定義します。「発信者に進行中の高優先度チケットがある場合は、すぐにシニアサポートチームに通知する」といった指示をAIが理解し、実行します。

Zendesk Talkとの連携方法

インテグレーションは簡単です：

1. 数分で接続: eesel AIをZendeskアカウントにリンクします。エンジニアのリソースは不要です。
2. データから学習: 過去のチケット、マクロ、ヘルプセンターを分析し、ビジネスの文脈とトーンを理解します。
3. 不在着信がチケットをトリガー: Zendesk Talkが不在着信からチケットを作成すると、即座にそれを受信します。
4. AIが即座にアクション: ルールに基づいてチケットをトリアージし、回答を下書きし、適切なチームメンバーに通知します。
5. チームが引き継ぐ: エージェントは、ゼロから始めるのではなく、下書きされた回答と完全な文脈を持って有利にスタートできます。

その結果、折り返し電話がより迅速に、より適切な文脈で行われ、チームが手動のトリアージに費やす時間が削減されます。

期待できる効果

サポートにeesel AIを使用しているチームでは、通常以下のような効果が見られます：

• フォローアップチケットの最大81%の自律的な解決（運用が定着した場合）
• 時間短縮と応答率の向上により、2ヶ月未満の投資回収期間
• 不在着信の折り返しにおける応答時間の劇的な短縮

能動的な監視と手動の対応が必要なZendeskのネイティブツールとは異なり、私たちは日常的な作業を自動的に処理するため、チームは最も重要な会話に集中できます。

チームに適したソリューションの選択

すべてのチームにAI搭載の不在着信管理が必要なわけではありません。何が自分たちに適しているかを判断する方法を以下に示します。

Zendesk Talkのネイティブ機能で十分な場合

以下の場合は、Zendeskのネイティブ機能で十分かもしれません：

• 通話量が少ない小規模なチーム（1日数百件ではなく数十件程度）
• 営業時間中に誰かがTalkダッシュボードを能動的に監視している
• コールルーティングのニーズが単純である
• 不在着信がビジネスにとって大きな収益損失の原因になっていない

これらのケースでは、スケジュールされたExploreレポートとダッシュボードの監視で十分かもしれません。

eeselのようなAI搭載ソリューションが必要な場合

以下の場合は、eesel AIの導入を検討してください：

• 通話量が多く、不在着信が頻繁に発生する
• プロアクティブな通知が必要で、手動のチェックを待つ余裕がない
• ルーティング要件が複雑（複数のチーム、優先順位、エスカレーションルール）
• 手動のチケットトリアージや回答の下書きを減らしたい
• 不在着信が大きな収益損失や顧客満足度のリスクにつながっている

eesel AIを始める

不在着信による機会損失をなくす準備ができたら、開始は簡単です：

• 数分で接続: ワンクリックのインテグレーションで既存のZendeskにリンクします。
• ビジネスを学習: 手動のトレーニングは不要です。過去のチケット、マクロ、ヘルプセンターのコンテンツを自動的に吸収します。
• ガイダンスから開始: 新入社員と同じように、まずは監視下で開始します。送信前に下書きを確認してください。
• 自律型へレベルアップ: 実績を積むにつれて、役割を拡大します。最終的には、日常的な折り返し電話を完全に任せることも可能です。

料金は、最大3つのボットと月間1,000件のAIインタラクションを含むチームプランで月額239ドル（年払い）からとなっています。月額639ドルのビジネスプランでは、自律的なチケット処理のためのAIエージェント機能、トリアージのためのAIアクション、および無制限のボットが追加されます。