カスタマーヘルススコアのモニタリングにZendeskチケットトリガーを使用する方法

サポートチームは、顧客が苦労していることを最初に知ることがよくあります。チケットのボリュームが急増し、エスカレーションのパターンが変化し、感情が変化します。しかし、その知識は、解約を防ぐためにカスタマーサクセスチームに間に合うように届くことはめったにありません。

カスタマーヘルススコアは、このギャップを埋めます。これらは、サポートデータと製品の使用状況、エンゲージメント、および関係の質を組み合わせて、更新の会話が始まる60〜90日前にリスクのあるアカウントにフラグを立てる予測メトリックです。そして、Zendesk チケットトリガーを使用すると、これらのスコアへの対応をサポートワークフロー内で直接自動化できます。

このガイドでは、カスタマーヘルススコアに基づいてチケットをルーティング、タグ付け、およびエスカレーションするトリガーの設定について説明します。ゼロから始める場合でも、既存の自動化を改良する場合でも、サポートオペレーションをカスタマーサクセスの成果に結び付ける方法を学びます。

カスタマーヘルススコアとは？サポートでそれらを使用する理由

カスタマーヘルススコアは、顧客が更新、拡張、または解約するかどうかを予測する単一のメトリックであり、通常は0〜100または赤/黄/緑です。顧客関係のクレジットスコアのように考えてください。複数のシグナルを組み合わせます。

• 製品の使用状況（ログイン頻度、機能の採用）通常、スコアの40％
• サポートチケットのボリュームと重大度 10〜20％の重み付け
• エンゲージメントパターン（メールの開封、会議への参加）
• 関係の質（CSMパルス、NPSスコア）

サポートのやり取りは、アカウントの健全性の先行指標です。頻繁にチケットを提出する顧客は、多くの場合、製品に苦労しています。エスカレーションは不満を示しています。解決時間が長いほど、満足度が低くなります。これらのシグナルを自動トリガーに接続すると、サポートは受動的ではなく、プロアクティブになります。

ルールベースの自動化を超えるチームのために、トリガーが不十分なシナリオを処理するためにeesel AIを構築しました。チケットの感情の解釈、コンテキストの理解、および単純なフィールドマッチング以上のものを必要とする判断の実行です。ただし、簡単なヘルススコアのルーティングには、Zendeskトリガーが適切な出発点です。

ヘルススコアトリガーを設定するための前提条件

トリガーを構築する前に、次のことを確認してください。

• Teamプラン以上のZendesk Support カスタムフィールドと高度なトリガーは、従来のEssentialプランでは利用できません
• 管理者アクセス カスタムフィールドとトリガーを作成するためのアクセス許可が必要です
• ヘルススコアデータソース これは、CRM統合（Salesforce、HubSpot）、カスタマーサクセスプラットフォーム（Gainsight、ChurnZero）、またはCSチームからの手動入力である可能性があります
• 基本的なトリガーの知識 条件とアクションがどのように連携するかを理解する

事前に知っておくべき重要な制限事項：Zendeskトリガーは、「ヘルススコア < 40」のような数値のしきい値を評価できません。ドロップダウンフィールドまたはタグを使用してこれを回避する必要があります。これについては、以下の手順で説明します。

ステップ1：ヘルススコアデータを保存するためのカスタムフィールドを作成する

まず、各チケットにヘルススコアデータを保存する場所が必要です。[管理センター → オブジェクトとルール → チケット → フィールド]に移動し、[フィールドを追加]をクリックします。

フィールドタイプを慎重に選択してください。 Zendeskのトリガーシステムには制限があります。

• 数値フィールド：「存在」または「存在しない」演算子のみをサポートします。「60より大きい」のような条件を作成することはできません。
• テキストフィールド：同じ制限事項 トリガーでのコンテンツマッチングはありません。
• ドロップダウンフィールド：「である」、「でない」、「存在する」、「存在しない」演算子をサポートします。これが最適なオプションです。

推奨されるアプローチ：「カスタマーヘルススコア」という名前のドロップダウンフィールドを作成し、次のオプションを設定します。

ワークフローに基づいてフィールドのアクセス許可を構成します。ほとんどのチームは、顧客が自分のヘルススコアを見る必要がないため、これをエージェントのみに制限しています。すべての関連するチケットフォームにフィールドを追加して、すべてのチケットに表示されるようにします。

