Zendeskで最初のリプライ時にリクエスターにメールを送信する方法

顧客がサポートチケットを送信すると、通常、自動応答が送信されます。しかし、エージェントが実際に最初のリプライを送信した場合はどうでしょうか？それはまったく異なる瞬間であり、多くのサポートチームは、適切な期待を設定したり、特定の情報を提供したりするために、この通知をカスタマイズしたいと考えています。

Zendeskトリガーを設定して最初のリプライ時にリクエスターにメールを送信するのは簡単そうに聞こえますが、一般的な混乱点があります。ほとんどのZendeskアカウントには、チケットが作成されたときに通知を送信するデフォルトのトリガーがすでに存在します。実際に必要なのは、チケットが送信されたときではなく、エージェントが最初の公開コメントを送信したときに特に発動するトリガーかもしれません。

これを正確に設定する方法を詳しく見ていきましょう。

違いを理解する：チケット作成 vs. 最初のリプライ

設定に入る前に、何に取り組んでいるかを理解することが重要です。Zendeskには、「リクエスターとCCに受信リクエストを通知する」という標準トリガーが付属しています。これは、顧客がチケットを送信するとすぐに発動し、「リクエストを受信し、レビュー中です」のような一般的な応答を送信します。

チームがエージェントが実際に応答したときに顧客に通知したい場合に混乱が始まります。これは根本的に異なるイベントです。チケットの更新（作成ではない）であり、エンドユーザーではなくエージェントからの公開コメントが含まれます。

なぜこの区別が重要なのでしょうか？メッセージングが異なる必要があるからです。自動応答は単なる応答です。最初のリプライ通知には、推定応答時間、役立つリソースへのリンク、またはチケットの内容に基づいたパーソナライズされた情報が含まれる場合があります。

一部のチームは、最初のリプライ時間をメトリックとして追跡したいと考えています。この瞬間のための専用トリガーを持つことは、レポート作成に役立ち、顧客が自分の問題に積極的に取り組んでいることを知ることができます。

メッセージングトリガー（チャットでの会話の場合）を使用している場合は、Zendeskメッセージングトリガー、条件、およびアクションに関するガイドが、より広範なトリガーエコシステムを理解するのに役立つ場合があります。

開始する前に必要なもの

トリガーを作成する前に、次のものがあることを確認してください。

• Zendeskへの管理者アクセス。 管理者のみがトリガーを作成および変更できます。管理者権限がない場合は、Zendesk管理者にリクエストする必要があります。
• 現在のトリガーの順序の明確な理解。 トリガーは上から下へ順番に実行され、順序が重要です。通常、新しいトリガーはルーティングトリガーの後、一般的な通知トリガーの前に発動する必要があります。
• 送信する正確なメッセージ。 設定を開始する前に、件名とメール本文を下書きしてください。この特定の瞬間に顧客にとって最も役立つ情報は何であるかを検討してください。
• テスト計画。 実際の顧客に影響を与える前に、これが正しく機能することを確認する必要があります。

重要な注意点の1つ：Zendeskは、エージェントがチケットに公開コメントを追加すると、常にリクエスターにメール通知を送信します。これは、デフォルトの「コメントの更新をリクエスターとCCに通知する」トリガーを通じて行われます。メッセージの内容をカスタマイズしたいだけの場合は、新しいトリガーを作成するのではなく、既存のトリガーを編集するだけで済む場合があります。ただし、特定の条件（チケットの種類ごとに異なるメッセージなど）が必要な場合は、カスタムトリガーを使用する必要があります。

ステップバイステップ：最初のリプライトリガーの作成

最初のエージェントリプライを特にターゲットとするトリガーを作成する方法を次に示します。

ステップ1：管理センターでトリガーページにアクセスする

管理センターに移動し、サイドバーのオブジェクトとルールをクリックします。ビジネスルール > トリガーを選択します。これにより、アカウント内のすべてのアクティブおよび非アクティブなトリガーのリストが表示されます。

時間を取って既存のトリガーを確認してください。リクエスターへの通知を処理するトリガーを探してください。重複したメールを作成しないように、すでに送信されている通知を理解する必要があります。

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

右上隅にあるトリガーを追加をクリックします。トリガーに、その目的を明確に示す説明的な名前を付けます。「最初のエージェントリプライのリクエスターに通知する」のようなものが適切です。「新しいトリガー」や「最初のリプライ」のような、具体的な機能が説明されていない曖昧な名前は避けてください。

他の管理者がこのトリガーの機能を理解できるように、説明を追加することもできます。これは、複数の人がZendeskの設定を管理する大規模なチームで特に役立ちます。

