Zendeskトリガーを使用してフォームごとにチケットを自動的にタグ付けする方法

顧客がZendeskヘルプセンターの異なるフォームからチケットを送信すると、それらのチケットは多くの場合、キュー内で同じように見えます。バグレポートは、販売に関する問い合わせと同じように見えます。ITサポートのリクエストは、一般的な質問と違いはありません。これにより、チケットの優先順位付け、ルーティング、およびレポートを効果的に行うことが困難になります。

解決策は、Zendeskトリガーを使用して、使用されたフォームに基づいてチケットを自動的にタグ付けすることです。これにより、より優れたルーティング、レポート、および応答ワークフローを強化する即時の分類が作成されます。

これを設定する方法を詳しく見ていきましょう。

Zendeskでフォームごとにチケットをタグ付けする理由

フォームベースのタグ付けがない場合、チームは受信するすべてのチケットを手動で分類するのに時間を浪費します。エージェントは、それぞれのチケットを読んで、それが何に関するもので、どこに送られるべきかを把握する必要があります。これにより、遅延と一貫性のない分類が発生します。

フォームベースのタグ付けは、チケットが作成された瞬間に自動的にタグを適用することで、これを解決します。これにより、次のことが可能になります。

• 手作業なしで即座に分類。 タグはフォームの選択に基づいて自動的に表示されるため、エージェントはすぐにどのような種類の問題を見ているかを知ることができます。

• 専門チームへのより良いルーティング。 タグ付けされたチケットを特定のグループにルーティングする追加のトリガーを作成できます。ITサポートのチケットはITチームに直接送信されます。販売に関する問い合わせはすぐに販売キューに入ります。

• リクエストタイプ別の改善されたレポート。 すべてのチケットに一貫したタグが付いているため、カテゴリ別のボリューム、解決時間、および満足度スコアを示すレポートを作成できます。

• より速い応答時間。 チケットが事前に分類され、正しくルーティングされると、適切なエージェントにすばやく到達します。チーム間を移動したり、間違ったキューに座ったりする必要はもうありません。

複雑なルーティングのニーズまたは大量のチケットボリュームを持つチームの場合、eesel AIは、これらのトリガーと連携する代替手段を提供します。当社のプラットフォームは、チケットの内容と意図を理解し、フォームの選択のみに依存せずにインテリジェントにルーティングします。ただし、多くのチームにとって、このガイドで説明されているトリガーベースのアプローチは、まさに必要なものを提供します。

開始する前に必要なもの

トリガーの構成に入る前に、次のものが整っていることを確認してください。

• Zendesk Suite Growthプラン以上（またはSupport Enterprise）。「チケット > フォーム」の条件には、これらのプランレベルが必要です。Teamプランを使用している場合、トリガーにフォーム条件は表示されません。

• トリガーを作成するための管理者アクセス。 ビジネスルール権限を持つカスタムロールの管理者とエージェントのみが、トリガーを作成および変更できます。

• 既存のチケットフォームが設定されていること。 フォームの選択に基づいてタグ付けする前に、少なくとも1つのカスタムチケットフォームを作成する必要があります。デフォルトのフォームしかない場合、このアプローチではまだあまり価値は追加されません。

• 構成に約10〜15分。 各トリガーの設定には数分しかかかりませんが、十分にテストする必要があります。

• ルーティングのニーズを明確に理解していること。 どのフォームがあり、どのタグを適用するか、およびそれらのタグがルーティングまたはレポートにどのように使用されるかを知っておいてください。

フォームベースのタグ付けを超えるより高度なソリューションをお探しの場合は、eesel AIのAIトリアージは、フォームの選択だけでなく、コンテンツ分析に基づいてチケットを自動的にタグ付け、ルーティング、および優先順位付けできます。

フォームベースのタグ付けトリガーを作成するためのステップバイステップガイド

フォームを使用してチケットを自動的にタグ付けするトリガーを作成する方法を次に示します。