正確なスコアの代替案：粒度が必要な場合は、データストレージに数値フィールドを使用し、しきい値に基づいて「health_35」または「health_68」のようなタグを適用する別の自動化（Zendesk APIまたは外部ツール経由）を使用します。トリガーは、タグの存在を確認できます。

ステップ2：最初のヘルススコアトリガーを構築する

次に、クリティカルなヘルススコアに対応するトリガーを作成しましょう。[管理センター → オブジェクトとルール → ビジネスルール → トリガー]に移動し、[トリガーを追加]をクリックします。

明確に名前を付けます。 他の管理者が開かなくてもその目的を理解できるように、「エスカレーション：クリティカルなヘルススコアカウント」のような説明的な名前を使用します。トリガーが何を行い、なぜ存在するのかを説明する簡単な説明を追加します。

条件を設定します。 「次のすべての条件を満たす」で、次を追加します。

1. チケット > カスタマーヘルススコア > である > クリティカル（0〜40） これにより、トリガーがリスクのあるアカウントに対してのみ発動することが保証されます。
2. チケット > ステータス > でない > 解決済み 閉じられたチケットでトリガーが発動するのを防ぎます。

「すべて満たす」を使用すると、両方の条件がtrueである必要があります。単一の条件が一致した場合にトリガーを発動する場合は、代わりに「いずれかを満たす」を使用します。

アクションを構成します。 条件が満たされた場合、トリガーは次のことを行う必要があります。

1. 優先度 > 緊急 チケットをキューの先頭に移動します
2. タグを追加 > critical_health_score, escalation_needed レポートを有効にし、重複するトリガーを防ぎます
3. グループ > エスカレーション または シニアサポート 経験豊富なチームにルーティングします
4. 通知 > ユーザーメール > （担当者） 割り当てられたエージェントにコンテキストを通知します

通知メールには、エージェントがこのチケットが緊急である理由を理解できるように、関連するプレースホルダーを含めます。

件名：緊急：クリティカルなヘルススコアカウント {{ticket.title}}

このチケットは、クリティカルなヘルススコア（0〜40）を持つ顧客からのものです。
優先順位を付けて、プロアクティブなアウトリーチを検討してください。

チケット：{{ticket.link}}
顧客：{{ticket.requester.name}}
ヘルススコア：{{ticket.ticket_field_xxxxxxxx}}

[保存]をクリックし、ヘルススコアがクリティカルに設定されたテストチケットを作成してトリガーをテストします。すべてのアクションが正しく発動することを確認します。

ステップ3：完全なカバレッジのために追加のトリガーを作成する

1つのトリガーだけでは十分ではありません。さまざまなヘルスシナリオを処理する完全なセットを構築します。

リスクのあるアカウントのルーティング

まだ危機に瀕していないが、注意が必要な41〜60の範囲の顧客のトリガーを作成します。

条件：

• チケット > カスタマーヘルススコア > である > リスクあり
• チケット > チケット > である > 作成済み

アクション：

• グループ > CSMキュー（カスタマーサクセスのフォローアップ専用キュー）
• タグを追加 > at_risk, proactive_outreach
• 優先度 > 高

繁栄しているアカウントの拡張シグナル

ヘルススコアの高い顧客は、拡張の機会を提供します。これらの顧客にアカウント管理チームのフラグを立てるトリガーを作成します。

条件：

• チケット > カスタマーヘルススコア > である > 繁栄
• チケット > コメントテキスト > 次の単語の少なくとも1つを含む：アップグレード 拡張 追加シート ユーザーの増加

アクション：

• タグを追加 > expansion_opportunity, thriving_account
• 通知 > ユーザーメール > （アカウントマネージャー）
• グループ > アカウント管理

ヘルススコアの変更通知

顧客のヘルススコアがクリティカルに低下した場合、CSチームはすぐに知る必要があります。

条件：

• チケット > カスタマーヘルススコア > 変更元 > [任意の値] > 変更先 > クリティカル

アクション：

• 通知 > ユーザーメール > （カスタマーサクセスマネージャー）
• 内部メモを追加 > 「ヘルススコアがクリティカルに変更されました。以前のスコア：[以前の値]」

高度なトリガー構成

基本的なヘルススコアトリガーが機能したら、追加の条件を重ねて、より高度なルーティングを実現します。

ヘルススコアと他の条件の組み合わせ

