2026年にZendeskマクロの入力フィールドを使用してエージェントにプロンプトを表示する方法

Zendesk（ゼンデスク）のマクロで、送信前にエージェントが特定の詳細を入力するように求められたらいいのに、と思ったことはありませんか？　サポートチームはどこでも同じ不満を抱えています。マクロは一貫性を保つのには最適ですが、それぞれの状況に適応できない静的なテンプレートです。

払い戻しのマクロで、エージェントが正確な金額を入力するように求められたらどうでしょう。または、発送状況の更新で、その場で追跡番号を尋ねられたらどうでしょう。それが理想です。しかし、現実には、Zendeskマクロは、エージェントに値を求める入力フィールドをネイティブでサポートしていません。

このガイドでは、この制限が存在する理由、現在チームが使用している回避策、および最新のAIがパーソナライズされたサポート応答に根本的に異なるアプローチをどのように提供するかを説明します。

制限事項の理解：Zendeskマクロがネイティブで入力を求めない理由

まず、根本的な問題から始めましょう。Zendeskマクロは、基本的に、エージェントがワンクリックでチケットに適用できるアクションとテキストの保存されたセットです。標準化には強力ですが、すべての空白がすでに入力されている「おもしろ作文」のように機能します。

入力プロンプトの機能リクエストは、Zendeskコミュニティで長年議論されています。あるユーザーは、問題点を完璧に説明しました。

マクロで動的コンテンツを使用できますが、エージェントに入力を求めるマクロがあると非常に便利です。ユーザーが1か月以内にアカウントをキャンセルした時期に応じて、$ xxxの比例配分された払い戻しを提供するマクロがあります。エージェントは、マクロ内の変数を変更するために注意する必要があります。

Zendesk Community

ネイティブの入力プロンプトがない場合、エージェントはリスクを伴う回避策に頼ります。彼らは、

• 送信する前に、$ XXX_AMOUNT_XXXのようなプレースホルダーマーカーのマクロテキストを手動でスキャンする
• 変数情報を保存した外部メモからコピーアンドペーストする
• 何も見逃さないように、その場でマクロを編集する

その結果、顧客体験の一貫性のなさ、潜在的なエラー、およびすでに複数のチケットを処理しているエージェントの認知負荷の増加につながります。

回避策1：カスタムフィールドとプレースホルダーの使用

最も一般的な回避策は、変数データを保存するためのカスタムユーザーフィールドを作成し、プレースホルダーを使用してマクロでそれらのフィールドを参照することです。

仕組みは次のとおりです。顧客にメンバーシップの有効期限を頻繁に伝える必要があるとします。エージェントが毎回手動でこれを調べる代わりに、次のことを行います。

1. 管理センターで「メンバーシップの有効期限」というカスタムユーザーフィールドを作成します。
2. （API、一括アップロード、または統合を介して）そのフィールドにデータを入力します。
3. プレースホルダー構文を使用してマクロでそれを参照します。

プレースホルダーは次のようになります。

{{ticket.requester.custom_fields.member_expiration_date}}

Ruby構文を使用して日付の書式を設定し、読みやすくすることもできます。

{{ticket.requester.custom_fields.member_expiration_date | date: "%-d %B %Y"}}

これにより、生のタイムスタンプの代わりに、「2026年1月15日」のようなものが出力されます。

制限事項は？これは、Zendeskにすでに保存されているデータに対してのみ機能します。エージェントが新しい情報（その場で計算された比例配分された払い戻し金額など）を入力する必要があるユースケースは解決しません。そのためには、手動編集に戻ります。

回避策2：多言語サポートのための動的コンテンツ

課題が可変データ入力ではなく、多言語のサポートである場合は、Zendeskの動的コンテンツ機能が役立ちます。

動的コンテンツを使用すると、さまざまな言語のコンテンツバリアントを作成し、次のようなプレースホルダーを使用してマクロでそれらを参照できます。

{{dc.welcome_message}}

エージェントがマクロを適用すると、Zendeskはユーザーのロケール設定に基づいて適切な言語バージョンを自動的に表示します。

このアプローチにより、マクロライブラリの複雑さが軽減されます。言語ごとに個別のマクロを作成する代わりに、適切なコンテンツを動的にプルする1つのマクロを維持します。

動的コンテンツは依然として静的です。エージェントに入力を求めることはありません。定義したルールに基づいて、事前に記述されたコンテンツから選択するだけです。

回避策3：明確なプレースホルダーを使用したエージェントの手動編集

他の回避策が適合しない場合、多くのチームは送信前にマクロを手動で編集するようにエージェントをトレーニングすることに頼ります。ここでの鍵は、見落としにくい、明白なプレースホルダーマーカーを使用することです。

テキストに溶け込む微妙なプレースホルダーの代わりに、次のようなマーカーを使用します。

• $ 50.00の代わりに$ REFUND_AMOUNT $
• 偽の追跡コードの代わりに[[TRACKING_NUMBER]]
• エージェント固有のパーソナライズの場合は{{AGENT_NAME}}

