担当者の変更時に Zendesk オートメーション条件を使用する方法

チケットの担当者が変更されたときに反応するワークフローを設定しようとしたことがある場合は、おそらく混乱を招く障害に遭遇したことがあるでしょう。オートメーションを作成し、適切な条件を設定したように見えても、何も起こりません。チケットは再割り当てされますが、通知は送信されず、ウェブフック (webhook) は起動せず、ワークフローは沈黙したままです。

ここに問題があります。Zendesk のオートメーションは、担当者の即時変更を検出できません。「割り当てからの時間」のような時間ベースの条件について、チケットを毎時間チェックするスケジュールで実行されます。誰かがチケットを割り当てられたときに即座に反応したい場合は、オートメーションではなく、トリガーが必要です。

このガイドでは、両方のツール、それぞれの使用時期、実際に機能するワークフローの構築方法について説明します。必要な特定の条件、ステップごとの設定手順、一般的なユースケース、および問題が発生した場合のトラブルシューティングのヒントについて説明します。

Zendesk トリガーを使用して担当者の変更を検出する方法

トリガーが即時担当者検出に適したツールであることを理解したので、それらを正確に設定する方法を順を追って説明します。

「担当者変更」条件

必要な条件は簡単です。チケット > 担当者 > 変更済み。この条件は、Zendesk トリガー条件リファレンスに記載されています。

これは、管理センター > オブジェクトとルール > ビジネスルール > トリガーのトリガー作成インターフェースにあります。管理センターのナビゲーションの詳細については、Zendesk のトリガーの作成と管理に関するガイドを参照してください。条件ステートメントを作成するときは、カテゴリとして「チケット」、フィールドとして「担当者」、演算子として「変更済み」を選択します。

この条件は、担当者フィールドへの変更を検出します。次のときに起動します。

• 未割り当てのチケットに担当者が割り当てられた場合
• チケットがエージェントから別のエージェントに移動した場合
• 割り当てられたチケットが未割り当てになった場合

重要なことに、「変更済み」は、フィールドが以前に空であった場合でも、フィールド値への更新を検出します。チケットが作成され、すぐに割り当てられた場合、「担当者変更」条件は、割り当てがその作成イベント中に発生したため、起動します。

ステップバイステップ: 担当者変更トリガーの作成

担当者の変更に対応するトリガーを構築する方法を正確に示します。

ステップ 1: トリガーページにアクセスする

管理センター > オブジェクトとルール > ビジネスルール > トリガーに移動します。これは、すべてのチケット自動化が存在する場所です。

ステップ 2: 新しいトリガーを作成する

ページの上部にある「トリガーを追加」をクリックします。「割り当てられたときにエージェントに通知する」または「担当者への割り当て通知」のような明確で説明的な名前を付けます。このトリガーの動作を説明する説明を追加します。これにより、他の管理者が後で設定を理解するのに役立ちます。

整理のために適切なカテゴリを選択します。ほとんどのチームは「通知」を使用するか、「エージェントアラート」のようなカスタムカテゴリを作成します。

ステップ 3: 条件を設定する

「次のすべての条件を満たす」で、次を追加します。

1. チケット > 担当者 > 変更済み
2. チケット > 担当者 > 次と異なる > (現在のユーザー) (オプションですが推奨)

最初の条件は、割り当てが変更されるたびにトリガーが起動するようにします。2番目の条件は、エージェントがチケットを自分自身に割り当てたときにトリガーが起動するのを防ぎます。マイクが未割り当てのチケットを取得するために「取得」をクリックすると、彼はすでに自分がそれを持っていることを知っています。彼は自分がしたことを伝えるメールを必要としません。

自己割り当てでも通知が必要な場合は、2番目の条件を省略してください。

ステップ 4: アクションを構成する

「アクション」で、次を選択します。

通知 > ユーザーにメールを送信 > (担当者)

これにより、Zendesk は、条件が満たされた後、担当者フィールドに表示される人にメールを送信するように指示されます。

次に、メールの件名と本文をカスタマイズします。割り当て通知に最も役立つプレースホルダーを次に示します。

