Zendeskビジネスルール・チケットアクション：完全ガイド

サポートチケットを手動で管理することには限界があります。顧客ベースが拡大するにつれて、チケットのルーティング、ステータス更新の送信、緊急案件のエスカレーションといった繰り返しの作業に多くの時間を費やすことになります。そこで役立つのがZendeskのビジネスルールです。

Zendeskのビジネスルールは、定義した条件に基づいてチケットアクションを処理する自動化されたワークフローです。これらはサポート自動化の第一線として機能します。24時間365日稼働し、常に手動で介入することなく、チケットが適切なタイミングで適切な担当者に届くようにします。Zendeskのドキュメントによると、これらのルールはシンプルな「if-then（もし〜なら〜する）」ロジックに従っており、サポートの規模に合わせて拡張可能です。

このガイドでは、Zendeskのビジネスルール・チケットアクションについて知っておくべきすべてのことを網羅しています。トリガー、自動化、マクロの仕組みに加え、最初から正しく設定する方法を学ぶことができます。

---

Zendeskのビジネスルールとは？

Zendeskのビジネスルールとは、特定の条件が満たされたときに自動的にチケットを変更し、通知を送信する事前定義されたワークフローのことです。これらはシンプルなロジックに従います。「もしXが真であれば、Yを実行する」というものです。

例えば、VIP顧客からチケットが届いた場合（条件）、自動的にシニアサポートチームに割り当て、優先度を「緊急」に設定する（アクション）といった具合です。あるいは、チケットが24時間保留状態にある場合（時間ベースの条件）、リクエスタにリマインドメールを送信する（アクション）ことも可能です。

すべてのビジネスルールの核となる構成要素は以下の通りです。

• 条件（Conditions）： ルールを適用するためにチケットが満たすべき要件
• アクション（Actions）： 条件が満たされたときに何が起こるか
• 演算子（Operators）： 条件がどのように評価されるか（「である」、「ではない」、「より小さい」、「を含む」など）

ビジネスルールの作成と管理ができるのは管理者のみです。この制限があるのは、これらのルールがシステム内のすべてのチケットに影響を与え、設定を誤るとサポートワークフロー全体を混乱させる可能性があるためです。意図しない結果を避けるために、変更できる人を制限することをお勧めします。

出典: https://support.zendesk.com/hc/en-us/articles/4408885959066

---

Zendeskにおけるビジネスルールの種類

Zendeskには主に4種類のビジネスルールがあり、それぞれサポートワークフローにおいて異なる目的を果たします。

トリガー（Triggers）

トリガーは、チケットが作成または更新されたときに即座に実行されるイベントベースの自動化です。これらはリアルタイムのレスポンダーであり、迅速なサポート運営には欠かせません。

他のルールタイプとの大きな違いはスピードです。トリガーはチケットの変更から数秒以内に実行されます。そのため、リクエストを受け取ったことを顧客に通知したり、緊急のチケットを専門チームにルーティングしたりといった、時間に敏感なアクションに最適です。

トリガーの仕組みに関する重要な詳細として、これらはサイクルで実行されます。チケットが作成または更新されると、Zendeskは「トリガー」ページに表示されている順序ですべてのトリガーをチェックします。あるトリガーが実行されてチケットが更新されると、サイクルが再開されます。つまり、1回のチケット更新によって、複数のトリガーが順番に実行される可能性があります。

出典: https://support.zendesk.com/hc/en-us/articles/4408822236058

自動化（Automations）

自動化は、指定された時間が経過した後に実行される時間ベースのルールです。トリガーがイベントに反応するのに対し、自動化は時間に反応します。

一般的な用途としては、X時間放置されているチケットのエスカレーション、保留中のチケットに関する顧客へのリマインド、待機期間後の解決済みチケットの自動終了などがあります。

利用可能な時間ベースの条件には以下が含まれます。

• 作成/オープン/保留/解決からの時間
• 最後の更新からの時間
• 担当者の更新からの時間
• 次のSLA違反までの時間

重要な制限事項が1つあります。自動化は終了（閉鎖）したチケットを変更することはできません。チケットが終了するとロックされ、それ以上の自動アクションは適用されなくなります。

出典: https://support.zendesk.com/hc/en-us/articles/4408832701850

マクロ（Macros）

マクロは、エージェントが手動で適用する事前定義されたアクションのセットです。トリガーや自動化とは異なり、マクロは自動的には実行されません。エージェントが使用するタイミングを選択します。

