Zendeskでマクロを使ってリクエスターを変更する機能リクエスト：なぜ必要で、どう解決するか

Zendeskインスタンスを管理したことがある方なら、おそらくこの壁にぶつかったことがあるでしょう。チケットを作成し、特定の人をリクエスタとして設定するという、単純で反復的なタスクを自動化したい。そのために、手早く作業をこなすための定番ツールであるマクロに手を伸ばしたものの、優先度の変更、タグの追加、コメントの挿入はできても、リクエスタのフィールドには触れられないことに気づくのです。

これには髪をかきむしりたくなるかもしれませんが、そう感じているのはあなただけではありません。これはZendeskコミュニティで長年議論されている話題です。パートナー、ベンダー、または新入社員のために定期的にチケットを作成するチームは、時間のかかる手作業に追われています。

この記事では、なぜこの機能がこれほどまでに求められているのかを掘り下げ、一般的な回避策（とその深刻な欠点）を検討し、この問題を完全に解決する、よりスマートで現代的なワークフロー自動化の方法を紹介します。

マクロでリクエスタを変更することがなぜ重要なのか

Zendeskマクロはサポートチームにとって非常に役立つツールです。これは基本的に事前に設定されたアクションのレシピのようなもので、エージェントはワンクリックでチケットに適用でき、大幅な時間短縮が可能です。しかし、多くのチケットフィールドを更新できる一方で、「リクエスタ」フィールドは頑なに編集が許可されていません。

このたった一つの制限が、多くの日常的な状況で業務の妨げとなります。これが本当に面倒なことになる一般的なシナリオをいくつかご紹介します。

• プロアクティブサポート： チームが毎月同じベンダーに認証情報のリクエストを送るとします。チケットはエージェントではなく、ベンダーの担当者に割り当てたいものです。しかし、この機能がなければ、毎回手作業で担当者を検索し、設定しなければなりません。

• オンボーディングとオフボーディング： ITチームがMS Power Automateのようなシステムから新しいコンピューターをセットアップするための自動化されたチケットを受け取ります。デフォルトではシステムがリクエスタになりますが、チケットは実際には新入社員のためのものです。エージェントは、新入社員がすべての適切な更新情報を受け取れるように、手動でリクエスタを変更する必要があります。

• リクエストの転送： 顧客が間違った部署にメールを送ってしまいました。エージェントはリクエストを正しい担当者に転送し、その担当者を新しいリクエスタにし、元の送信者をCCに入れる必要があります。単純な引き継ぎであるべきものが、いくつかの手動ステップを伴う作業になってしまいます。

ビジネスへの影響は明らかです。この機能がないことは、クリック数の増加、誤った担当者を選ぶ可能性の上昇、そして応答時間の遅延を意味します。これはツール上の小さな欠点ですが、チームの効率を大きく損なう要因となります。

Zendeskネイティブの回避策：トリガーとWebhook

単純なマクロが使えないため、公式のZendeskフォーラムでは、より技術的な解決策としてトリガーとWebhookの組み合わせがしばしば提案されます。

そのプロセスは次のようなものです。エージェントが特別なタグをチケットに追加するマクロを適用します。常にチケットの更新を監視しているトリガーがそのタグを検知し、作動します。次にトリガーはWebhookを呼び出します。WebhookはZendeskが他のアプリケーションと通信するための手段です。この場合、WebhookはZendesk APIにコマンドを送信し、同じチケットを見つけてリクエスタを更新します。

Webhookを使用する際の問題点

これは技術的には機能しますが、誰もが望むシンプルでワンクリックの解決策とは程遠いものです。このルーブ・ゴールドバーグ・マシンのような仕組みには、いくつかの重大な欠点があり、ほとんどのチームにとって不適切なものとなっています。

• 技術的な頭痛の種： Webhookの設定やAPIコールの記述は、決して簡単な作業ではありません。ほとんどのZendesk管理者にはないレベルの技術スキルが必要で、たった一つのフィールド更新を自動化するためだけに開発者を引き入れる必要があることもしばしばです。

• 脆弱性： この一連のプロセスは簡単に壊れる可能性があります。Zendesk APIが変更されたり、Webhookの認証が失敗したり、誰かが誤ってトリガーを調整したりすると、全体が崩壊します。何が問題だったのかを突き止めるのは、時間のかかる調査になりかねません。

• 拡張性に乏しい： このアプローチは成長に合わせて作られていません。何十ものベンダーと取引がある場合、それぞれに独自のWebhookとトリガーを作成し、維持するのでしょうか？それはすぐに管理上の悪夢となります。

• 遅延が発生する：

  

  コミュニティのユーザーが指摘しているように、リクエスタの変更は即時ではありません

  Reddit
  。更新はチケットが保存された後に行われます。これにより、他のトリガーが古い、誤ったリクエスタ情報に基づいて発動してしまい、混乱を招き、他の自動化を壊す原因となることがあります。

サードパーティアプリ：部分的な解決策

Zendesk Marketplaceには、ネイティブツールの欠点を補うために設計されたアプリが数多くあります。Extended MacrosやSweetHawkのアプリなど、マクロでリクエスタを変更する機能を特に追加するアプリがいくつか見つかります。