適切なメールの件名は、「チケット #{{ticket.id}} があなたに割り当てられました: {{ticket.title}}」のようになります。

本文には、エージェントがチケットを開かなくても問題を理解できる十分なコンテキストを含めます。

ステップ 5: 保存してテストする

「作成」をクリックしてトリガーを保存します。次に、テストします。

1. テストチケットを作成するか、既存のチケットを使用します
2. 別のエージェント (自分自身ではない) にあなたに割り当ててもらいます
3. メールで通知を確認します
4. メールに構成したすべての情報が含まれていることを確認します

数分以内にメールを受信しない場合は、スパムフォルダーを確認し、エージェントプロファイルでメール通知が有効になっていることを確認してください。

担当者変更トリガーの一般的なユースケース

基本的な設定を理解したら、さまざまなワークフローに合わせて調整できます。担当者変更トリガーが価値を高める最も一般的なシナリオを次に示します。

割り当て通知

最も簡単なユースケースは、作業がキューに到着したときにエージェントに通知することです。この通知がないと、エージェントはビューまたはダッシュボードを常にチェックする必要があります。チケットは見過ごされ、顧客は待ち、SLA (Service Level Agreement) が違反されます。

このトリガーは、スキルベースのルーティングまたは自動割り当てを使用するチームにとって特に価値があります。チケットが手動介入なしでエージェントに流れる場合、通知は新しい作業が到着したという唯一のシグナルになります。Zendesk での自動チケットルーティングの詳細をご覧ください。

エスカレーションワークフロー

担当者変更トリガーは、高度なエスカレーションパターンを強化できます。次のようなトリガーを作成できます。

• 優先度の変更に基づいて、緊急チケットを上級エージェントにルーティングする
• 特定のグループに再割り当てされたときに、チケットを専門チームに移動する
• 割り当て履歴を追跡するカスタムフィールドを更新する
• 複数回再割り当てされたチケットにタグを追加する

たとえば、チケットが「エスカレーション」グループに割り当てられたときに起動するトリガーを作成し、自動的にタグを追加し、優先度を「高」に設定し、グループマネージャーに通知することができます。

統合同期

Zendesk がより大きなツールエコシステムの一部である場合、担当者の変更は多くの場合、他のプラットフォームと同期する必要があります。トリガーは、割り当てが変更されたときにウェブフック (webhook) 経由で外部システムに通知できます。

一般的な統合パターンは次のとおりです。

• 可視性のために、担当者の変更を Slack チャネルに同期する
• 所有権が変更されたときに CRM レコードを更新する
• プロジェクト管理ツールでワークフローをトリガーする
• 外部監視システムに通知する

トリガーのウェブフック (webhook) アクションを使用すると、任意のエンドポイントに HTTP リクエストを送信できるため、外部システムを Zendesk の割り当てとリアルタイムで同期させることができます。

追跡とレポート

分析のために割り当てパターンを追跡する必要がある場合があります。担当者変更トリガーは、次のことができます。

• 担当者が変更されたときにタグを追加し、レポート用のトレイルを作成する
• 以前の担当者または割り当て数を格納するカスタムフィールドを更新する
• SLA 分析のためにチーム間のハンドオフをログに記録する
• チケットがエージェント間でバウンスするときにマネージャーに通知をトリガーする

このデータは、ルーティングの問題を特定し、チームのワークロード分散を測定し、チケットが組織内をどのように流れるかを理解するのに役立ちます。

担当者関連の条件でオートメーションを使用する

トリガーは即時担当者変更を処理しますが、オートメーションは割り当てワークフローでその場所を占めます。割り当て後、時間ベースのフォローアップに役立ちます。

トリガーの代わりにオートメーションを使用する場合

オートメーションは、特定の期間割り当てられた後、チケットをチェックする必要がある場合に役立ちます。一般的なシナリオは次のとおりです。

• 割り当てられているが、24時間以内に更新されていないチケットをフォローアップする
• エージェントに長期間滞留しているチケットをエスカレートする
• 解決済みで割り当てられているが、確認されていないチケットをクローズする
• 割り当て時間に基づいて SLA 期限に関するリマインダーを送信する

