サポートデータのセグメンテーション：顧客ティア・プラン・地域でチケットを切り分ける方法

要点

サポートデータのセグメンテーションは、ある一点でつまずきます。ティアは顧客に保存されているのに、レポートが読むのはチケットだということです。Gorgias、Help Scout、Frontでは、顧客レベルのフィールドはルールやビューでは使えますが、分析フィルターはタグや会話フィールドなどチケットレベルのデータを読みます。チケットにコピーしていないティアは、レポートからは見えません。

解決策はどのツールでも同じです。ティア、プラン、地域を単一の信頼できる情報源（CRMまたは請求システム）に置き、ルールで新しいチケットごとにタグまたはフィールドとしてコピーします。そうすれば同じフィールドがレポート、振り分け、SLA目標を動かします。プランの制約にも注意してください。セグメント別SLAにはHelp Scout Plus、Front分析のアカウントフィルターにはProfessionalが必要で、ZendeskのSLAポリシーはエントリースイートにはありません。

私はeeselでAIエージェントを作っており、どのエージェントも回答の前にこれらのフィールドを読みます。Zendeskをお使いのB2Bテレマティクス企業が、営業の通話でまさにこれをeeselに求めてきました。定義済みのタグリストからの自動タグ付けと、チケットフィールドの自動入力です。このトピックの層は、eeselのAIチームメイトがヘルプデスクの中で担当するので、エージェントが手作業でタグ付けしなくてもセグメントがきれいに保たれます。

サポートデータのセグメンテーションが実際に扱う範囲

セグメンテーションとは、平均値が問題を隠さないようにサポートデータを分けることです。初回応答時間の中央値が4時間なら問題なさそうに見えても、上位20アカウントはより難しい内容で問い合わせるため、その2倍待たされているかもしれません。

私は、すべてのチケットに3つの層があると考えています。

• 誰： 顧客ティア、プラン、地域、売上、顧客生涯価値。これは顧客に属するもので、CRMまたは請求システムから取得するべきです。
• 何： トピック、製品領域、意図。これはチケットに属し、毎回変わります。
• どのように： チャネル（メール、チャット、電話、SNS）。ヘルプデスクが自動で記録します。

「どのように」の層は無料です。「何」の層はチケットタグ付けの領域で、多くのチームがすでに苦労しているところです。「誰」の層は、レポートに静かに届かなくなる層なので、このガイドの主題です。

タグ付けの一貫性が最初に崩れるのはよくあることです。あるカスタマーサクセスのリーダーがRedditでこう書いています。

"Tried tagging tickets ourselves for a few months which worked fine the first month, then fell apart the second we onboarded a couple more csms and every one of them tagged things their own way."

u/yuuliiy in r/CustomerSuccess, Reddit

ティアのデータがレポートに現れない理由

5つのヘルプデスクのドキュメントを調べて見つけたパターンがあります。顧客データは、顧客、連絡先、組織、アカウントに保存されます。ルールやビューは通常それを読めます。ところが分析モジュールは、チケットレベルのデータで絞り込みます。

具体例を3つ挙げます。

• Gorgias： Analyticsのフィルターは日付、エージェント、チャネル、連携、ストア、タグ、チケットフィールド、品質です。顧客フィールドのフィルターはありますが、AnalyticsではなくViewsにあります。
• Help Scout： Report Viewsは受信箱、タグ、フォルダー、カスタムフィールドで絞り込みます。顧客プロパティはこの一覧にありません。
• Front： 分析のカスタムフィールドフィルターが対象とするのは会話のカスタムフィールドだけで、型はText、Dropdown、Yes/Noです。連絡先のカスタムフィールドは対象外ですが、アカウントは対象です（Professionalの場合）。

つまり、「スタンプ」の手順こそが仕事のすべてです。チケット作成時に発火し、顧客のティアをタグまたはフィールドとしてチケットに書き込むルールです。Frontは自社のルールのドキュメントでほぼそのまま述べています。Revenue、Tier、Regionをアカウントに保存し、ルールでVIPタグを付け、そのタグを "to filter conversations in analytics, views, and other rules" 使う、という流れです。

スタンプにはもう一つ利点があります。チケット作成時点のセグメントを固定できることです。アカウントが来月GrowthからEnterpriseにアップグレードしても、先四半期のチケットはGrowthのまま集計されます。通常はこれが望ましい動きです。

各ヘルプデスクでセグメントデータが置かれる場所

eeselの導入で最もよく見る5つのヘルプデスクを比較しました。価格は2026-10-06時点で各社の料金ページに表示されていたものです。