マクロは、一般的なタスクのショートカットと考えてください。毎日50回同じ回答を入力する代わりに、エージェントはマクロをクリックします。エスカレーションのたびに5つのチケットフィールドを手動で更新する代わりに、1回のマクロクリックですべてを処理できます。これは、複雑な設定なしでエージェントの生産性を高めるシンプルな方法です。

マクロには、書式設定されたテキスト、インライン画像、および最大5つの添付ファイルを含めることができます。これにより、視覚的な要素やドキュメントが必要な標準回答に最適です。

出典: https://support.zendesk.com/hc/en-us/articles/4408844187034

ビュー（Views）

ビューは、特定の基準に基づいて整理されたチケットリストです。厳密には自動化ではありませんが、どのチケットに注意が必要かをチームが監視するのに役立つため、ビジネスルールにおいて不可欠です。

「未割り当てのチケット」、「緊急度の高いチケット」、「顧客の返信待ちが3日以上経過しているチケット」などのビューを作成できます。

出典: https://support.zendesk.com/hc/en-us/articles/4408888828570

---

条件とアクションの理解

ビジネスルールを作成する前に、条件とアクションがどのように連携するかを理解する必要があります。

条件の仕組み

すべてのビジネスルールには、「すべて（All）」と「いずれか（Any）」という2つの条件セクションがあります。

「すべて」の条件は、ルールが実行されるためにすべてが真である必要があります。ここに5つの条件をリストし、4つが満たされていても1つが満たされていない場合、ルールは適用されません。

「いずれか」の条件は仕組みが異なります。少なくとも1つが真であればよく、すべてである必要はありません。これにより、ルール内に「OR（または）」ロジックが作成されます。

実用的な例を挙げましょう。緊急のチケットを提出したVIP顧客に対してトリガーを実行したいとします。条件は次のようになります。

すべて:

• チケット > 優先度 > である > 緊急
• チケット > タグ > 次のタグの少なくとも1つを含む > vip

いずれか:

• チケット > である > 作成された
• チケット > である > 更新された

このトリガーは、チケットが「緊急」かつ「vip」タグを持っている場合に実行されますが、それはチケットが「作成された」とき、または「更新された」ときのいずれかである場合に限られます。

一般的な条件演算子

演算子は、条件と値の関係を定義します。

ステータスフィールドの場合、「より小さい」と「より大きい」はステータスの階層（新規 < オープン < 保留 < 待機中 < 解決済み < 終了）に基づいて機能します。したがって、「ステータスが解決済みより小さい」は、新規、オープン、保留のチケットを対象とします。

出典: https://support.zendesk.com/hc/en-us/articles/4408893545882

利用可能なチケットアクション

アクションは、条件が満たされたときに何が起こるかを定義します。利用可能なアクションはルールの種類によって異なりますが、一般的なオプションには以下が含まれます。

チケットフィールドの更新:

• ステータス（新規、オープン、保留、待機中、解決済み）
• 優先度（低、普通、高、緊急）
• タイプ（質問、インシデント、問題、タスク）
• グループおよび担当者
• タグ（設定、追加、削除）

通知:

• ユーザーにメールを送信（リクエスタ、担当者、特定のエージェント）
• グループにメールを送信
• ツイート（X/Twitterチケット用）
• Webhookを通知
• 外部ターゲットを通知

高度なアクション:

• メールによるサイドカンバセーションの作成
• 子チケットの作成
• フォロワーの追加
• ルーティングチャネルの設定
• アクティブなWebhookを通知

出典: https://support.zendesk.com/hc/en-us/articles/4408893545882

---

初めてのチケットトリガーの設定

すぐに使える実用的なトリガーを作成する手順を見ていきましょう。

ステップ1：トリガー設定にアクセスする

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

既存のトリガーが実行順にリストされています。順序が重要であることを忘れないでください。一番上のトリガーが最初に実行されます。

ステップ2：トリガー条件を定義する

**「トリガーを作成」**をクリックします。まず条件から始めます。

優先度の高いチケットが届いたときにチームに通知するトリガーを作成してみましょう。

「すべて」の条件:

• チケット > 優先度 > である > 高
• チケット > である > 作成された

「チケット > である > 作成された」という条件は非常に重要です。これがないと、優先度の高いチケットが更新されるたびにこのトリガーが実行され、通知スパムが発生してしまいます。

ステップ3：トリガーアクションを設定する

次に、優先度の高いチケットが作成されたときに実行されるアクションを追加します。

1. 通知 > グループにメールを送信 > （緊急対応チームを選択）
2. チケット > タグを追加 > high_priority_alert