ステップ3：トリガー条件を設定する

ここでは、トリガーをいつ発動させるかを正確に定義します。最初のリプライ通知の場合、次の条件が必要です。

次のすべての条件を満たす：

• チケット > が > 更新済み（作成済みではない - 最初のリクエストの送信時ではなく、リプライ時に発動させたい）
• チケット > コメント > が > 公開（内部メモではなく、顧客向けのコメントに応答していることを確認する）
• チケット > ステータス > が変更された > 新規から（未割り当ての新しいチケットから処理中のチケットへの移行を識別する）
• チケットの詳細 > 現在のユーザー > が > （エージェント）（リクエスター自身ではなく、エージェントからのコメントであることを確認する）

「新規から変更された」という条件が重要です。これにより、このトリガーは、後続のコメントではなく、最初のエージェントリプライでのみ発動することが保証されます。チケットが新規からオープンまたは保留に移行すると、この条件は再び満たされません。

ステップ4：メールアクションを設定する

これらの条件が満たされたときに何が起こるかを設定します。

アクション：

• 通知 > ユーザーメール > （リクエスター）

メール本文では、プレースホルダーを使用してメッセージをパーソナライズできます。役立つプレースホルダーには次のものがあります。

• {{ticket.id}} - チケット番号
• {{ticket.title}} - 件名
• {{ticket.latest_comment}} - この通知をトリガーしたエージェントのコメント
• {{ticket.assignee.name}} - チケットを処理しているエージェントの名前

サンプルメッセージテンプレートを次に示します。

件名：Re: {{ticket.title}}

こんにちは {{ticket.requester.first_name}}様、

お問い合わせありがとうございます。リクエストを受け付け、エージェントが確認中です。

{{ticket.latest_comment}}

追加情報がある場合は、このメールに返信してください。

チケット#{{ticket.id}}

ステップ5：トリガーを保存して配置する

保存をクリックしてトリガーを作成します。しかし、まだ完了していません。トリガーリストで正しく配置する必要があります。

トリガーリストに戻り、新しいトリガーを見つけます。ドラッグハンドルを使用して、適切な位置に移動します。通常、通知トリガーは、ルーティングおよびカテゴリトリガーの後、キャッチオール通知トリガーの前に配置する必要があります。

トリガーはチケットを変更でき、それらの変更は後続のトリガーが発動するかどうかに影響を与える可能性があるため、順序が重要です。最初のリプライトリガーがチケットを割り当てるルーティングトリガーの前に実行される場合、通知で担当者名を使用できない可能性があります。

本番環境に移行する前にトリガーをテストする

最初にテストせずに、新しいトリガーを本番環境にデプロイしないでください。すべてが機能することを確認する方法を次に示します。

1. テストチケットを作成します。 エンドユーザー（エージェントではない）としてチケットを送信します。個人のメールアドレスまたはテストアカウントを使用できます。

2. エージェントとして公開コメントを追加します。 エージェントとしてログインし、テストチケットを開き、公開コメントを追加します。

3. 通知を確認します。 メールがリクエスターのメールアドレスに正しい内容で送信されることを確認します。

4. 再度発動しないことを確認します。 同じチケットに別の公開コメントを追加します。トリガーは別の「最初のリプライ」通知を送信しないでください。

5. Zendeskのトリガーテスト機能を確認します。 トリガーエディターで、「トリガーのテスト」ボタンを使用して、どのチケットが条件に一致するかを確認できます。これにより、保存する前にロジックを確認できます。

トリガーが期待どおりに発動しない場合は、チケットのイベントログを確認してください。これにより、どのトリガーが実行されたかが表示され、条件の問題をデバッグするのに役立ちます。

よくある間違いとその回避方法

経験豊富なZendesk管理者でも、トリガーで問題が発生することがあります。最も一般的な問題を次に示します。

重複した通知。 リクエスターが同じリプライに対して2通のメールを受信している場合は、トリガーが重複している可能性があります。カスタムトリガーとデフォルトの「コメントの更新をリクエスターとCCに通知する」の両方が発動しているかどうかを確認してください。除外条件を追加するか、デフォルトのトリガーを無効にする必要がある場合があります。

プライベートコメントが通知をトリガーする。 「コメントが公開」という条件を含めない場合、内部メモが顧客へのメールをトリガーする可能性があります。常にこの条件が正しく設定されていることを確認してください。

トリガーの順序が問題を引き起こす。 トリガーがルーティングの前に実行される場合、担当者情報を使用できない可能性があります。実行が遅すぎると、他のトリガーがすでにチケットを変更して、発動を防いでいる可能性があります。

