ZendeskでX件の返信後にタグを追加する方法:完全ガイド

Stevia Putri
Written by

Stevia Putri

Reviewed by

Stanley Nicholas

Last edited 2026 2月 24

Expert Verified

ZendeskでX件の返信後にタグを追加する方法:完全ガイドのバナー画像

多忙なサポートキューを管理している場合、なかなか終わらないチケットに遭遇したことがあるでしょう。簡単な質問が15件のメッセージスレッドに発展し、エージェントの時間を浪費し、顧客の忍耐力を試します。Zendeskがこれらの会話を自動的にフラグ付けして、エスカレーションしたり、上級エージェントを割り当てたりできたら素晴らしいと思いませんか?

課題は、Zendeskには組み込みの「返信数」条件がないことです。「このチケットの返信が5件以上の場合、「エスカレーション」タグを追加する」というルールを作成することはできません。しかし、それは選択肢がないという意味ではありません。このガイドでは、Zendeskで返信ベースのタグ付けを実現するための実用的な回避策と、自動化の制限にうんざりしている場合のよりスマートな代替案を紹介します。

カスタマーサポートチーム向けのZendeskヘルプデスクプラットフォーム
カスタマーサポートチーム向けのZendeskヘルプデスクプラットフォーム

Zendeskでの返信ベースのタグ付けにおける課題の理解

基本から始めましょう。Zendeskは、2種類のビジネスルールを提供しています。トリガーと自動化です。これらは似ているように聞こえますが、動作が異なります。

トリガーはイベントベースです。チケットの作成や更新など、何かが発生するとすぐに起動します。チャネル、優先度、件名に含まれるキーワードに基づいてチケットにタグ付けする場合は、トリガーが最適なツールです。

自動化は時間ベースです。約1時間ごとに実行され、経過時間に基づいて条件を確認します。「作成からの時間」や「最終更新からの時間」などです。

問題は、トリガーも自動化も、チケットの返信数を直接カウントできないことです。「返信数がXより大きい」という条件はありません。これは、次のようなことを行いたいサポートチームにとって共通の不満です。

  • 何度もやり取りされているチケットをエスカレーションする
  • メールではなく電話が必要な複雑な問題を特定する
  • 爆発する前に潜在的な顧客満足度リスクにフラグを立てる
  • レポート作成とリソース計画のためにチケットの複雑さを測定する

良いニュースは?ほとんどの場合、回避策があります。完璧ではありませんが、問題のある会話が制御不能になる前に特定するのに役立ちます。

よりインテリジェントなアプローチをお探しの場合は、eesel AIがZendeskと統合して、単に返信をカウントするだけでなく、会話のコンテキストと意図を理解します。

返信ベースの自動化を設定する前に必要なもの

始める前に、次のものがあることを確認してください。

それだけです。基本的な回避策にはサードパーティアプリは必要ありませんが、より高度な機能が必要な場合は、後でいくつかのオプションについて説明します。

方法1:「リクエスタの更新からの時間」をプロキシとして使用する

最も実用的な回避策は、「リクエスタの更新からの時間」条件を使用することです。ロジックは次のとおりです。顧客が最近チケットを更新した場合、それは事実上返信です。最後の更新からの時間を測定することで、返信アクティビティを概算できます。

この方法は、保留中のステータスと組み合わせると最適に機能します。エージェントがチケットを保留中にすると、顧客の応答を待っています。顧客が返信(チケットを更新)すると、自動化は経過時間に基づいてタグ付けできます。

ステップ1:自動化メニューに移動する

管理センター > オブジェクトとルール > ビジネスルール > 自動化に移動します。

時間ベースのビジネスルールを作成するためのZendesk自動化インターフェイス
時間ベースのビジネスルールを作成するためのZendesk自動化インターフェイス

既存の自動化のリストが表示されます。これらは1時間ごとに実行され、すべてのチケットを条件と照らし合わせて確認します。

ステップ2:新しい自動化を作成する

右上隅にある自動化を追加をクリックします。

「過度のやり取りのあるチケットにタグを付ける」のようなわかりやすい名前を付け、その内容を説明する説明を追加します。将来のあなた(および他の管理者)はそれを高く評価するでしょう。

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