タグには2つの目的があります。このルールを実行したチケットを特定するのに役立つことと、関連するトリガーがある場合に重複通知を防ぐために使用できることです。

ステップ4：テストと有効化

**「作成」**をクリックします。新しいトリガーは自動的にアクティブになります。

優先度を「高」にしたテストチケットを作成してテストしてください。以下を確認します。

• 通知メールが届くこと
• タグが適用されていること
• チケットのイベントログにトリガーが表示されていること

期待通りに動作しない場合は、テストチケットのイベントログを確認してください。どのトリガーが実行され、どのアクションが取られたかが正確に表示されます。

出典: https://support.zendesk.com/hc/en-us/articles/4408886797466

---

一般的な自動化のユースケース

自動化は時間ベースのワークフローに優れています。すべてのサポートチームが検討すべき3つの不可欠な自動化を紹介します。

未解決チケットのエスカレーション

この自動化は、チケットが未解決のまま長時間放置されている場合に優先度を上げます。

条件:

• チケット > ステータス > より小さい > 解決済み
• チケット > 作成からの時間 > である > 24
• チケット > 優先度 > ではない > 緊急

アクション:

• チケット > 優先度 > 緊急
• 通知 > ユーザーにメールを送信 > （担当者）

「ステータスが解決済みより小さい」という条件は、新規、オープン、または保留を意味します。「優先度が緊急ではない」という条件は、すでに緊急になっているチケットをさらにエスカレーションするのを防ぎます。

出典: https://support.zendesk.com/hc/en-us/articles/4408883801626

解決済みチケットの自動終了

Zendeskにはデフォルトでこの自動化が含まれていますが、その仕組みを理解しておく必要があります。

条件:

• チケット > ステータス > である > 解決済み
• チケット > 解決からの時間 > である > 96 (4日間)

アクション:

• チケット > ステータス > 終了

96時間のウィンドウは、1時間から28日までの間で変更できます。ほとんどのチームは2〜7日が適当だと考えています。期間を短くするとチケットリストが整理されます。長くすると、顧客が必要に応じて再オープンする時間を確保できます。

出典: https://support.zendesk.com/hc/en-us/articles/4408835051546

保留チケットのリマインダー

この自動化（デフォルトでは無効）は、チケットが保留状態のままになっている場合に顧客にリマインドします。

条件:

• チケット > ステータス > である > 保留
• チケット > 保留からの時間 > である > 24

アクション:

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

これを有効にする前に、カスタマーエクスペリエンスを考慮してください。リマインドメールを役立つと感じる顧客もいれば、特に回答前に情報を集めている最中の場合は、煩わしいと感じる顧客もいます。

出典: https://support.zendesk.com/hc/en-us/articles/4408835051546

---

ビジネスルールのベストプラクティス

以下の慣行に従うことで、ルールの数が増えても混乱を避けることができます。

ルールを整理しておく

一貫した命名規則を使用してください。名前に目的とトリガーイベントを含めます。

• 良い例：「VIP作成 - シニアチームへエスカレーション」
• 悪い例：「エスカレーション用トリガー1」

トリガーカテゴリを使用して、関連するルールをグループ化します。一般的なカテゴリには以下が含まれます。

• ルーティング
• 通知
• エスカレーション
• タグ付け

デプロイ前にテストする

エンタープライズプランにはサンドボックス環境が含まれています。本番環境で有効にする前に、複雑なルールをテストするために使用することをお勧めします。

すべてのプランにおいて、サンプルチケットでテストを行ってください。イベントログをチェックして、トリガーが期待通りに実行され、アクションが正しく適用されていることを確認します。

ルールを文書化する

複雑なトリガーロジックについてはドキュメントを維持してください。複数のトリガーが連携していたり、特定の条件に依存していたりする場合は、その関係を文書化します。

ドキュメントに含めるべき内容：

• ルールが何をするか
• なぜ存在するのか
• 他のどのルールと相互作用するか
• 最後に更新されたのはいつか

監視と改善

ビジネスルールの四半期ごとの見直しをスケジュールしてください。以下の点を確認します。

• このルールはまだ必要か？
• 実行回数が多すぎたり、少なすぎたりしないか？
• 新しいルールとの競合はないか？
• もっと簡素化できないか？

出典: https://support.zendesk.com/hc/en-us/articles/4408882237722

---

高度なチケットアクション

基本をマスターしたら、これらの高度なアクションを使用してワークフローをさらに合理化できます。

