オムニチャネルルーティングでは、メール(Webフォーム、サイドカンバセーションおよびAPIによるものも含む)、コール、メッセージングからの新しいチケットとオープンチケットを、エージェントの空き状況やキャパシティに基づいてエージェントに振り分けることができます。Growthプラン以上では、チケットはサービスレベルアグリーメント違反までの時間に基づいてルーティングすることができます。Professional以上のプランでは、優先度とスキルに基づいてチケットをルーティングすることもできます。
つまり、オムニチャネルルーティングを使用すると、エージェントはすべてのチャネルに対して1つの統合されたステータスを設定することができ、重要なチケットは最も手の空いているエージェントに割り当てられることになります。この方法には次のような利点があります。
- エージェントがチケットに迅速に対応できる
- 価値の高いカスタマーからの作業(コールなど)を優先させることができる
- エージェントは自動的にチケットを割り当てられるため、チケットを探す必要がない
- エージェントにチケットを「えり好み」されないようにできる
- エージェントは複数のチケットチャネルを同時に処理できる
- 発信者の国番号やその他の属性に基づいて、特定のエージェントグループにコールをルーティングできる
キャパシティルールを使用すれば、エージェントに一度に割り当てられる作業量を制限することができます。ただし、これらのルールに関係なく、エージェントが希望すれば、これらの制限を超える作業を自分で割り当てることができます(「エージェントの仕事量を平準化するキャパシティルールの作成」を参照)。
オムニチャネルルーティングでは、エージェントがチャネルごとに個別にステータスを設定するのではなく、Support、Talk、メッセージングに共通の統合ステータスを設定することができます。Professional以上のプランでは、管理者は「ランチタイム」「会議中」など、独自のステータスを定義することも可能です。これは、エージェントのステータスとキャパシティに基づいて作業項目(コール、チケット、メッセージ)をルーティングする方法を決める際に役立ちます。詳しくは、「エージェントの統合ステータスの追加」を参照してください。
この記事では、以下のトピックについて説明します。
オムニチャネルルーティングの要件と制限事項
オムニチャネルルーティングを使用するには、セットアップして、構成する必要があります。使用を中止する場合は、この機能をオフにすることができます。
オムニチャネルルーティングを使用するにはいくつかの要件があり、注意すべき制限事項もいくつかあります。
要件
- アカウントでエージェントワークスペースがアクティブになっていること。
- Chatサブスクリプションを含むアカウントでは、ネイティブのメッセージング機能またはSunshine Conversationsもアクティブになっていること。
- オンラインチャットを使用する際にオムニチャネルルーティングをアクティブにするには、メッセージング機能をアクティブにする必要がある。Chatの限定サポートは、メッセージングおよびオムニチャネルルーティングに移行するアカウントに提供されます。
制限事項
エージェントの統合ステータスを使用するオムニチャネルルーティングには、現在以下の制限があります。
- department spaceを使用している場合は、オムニチャネルルーティングを有効にすることはお勧めしません(ブランド別にエージェントのチケットアクセスを制限することでも知られています)。有効にすることで、ルーティングの問題を引き起こす可能性があります。詳しくは「オムニチャネルルーティングでのdepartment spaceの利用(非推奨)」を参照してください。
- オンラインチャットのみを使用している場合、オムニチャネルルーティングをアクティブにすることはできません。加えて、メッセージングがアクティブになっていることも必要です。
- オムニチャネルルーティングがアクティブにされると、エージェントのステータスは最初に自動的にオフラインに設定され、その後、エージェントが自分のステータスを設定するように求められます。
- オムニチャネルルーティングでルーティングされるのは、ステータスが「新規」または「オープン」のチケットのみです。
- メッセージングの一斉送信モードおよび割り当て制限解除モードはサポートされていません。
- エージェントの統合ステータスでは、営業時間に合わせて自動的にエージェントのステータスが設定されることはありません。
- ライトエージェントにはチケットを割り当てられず、ライトエージェント自身がステータスを設定することもできません。
- Talkダッシュボード、モバイルアプリ、またはTalk APIを使用してTalkエージェントのステータスを変更する機能はサポートされていません。Talk APIを使用してエージェントのステータスを変更するインテグレーションも影響を受ける可能性があります。
- カスタムキューを使用する場合、個々のチケットの優先度に関係なく、カスタムキューからルーティングされる作業項目が、標準キューからルーティングされるすべての作業項目よりも優先されます。
- 営業時間中は、キューに入ったすべてのコールに対して、ただちにチケットが作成されます。作成されたチケットは、コールがアクティブな場合にのみエージェントにルーティングされます。放棄呼やキューの最大待機時間を超えたコールは非アクティブとみなされるため、オムニチャネルルーティングではルーティングされません。営業時間中にかかってきたコールは、コールを受けたかボイスメールに入ったかにかかわらず、着信コールになります。
営業時間外に受けたコールは直接ボイスメールに入り、そのチケットにはボイスメールのチャネルが追加されます。ボイスメールから生成されたチケットは、オムニチャネルルーティングではルーティングできません。ボイスメールに転送されたコールのチケットは、いつ受信されたかにかかわらず、件名が「ボイスメールの発信元」で始まります。
- 「放棄呼にチケットを作成しますか?」の設定は利用できなくなりました。ヒント:放棄呼から作成されたチケットを自動終了するワークフローを作成できます。
- コールの転送が有効で、エージェントが切断された場合、そのエージェントのステータスは自動的に「オフライン」になります。その結果、そのエージェントへのコールはそのエージェントの電話に転送されなくなります。
- Talkで優先電話番号を使用する場合、優先回線を参照するコールが最初にエージェントに割り当てられます。次に、関連するチケットの優先度とタイムスタンプに基づいて、コールがエージェントに順番に割り当てられます。優先回線のコールに関連するチケットの優先度は「高」です。
- Talk Partner Editionはサポートされません。Talk Partner Editionのコールをルーティングする方法は、ご利用のインテグレーションにより異なります。
- エージェントにメッセージング会話(場合によってはオンラインチャット)の割り当てをオファーする場合、チケット1件あたりのオファー先イベントが20回まで記録されます。オムニチャネルルーティングは、エージェントがチケットを受け入れるまで、必要に応じて20回を超えてチケットの割り当てをオファーし続けますが、最初の20回以降のオファーはチケットイベントログに記録されません。
- オムニチャネルルーティングでは、コールのチケットが最初に作成されたときに、トリガによってコールに追加されたスキルのみが考慮されます。その後にコールのチケットに加えられた変更は考慮されません。
- Talkチケットがエージェントに割り当てられた後、チケットが未割り当てになったり、グループに割り当て直されたりしても、オムニチャネルルーティングによって再割り当てされることはありません。メールチャネルとメッセージングチャネルの場合、チケットの再割り当ては、お客様のプランとルーティング設定に依存します。TeamプランとGrowthプランでは、メールチケットとメッセージングチケットはムニチャネルルーティングの標準キューを通じて再割り当てできますが、カスタムキューに戻すことはできません。Professional以上のプランでは、カスタムキューでメールチケットとメッセージングチケットを再割り当てするか、標準キューを使用するかを選択できます。
オムニチャネルルーティングの仕組み
オムニチャネルルーティングを使用すると、すべての作業チャネルで受信時にチケットが生成され、それらのチケットに対してトリガを実行することができます。これには、着信コールも含まれます。つまり、作業チャネルは「メール」(メール、Webフォーム、サイドカンバセーション、APIから生成されたチケットを含む)、「メッセージング」(Chatからのチケットを含むこともある)、「Talk」とラベル付けされています。オムニチャネルルーティングは、チケットを解決する過程で他のチャネルが使用された場合でも、最初にチケットを受け取ったチャネルに基づいて分類します。
チケットがルーティングの対象になると、オムニチャネルルーティングは、利用できる最初の適格なエージェントにそのチケットを割り当てようとします。その時点で適格なエージェントがいない場合、チケットはキューに挿入され、以下に基づいてルーティングされます。
- キュー:チケットが入るオムニチャネルルーティングのキューによって定義されます。オムニチャネルルーティングは、1つの標準キュー(デフォルト)やカスタムキューを1つまたは複数使用して、チケットを順序付けてエージェントに割り当てます。キューの割り当てによって、各チケットに割り当てることができるエージェントのグループが決まります。カスタムキューを使用しない場合、すべてのチケットはオムニチャネルルーティングの標準キューに入ります。
- 空き状況:エージェントがチャネル間で設定する1つの統合ステータスによって定義されます。
- 各ワークチャネルのキャパシティ:各チャネルの最大キャパシティを定義し、どのメールチケットがルーティングの対象となるかを決めておきます。
- 割り当ての方法:これはルーティング設定の割り当て方法によって定義され、すべてのチャネルとキューに適用されます。
- スキル:エージェントとチケットに割り当てられたスキルによって定義され、すべてのチャネルに適用されます。
次に、トリガを使用して、チケットをグループに割り当て、チケットの優先度を割り当て、タグをチケットに追加します。チケットに対してトリガが実行された後、オムニチャネルルーティングのカスタムキューが評価され、条件を満たす最初のキューにチケットが入れられます。オムニチャネルルーティングの標準キューを使用する場合、メッセージング会話やコールは受信するとすぐにキューに入りますが、メールチケットはキューに入る前にルーティングタグを追加する必要があります。標準キューにあるチケットは、チケットに割り当てられたグループに基づいて、適格なエージェントを識別します。オムニチャネルルーティングのカスタムキューを作成する場合、メールチケットはメッセージングの会話やコールと同じように扱われ、タグの有無に関係なく、着信するとすぐに評価され、キューと照合されます。チケットがカスタムキューのどの条件にも当てはまらない場合、チケットは標準のオムニチャネルルーティングキューに入れられ、チケットに割り当てられたグループのエージェントにルーティングされます。
チケットがエージェントに割り当てられた後、そのチケットはオムニチャネルルーティングのキューから削除されます。
次の表に、チケットがエージェントにルーティングされる流れを示します。
プラン | チケットがルーティングされる順番 |
---|---|
Suite Team |
キュー内で最も古いルーティング対象タイムスタンプを持つチケットが、最初にルーティングされます。 |
Suite Growth以上 | 管理者は、キュー内で最も古いルーティング対象タイムスタンプを持つチケットと、最も早くサービスレベルアグリーメントに違反したチケットのどちらを先にルーティングするかを設定できます。 |
Suite Professional以上 |
管理者は、最も高い優先度と最も古いルーティング対象タイムスタンプを持つチケットと、最も早くサービスレベルアグリーメントに違反したチケットのどちらを先にルーティングするかを設定できます。 スキルはキュー内のチケットの順番には影響しませんが、優先順位の低いチケットやタイムスタンプが新しいチケットが先にルーティングされ、スキルが一致するエージェントを待っているチケットがキューに残されることがあります。 |
チケットがキューの先頭に来ると、以下の項目に基づいてエージェントに割り当てられます。
- チケットグループまたはキューのグループ:
- カスタムキューを使用しない場合、オムニチャネルルーティングでルーティングを行うには、チケットがグループに割り当てられている必要があります。
- カスタムキューは、オムニチャネルルーティングで複数のエージェントグループに作業をルーティングするために使用できます。キュー内のチケットは、チケットの担当グループを無視して、キューのグループにルーティングされます。
- カスタムキューを使用すると、最初にメイングループのエージェントに作業が割り当てられます。チケットがキューの先頭に到達したときに、それらのグループに対応可能なエージェントがいない場合、オムニチャネルルーティングは、セカンダリグループまたは「フォールバック」グループで対応可能なエージェントを探します。
- エージェントが複数のキューから作業を受け取ることができる場合、オムニチャネルルーティングは、最も優先順位の高いキューから順に作業を割り当てます。
- カスタムキューに一致しないチケットは、標準のオムニチャネルルーティングキューに挿入され、チケットに割り当てられたグループに基づいてエージェントにルーティングされます。カスタムキューの条件を満たさないすべてのチャネルからのチケットは、標準のオムニチャネルルーティングキューを経由するようにグループを割り当てる必要があります。さらに、カスタムキューの条件を満たさないメールチケットにも、オートルーティングタグが必要です。
詳しくは「オムニチャネルルーティングキューについて」を参照してください。
- チャネルでのエージェントのステータス:
- メールチケット:メールでチケットを受け取るエージェントは、ステータスが「オンライン」または「離席中」である必要があります。
- メッセージングの会話:エージェントがメッセージチケットを受け取るには、ステータスが「オンライン」である必要があります。
- コール:着信コールのチケットを受け取るエージェントは、ステータスが「オンライン」である必要があります。
エージェントは、アイドルステータスのしきい値よりも長い時間アイドルステータスになると、管理者によって定義された「オフライン」または「離席中」ステータスに自動的に設定されます。さらに、エージェントがステータスを「オフライン」に設定するのを忘れた場合、次のいずれかのイベントが検出されると、エージェントのステータスは自動的に「オフライン」に設定されます。
- エージェントがサインアウトせずにエージェントワークスペースを閉じた(コンピュータまたはブラウザウィンドウを閉じたり、コンピュータをスリープさせた場合)
- ネットワーク障害により、エージェントの接続が失われた
詳しくは「オムニチャネルルーティング使用時のエージェントの統合ステータスの設定」を参照してください。
- 割り当ての方法:
-
空いているキャパシティが最大:オムニチャネルルーティングの標準の設定では、そのチャネル内で空いているキャパシティが最大のエージェントに仕事を割り当てます。
- オムニチャネルルーティングで仕事を受けるには、エージェントに空いているキャパシティが必要です。空いているキャパシティとは、そのチャネルの最大キャパシティに対して、割り当てられたオープンチケットが少ない状態を指します。詳しくは「エージェントの仕事量を平準化するキャパシティルールの作成」を参照してください。
- 適格なステータスにあり、キャパシティのあるエージェントが複数いる場合、そのチャネルで一番キャパシティのあるエージェントに割り当てられます。
- 適格なステータスにあり、当該チャネルのキャパシティが同じエージェントが複数いる場合は、当該チャネルからのチケットを割り当てられていない時間が最も長いエージェントにチケットが割り当てられます。オムニチャネルルーティングでは、再オープンされたチケットは割り当てイベントとして扱われます。
- 非アクティブなメッセージングチケット(10分以上返信なし)を割り当てるには、エージェントのキャパシティに余力があることが必要です。非アクティブなメッセージングチケットがエージェントのキャパシティにカウントされるかどうかは、ルーティング設定によって異なります。
- ラウンドロビン:そのチャネルで最も長く仕事を割り当てられていないエージェントに仕事を割り当てます。仕事を割り当てるには、エージェントに空いているキャパシティが必要です。
-
空いているキャパシティが最大:オムニチャネルルーティングの標準の設定では、そのチャネル内で空いているキャパシティが最大のエージェントに仕事を割り当てます。
- エージェントのスキル:
- エージェントは、該当するステータスと予備のキャパシティがあることに加え、チケットと同じスキルを持つことが必要です。
- スキルのタイムアウトを設定した場合、チケットがキューの先頭に到達してから指定時間内に、当該のスキルをすべて持っているエージェントが対応できない場合、オプションのスキルに関係なくチケットが割り当てられます。スキルのタイムアウトが設定されていない場合、すべてのスキルは必須として扱われ、当該のスキルを持つエージェントが対応可能になるか、コールがキュー内の最大時間に達してボイスメールに送信されるまで、チケットはキューに留まります。詳しくは「オムニチャネルルーティングでスキルを使用する」をご覧ください。
オムニチャネルルーティングのシナリオの一例を紹介します。
- 重要なVIPエンドユーザーに、解決しなければならない緊急の問題が生じました。
- VIPエンドユーザーは、メールチャネルを使用してチケットを送信します。
- アカウント管理者は、これらのチケットにオートルーティングタグを追加して、グループ、優先度、およびスキルを割り当てるトリガを設定しています。
- トリガが起動した後、エンドユーザーのチケットがオムニチャネルルーティングキューに照合され、チケットの優先度である「緊急」と、ルーティング対象タイムスタンプに基づいてキューに入れられます。
- オムニチャネルルーティングが、エージェントのスキル、ステータスおよびキャパシティに基づいてチケットのルーティング先を評価します。
- ルーティングシステムは、まず、3人のエージェントが対応可能であることを理解します。
- 次に、エージェントのうち2人がチケットに必要なスキル(ドイツ語)を持っていることを特定します。
- 最後に、この2人のエージェントのうち、メールのキャパシティが多い方のエージェントを検出し、そのエージェントにチケットを割り当てます。
オムニチャネルルーティングでのメッセージとコールの再割り当て
メッセージングの会話やコールでは、迅速な応答が求められます。そのため、オムニチャネルルーティングでは、それぞれに特別な再割り当てロジックが用意されています。チケットがキューにどのように入り、どのようにオムニチャネルルーティングによってキューを出てルーティングされるかについて詳しくは、「オムニチャネルルーティングがキュー内のチケットの順序を決める仕組みについて」を参照してください。
メッセージングの会話とチャットを再割り当てする
再割り当てのタイミングでは、元のエージェントが特定の時間しきい値内に作業を受け入れない場合、グループ内の別のエージェントにメッセージやチャットを再割り当てすることができます。デフォルトのしきい値は30秒です。Enterprise以上のプランでは、このしきい値をカスタマイズできます。
設定された時間内にメールへの対応がなかったときに自動的にメッセージを再割り当てするには、再割り当てのタイミングの設定を構成時にオンにする必要があります。この設定が有効にされていないと、ルーティングエンジンは同じエージェントに割り当てを試行し続けることになります。
着信コールを再割り当てする
コールを受けたエージェントは、コールに応答するか拒否するかを選択できます。エージェントがコールを拒否したり、30秒以内に応答しなかった場合、コールはキューに戻され、別の対応可能なエージェントに割り当てられます。このコールは、キューの最大待ち時間に達するまで、対応可能なエージェントにラウンドロビン方式でルーティングされ続けます。コールにスキルベースルーティングを使用する場合は、スキルタイムアウト設定を活用して、一致するスキルを持たないエージェントへ必要に応じてコールを「オーバーフロー」させることができます。メイングループとセカンダリグループでカスタムキューを使用して、この「オーバーフロー」動作を実現することもできます。
- 作成されてからの時間数 > (カレンダー)より小さい >1
- ステータス > より小さい > 解決済み
- チャネル > = > 電話(着信)
コール終了後、コールによって生成されたチケットはオムニチャネルルーティングキューから削除されます。コールの終了後、エージェントがチケットにさらに情報を追加する必要がある場合、検索またはビューを使用して手動でチケットを見つける必要があります。
機能の概要
オムニチャネルルーティングの範囲は広いため、ここでは簡単な機能のリファレンスを示します。
オムニチャネルルーティングでサポートされるチャネル
大まかに述べれば、オムニチャネルルーティングは、メール、メッセージング、およびコールからのチケットをルーティングするために使用することができます。しかし、ビジネスルールでは、これらのチケットのカテゴリはvia
タイプに分けられます。以下のリストは、管理センターのビジネスルール条件で表示される、サポートされている経由タイプ(「チャネル」と呼ばれる)を示しています。
- メールアドレス
- Webフォーム
- Webサービス(API)
- 終了済みチケット
- チケット共有
- Facebookの投稿
- X(旧Twitter)
- Web Widget
- モバイルSDK
- サイドカンバセーション
- 統合
- 旧バージョンのチャネルフレームワーク(任意のチャネル)
- SMSテキスト(Talk経由)
- ネイティブメッセージング
- LINE
- SMS(Sunshine Conversations経由でのみ)
- Facebook Messenger
- Telegram
- X(旧Twitter)ダイレクトメッセージ
- Google RCS
- Apple Messages for Business
- Google Business Messages
- カカオトーク
- Instagram Direct Messenger
- Sunshine Conversations API
- Chat(特定の状況下でのみサポートされる)
- 電話(着信)
- 電話(発信)
プランごとの機能の概要
オムニチャネルルーティング機能の対応状況は、プランレベルによって異なります。以下は、Zendesk Suiteのプランレベル、またはすべての個別製品のプランレベルに適用されます。
Team | Growth | Professional | Enterprise |
---|---|---|---|
メール、メッセージング、コールのチケットのルーティング | メール、メッセージング、コールのチケットのルーティング | メール、メッセージング、コールのチケットのルーティング | メール、メッセージング、コールのチケットのルーティング |
キャパシティとエージェントステータスに基づくルーティング | キャパシティとエージェントステータスに基づくルーティング | キャパシティ、エージェントステータス、スキル、およびキューに基づくルーティング | キャパシティ、エージェントステータス、スキル、およびキューに基づくルーティング |
デフォルトのエージェントの統合ステータス | デフォルトのエージェントの統合ステータス | デフォルとカスタムのエージェントステータス統合 | デフォルとカスタムのエージェントステータス統合 |
メッセージとコールを処理するエージェントのためのフォーカスモード | メッセージとコールを処理するエージェントのためのフォーカスモード | メッセージとコールを処理するエージェントのためのフォーカスモード | メッセージとコールを処理するエージェントのためのフォーカスモード |
エージェントのキャパシティを計算する際に、非アクティブなメッセージングチケットを含める/除外する | エージェントのキャパシティを計算する際に、非アクティブなメッセージングチケットを含める/除外する | エージェントのキャパシティを計算する際に、非アクティブなメッセージングチケットを含める/除外する | エージェントのキャパシティを計算する際に、非アクティブなメッセージングチケットを含める/除外する |
メッセージングチケットの自動割り当て | メッセージングチケットの自動割り当て | メッセージングチケットの自動割り当て | メッセージングチケットの自動割り当て |
キャパシティの空き状況またはラウンドロビンに基づく割り当て | キャパシティの空き状況またはラウンドロビンに基づく割り当て | キャパシティの空き状況またはラウンドロビンに基づく割り当て | キャパシティの空き状況またはラウンドロビンに基づく割り当て |
メッセージの再割り当て | メッセージの再割り当て | メッセージの再割り当て | カスタマイズ可能な再割り当てタイミング |
SLA違反の早い順、または優先度の高い順にルーティング | SLA違反の早い順、または優先度の高い順にルーティング | SLA違反の早い順、または優先度の高い順にルーティング | |
担当エージェントが不在の場合、再オープンされたチケットの再割り当て | 担当エージェントが不在の場合、再オープンされたチケットの再割り当て | ||
オムニチャネルルーティングのカスタムキュー | オムニチャネルルーティングのカスタムキュー | ||
最大5個のカスタムステータス | 最大100個のカスタムステータス |
関連記事
オムニチャネルルーティングとエージェントステータスの運用に役立つ情報は、以下の記事をご覧ください。
267件のコメント
Barry Neary
Hi 1265426639690
When it comes to support tickets (inc email and webform), you choose to only have some of them routed by using the auto routing tag
For messages, all of them will be assigned via omnichannel routing if you switch it on.
0
Elżbieta Petryka
Hi Can we use omnichanell routing only for specific group of tickets (one product or one brand) or do we have to turn it on for the whole Zendesk instance at once?
0
Barry Neary
HI 1265343108529
The only way currently to do this is to leveage the Zendesk Agent Status API to make changes to an agent status and write some type of script to call these APIs. We are currently developing a bulk edit status capabilty that you can change several agents status with one call. (cc: 1263082181109 )
0
Nico V
Hi,
not sure if this is the appropriate area but cannot find reference.
The agent status can be online, away, offline (for chats and for calls).
Is there a way to change the status from “online” to “offline”, etc. time-based? i.e. officer A is online from 09:00 to 13:00, the system automatically turns him “online” at 09:00 and o"offline" at 13:00?
Most likely someone has already replied and the answer yes, just, I cannot find how to do it.
Thank you!
Nico
0
Lara McCaleb
Hoping for some help. We have just implemented omni-channel routing of email/web/api tickets. I have some support agents who work other specialized tickets that are created via API and are assigned with a separate group. We have an automation that reopens those tickets based on the due date for followup, and those tickets are then counting toward their overall capacity to take email/web tickets.
Separately, we have an agent that manages feature requests and will have a backlog of tickets in the feature request group that are open, waiting to work, but are low priority. Those now count toward this agent's capacity when they are low priority.
It seems that need a way to customize capacity based on ticket group or omit tickets from certain groups from applying to capacity. Anyone have ideas?
1
Zach Gilbert
Thanks, 1263082080589 - We've turned off auto reassignment of chat until that feature is implemented.
0
Barry Neary
Hi 1263213544769
This is on the roadmap for early 2025
0
James Molina
Many clients need the ability to change a messaging ticket from a messaging channel to an email channel since inactive messages are treated like emails after an initial messaging conversation. This fixes many of the OCR issues related to routing inactive messages. Currently, if you count inactive messages, they are prioritized over live messages. If you don't don't count inactive messages, no channel capacity is accounted for then the first agent can get dumped all the messages. Separate queues then prevents emails from taking priority over inactive messages.
0
Barry Neary
Hi 4532417749018
Once a messaging session has been ended by an agent, the message is no longer routable - i.e. if you remove the assignee it wont be automatically be assigned to another agent in the group
We do have plans to allow these messaging tickets to be transformed into email tickets and they would be routable
Barry
0
Zach Gilbert
1263082080589 this is the same comment that was left in the other group that you replied to this morning where the agent ends the messaging conversation, then emails the customer on the same ticket, the agent goes offline, and then the customer emails back on that ticket. SInce we have the setting to re-assign chats when an agent is offline, the agent is stripped from the ticket, but the ticket is not being offered to any other agents like a messaging ticket would. It sits in the cue as an unassigned messaging conversation.
0
サインインしてコメントを残してください。