ここが魔法が起こる場所です。次のすべての条件を満たすの下に、次の条件を追加します。

  1. チケット:ステータスカテゴリ > 次のいずれかである > 保留中 - これにより、顧客からの入力を待っているチケットのみが表示されるようになります
  2. チケット:リクエスタの更新からの時間 > 次より大きい > 24(または、ワークフローに適した期間)
  3. チケット:タグ > 次のいずれも含まない > multiple_replies

3番目の条件は非常に重要です。これは「無効化条件」と呼ばれ、同じチケットで自動化が繰り返し実行されるのを防ぎます。これがないと、自動化は1時間ごとにチケットにタグ付けします。Zendeskの自動化ドキュメントでは、このパターンについて詳しく説明しています。

ステップ4:タグアクションを追加する

アクションで、アクションを追加をクリックし、タグを追加を選択します。

multiple_repliesまたはescalation_candidateのようなタグを入力します。このタグは、顧客が指定された期間保留中のステータスになった後に応答したすべてのチケットに表示されるようになります。

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

作成をクリックして自動化を保存します。

次に、テストします。テストチケットを作成し、保留中のステータスにし、リクエスタとしてコメントを追加します(リクエスタのビューに切り替えるか、「次として送信」オプションを使用することで実行できます)。自動化が実行されるのを待ち(1時間ごとにチェックされることを忘れないでください)、タグが表示されることを確認します。

理解すべき制限事項

この回避策には、知っておくべきいくつかの制約があります。

  • 実際の返信数ではなく、時間を測定します。24時間後の1回の返信は、5回の連続した返信と同じタグを取得します。
  • 保留中のステータスのチケットでのみ機能します。ワークフローで保留中が一貫して使用されていない場合、これは役に立ちません。
  • 1時間ごとの自動化サイクルは、返信とタグの適用との間に遅延があることを意味します。

これらの制限にもかかわらず、この方法は、フラグを立てたいチケットの大部分をキャッチします。多くのチームにとって、これで十分です。より高度なタグ付け機能をお探しの場合は、AIを使用してサポートチケットを分類またはタグ付けする方法に関するガイドをご覧ください。

方法2:カスタムフィールドを使用したやり取りの追跡

実際の返信数をカウントする必要がある場合は、カスタムフィールドと複数のトリガーを使用して、より複雑なシステムを構築できます。設定にはより多くの作業が必要ですが、より正確です。Zendeskのカスタムフィールドドキュメントでは、これらの設定の基本について説明しています。

概念

「返信数」という数値カスタムフィールドを作成します。次に、顧客が返信するたびにこのフィールドを増やすトリガーを作成します。最後に、カウンターがしきい値に達したときにタグを追加する自動化を作成します。

カスタムフィールドの設定

  1. 管理センター > オブジェクトとルール > チケット > フィールドに移動します
  2. フィールドを追加をクリックし、数値を選択します
  3. 「返信カウンター」などの名前を付けます
  4. デフォルト値を0に設定します

インクリメントトリガーの作成

次に、顧客がチケットを更新するたびにこのフィールドに1を追加するトリガーを作成します。

条件:

  • チケット:次である > 更新済み
  • コメント:次である > 公開(または、必要に応じて非公開)
  • コメント作成者:次である > リクエスタ

アクション:

  • チケット:返信カウンター + 1(Zendeskはトリガーで計算を行わないため、これには少し回避策が必要ですが、一連のトリガーまたはサードパーティアプリを使用できます)

カウンターを増やすための純粋なZendeskのアプローチは扱いにくいです。複数のトリガー(カウンターが1の場合は2に設定、カウンターが2の場合は3に設定など)が必要になるか、計算を実行できるサードパーティアプリを使用する必要があります。

タグ付けの自動化

カウンターが機能したら、自動化を作成します。

条件:

  • チケット:返信カウンター > 次より大きい > 4
  • チケット:タグ > 次のいずれも含まない > high_reply_count

アクション:

  • チケット:タグを追加 > high_reply_count

このアプローチはより正確ですが、設定とメンテナンスが大幅に必要です。複雑さを管理できる専任のZendesk管理者を持つチームに最適です。専任の管理者リソースがないチームの場合は、複雑さを自動的に処理するAI搭載の代替手段の検討を検討してください。