このアプローチのベストプラクティス：

• すべてのマクロで一貫した書式設定を使用する
• エージェントに何を置き換えるかを思い出させるマクロの説明にコメントを含める
• 新入社員をこのワークフローで具体的にトレーニングする
• 送信されたチケットを定期的に監査して、間違いを見つける

リスクは人的エラーです。急いでいるエージェントがプレースホルダーを見逃し、「$ REFUND_AMOUNT $の払い戻しが処理されました」という応答を顧客に送信する可能性があります。見栄えが良くありません。

より良いアプローチ：eesel AIによるAI搭載の動的応答

これらの回避策はすべて、根本的な制限に対するパッチです。マクロは、サポートが多くの人に同じ応答を送信することを意味していた時代に設計されました。今日の顧客はパーソナライズを期待しています。McKinseyの調査によると、顧客の71％がパーソナライズされたエクスペリエンスを期待しており、企業がそれを提供しない場合、76％が不満を感じています。

これは、AIが方程式全体を変える場所です。

eesel AIは、マクロとは異なる方法で機能します。静的なテンプレートの代わりに、既存の知識（過去のチケット、ヘルプセンターの記事、マクロ、接続されたドキュメント）から学習し、それぞれの状況に合わせてパーソナライズされた応答を作成します。

実際には次のようになります。

• エージェントが払い戻しリクエストに関するチケットを開きます
• eesel AIがチケットを分析し、ナレッジベースから関連するコンテキストをプルし、応答を作成します
• 応答には、プレースホルダーの検索なしでパーソナライズされた詳細が含まれています
• エージェントは確認し、必要に応じて編集して送信します

置き換える$ XXX_AMOUNT_XXXはありません。手動でのデータ入力は不要です。チームが書いたように聞こえる、状況に応じた適切な応答です。

ドラフト作成以外にも、eesel AIはマクロでは実行できないリアルタイムアクションを実行できます。

• Shopifyで注文の詳細を調べる
• データベースでサブスクリプションのステータスを確認する
• Jira Service Managementで課題を作成する
• ConfluenceまたはGoogleドキュメントからデータを参照する

また、従来の自動化のオールオアナッシングのアプローチとは異なり、eesel AIをCopilotモード（エージェントレビュー用の応答のドラフト作成）から開始し、信頼が高まるにつれて完全な自律性に徐々に拡大できます。過去のチケットでシミュレーションを実行して、ライブになる前にどのように実行されるかを確認することもできます。

チームに適したアプローチの選択

では、どのソリューションがあなたの状況に合っていますか？簡単なフレームワークを次に示します。

これをさらに詳しく見ていきましょう。

カスタムフィールドは、次の場合に最適に機能します。 変数データがZendeskにすでに保存されており、頻繁に変更されない場合。メンバーシップレベル、アカウントタイプ、またはサブスクリプション層が良い例です。これらのフィールドを多くのマクロで使用する場合、セットアップの労力は報われます。

動的コンテンツは、次の場合に最適です。 単一のマクロライブラリを維持したい複数の言語をサポートするチーム。可変入力ではなく、スマートなコンテンツ選択についてです。

eesel AIのようなAIソリューションは、次の場合に意味があります。 コンテキストとパーソナライズが必要な、複雑でニュアンスのある応答を処理している場合。エージェントが送信前にマクロ応答をカスタマイズするのにかなりの時間を費やしている場合、AIはその雑用を完全に取り除くことができます。

手動編集は、次の場合に実行可能な短期的なオプションです。 小規模なチーム、限られた予算、および比較的単純な可変ニーズがある場合。ただし、時折発生する人的エラーに備えてください。

移行パスも検討する価値があります。多くのチームはカスタムフィールドから開始し、制限に達し、次のステップとしてAIを検討します。良いニュースは、eesel AIが既存のマクロから学習できるため、現在のワークフローへの投資が無駄にならないことです。

今すぐ動的なサポート応答の作成を開始する

制限は現実です。Zendeskマクロは、エージェントに値を求める入力フィールドをネイティブでサポートしていません。回避策（カスタムフィールド、動的コンテンツ、手動編集）があり、それぞれに独自のトレードオフがあります。

しかし、ここにはより大きな全体像があります。パーソナライズされたサポートへの期待は高まり続けています。顧客は、基盤となる情報が標準化されている場合でも、定型的な応答を受けているように感じたくありません。彼らは、聞かれ、理解されていると感じたいのです。

それがAIが実現する変化です。プレースホルダーや回避策と格闘する代わりに、各顧客の状況に合わせて真にパーソナライズされた応答を得ることができます。手動での変数の置き換えは不要です。顧客に$ REFUND_AMOUNT $を送信するリスクはありません。高速で正確、人間のようなサポートです。

静的なマクロから移行する準備ができている場合は、eesel AIがZendeskとどのように統合されるかをご覧ください。エージェントが確認するAI作成の応答から開始し、結果を確認したら完全な自動化に拡張できます。セットアップには数週間ではなく数分かかり、ライブの会話に触れる前に過去のチケットでテストできます。