Zendeskトリガーと自動化ガイド：最初の自動化を設定する

TL;DR（要約）

Zendeskのトリガーはチケットの作成時や更新時に実行され（割り当て、タグ付け、メール送信などの即時アクション）、自動化はスケジュールに基づいて、または停滞したチケットを検知して実行されます（エスカレーションや自動クローズなどの日常的なメンテナンス）。まずは、チームの週あたりの時間を最も節約できるトリガーを1つ作成しましょう。キーワードによるチケットの割り当て、担当者への通知、解決済みチケットの自動クローズなどが有効です。Zendeskの組み込みトリガーテンプレートを活用して他チームの事例を参考にし、過去のチケットでテストを行い、トリガーログを確認して予期せぬ動作をデバッグしてください。

トリガーと自動化がチームの時間を節約する理由

サポートチームは、チケットの割り当て、フォローアップの送信、リクエストのタイプ別タグ付け、停滞した会話のエスカレーション、解決済みチケットの自動クローズなど、機械がより得意とする反復作業に多くの時間を費やしています。Zendeskのトリガーと自動化は、手作業による負担を軽減するための最初の防衛線です。

トリガーは、チケットが作成または更新された瞬間に実行されます。自動化はスケジュール（毎時、毎日）に基づいて実行されるか、時間の経過とともに条件を満たすチケットを検知します。マクロはこれらとは異なり、エージェントが手動でクリックして一度だけ実行するアクションです。

作成すべき最高のトリガーとは、チームが毎週何十件ものチケットに対して手動で行っている作業を自動化するものです。もしエージェントが毎日15分かけて、適切なチームに届くように製品カテゴリごとにリクエストをタグ付けしているなら、それがトリガーの候補です。もし請求チームが返金リクエストが届くたびに手動で再割り当てしているなら、それもトリガーの対象です。まずはそこから始めましょう。頻度が高く、複雑さが低い、確実に時間を節約できるルールを1つ作成してください。

トリガーを理解する：基本

Zendeskのトリガーは、一連の条件とアクションで構成されます。すべての条件が真であれば、すべてのアクションが即座に実行されます。

トリガーの構造：

• 条件： 「IF チケットステータス = 新規 AND 件名に '請求' を含む」
• アクション： 「THEN 請求チームに割り当て AND エージェントにメール送信 AND 優先度を高に設定」

トリガーが強力な理由は、作成時や更新時に実行されるため、人間が目にする前にチケットが処理される点にあります。これにより、作業が最初から適切にルーティングされ、チームの認知的負荷が軽減されます。

基本的なトリガーの例：

サポートチームがチャット、メール、ヘルプセンターなど、あらゆるチャネルから配送状況に関する質問を受け取っているとします。配送パートナーは注文状況を確認できる公開APIを提供しています。

条件： チケットの件名に "配送" または "追跡" または "注文状況" を含む アクション：

1. 優先度を中に設定
2. タグ "配送に関する問い合わせ" を追加
3. 配送チームに割り当て
4. メール送信：「配送に関するご質問を受け付けました。配送チームに転送いたします」

このトリガー1つで、1日数十件のチケットをキャッチし、手動での分類作業を完全に排除できます。配送チームは、受信トレイのノイズなしで、適切にラベル付けされたチケットを確認できるようになります。

最初のトリガーを設定する

Zendeskにログインし、管理 → オブジェクトとルール → トリガー に移動します。

ステップ1：名前と説明

「請求に関する質問を自動割り当て」や「緊急フィードバックのエスカレーション」など、明確な名前を付けます。「トリガー1」のような一般的な名前は避けましょう。将来、チケットが正しくルーティングされなかった原因をデバッグする際に、自分自身に感謝することになります。

ステップ2：条件を定義する

条件を追加をクリックし、このトリガーがいつ実行されるかを指定します。Zendeskはすべての条件をANDロジックで評価します（すべてが真である必要があります）。一般的な条件：

• チケットフィールド： ステータス、優先度、タイプ、担当者
• テキストフィールド： 件名、説明、コメント（プレーンテキストまたは正規表現をサポート）
• カスタムフィールド： 作成した任意のフィールド
• リクエスタ情報： メールドメイン、ユーザーロール、顧客セグメント
• 時間ベース： 過去N時間以内に作成/更新された

例：すべての新規請求リクエストを請求チームに割り当てる。

条件：

• チケットステータス = オープン
• AND チケットタイプ = 質問
• AND 件名に "請求" または "請求書" または "返金" を含む

ステップ3：アクションを選択する

アクションを追加をクリックし、条件が満たされたときにZendeskが行う動作を選択します。一般的なアクション：