ステップ1：トリガーセクションに移動します

Zendeskアカウントにログインし、管理センターに移動します。左側のサイドバーで、次のパスに従います。オブジェクトとルール > ビジネスルール > トリガー。

これは、すべてのチケット自動化が存在する場所です。アカウントに既にある既存のトリガーが表示されます。右上のトリガーを作成ボタンをクリックして、新しいルールを作成します。

ステップ2：トリガーに名前を付けます

トリガーに明確でわかりやすい名前を付けます。優れた命名規則は、サポート業務を拡大するのに役立ちます。次のようなものがあります。

• 「タグ：ITサポートリクエスト」
• 「自動タグ：バグレポートフォーム」
• 「フォームタグ：販売に関するお問い合わせ」

重要なのは一貫性です。数十のトリガーがある場合、フォームベースのタグ付けを処理するトリガーを一目で把握する必要があります。

トリガーが何をするかを説明する説明を追加します。これにより、他の管理者はトリガーを開いて条件を調べることなく、ロジックを理解できます。次のようなものがあります。「ITサポートリクエストフォームから作成されたすべてのチケットに「it_support」タグを追加します。」

ステップ3：条件を設定します

これは、トリガーをいつ起動するかを定義する場所です。次のすべての条件を満たすセクションで、次の2つの条件を追加します。

1. チケット > 次の状態である > 作成された これにより、トリガーがすべての更新ではなく、新しいチケットが作成されたときにのみ実行されるようになります。

2. チケット > フォーム > 次の状態である > [フォーム名] タグ付けする特定のフォームを選択します。ドロップダウンには、利用可能なすべてのチケットフォームが表示されます。

「次のすべてを満たす」を使用すると、トリガーが起動するには両方の条件が真である必要があります。チケットは新しく作成されている必要があり、指定されたフォームを使用している必要があります。

重要：「チケット > フォーム」が条件オプションとして表示されない場合、アカウントに適切なプランレベルがない可能性があります。この条件には、Suite Growth +またはSupport Enterpriseが必要です。

ステップ4：タグを追加するアクションを設定します

次に、これらの条件が満たされたときにZendeskに何をするかを指示します。アクションセクションで：

1. アクションを追加をクリックします
2. ドロップダウンからチケット > タグを追加を選択します
3. 適用するタグを入力します

わかりやすく一貫性のあるタグを選択してください。良い例：

• ITリクエストフォームの場合はit_support
• バグ送信フォームの場合はbug_report
• 連絡先販売フォームの場合はsales_lead
• 製品フィードバックフォームの場合はfeature_request

必要に応じて、スペースで区切られた複数のタグを追加できます。たとえば、sales_lead high_priorityは両方のタグを追加します。

ステップ5：保存してテストします

トリガーを作成をクリックして、新しいルールを保存してアクティブにします。新しいトリガーはすぐにアクティブになります。

次に、テストします。

1. 構成したフォームからテストチケットを送信します
2. Zendeskでチケットを開きます
3. チケットの左側にある[タグ]フィールドを確認します
4. タグが表示されることを確認します

タグが表示されない場合は、チケットのイベントログを確認して、トリガーが起動したかどうかを確認します。以下のトラブルシューティングのヒントを確認することもできます。

タグ付けするフォームごとにこのプロセスを繰り返します。1つの複雑なトリガーに結合しようとするのではなく、フォームごとに個別のトリガーを作成します。これにより、トラブルシューティングがはるかに簡単になります。

フォームベースのタグ付けの一般的なユースケース

フォームベースのタグ付けを使用してワークフローを改善するチームの実際的な例を次に示します。

ITサポートリクエスト

設定： 問題の種類、緊急度、および影響を受けるシステムのフィールドを含む専用の「ITサポートリクエスト」フォーム。

トリガー： すべての送信にit_supportでタグ付けします。

これにより、次のことが可能になります。