会話の深さを追跡するための時間ベースのプロキシとカスタムフィールドカウンターの比較
会話の深さを追跡するための時間ベースのプロキシとカスタムフィールドカウンターの比較

返信ベースのタグ付けの一般的なユースケース

なぜこれほど苦労するのでしょうか?返信ベースのタグ付けが実際に違いを生む最も一般的なシナリオを次に示します。

過度のやり取りのあるチケットのエスカレーション

チケットが5件以上の返信に達した場合、多くの場合、メールが適切なチャネルではない兆候です。問題が複雑すぎるか、リアルタイムの会話が必要な誤解がある可能性があります。これらのチケットにタグ付けすると、顧客が不満を感じる前に、積極的に連絡を取り、電話またはビデオ通話を提供できます。

複雑な問題の特定

一部の問題は本質的に複雑です。特定のチケットタイプが一貫して高い返信数を記録している場合、それは貴重なデータです。より良いドキュメント、製品の改善、またはチームの専門的なトレーニングが必要になる可能性があります。チケットの要約ツールを利用して、長い会話スレッドをすばやく理解することもできます。

SLAリスクのフラグ付け

やり取りの多いチケットは、解決に時間がかかることがよくあります。早期にタグ付けすることで、SLAのコミットメントに違反する前に優先順位を付けることができます。

レポート作成のための測定

返信数は、チケットの複雑さのプロキシです。これらのチケットにタグ付けして追跡することで、キューの何パーセントが「複雑」で、何パーセントが「単純」であるかを報告し、人員配置とトレーニングの決定に役立てることができます。サポートワークフローの自動化の詳細については、カスタマーサポートにおけるAIと自動化に関するガイドをご覧ください。

Zendesk自動化タグ付けのベストプラクティス

単純な回避策を使用する場合でも、複雑なカスタムフィールドアプローチを使用する場合でも、これらのプラクティスは頭痛の種を軽減します。

常に「タグを追加」を使用し、「タグを設定」は使用しない

タグを設定アクションは、既存のすべてのタグを削除し、指定したタグに置き換えます。チケットにvip_customerbilling_issueなどの重要なタグがある場合、タグを設定を使用すると削除されます。すべてのタグを本当にクリアしたい場合を除き、常にタグを追加を使用してください。

一貫した命名規則を使用する

返信関連のタグのパターンを確立します。

  • 3件以上の返信があるチケットの場合はreply_count_3
  • 注意が必要なチケットの場合はescalation_candidate
  • 本質的に難しい問題の場合はcomplex_issue

一貫した命名により、レポート作成と検索がはるかに簡単になります。

無効化条件を含める

タグを追加するすべての自動化には、タグがまだ存在しないことを確認する条件も必要です。次に、そのタグをアクションとして追加します。これにより、自動化が繰り返し実行されるのを防ぎます。

ライブになる前にテストする

テストチケットを作成し、自動化ロジックをウォークスルーします。チケットイベントをチェックして、自動化がいつ、なぜ起動したかを正確に確認します。実際の顧客チケットよりもテストデータでデバッグする方がはるかに簡単です。

セットアップを文書化する

各自動化の内容とその理由を書き留めます。休暇中または新しい役割に移動した場合、次の管理者はロジックを理解する必要があります。シンプルな共有ドキュメントは、毎回自動化設定を掘り下げるよりも優れています。

タグ付けのベストプラクティスの詳細については、タグの追加、タグの削除、タグの設定のためのZendeskトリガーアクションに関するガイドをご覧ください。

よりスマートな代替手段:eesel AIによるAI搭載のタグ付け

回避策は問題ありませんが、それでも回避策です。会話を実際に理解しているわけではありません。ステータスの変更に基づいて、時間または概算の返信をカウントするだけです。

タグ付けシステムが各会話の実際のコンテンツと意図を理解したらどうでしょうか?

パフォーマンス監視メトリクスを備えたAIトリアージダッシュボード
パフォーマンス監視メトリクスを備えたAIトリアージダッシュボード

eesel AIは、異なるアプローチを取ります。返信数と時間条件に関する複雑なルールを構築する代わりに、AIトリアージ製品は、チケットの実際のコンテンツを分析します。

違いは次のとおりです。