重要な区別: トリガーは割り当てイベント自体に反応します。オートメーションは、そのイベントが発生してからの時間の経過に反応します。

担当者に利用可能なオートメーション条件

オートメーションは、割り当てに関連するいくつかの時間ベースの条件を提供します。

• 割り当てからの時間 - チケットが最初のエージェントに割り当てられてからの経過時間
• 担当者更新からの時間 - 担当者フィールドが最後に変更されてからの時間
• 更新からの時間 - チケットへの更新からの時間
• ステータス + 担当者の組み合わせ - ステータスと割り当て状態の両方を一緒に確認する

「割り当てからの時間」は、実際に割り当てられたチケットでのみ機能することに注意してください。未割り当てのチケットはこの条件を満たしません。

例: 割り当てられたチケットのフォローアップ

エージェントが触れていないチケットについてエージェントにリマインダーを送信する実用的なオートメーションを次に示します。

すべての条件を満たす:

• 割り当てからの時間 > 次より大きい > 24
• ステータス > 次と異なる > 解決済み
• ステータス > 次と異なる > クローズ
• 担当者 > 次と異なる > ( )

アクション:

• 通知 > ユーザーにメールを送信 > (担当者)
• 件名: 「リマインダー: チケット #{{ticket.id}} は 24 時間割り当てられています」

このオートメーションは毎時間実行され、解決またはクローズされていない 24 時間以上割り当てられているすべてのチケットを確認し、担当者に穏やかなリマインダーを送信します。

担当者変更トリガーのトラブルシューティング

適切な条件を設定しても、トリガーが起動しない場合があります。一般的な問題を診断して修正する方法を次に示します。

担当者が変更されたときにトリガーが起動しない

トリガーが機能しない場合は、次の一般的な原因を確認してください。

トリガーの位置が重要です。 Zendesk はトリガーを上から下に評価します。あなたより上の別のトリガーが、あなたの条件が一致しないようにチケットを変更した場合、あなたのトリガーは起動しません。すべての分類およびルーティングトリガーの後、トリガーリストの最後に通知トリガーを配置します。

条件が厳しすぎる可能性があります。 「担当者変更」以外の追加条件がある場合は、割り当てが発生したときに実際に満たされていることを確認してください。たとえば、「優先度が高い」を追加したが、割り当てられているチケットの優先度が「普通」の場合、トリガーは起動しません。

「チケットが更新されました」条件。 一部のトリガー設定は、追加条件として「チケット > 次の状態 > 更新済み」を使用すると、より適切に機能します。これにより、トリガーがチケットの作成時ではなく、更新時にのみ起動することが保証されます。

重複した通知

同じ割り当てに対して複数のメールを受信するということは、通常、条件が重複する複数のトリガーがあることを意味します。以下を確認してください。

• 担当者変更時にすべて起動する複数の通知トリガー
• 割り当てが発生したときに、「担当者変更」および「チケットが更新されました」で起動するトリガー
• あるトリガーがチケットを変更し、別のトリガーが起動する原因となるトリガーの順序

修正は通常、同様のトリガーを統合するか、互いに干渉しないように順序を調整することです。

自己割り当て通知

エージェントがチケットを自分自身に割り当てたときにメールを受信することについて不満を言う場合は、「担当者は (現在のユーザー) ではありません」条件を確認してください。この条件は、このシナリオを防ぐために特別に存在します。自己割り当て通知が必要な場合は、この条件を削除します。不要な場合は、それが存在し、正しく構成されていることを確認してください。

オートメーションで担当者の変更が検出されない

オートメーションを使用して即時担当者変更を検出しようとしている場合、それは機能しません。オートメーションはこれを行うことができません。代わりに、そのワークフローをトリガーに移動します。オートメーションは、割り当て後の時間ベースのフォローアップにのみ使用してください。

高度なパターンとベストプラクティス

基本を習得したら、これらのパターンを使用して、より高度な割り当てワークフローを構築できます。

「返送」パターン

チケットはチーム間でバウンスする必要がある場合があります。最前線のサポートエージェントがスペシャリストに割り当て、スペシャリストが作業を行い、チケットを元のエージェントに戻す必要があります。Zendesk は「元の担当者」をネイティブに追跡しませんが、カスタムフィールドとウェブフック (webhook) でこれを構築できます。