• 割り当て： 特定のエージェントまたはグループに送信
• フィールド値を設定： ステータス、優先度、またはカスタムフィールドを変更
• タグを追加： レポートや自動化のためにチケットにラベル付け
• 通知を送信： エージェント、グループ、または顧客にメール送信
• 通知を作成： チームへのアプリ内アラート
• コメント： 内部メモを自動追加（エージェントのみ、顧客には送信されない）
• Webhook： 外部APIを呼び出し

請求トリガーのアクション例：

1. グループに割り当て： 「請求チーム」
2. 優先度を設定： 「高」
3. タグを追加： 「請求に関する問い合わせ」
4. 通知を送信： 「billing-team@company.com」へ「[顧客名]様からの新しい請求に関する質問」というメールを送信

ステップ4：有効にする前にテストする

トリガーをオンにする前に、条件に一致する過去のチケットを検索します。レポート → 検索に移動し、条件をフィルターとして使用します。それらのチケットは正しく表示されていますか？このトリガーで処理したい内容ですか？

また、意図しない一致がないかも確認してください。条件が「件名に '注文' を含む」で、特定の製品の注文を意図していた場合、無関係なチケットもキャッチしてしまいます。

ステップ5：有効にする

トリガーを作成をクリックします。これでトリガーが有効になり、条件に一致するすべての着信チケットが処理されます。

ステップ6：ログを監視する

トリガーリストに戻り、監査ログをクリックして、トリガーがどのチケットを処理したかを確認します。これはデバッグに非常に役立ちます。チケットが予期せず割り当てられた場合、ログを見ればどのトリガーがなぜ実行されたかがわかります。

すべてのサポートチームが持つべき一般的なトリガー

1. リクエストタイプや製品による自動割り当て

条件： チケットタイプ = バグレポート または 件名に "エラー" または "動作しない" を含む アクション：

• 製品サポートチームに割り当て
• タグ "バグレポート" を追加
• 優先度を「高」に設定

2. 顧客への自動応答送信

条件： チケットステータス = 新規 アクション：

• コメントを追加（内部）：「[タイムスタンプ] 受信。 [担当エージェント] に割り当て済み。」
• 顧客に通知を送信：「お問い合わせありがとうございます。4時間以内に回答いたします。」

これにより、エージェントの手を煩わせることなく、顧客とのつながりを維持できます。

3. 確認後の解決済みチケットの自動クローズ

条件： ステータス = 顧客の返信待ち AND 最終更新 > 7日前 アクション：

• ステータスを「クローズ」に設定
• タグ "自動クローズ" を追加
• 顧客に通知を送信：「返信がないため、このチケットをクローズします。まだサポートが必要な場合は返信してください。」

4. VIP顧客を即座にエスカレーション

条件： リクエスタセグメント = "エンタープライズ" または リクエスタのメールドメイン = company.com アクション：

• 優先度を「緊急」に設定
• VIPサポートチームに割り当て
• 通知を送信：「VIPチケットを受信しました」

5. キーワードによるタグ付けとルーティング

条件： 件名に "返金" を含む アクション：

• タグ "返金リクエスト" を追加
• 請求チームに割り当て
• 内部コメントを追加：「顧客が返金を要求しています。返金ポリシー [リンク] を参照してください。」

自動化：スケジュールに基づく実行

自動化は、チケット作成時ではなく、スケジュールに基づいて、または条件が一定期間継続したときに実行されるトリガーです。自動化は以下のような用途に使用します：

• エスカレーション： 2時間割り当てがない高優先度チケットをマネージャーに通知
• 自動クローズ： 解決済みとしてマークされたチケットを、7日間返信がない場合にクローズ
• 停滞検知： 30日以上非アクティブなチケットにタグ付け
• フォローアップ： 顧客からの返信待ちチケットを24時間ごとにエージェントにリマインド

一般的な自動化：停滞したチケットの自動クローズ

条件： ステータス = 顧客の返信待ち AND 最終更新 > 7日前 アクション：

• ステータスを「クローズ」に設定
• タグ "自動クローズ-停滞" を追加
• 顧客に通知を送信：「1週間非アクティブだったため、このチケットをクローズします。まだサポートが必要な場合はご連絡ください。」

これにより、オープンキューが忘れ去られた会話で埋め尽くされるのを防ぎ、必要に応じて顧客が再オープンできる機会を提供します。

一般的な自動化：緊急チケットのエスカレーション

条件： 優先度 = 高 AND ステータス = オープン AND 担当者 = 未割り当て AND 作成からの経過時間 > 2時間 アクション：

• マネージャーに割り当て（エスカレーションキュー）
• タグ "エスカレーション-緊急" を追加
• マネージャーに通知を送信：「[顧客名]様が2時間待機しています。緊急リクエストのトリアージが必要です。」

トリガーと自動化の一般的な間違いを避ける

重複する条件によるアクションの重複

2つのトリガーがある場合：

• トリガーA：件名に "請求" を含む → 請求チームに割り当て
• トリガーB：件名に "請求書" を含む → 請求チームに割り当て ＆ タグ "請求書" を追加