サイドカンバセーション

サイドカンバセーションを使用すると、エージェントはチケットの会話にCCとして追加することなく、外部の人と共同作業を行うことができます。

メールによるサイドカンバセーションはトリガー経由で作成できます。これは、特定の条件が満たされたときに外部ベンダーやパートナーを自動的に巻き込むのに便利です。

子チケットのサイドカンバセーションは、他のZendeskアカウントにリンクされたチケットを作成します。これにより、チーム間や企業間のエスカレーションワークフローが可能になります。

サイドカンバセーションのアクションを使用する場合は、タグ（例：「triggered_sc」）を追加し、「タグ > 次のタグを1つも含まない > triggered_sc」という条件を含めるようにしてください。これにより、重複したサイドカンバセーションが作成されるのを防ぐことができます。

出典: https://support.zendesk.com/hc/en-us/articles/4408893545882

Webhook通知

Webhookを使用すると、チケットデータをリアルタイムで外部システムに送信できます。一般的な用途は以下の通りです。

• チケットが解決されたときにCRMレコードを更新する
• 分析プラットフォームにサポートのやり取りを記録する
• 他のアプリケーションでカスタムワークフローをトリガーする

Webhookを使用するには、まず 管理センター > アプリおよびインテグレーション > Webhook でWebhookを作成します。その後、トリガーで「通知 > アクティブなWebhook」アクションを使用します。

出典: https://support.zendesk.com/hc/en-us/articles/4408839108378

チケット共有

エンタープライズプランで利用可能なチケット共有は、他のZendeskアカウントとチケットを自動的に共有します。

ユースケース:

• 特定のチケットタイプをベンダーのサポートチームと共有する
• 親会社のZendeskインスタンスにチケットをエスカレーションする
• 複数のZendeskアカウント間で業務を分散させる

「チケットを共有」アクションを使用するには、アカウント間で共有契約が結ばれている必要があります。

出典: https://support.zendesk.com/hc/en-us/articles/4408887148698

---

AIで自動化をさらに進化させる

ビジネスルールはロジックベースの自動化をうまく処理します。「Xが起きたらYをする」というものです。しかし、文脈、感情、または意図を理解することはできません。

AI搭載ツールはこのギャップを埋めます。ZendeskもいくつかのAI機能（高度なAIアドオンによるインテリジェントなトリアージなど）を提供していますが、専用のAIソリューションはより洗練された自動化を提供できます。

例えば、eesel AIでは、過去のチケットやヘルプセンターのコンテンツから学習し、チケットを自律的に処理します。キーワードに基づいてチケットをルーティングするだけでなく、顧客が何を求めているかを理解し、ナレッジベースに基づいた回答を返します。

その違いは顕著です。ビジネスルールは「もしこれなら、あれをする」というロジックに従います。AIはパターンを学習し、時間の経過とともに改善されます。チケットの量に圧倒されているチームにとって、AIは日常的な質問を処理し、ビジネスルールはワークフローのロジスティクスを管理するという役割分担が可能です。どちらかを選ぶ必要はありません。これらは互いに補完し合います。

---

今日からZendeskワークフローの自動化を始めましょう

Zendeskのビジネスルールを使用すれば、コードを書くことなく強力な自動化を実現できます。まずはシンプルに始めましょう。チャネルに基づいたチケットのルーティングや、優先度の高い問題のエージェントへの通知など、一般的なシナリオに対して1つのトリガーを作成してみてください。

慣れてきたら、時間ベースのワークフローのための自動化を追加しましょう。エージェントの最も一般的な回答のためにマクロを設定します。日常的なタスクを自動的に処理するシステムを徐々に構築してください。これがどれほどの時間を節約してくれるか、驚くはずです。

自動化はチームをサポートするためのものであり、人間の判断に取って代わるものではないことを忘れないでください。最高のサポート運営とは、ビジネスルールを使用して繰り返しの作業を処理し、エージェントが人間の対応を必要とする複雑な問題に集中できるようにすることです。

ルールベースの自動化だけでは不十分で、日常的なチケットのインテリジェントな処理が必要だと感じているなら、eesel AIで何ができるか検討してみてください。Zendeskと連携し、既存のコンテンツから学習して時間の経過とともに改善される自律的なチケット解決を提供します。

サポート自動化をルールベースのワークフロー以上に進化させる準備はできていますか？ eesel AIを無料でお試しください。ビジネスルールがワークフローのロジスティクスを管理する一方で、AIがどのように日常的なチケットを処理できるかをご確認いただけます。