**維持する複雑なルールはありません。**すべてのシナリオを予測し、それぞれに条件を記述する必要はありません。AIは既存のチケットから学習し、コンテキストを理解します。AIトリアージ機能の詳細をご覧ください。

**コンテンツを認識したタグ付け。**単に返信をカウントするだけでなく、eesel AIは、会話が不満を募らせている場合、技術的な複雑さが増している場合、または人々が実際に言っていることに基づいてチケットをエスカレーションする必要がある場合を特定できます。

**自動適応。**ビジネスが変化するにつれて、AIは修正から学習します。新しい製品を追加したり、プロセスを変更したりするときに、自動化ルールを常に更新する必要はありません。

すぐに機能します。Zendeskアカウントにeesel AIを接続すると、すぐに過去のチケットから学習を開始します。ライブになる前に、過去のチケットでシミュレーションを実行して、どのようにタグ付けしたかを確認できます。

トリガー ルールの維持に、作成したタグから得られるメリットよりも多くの時間を費やしているチームにとって、AI 搭載のタグ付けは検討する価値があります。料金をご覧ください。

今すぐZendeskタグ付けの自動化を開始する

Zendeskには、返信ベースのタグ付けのオプションがあります。「リクエスタの更新からの時間」の回避策はすばやく設定でき、必要なもののほとんどをキャッチします。カスタムフィールドアプローチはより正確ですが、より多くのメンテナンスが必要です。どちらもZendeskのネイティブ機能内で動作します。

しかし、回避策にうんざりしていて、会話を実際に理解するタグ付けが必要な場合は、eesel AIをお試しください。インテリジェントなタグ付けの複雑さを処理するため、自動化ルールを維持するのではなく、優れたサポートの提供に集中できます。

結論は?Zendeskの制限によって、複雑なチケットの特定とエスカレーションが妨げられないようにしてください。回避策を構築する場合でも、AI搭載のタグ付けにアップグレードする場合でも、顧客(およびエージェント)は、問題のある会話を早期にキャッチしてくれたことに感謝するでしょう。

よくある質問

いいえ、Zendeskにはネイティブの「返信数」条件がありません。このガイドで説明されている回避策(「リクエスタの更新からの時間」をプロキシとして使用したり、カスタムフィールドシステムを構築するなど)のいずれかを使用する必要があります。または、会話のコンテキストを理解するeesel AIのようなサードパーティソリューションを使用することもできます。
正確なカウントではなく、近似値です。顧客が特定の期間後に返信したチケットにタグ付けしますが、1回の返信と5回の返信を区別しません。多くのチームにとって、これは注意が必要なチケットを特定するのに十分です。正確な返信カウントが必要な場合は、カスタムフィールドアプローチまたはAIソリューションが必要です。
「リクエスタの更新からの時間」メソッドは、保留中のステータスのチケットで最適に機能します。これは、顧客からの入力を明示的に待っている場合です。他のステータスでは、異なる条件が必要になる場合があります。カスタムフィールドアプローチは、実際のアクティビティを追跡するため、すべてのステータスで機能します。
はい、ただし条件を調整する必要があります。「リクエスタの更新からの時間」の代わりに、「更新からの時間」を使用します。これは、内部メモを含むチケットの変更をキャプチャします。これは、顧客の返信だけでなく、エージェントの更新でもトリガーされることに注意してください。
トリガーはイベントが発生するとすぐに起動しますが、時間の経過とともに返信をカウントできません。自動化は1時間ごとに実行され、「リクエスタの更新からの時間」のような時間ベースの条件を確認できるため、返信ベースのワークフローに適しています。カスタムフィールドアプローチでは、トリガー(カウンターを増やすため)と自動化(しきい値に達したときにタグを追加するため)の両方を使用します。
常に無効化条件を含めます。「タグに次のいずれも含まれていない:[your_tag]」のような条件を追加し、同じタグをアクションとして追加します。これにより、自動化がチケットごとに1回だけ実行されるようになります。これがないと、自動化は1時間ごとにチケットにタグ付けします。

この記事を共有

Stevia undefined

Article by

Stevia Putri

Stevia Putri is a marketing generalist at eesel AI, where she helps turn powerful AI tools into stories that resonate. She’s driven by curiosity, clarity, and the human side of technology.