パターンは次のようになります。

1. 元の担当者とグループを格納するカスタムフィールドを作成します
2. チケットが最初のグループから最初に割り当てられたときに、これらのフィールドに入力するためにトリガーを使用します
3. エージェントがチケットを返す準備ができたときに使用するマクロを作成します
4. 保存された元の担当者を読み取り、チケットを再割り当てするためにウェブフック (webhook) トリガーを使用します

これは、ウェブフック (webhook) 構成を必要とする高度な設定ですが、一般的なワークフローの問題を解決します。

トリガー組織のヒント

トリガーリストが増えるにつれて、組織化が重要になります。

• カテゴリを使用して関連するトリガーをグループ化します。「通知」カテゴリ、「ルーティング」カテゴリなどを用意します。
• トリガーの動作を説明する説明的な名前を使用します。「割り当て時に担当者に通知する」は「割り当てトリガー」よりも優れています。
• トリガーの説明で依存関係を文書化します。トリガー B がトリガー A の実行に最初に依存している場合は、両方の説明にこれを記述します。
• トリガーの順序を四半期ごとに確認します。トリガーを追加すると、最適な順序が変わります。ルーティングが通知の前に、分類がエスカレーションの前に、など定期的に監査して、ルーティングが通知の前に、分類がエスカレーションの前に発生するようにします。

トリガーを安全にテストする

新しいトリガーをアクティブ化する前に:

• 「一致のプレビュー」機能を使用して、既存のチケットに対して条件をテストします
• 最初に非本番チケットでテストします
• 同僚にテスト割り当てを行ってもらい、「現在のユーザー」ロジックが正しく機能することを確認できるようにします
• 何かが期待どおりに機能しない場合は、トリガーログを確認します

基本的な担当者自動化を超える

Zendesk トリガーは、担当者の変更を検出して対応するという基本的なタスクを処理します。しかし、最新のサポートチームは、単純な通知からインテリジェントなワークフロー自動化へと移行しています。

違いは次のとおりです。トリガーはエージェントに「チケットがあります」と伝えます。AI チームメイトはエージェントに「チケットがあります。請求に関する問題であり、顧客は不満を抱いています。これは下書きの返信であり、同様のチケットはこのように解決されました」と伝えます。

eesel AI では、これを構成するツールではなく、採用するチームメイトとしてアプローチします。ヘルプデスク向けのAI エージェントは、成熟した展開で最大 81% のチケットを自律的に解決できます。ルーティングと通知を行うだけでなく、当社の AI は次のことができます。

• 割り当て前のスマートトリアージ: AI は受信チケットを読み取り、トピックと緊急度で分類し、可用性だけでなくコンテンツに基づいて適切なスペシャリストにルーティングします。これは、請求の専門家が請求の質問を受け、技術チームがバグレポートを受け取ることを意味します。

• コンテキストが豊富な通知: チケットの件名を送信するだけでなく、AI コパイロットは顧客が求めていることの要約を生成し、感情を特定し、緊急インジケーターにフラグを立てます。

• 自動下書きの返信: エージェントは、割り当て通知とともに下書きの返信を受け取ります。下書きはナレッジベースと過去のチケットに基づいているため、チームが書いたように聞こえます。

• インテリジェントなエスカレーション: AI は、人間の注意が必要なチケットと、自律的に解決できるチケットを識別します。これは、エージェントが本当に専門知識を必要とするチケットについてのみ通知されることを意味します。

その結果、エージェントが通知を受け取ると、ゼロから開始するわけではありません。彼らはコンテキスト、下書きの返信、そしてこのチケットが本当に彼らの注意を必要としているという確信を持っています。

基本的な通知を機能させるために Zendesk トリガーの構成にかなりの時間を費やしている場合は、AI チームメイトが通知ワークフローをよりインテリジェントに処理し、自律的な解決を通じて全体的なチケット量を削減できるかどうかを検討する価値があるかもしれません。eesel AI が Zendesk と統合してサポートワークフローを強化する方法をご覧ください。