そして、その特定のタスクに対しては、それらは仕事を果たします。アプリをインストールし、新しいタイプのマクロを設定すれば、エージェントはついにクリック一つでリクエスタを変更できるようになります。問題解決…ですよね？いえ、完全にはそうではありません。

アプリ乱立の隠れたコスト

一つの穴は塞ぎましたが、単一目的のアプリの寄せ集めに頼ることは、将来的に新たな問題を生み出します。これはしばしば「アプリの乱立（app sprawl）」と呼ばれ、いくつかの隠れたコストを伴います。

• 断片化されたワークフロー： 自動化ロジックがいたるところに散らばってしまいます。一部のルールはネイティブのトリガーに、他はマクロに、さらにいくつかはサードパーティのアプリに隠されています。チケットがシステム内をどのように移動するかを明確に把握することがほぼ不可能になり、トラブルシューティングや更新が非常に困難になります。

• 管理コストの増加： すべてのアプリが管理すべき対象となります。更新が必要で、サブスクリプション料金を支払い、チームは使い方を学ばなければなりません。これにより、総コストと管理者の精神的負担が増加します。

• 限定的な範囲： これらのアプリは特定の単一の問題を解決するために作られています。エージェントがボタンをクリックしたときにリクエスタを変更することはできますが、より大きなニーズであるスマートなエンドツーエンドの自動化には対応できません。例えば、メールを自動的に読み取り、正しいリクエスタを判断し、誰も指一本動かすことなく変更を加えることはできません。

マクロを超えて：AIで問題を解決する

もしかしたら、私たちは会話の視点を変える必要があるのかもしれません。「どうすればマクロでリクエスタを変更できますか？」と問うのではなく、「どうすればチケットが現れた瞬間に、インテリジェントに管理し、分類できますか？」と問うべきなのです。

ここで、現代のAIプラットフォームが根本的により良い答えを提供します。これらは単に欠けている機能を補うだけでなく、脆弱な回避策やアプリの寄せ集めに頼ることなく、ワークフローを自律的に処理する新しい方法を提供します。eesel AIのようなAI搭載プラットフォームは、Zendeskに直接接続してこの問題や他の多くの問題を解決します。

eesel AIがチケット管理を自動化する方法

エージェントが適切なチケットを見つけて適切なマクロを適用する必要はなく、AIエージェントが人間のキューに到達する前にこれらのステップを処理できます。

eesel AIがこの中心的な問題に取り組み、それをはるかに超える方法をご紹介します。

• インテリジェントなトリアージ： **eesel AI Triage**製品は、単に命令に従うだけでなく、文脈を理解します。先ほど話したオンボーディングのリクエストでは、受信メールを分析し、メッセージ内の新入社員の名前とメールアドレスを見つけ、自動的に彼らをリクエスタとして設定し、チケットをITチームに割り当てることができます。手作業は一切不要です。

• カスタムアクション： なぜリクエスタの設定だけで止まる必要があるのでしょうか？**eesel AI Agent**を設定して、一連のアクションを実行させることができます。チケットに「オンボーディング」と「ハードウェアリクエスト」のタグを付け、優先度を「高」に設定し、さらにはカスタムAPIアクションを使用して人事システムで従業員の開始日を検索することも可能です。

eesel AIのカスタマイズとアクションワークフロー画面のスクリーンショット。Zendeskのマクロでリクエスタを変更する機能リクエストの問題を解決します。

• 簡単なセットアップ： Webhookとの格闘に日々を費やすのは忘れましょう。eesel AIはワンクリックの**Zendeskインテグレーション**を提供し、数分で利用を開始できます。開発者を必要とせず、シンプルなダッシュボードから強力なワークフローを構築できます。

• リスクフリーのシミュレーション： 新しいワークフローを有効にする前に、過去の何千ものチケットでシミュレーションモードで実行できます。eesel AIは、リクエスタをどのように変更し、チケットにタグを付け、ルーティングしたかを正確に表示します。これにより、自動化が意図したとおりに機能するという完全な自信を得ることができます。これは、従来のマクロやWebhookでは不可能なことです。

eesel AIのシミュレーション機能を示すスクリーンショット。Zendeskのマクロでリクエスタを変更する機能リクエストの解決策をリスクフリーでテストする方法です。

ワークフローの応急処置はやめて、自動化を始めよう

「Zendeskでマクロを使用してリクエスタを変更する機能リクエスト」は、単にボタンが一つ欠けているという話ではありません。これは、手動のサポートプロセスにおけるより深い限界と、それらを応急処置しようとする終わりのないいたちごっこを指摘しています。

ネイティブの回避策はほとんどのチームにとって技術的すぎ、脆弱であり、一方で単一目的のアプリは一つの問題を解決する代わりに、煩雑で高価な技術スタックを生み出すことを見てきました。

真の解決策は、応急処置からインテリジェントな自動化へと移行することです。eesel AIのようなプラットフォームは、一つの小さな問題を修正するだけでなく、顧客が連絡してきた瞬間からチケットライフサイクル全体を管理するための統一された強力なエンジンを提供します。実現しないかもしれない機能リクエストを待つのではなく、より堅牢で将来性のあるソリューションを今日から導入できます。インテリジェントに自動化を始め、エージェントが最も得意とすること、つまり人々を助けることに集中できるようにする時が来たのです。