• チケットは2番目のトリガーを使用してITチームに直接ルーティングされます
• IT固有のSLAポリシーが自動的に適用されます
• ITマネージャーは、チケットのみにフィルタリングされたビューを作成できます
• レポートは、ITチケットのボリュームと解決傾向を示しています

バグレポート

設定： 再現手順、予想される動作と実際の動作、および重大度のフィールドを含む「バグを報告する」フォーム。

トリガー： 送信にbug_reportでタグ付けします。

これにより、次のことが可能になります。

• エンジニアリングは新しいバグをすぐに確認できます
• 統合トリガーはJiraの問題を自動的に作成できます
• 製品チームは重大度別にバグの傾向を追跡できます
• サポートは技術的な問題をマニュアルでトリアージすることを回避します

販売に関するお問い合わせ

設定： 会社の規模、ユースケース、およびタイムラインをキャプチャする「販売に連絡する」フォーム。

トリガー： 送信にsales_leadおよびオプションでhigh_priorityでタグ付けします。

これにより、次のことが可能になります。

• 営業チームは新しいリードの即時通知を受け取ります
• リードは一般的なサポートキューを完全にバイパスします
• 応答時間SLAは、販売チケットに対してより厳しくすることができます
• マーケティングはソース別にリードボリュームを追跡できます

機能リクエスト

設定： 機能のアイデアとユースケースを収集する「製品フィードバック」フォーム。

トリガー： 送信にfeature_requestでタグ付けします。

これにより、次のことが可能になります。

• 製品チームは手動で並べ替えることなく、整理されたフィードバックを受け取ります
• フィードバックはProductboardやCannyなどのツールにルーティングできます
• サポートは標準マクロでこれらのチケットを閉じることができます
• プロダクトマネージャーはリクエストの傾向を分析できます

フォームベースのタグ付けのベストプラクティス

さまざまなチームに対してこれらのトリガーを数十個設定した後、最も効果的なパターンを次に示します。

フォームごとに1つのトリガーを作成します。 「次のいずれかの条件を満たす」を使用して複数のフォームを処理する単一の複雑なトリガーを作成したくなるかもしれません。そうしないでください。個別のトリガーは、トラブルシューティング、変更、および個別に無効にすることが容易です。「1つのトリガー、1つのジョブ」の原則は、午前2時に何かが壊れた場合に役立ちます。

一貫した命名規則を使用します。 形式を決定し、それに従ってください。form_it_support、it_support、またはit-requestを使用するかどうかにかかわらず、一貫性によりレポートと検索がはるかに簡単になります。タグは大文字と小文字が区別されるため、IT_Supportとit_supportは異なるタグとして扱われます。

トリガーを意図的に順序付けます。 Zendeskはトリガーを上から下に処理します。ルーティングトリガーの前に、フォームベースのタグ付けトリガーをリストの早い段階（「分類」カテゴリ）に配置します。これにより、他のトリガーがルーティングの決定に使用する前にタグが存在することが保証されます。

トリガーロジックを文書化します。 次のリストを含む簡単なスプレッドシートまたは内部ドキュメントを保持します。

• 各トリガーが何をするか
• 追加するタグ
• それらのタグに依存する他のトリガーまたは自動化

このドキュメントは、50以上のトリガーがあり、物事を壊さずに変更を加える必要がある場合に非常に貴重になります。

定期的に監査します。 四半期ごとに、トリガーを確認して未使用のトリガーを削除します。過去30日間に起動していないトリガーを確認します。フォームが廃止された場合は、タグ付けトリガーも削除します。

他の条件と組み合わせて高度なルーティングを実現します。 基本が機能したら、次のような条件を追加できます。

• 組織はVIPです
• チケットの件名に「緊急」が含まれています
• 時刻は営業時間外です

これにより、VIP顧客のチケットを自動的にタグ付けしてエスカレートするなどのことができます。