件名が "請求書" のチケットには両方のトリガーが実行されます。チケットは2回割り当てられ（無害）、タグは1回追加されます。アクションが競合する場合（例：一方が請求チームに割り当て、もう一方が財務チームに割り当てる）、最後に実行されたトリガーが優先され、上書きされます。

解決策： 重複する条件を統合するか、正確なキーワードを使用してください。

通知ループを作成するトリガー

トリガーが送信した通知が新しいチケットとして着信すると、ループが発生する可能性があります。例：「チケット作成 → Slack通知を送信 → Slack通知が新しいチケットとして投稿される → 再びトリガーされる → ループ」。

解決策： 内部通知が新しいチケットをトリガーしないように除外します。チケットを作成する通知の代わりに、内部コメントを使用してください。

条件が広すぎる、または狭すぎる

広すぎる：「件名に '注文' を含む」は「備品を再注文してください」にも一致してしまいます（顧客の注文問題ではない）。 狭すぎる：「件名 = '注文が届きません'」は完全一致のみに反応します。

解決策： 有効にする前に、過去のチケットで条件をテストしてください。バリエーションにはORを使用します：「件名に '注文' または '購入' または '配送' を含む」。

トリガーログを監視していない

トリガーを設定して放置すると、退職したエージェントにチケットが割り当てられたり、解決済みのチケットまでエスカレーションされたりする可能性があります。

解決策： トリガーの監査ログを毎月確認してください。四半期ごとにトリガーのパフォーマンスを見直すカレンダーリマインダーを設定しましょう。

マクロの複雑さを忘れている

マクロはシンプル（ワンクリックのエージェントアクション）ですが、トリガーはスマート（条件＋アクション）です。同じマクロを毎日50回手動でクリックしているなら、自動的に実行されるようにトリガーに変換しましょう。

解決策： エージェントが同じマクロを1日5回以上使用している場合は、トリガー化を検討してください。

アクションビルダーでトリガーを外部システムに接続する

Zendeskのアクションビルダーを使用すると、トリガーでZendesk外の操作が可能になります。Shopify、Jira、Slack、またはAPI対応ツールへのWebhookを呼び出すことができます。

例：Shopifyで返金をトリガーする

条件： チケットタイプ = 返金リクエスト AND ステータス = 新規 アクション：

1. 請求チームに割り当て
2. Shopify APIへのWebhook呼び出しを作成：
   • URL: https://shopify-store.myshopify.com/admin/api/2024-01/orders/{order_id}/refunds.json
   • メソッド: POST
   • ボディ: {"refund": {"line_items": [{"id": item_id, "quantity": 1}]}}

これにより、返金リクエストが届いた瞬間にShopifyで返金処理が自動的に開始され、チケット1件あたり10分の手作業が削減されます。

例：VIP顧客が到着したときにSlackで通知する

条件： リクエスタセグメント = "エンタープライズ" AND ステータス = 新規 アクション：

1. VIPサポートチームに割り当て
2. SlackへのWebhook呼び出しを作成：
   • URL: https://hooks.slack.com/services/YOUR/WEBHOOK/URL
   • メソッド: POST
   • ボディ: {"text": "VIPチケット受信 [顧客名]: {{ticket.requester.name}}: {{ticket.subject}}"}

VIPチケットが届いた瞬間にチームがSlackで通知を受け取るため、キューで見落とされることはありません。

トリガーの影響を測定する

トリガーを設定した後、以下を追跡してください：

1. エージェントの入力なしで割り当てられたチケット数 - 最上位のトリガーが週に何件のチケットを自動割り当てしているか？
2. チケットあたりの節約時間 - トリガーが2分の手作業を節約し、週に100件のチケットが一致する場合、週に3時間以上の節約になります。
3. エラー率 - トリガーによって誤って割り当てられたチケットはいくつあるか？監査ログを確認してください。
4. 顧客満足度 - （適切なルーティングによる）応答時間の短縮は、CSATスコアに反映されているか？

トリガー設定前にベースラインを設定し、2週間後に再度測定してください。ほとんどのチームは、適切に設計されたトリガーを1つ導入するだけで、5〜10％の時間の節約を実感しています。

eeselを試す

手動でのトリガー管理がチームにとって過剰だと感じたり、トリガーでは対応できないエッジケースを処理したい場合は、eeselのような自律型AIエージェントが、人間の介入なしにチケットカテゴリ全体を解決できます。エージェントはナレッジベースや過去のチケットから学習し、統合されたシステム（Shopify、Jiraなど）にまたがる多段階の問題を処理し、確信が持てない場合のみエスカレーションを行います。

Zendeskと併用してeeselを使用しているチームは、トリガー設定なしで、導入直後から70〜85％の一次対応自動化を実現しています。eeselの詳細は https://www.eesel.ai をご覧ください。