目を引く点が2つあります。レポートでチケットとアカウントデータをネイティブに結合できるのはZoho Deskだけです。カスタムレポートで主モジュールと関連モジュールを選べるためです。ほかのツールでは、チケットにコピーするルールが必須です。

また、最も安いプランで全部をこなせることはまれです。Help Scoutは、ワークフローでの顧客プロパティ条件をPlusまたはProに限定しています。FrontはStarterをルール10個までに制限しており、ティア、地域、プランにそれぞれ1つ必要になると、すぐに足りなくなります。

ヘルプデスクを選ぶ：セグメンテーションのレシピ

ご利用のヘルプデスクをクリックすると、顧客データから絞り込み可能なレポートまでの正確な手順が表示されます。

Zendesk：ティアは組織が持つ

Zendeskでティアの置き場所として自然なのは組織です。メールドメインを組織に紐付けておけば、顧客のドメインから来る全員が自動的にその組織に入ります。ドロップダウン形式の組織フィールドを使うと、ティアが各メンバーのチケットに付いて回るタグになります。

大口顧客のドメインからのチケットをTier 1として扱う方法を尋ねられたZendeskの管理者が、Redditでまさにこのレシピを紹介していました。

"I would create an Organization drop-down field for your Tiers. This will apply a tag to that Org, and anytime an End User that's in the Org submits a ticket, they will have the Tier tag applied directly to the Ticket. Next you would setup the SLA's and use the "Tag contains the following" for each Tier."

u/Camperkris in r/Zendesk, Reddit

そこから、SLAポリシーでティアのタグを条件に使えます。条件には標準フィールドとカスタムフィールドの両方を指定できるためです。SLAポリシーにはSuite Growth以上（またはSupport Professional）が必要です。現在のZendesk料金ページでは、年払いでSuite Teamがエージェント1人あたり月$55、Suite Professionalが月$115と表示されています。ティア別の目標を運用するなら、上位プランを予算に入れてください。目標値は私のZendeskのSLA解説で、どの値に設定するかはSLAのベストプラクティスで扱っています。

月に約5,000件のチケットを扱うあるチームは、これをどこまで活用しているかを説明していました。

"We utilize a tiering system for organizations by MRR. We utilize that tier to set the priority of tickets and have the incoming ticket queue sorted by priority and grouped by SLA. Our top tier orgs have a 1 hour FRT, tiers 2 & 3 have a 2 hour FRT and so on."

u/AccomplishedMud9169 in r/Zendesk, Reddit

レポートでは、ティアのタグが確実な選択です。組織ごとのSLA結果をレポートしたい場合は、初回返信時間のレシピが応用しやすい雛形になります。

Gorgias：Shopifyデータが仕事の半分を担う

Gorgiasには、ECチームにとっての強みがあります。Shopifyのデータがすでにあることです。ルール用語集には、顧客の注文数、累計購入額、顧客タグ、作成日が条件として載っており、累計購入額は高価値顧客の判別に役立つと説明されています。そのため、ルールで "total spent greater than $1,000" を読み取って優先度を設定したりVIPチームに割り当てたりでき、CRM同期は一切不要です。eeselのGorgias連携も、回答の前に同じShopifyのコンテキストを読みます。

Shopifyが把握していない情報には、顧客フィールドがあります。Yes/No、Dropdown、Number、Textの型があり、全Helpdeskプランで使えます。ドキュメントにある3つの落とし穴です。

• 同時に有効にできる顧客フィールドは4つだけです。5つ目を使うには、どれかをアーカイブする必要があります。
• フィールドの型は作成後に変更できません。
• Shopifyのメタフィールド（ストアごと、カテゴリごとに最大10個）は、インポート後に作成または更新された顧客と注文にしか表示されないため、古い顧客は再購入するまで空のままです。

次にスタンプを追加します。Analyticsは顧客フィールドで絞り込めないため、同じルールに "Add tags" または "Set ticket field" を加えます。ルールの手順はVIPタグのガイドで説明しています。

命名については、ティアのタグは短く、接頭辞付き（tier_gold、tier_silver）にして並び順がまとまるようにしてください。そのほかはGorgiasのタグで扱っています。Gorgiasはシート数ではなくチケット量で課金されます。料金ページによると、Starterは50チケットで月$10、Proは2,000チケットで$360です。

Help Scout：プロパティはあるが、プラン制限つき

Help Scoutはデータをきれいに分けています。顧客プロパティは、プラン名や請求ステータスのような連絡先レベルの事実を保持します（連絡先50個、会社50個まで）。会話のカスタムフィールドは、質問の種類のようなチケットごとの事実を保持します。