CCの処理。 CCに通知を受信させたい場合は、（リクエスター）だけでなく、（リクエスターとCC）をメール受信者として使用します。Zendeskには、同じ人への重複したメールを防ぐための特定の抑制ルールがあることに注意してください。

「現在のユーザー」条件の混乱。 トリガー条件の「現在のユーザー」は、トリガーの評価を引き起こした更新を行った人を指すことを忘れないでください。最初のリプライトリガーの場合、これはリクエスターではなく、エージェントである必要があります。

特定のユースケース向けの高度なバリエーション

基本的なトリガーが機能したら、さまざまなシナリオに合わせてカスタマイズできます。

グループごとに異なるメッセージ。 「グループが請求」のような条件を追加し、チームごとにカスタマイズされたメッセージングで個別のトリガーを作成します。請求には支払いリンクを含め、テクニカルサポートにはトラブルシューティングの手順を含めることができます。

営業時間ロジック。 「営業時間内ですか？」の条件を追加して、営業時間中と営業時間外で異なるメッセージを送信します。営業時間外のリプライには、チームがオンラインに戻ったときの応答時間に関するメモを含めることができます。

特定のリクエスターまたは組織を除外する。 「リクエスターではない」または「組織ではない」の条件を追加して、特定のVIP顧客または内部ユーザーが自動通知を受信しないようにします。

自動返信との組み合わせ。 Zendeskの自動返信機能（以前のAnswer Bot）を使用する場合は、タグ条件を追加して、自動返信を受信したチケットを除外します。これにより、顧客が2通の自動メッセージを立て続けに受信することを防ぎます。

最初のリプライ通知の追跡。 トリガーが発動したときに「first_reply_sent」のようなタグを適用するアクションを追加します。これにより、どのチケットがこの通知を受信したか、いつ受信したかをレポートできます。

AIを活用した代替手段を検討する場合

ルールベースのトリガーは、単純なシナリオではうまく機能しますが、制限があります。顧客のメッセージのコンテキストや意図を理解できません。顧客が単純なパスワードのリセットについて質問しているか、複雑な技術的な問題について質問しているかに関係なく、同じテンプレートを送信します。

これは、AIを活用したサポートツールが異なるアプローチを提供する場所です。静的なテンプレートメッセージを送信する代わりに、AIエージェントは次のことができます。

• 顧客の実際の質問を分析し、コンテキストに応じた応答を提供する
• ナレッジベースから情報を取得して、具体的な回答を提供する
• 顧客の履歴に基づいてトーンとコンテンツをパーソナライズする
• 一般的な質問を自動的に処理しながら、複雑な問題を人にエスカレートする

従来のトリガーと並行して（または代わりに）機能するようにeesel AIを構築しました。Zendesk統合を使用すると、既存のヘルプセンターの記事、過去のチケット、ドキュメントから学習するAIを活用した最初のリプライを設定できます。プレーンな英語でエスカレーションルールを定義すると、AIがそれに従います。

チケットの量が多いチームにとって、これはトリガーロジックの維持にかかる時間が短縮され、複雑な顧客の問題に集中する時間が増えることを意味します。エージェントのレビューのためにAIがリプライを下書きすることから始め、AIがその能力を証明するにつれて、完全に自律的な応答にレベルアップできます。

ルールベースのトリガーとAIエージェントは、相互に排他的ではありません。多くのチームは、基本的なルーティングと通知にトリガーを使用し、AIに実際の顧客とのコミュニケーションを処理させています。適切なアプローチは、チケットの量、複雑さ、および必要なカスタマイズの量によって異なります。

よりスマートなサポート自動化を開始する

Zendeskトリガーを設定して最初のリプライ時にリクエスターにメールを送信することは、サポート自動化の堅固な基盤です。これにより、顧客は自分の問題が処理されていることを認識し、サポートジャーニーの重要な瞬間にメッセージングを制御できます。

重要なのは、単純なことから始めて反復することです。最初に基本的なトリガーを機能させ、徹底的にテストしてから、必要な場合にのみ複雑さを追加します。追加するすべての条件は、潜在的な障害のもう1つのポイントであることを忘れないでください。したがって、要件を満たしながら、トリガーを可能な限り単純に保ちます。

静的なトリガーを超えて、顧客を実際に理解するAIが必要な場合は、eesel AIを無料で試してください。数分でZendeskに接続し、既存のヘルプセンターと過去のチケットから学習して、初日からコンテキストに応じた役立つ応答を提供します。