複雑なシナリオでは、AI搭載のタグ付けを検討してください。 ルーティングロジックがトリガーだけでは複雑すぎる場合は、eesel AIのAIトリアージは、数十の手動ルールなしで高度な分類を処理できます。

一般的な問題のトラブルシューティング

単純なトリガーでも、期待どおりに機能しない場合があります。最も一般的な問題を解決する方法を次に示します。

チケットにタグが表示されない

まず、チケットのイベントログを確認します。実行されたすべてのトリガーと、それが起動したかどうかを確認できます。トリガーがリストされていない場合、条件が満たされていません。リストされているが「スキップ」と表示されている場合は、どの条件が失敗したかを確認します。

一般的な原因：

• チケットはWebフォームではなく、別のチャネル（API、メール）を介して作成されました
• フォーム条件が間違ったフォーム名を探しています
• 別のトリガーがタグを追加した後にタグを削除しています

間違ったタグが適用された

トリガー条件でフォームの選択を再確認します。特に同様の目的で複数のフォームがある場合、フォーム名は似ている可能性があります。条件ドロップダウンには、内部フォーム名（エージェントに表示されるもの）が表示されます。これは、一般に公開されているタイトルとは異なる場合があります。

トリガーがまったく起動しない

すべての条件が満たされていることを確認します。「チケット > 次の状態である > 作成された」AND「チケット > フォーム > 次の状態である > X」がある場合、両方が真である必要があります。APIを介して更新されたチケットは、「作成された」条件をトリガーしません。メールで作成されたチケットは、フォーム条件と一致しません。

他のトリガーとの競合

トリガーは相互に影響を与える可能性があることに注意してください。タグを追加するトリガーとタグを削除するトリガーがある場合、最後に実行されるトリガーが優先されます。トリガーの順序を確認してください。（「次のタグが含まれていない」など）無効化条件を使用して、競合を防ぐこともできます。

ドロップダウンにフォームが表示されない

「チケット > フォーム」が条件オプションとしてまったく表示されない場合、Zendeskプランはそれをサポートしていません。Suite Growth、Professional、Enterprise、またはEnterprise Plusが必要です。または、Support Enterpriseにもこの機能が含まれています。Teamプランは含まれていません。

eesel AIでフォームベースのタグ付けをさらに進める

フォームベースのタグ付けは、顧客が常に適切なフォームを使用する場合にうまく機能します。しかし実際には、彼らは常にそうではありません。請求の問題がある人は、一般的な連絡先フォームを使用する可能性があります。技術的な質問は、販売フォームから送信される可能性があります。フォームは役立ちますが、完璧ではありません。

そこで、eesel AIが登場します。Zendeskと統合されたAIチームメイトとして、eeselはフォームの選択だけでなく、チケットの内容と意図を理解します。どのフォームが使用されたかにのみ依存するのではなく、eeselは顧客が実際に書いた内容を分析し、その理解に基づいてルーティングします。

eeselがトリガーと連携する方法を次に示します。

• コンテンツの理解。 eeselはすべてのチケットを読み、適切なフォームから送信されたかどうかに関係なく、それが何に関するものかを理解します。

• インテリジェントなルーティング。 単純なif / thenルールではなく、eeselはメッセージ自体で検出された意図、感情、および緊急度に基づいてルーティングします。

• 継続的な学習。 チームがチケットを処理すると、eeselは彼らの行動から学習します。手動でルールを更新しなくても、時間の経過とともに分類が向上します。

• 安全な実装。 最初にシミュレーションモードでeeselを実行して、過去のチケットにどのようにタグ付けしてルーティングしたかを確認できます。ライブの顧客とのやり取りにリスクはありません。

チームがフォームベースの自動化を超えている場合、またはフォームの選択だけでは十分な正確な分類が得られない場合は、eeselがZendeskとどのように統合されているかを確認してください。eeselは既存のトリガーと連携して、現在の設定の上にインテリジェントなレイヤーを追加します。