問題はプランです。Customer PropertyとCompanyのワークフロー条件にはPlusまたはProが必要で、SLA条件も同様です。Standardでは、条件をまったく付けられないSLAポリシーが1つだけです。

構築前に知っておきたい注意点がもう2つあります。

• 新しいSLAポリシーは、ポリシー作成後に作られた会話にのみ適用されます。SLAのドキュメントに記載があります。すでに溜まっているエンタープライズのチケットは対象になりません。
• 会社プロパティはAPI経由でしか更新できません。ZapierとBeacon Identifyはまだ対応していません。

表示価格ではPlusがユーザー1人あたり月$45、Proが月$75です。完全な表はHelp Scoutの料金の解説にあります。手作業なしでトピックタグも付けたい場合、Help Scout向けのAIタグ付けが「何」の層を埋め、eeselのHelp Scout連携は受信箱の中でそれを行います。

Front：アカウントが適切な置き場所

Frontのアカウントは取引先の企業を表し、全プランで使えます。Revenue、Account Manager、Account Tierなどのアカウントのカスタムフィールドは、Salesforce、HubSpot、Dynamics 365から同期できます。Front自身の推奨は、ルール用のデータは基本的にアカウントに保存し、誰が書いてきたかで適切な担当者が変わる場合にだけ連絡先フィールドを使う、というものです。

ルールでは、アカウントのフィールドに基づいて割り当てられます。Account Managerのようなチームメイト型のフィールドなら、各会話を担当者へ直接送れます。

Professional以上では、AnalyticsにAccountsフィルターがあり、スタンプなしでアカウント別の指標を確認できます。

ただしこのフィルターで選べるのは個別のアカウントで、「Goldのアカウントすべて」ではありません。ティア別にレポートするには、やはりティアのタグを付けるルールが必要です。ドキュメントにある2つの制約があります。アカウント指標は遡及されず、アカウント作成時から始まります。また、1つのメールドメインは1つのアカウントにしか属せません。2つの事業部が同じドメインを共有している場合は、早めに対策を考えてください。eeselのFront連携は、返信を下書きするときに同じアカウントタグを読みます。Frontの料金は、年払いでシート1つあたり月$25（Starter、ルール10個）、$65（Professional、ルール20個）、$105（Enterprise）です。詳しくはFrontの料金の記事をご覧ください。

Zoho Desk：契約に組み込まれたセグメント

Zoho Deskは、5つの中で最もアカウント中心の設計です。チケットにはAccount Nameのルックアップがあり、アカウントにはIndustryとAnnual Revenueが標準で備わっており、カスタムレポートでは主モジュールにTickets、関連モジュールにAccountsを使えます。

ここでの最大の強みはサポートプランです。顧客をプランにまとめ、契約を通じて各アカウントをプランに紐付け、SLAを割り当てます。Zoho自身の例では、ライセンス数が50〜100のアカウントには3時間の応答目標を、500を超えるアカウントには別の目標を設定しています。プランにクレジット上限（たとえば月5チケット）を設けることもでき、クレジットを超えたチケットはSLAの対象外になります。これでセグメントは単なるラベルではなく、権利になります。

落とし穴はCRM同期です。Zoho CRM連携は、初回実行時に直近1年に作成または変更されたレコードしかインポートしません。18か月間変更のないエンタープライズアカウントは、誰かが手を加えるまで取り込まれません。カスタムレポートはStandard（ユーザー1人あたり月$14、年払い）から、ラウンドロビン割り当てはProfessional（$23）、スキルベースの割り当てはEnterprise（$40）からです。

サポートデータのセグメンテーションを5ステップで設定する

この順番は、5つのどのツールでも使えます。

1. 実際に対応する3〜5個のセグメントを選ぶ。 ティア、プラン、地域、場合によってはアカウント担当者。あるセグメントで誰も振り分けやレポート、価格を変えないなら、外してください。ツールが50個まで許していても、Gorgiasの4フィールド上限は良い規律になります。
2. 信頼できる情報源を1つ選ぶ。 通常、ティアと担当者はCRM、プランは請求システムです。エージェントに入力させるのではなく、ヘルプデスクに同期します（HubSpot、Salesforce、Zoho CRMにはネイティブな連携経路があります）。
3. 自由入力ではなく固定値のフィールドを使う。 ドロップダウンなら入力ミスが起きません。Help ScoutとFrontはどちらも、インポート時にフィールド値とIDが大文字小文字を区別すると注意しています。
4. 作成時にチケットへスタンプする。 セグメントごとに、値をタグまたはフィールドとしてチケットにコピーするルールを1つ作ります。これがセグメント別のレポートを成立させ、振り分けルールが読む情報になります。
5. 過去分は意図的に補完する。 Frontのアカウント指標、Help ScoutのSLA、Gorgiasのメタフィールドは、いずれも今後の分にしか効きません。履歴が必要か判断し、必要なら、トレンド線を信用する前にエクスポートして古いチケットに一括でタグを付けてください。