ヘルススコアだけでは、全体像を把握できません。これらの条件を追加して、トリガーを絞り込みます。

• 組織 > 組織（レコード） エンタープライズアカウントをシニアエージェントにルーティングし、SMBを一般キューにルーティングします
• チケット > チャネル チャットチケットをメールとは異なる方法で処理します（チャットは多くの場合、緊急性を示します）
• チケット > 営業時間内ですか？ 営業時間中はクリティカルなスコアをすぐにエスカレーションし、営業時間外は翌日まで保留します
• チケット > 休日ですか？ 応答時間の期待値を調整します

数値のしきい値の回避策としてタグを使用する

ドロップダウン範囲よりも詳細な情報が必要な場合は、タグを使用します。外部システム（CRM、Zapierワークフロー、またはカスタムアプリ）は、正確なヘルススコアを計算し、「health_35」または「health_68」のようなタグを適用します。

トリガーは、タグの存在を確認します。

• タグ > 次のいずれかのタグを含む > health_30 health_31 health_32 health_33 health_34 health_35
• これにより、ドロップダウンでは提供できない正確なしきい値制御が可能になります

トレードオフ：スコアが変化するにつれてこれらのタグを維持するには、外部自動化が必要です。

健全なアカウントからの価値の低いチケットを自動的にクローズする

最高のサポートはセルフサービスである場合があります。繁栄している顧客からの簡単な質問については、自動解決を検討してください。

条件：

• チケット > カスタマーヘルススコア > である > 繁栄
• チケット > タイプ > である > 質問
• チケット > 優先度 > である > 低

アクション：

• 通知 > ユーザーメール > （リクエスター）ナレッジベースの記事の提案付き
• ステータス > 解決済み

これを控えめに、そして本当にリスクの低いシナリオでのみ使用してください。目標は効率であり、健全な顧客を無視されたと感じさせないことです。

トリガーのテストとトラブルシューティング

トリガーには予期しない相互作用がある可能性があります。本番環境で信頼する前に、徹底的にテストしてください。

Zendeskのテストチケット機能を使用します。 さまざまなヘルススコア値を持つチケットを作成し、各トリガーが期待どおりに発動することを確認します。アクションが正しく適用されることを確認します（タグが追加され、優先度が変更され、通知が送信されます）。

トリガーの発動順序を確認します。 トリガーは、リストに表示される順に実行されます。2つのトリガーが同じチケットに適用される可能性がある場合は、位置が重要です。[管理センター]の[並べ替え]オプションを使用して、最も具体的なトリガーから最も一般的なトリガーに配置します。

チケットイベントを確認します。 チケットを開き、[イベント]をクリックして、どのトリガーがどの順序で発動したかを確認します。これはデバッグに非常に役立ちます。

一般的な問題と修正：

eesel AIによるヘルススコアの自動化のスケーリング

ルールベースのトリガーは、明確なシナリオには適していますが、制限があります。コンテキストを解釈したり、感情を理解したり、過去の結果から学習したりすることはできません。トリガーは「ヘルススコアがクリティカル」と認識しますが、チケットを読んで理由を理解したり、適切な対応を判断したりすることはできません。

ここで、私たちがお手伝いできます。eesel AIでは、過去のチケットから学習してヘルススコアを自動的に予測するAIエージェントを構築しました。外部のCRMデータに依存する代わりに、当社のAIはチケットの感情、緊急性、および顧客履歴を読み取って、インテリジェントなルーティングの決定を行います。

チームが通常アプローチを進化させる方法は次のとおりです。

1. トリガーから始める このガイドの手順を使用して、ルールベースの自動化を構築します
2. AIトリアージを追加する eesel AIトリアージを使用して、チケットの内容に基づいて自動的にタグ付けとルーティングを行います
3. 完全なAIエージェントに進む AIに健全なアカウントの最前線の対応を処理させ、リスクのある顧客を人間にエスカレーションします

当社のZendesk統合は、既存のセットアップに直接接続します。トリガーを一夜にして置き換えることはありません。代わりに、パフォーマンスを検証するにつれて、より複雑な決定をAIに徐々に引き渡します。

主な違い：トリガーはフィールドに反応しますが、AIはコンテキストを理解します。トリガーは「ヘルススコアがクリティカル」に基づいてルーティングできます。AIは「代替案を評価しています」というチケットを読み取り、正式なヘルススコアがまだ更新されていなくても、解約リスクを認識できます。