そのうえで、チームが吸収できる順番で価値を足していきます。

最初にレポートを置くのは、そのセグメントが対応する価値があるかどうかが分かるからです。振り分けとSLA目標は、エンタープライズのキューが遅いと分かった後に続きます。3つ目の、AIにセグメントごとに違う回答をさせることは、最初の2つが整って初めて機能します。

AIが向いている場面と、向いていない場面

AIは、ある層には向いていて、別の層には不向きです。

「何」の層は向いています。 チケットを読んで固定リストからトピックを選ぶのは分類であり、6人のエージェントにタグの認識を揃えてもらうより優れています。肝は固定リストです。AIタグ付けの一貫性は、与えるタグリストの質で決まります。AIでチケットを分類する方法と誤検出を減らす方法のガイドで詳しく扱っており、チケットの優先度付けも同じタグを土台にします。

「誰」の層は向いていません。 ティア、プラン、地域は顧客に関する事実です。CRMや請求システムから取得するべきで、メール署名からAIが推測するものではありません。データがヘルプデスクにないなら、まず同期を直してください。

あるヘルプデスク管理者が、もっと広い視点でこう述べていました。

"Adding AI onto a badly designed system will not help at all - it will only make matters worse. Get the basics of support right first before trying to add AI - it will never be a magic fix."

u/opcx_ in r/helpdesk, Reddit

私もそう思いますし、エージェントを作っていて目にする状況とも合っています。セグメントのフィールドがきれいなら、エージェントは回答の前にそれを読めます。エンタープライズ顧客にはセルフサービス記事を省いてアカウントマネージャーに引き継いだり、Starter顧客には正しいプラン上限を伝えたりできます。フィールドが乱れていれば、エージェントもその乱れを引き継ぎます。トリアージツールの比較では、各種AIツールがこの層をどう扱うかを比べています。

よくあるセグメンテーションの失敗

• セグメントが多すぎる。 40個の値があるティアのリストはセグメンテーションではなく、ノイズです。タグが細かすぎると、エージェントは最も頻繁に付け忘れたり誤って付けたりします。
• チケットではなくレポートでセグメント化する。 チケットをエクスポートして毎月CRMのシートと突き合わせるやり方は、一度は成功しても、そのうち誰もやらなくなります。作成時にスタンプしてください。
• 履歴を上書きする。 チケットが更新されるたびにルールでティアを更新すると、顧客のアップグレードが過去を書き換えてしまいます。スタンプは作成時のみにしてください。
• リストの管理者がいない。 新しいタグの値を承認する人がいないと、リストはまた膨らみます。ナレッジベースが古くなる問題と同じです。
• プランの制約を忘れる。 ワークフローを設計する前に、セグメント別SLAに必要なプラン（Help Scout Plus、Zendesk Suite Growth以上、アカウント分析にはFront Professional）の費用を見積もってください。

重要な顧客が埋もれ続けているためにセグメント化するなら、VIP組織のシナリオとサポートのオーバーフロー対策のガイドが振り分けの面を扱っています。ティアではなくブランドで分ける場合は、マルチブランドサポートが参考になります。

eeselでセグメントをきれいに保つ

上記のヘルプデスクのいずれかをお使いなら、eeselのAIヘルプデスクチームメイトは、すでに運用しているキューに加わってトピックの層を担当します。新しいチケットを読み、固定リストからタグを選び、レポートが頼りにするチケットフィールドを埋めます。ルールがスタンプしたティアを読むので、各セグメントの扱いを "for enterprise accounts, draft a reply and tag the account manager instead of sending" のように、普通の言葉で指示できます。

本番に入る前に、eeselは過去のチケットを使ったシミュレーションを実行するので、そのタグがチームの実際の選択と合っているか確認できます。レポート画面では、タスク量と、承認または却下されたアクションを確認できます。

料金は月額固定のクレジットプランで、チケットまたはチャット1件が1クレジットとして数えられ、シート数は無制限です。無料プランにはカード不要で100クレジットが含まれます。ご自身のキューでeeselを試して、そのタグがエージェントのタグと一致するか確かめてください。