ヘルプデスクのチケットシステムとは？仕組みと料金を解説

ヘルプデスクのチケットシステムとは実際何なのか

マーケティングの言葉を取り除くと、ヘルプデスクのチケットシステムがすることは1つだけです。メールボックスに届いたメッセージを、ステータス、担当者、優先度、時計付きの記録に変換することです。この記録があることで、「これに誰か返信した？」という会話がなくなります。

それ以外のすべては、この上に4つの階層として積み重なります。

この階層が重要なのは、ベンダーが最初の階層で売り込み、最後の2つの階層で課金してくるからです。受付は見栄えの良いデモになります。一方レポーティングでは、上司が毎週月曜に求めてくる数字を出すには、2段階上のプランが必要だと気づかされます。

階層1だけが必要なら、チケットシステムは不要です。必要なのは共有受信箱で、そちらの方が安く済みます。

チケット記録こそ、ベンダー間で密かに食い違う部分

ここはレポートの数字がおかしいと感じるまで誰も読まない部分です。「オープン」は普遍的な概念ではなく、「クローズ」もまた同じです。

Zendeskには6つの標準ステータス（New、Open、Pending、On-hold、Solved、Closed）があり、チケットライフサイクルのドキュメントにはいくつかの鋭い落とし穴が隠れています。Newは一方通行のドアで、一度そこから移動すると戻すことはできません。On-holdは顧客からは見えず、顧客には「Open」のままに見え続けます。そしてエージェントはチケットを自分でクローズすることすら一切できません。「チケットを手動でClosedに設定することはできない」ため、解決から4日後にオートメーションがそれを行うのです。そのオートメーションをオフにしても上限は28日で、「変更はできず、28日を超えてチケットをクローズするために作成されたビジネスルールは適用されない」というルールになっています。

Freshdeskは削除不可の4つのステータスを持ち、「誰の意見を基準にするか」で線引きしています。Freshdeskのフィールドドキュメントによると、Resolvedは「エージェントの視点でチケットが完了している」ことを意味し、Closedは「顧客の視点でチケットが完了している」ことを意味します。カスタムステータスの選択肢にはGrowth以上のプランが必要で、優先度は「SLAポリシー機能に直接紐づいているため編集できず、システムにハードコードされている」とされています。

Jira Service Managementはまた別の軸で分けています。ステータスは作業がどこにあるかを示し、解決状況はどのように終わったかを示します。そしてワークタイプの上にリクエストタイプを積み重ねる構造のため、「1つのリクエストタイプは一度に1つのワークタイプにしか紐づけられない」ことになります。HubSpotには実質的にステータスフィールド自体が存在せず、「チケットの場合、パイプラインステージはデフォルトでステータスと呼ばれるが、他のオブジェクトのステージと同じものである」とされています。

なぜ気にする必要があるのか？あなたのバックログの数字はこうした定義から作られており、思っている以上に嘘をつくからです。

"I was going through our queue today and found 90 tickets where we responded, asked for more information from the customer but then never heard back from them. They just sit there inflating our numbers and that honestly doesn't look good for management. We have been called before for unresolved open tickets so this is a big deal."

Our Help desk ticketing system shows 200 open tickets but half of them have had no user response, Reddit

200件の「オープン」チケットのうち90件は、返信のない顧客を待っている状態でした。ある近くのスレッドのITマネージャーは、たった1つのルールでよりすっきりした結果を得ています。r/ITManagersで、5日以上経過したチケットを自動クローズすることで「あるグループのバックログが即座に54%減少した」と書いています。新しいものを購入する前に、自分たちの問題が量なのか、それともチケットの整理整頓なのかを確認してください。

ルーティング、優先度、SLA

階層3は、エージェントがキューを信頼できるかどうかを静かに左右する部分です。正しく押さえるべきことが3つあります。

割り当て。 ラウンドロビンはスキルが関係してくるまでは問題ありません。請求専門のエージェントと返品専門のエージェントがいる状況になったら、順番待ちの次の人ではなく、意図によってルーティングするルールが必要になります。Zendeskはチケットルーティングでこれをカバーしており、Eコマースのチームは思っているより早く意図ベースのルーティングにたどり着くことが多いです。

優先度。 4段階が標準です（ZendeskではLow、Normal、High、Urgent。FreshdeskではLow、Medium、High、Urgent）。リクエストする側に優先度を自分で設定させたくなりますが、それはやめましょう。

"Dealt with this decades ago. It was scrapped quickly because as you might imagine it was abused to death. It really didn't bother me though. I still got the same number of tickets and just slogged through them. When people got mad because we were missing SLAs we just replied there was nothing we could do now that all tickets were priority."

u/bitslammer, Reddit

このコメントは371のアップボートを獲得しており、いかに普遍的な話かがわかります。優先度はルーティングの入力値であり、システムかエージェントに属すべきものです。

SLAタイマー。 ここには2つの罠があります。1つ目は、ZendeskがSLAを優先度フィールドに紐づけていることです。「優先度フィールドを無効化すると、ZendeskのSLAターゲットは適用されなくなる」とされています。2つ目はプランによる制限です。FreshdeskはすべてのAプランでSLAレポートを表示しますが、複数のSLAポリシーはPro機能なので、Growthでは1つのポリシーしか測定できず、セグメント分けもできません。Zoho DeskではStandard（月額14ドル）からSLAを設定できますが、SLAダッシュボードはProfessional（月額23ドル）まで提供されません。詳しくはSLA管理ガイドとZendesk SLAポリシーの作り方をご覧ください。

誰かに24時間365日対応を約束する前に、もう1つ知っておくべきことがあります。ほとんどのサポート契約では、24時間体制の対象は最も深刻な重大度のみです。Atlassian自身のサポート提供内容でも、L1の問題は24時間×週5日対応で、それ以外は営業時間内対応となっています。

セルフサービスと、偏向率の数字が期待外れになる理由

どのチケットシステムにもヘルプセンターが付属しており、どのベンダー資料も、それがボリュームの3分の1を吸収するかのように示唆します。しかし調査結果は違います。MetricNetのベンチマークデータベースについてのHDIの記事によると、セルフサービスの平均完了率は10.4%で、0%から55%までの幅があり、自己解決されたインシデントの大半はパスワードリセットだと指摘しています。

見落とされがちな二次的な効果があります。偏向は簡単なチケットから先に取り除いていくため、「生身のエージェントが引き続き対応するインシデントの平均的な複雑さと平均対応時間は増加する」ことになります。合計コストが下がっても、残ったチケット1件あたりのコストは上がるのです。

ナレッジベース自体が典型的なボトルネックになりますが、それは技術的な理由からではありません。

"I run a small team, and we have an internal wiki for processes, FAQs, and troubleshooting. The problem? No one updates it. People keep asking the same questions in Slack instead of checking the wiki."

Keeping a Knowledge Base Up to Date is a Nightmare, Reddit

ここはまさに、誰も注意していないとヘルプデスクの上のAIが間違いを起こす場所です。検索結果が空だった場合、言語モデルは喜んでその隙間を埋めてしまいます。私たちはこれが有料顧客に実際に起きるのを見てきました。あるデンマークの太陽光発電プロバイダーでは、ボットがサブスクリプションに関する主張をでっち上げ、実在の人々に送ってしまったこともあります。この出来事があったからこそ、eeselのすべてのロールアウトは今、まず過去のチケットに対して実行するようになっており、ハルシネーションの防止と確信度に基づくハンドオフをこれほど重視しているのです。何も言わないボットは取り返しがつきますが、返金ポリシーをでっち上げるボットは取り返しがつきません。

現実的な手順としては、まずナレッジベースとマクロを整え、それからAIをその上に向けます。ナレッジベースでAIをトレーニングする効果は、その土台となるナレッジベースの出来次第です。

実際にかかる費用

まずは座席料金からです。どの比較表にも載っている数字だからです。これらは各ベンダー自身の料金ページから取得した年払いの定価です。

実際にお金がかかる注意点が3つあります。ZendeskのCopilotアドオンはエージェント1人あたり月額さらに50ドルかかるため、Copilot付きのSuite Professionalはエージェント1人あたり165ドルになります。HubSpotはProfessionalで1,500ドル、Enterpriseで3,500ドルの初回オンボーディング費用を課します。そしてJira Service Managementはもはや単体では販売されておらず、ライセンスページには、Service Collectionは「Jira Service Management、Customer Service Management、Assets、Rovoを含む単一の提供物として販売され、各アプリを個別に購入することはできない」と記載されています。

AIメーターは別の請求書であり、みんなカウント方法が違う

ここは立ち止まって考えるべき部分です。今やどのプラットフォームにもAIレイヤーがありますが、同じイベントに対して課金しているところはほとんどありません。

Freshworksは、セッションとは24時間ウィンドウ内のすべてのやり取りを指すと明言しています。つまりFreddyは結果ではなく試行に課金します。Atlassianのアシステッド会話は、「仮想サービスエージェントが問題を解決したかエスカレーションしたかに関わらず、意図にマッチしたあらゆる会話」をカウントします。Help Scoutは厳格な側にあり、顧客がエスカレーションしたり、ナレッジベースを検索したり、別の質問をしたり、「まだヘルプが必要」をクリックした場合は解決としてカウントされません。

Zendeskは2026年5月18日にモデルを刷新し、3つの階層に分けました。アシステッドエスカレーション（課金なし）、コンテインド解決（課金なし）、検証済み解決（課金あり）です。以前よりは公平になりましたが、以前のモデルについて人々は率直に不満を述べていました。

"Complete trash lol, stuff I used to get free now counts as an AR. Most of the ARs are abandoned chats. There's no dispute resolution process. Complete scam. I used to like Zendesk but since trying the new bot and now this I have little good will left"

u/Kerrick, Reddit

ここでの不満は価格ではなく定義に対するものです。これがまさにこのセクションの要点です。コストを聞く前に、何がカウントされるのかを聞いてください。以下に自分の数字を入力してみてください。

1,000件のチケットのうち40%をAIにルーティングした場合、最も安いものと最も高い公表料率との差は、まったく同じ作業に対しておよそ6倍になります。これは更新の交渉に持ち込む価値のある数字です。

レポーティングは、誰もまともにデモしない階層

どのベンダーもダッシュボードを見せてくれます。もっと鋭い質問をしてみましょう。誰も作ってくれていないレポートを自分で作れるか、生の行データを取り出せるか、と。

Help Scoutはこの点について清々しいほど正直です。自分でレポートを作れるかという問いに対して、ドキュメントはこう答えています。「アプリ内ではできません。多くのフィルターは提供していますが、計算方法をカスタマイズする方法はなく、カスタムデータセットに基づいてカスタムレポートを作るオプションもありません」。料金ページの「カスタムレポート」の行は、保存されたフィルタービューを意味しているにすぎません。

ビルダーがあることと、実際に使いこなせることは別問題です。

"I have never found anything as complex as Zendesk explore.

I've worked with ThoughtSpot building dashboards, reports and exports but omg Zendesk, you are taking so much of my time!!!!!!!!

I have recently moved jobs where I worked with the platform Dixa and at my new job, I launched Zendesk - I have the most basic set up on Zendesk ever but the Explore setup is BREAKING ME."

u/kayscakes, Reddit

そしてビルダーが負けると、スプレッドシートが勝ちます。

"The reports and automations can be somewhat difficult to navigate. We ended up just exporting all of our tickets every month and creating our own reports through Power query in Excel."

Trent B., Director of Client Care, Capterra

ディレクターが毎月Excelでレポートを作り直しているというのは、実際にコストのかかる項目です。Zendeskのレポーティングを、よりシンプルなレポート機能を持つ安価なツールと比較する際は、その時間もコストとして計算に入れてください。

Exploreを使っているなら、手帳に書き留めておくべきZendeskのタイミングが2つあります。ライブダッシュボードは2026年5月5日より前にExploreにアクセスしたことのあるアカウントに限定されており、2027年1月25日にはプリビルドのライブダッシュボードとライブダッシュボードを作成する機能がExploreから完全に削除されます。後継となるリアルタイムダッシュボードもProfessionalプランの制限は維持され、過去データの遡及は30日までに制限されます。

ホスティング、データ所在地、稼働率

重要になる時だけ重要になり、そうなったときには非常に重要になる、3つの簡単なチェック項目があります。

データがどこにあるか。 Help Scoutはセキュリティページによると米国のみです。Freshdeskはサインアップ時のみ5つのリージョンから選択できますが、後から移動する場合はメールでのチケット対応となり、公表された移行SLAはありません。ZendeskのData Center Locationアドオンは、Suite Professional以上では無料ですが、「含まれてはいるが自動的には有効化されない」とされており、有効化するまでは「Data Center Locationアドオンを持っていない、または有効化していない顧客のアカウントデータを、Zendeskは通知なくリージョン間で移動することがある」とされています。

実際に契約している稼働率は何か。 Zendeskの99.9%はPremier Supportにのみ適用され、対象は5つの製品（Support、Knowledge、Community、Chat、Sunshine Conversations）のみで、ExploreやTalkは含まれません。Freshworks、Help Scout、Front、Gorgiasは稼働率をまったく公表していません。Zohoは全社的に99.9%を約束しており、これは月間およそ43.8分のダウンタイムに相当します。

離脱するとどうなるか。 エクスポートの品質が、移行後にどれだけの履歴が残るかを左右します。そしてそれは通常、期待よりも悪い結果になります。

"I have exported my historical tickets to XML but not going to work. First my tickets are a mess. They are not properly organized, tagged, or anything. Lot of the info chatGPT would need to understand is in custom fields which are not labeled in any export."

u/ToastyPasta, Reddit

エクスポートにラベルのないカスタムフィールドがあることも、移行後に過去チケットを使ったAIトレーニングが行き詰まる理由の1つです。契約する前に、契約した後ではなく、エクスポートをテストしておく価値があります。

今のツールを卒業すべきタイミングの見極め方

本当のサインは量ではありません。4つの別々の不満が同時に重なったときです。

"Zendesk is very configurable, though I struggle to think of what I like about Zendesk. I found the reporting tool in particular to be very difficult to use. Their AI offerings felt bolted on versus integrated, and their integrations didn't work particularly well. Support was not timely. Pricing was not competitive. This is why we moved to another tool."

Gail D., Senior Director of Customer Support, G2

とはいえ、移行プロジェクトを始める前に、もっと安いテストをしてみてください。私が話をするほとんどのチームは、チケットシステムの問題ではなく、ティア1のボリュームの問題を抱えています。MetricNetのコストデータは、この区別がなぜお金に換算できるのかを説明しています。ネットの一次解決率は平均74.3%で、エスカレーションのはしごは累積するため、レベル1で記録されレベル2へ押し上げられたチケットは、HDI/MetricNetの数字によると「62ドルに22ドルを加えて合計84ドル」かかります。レベル1で食い止めたチケットはすべて、手に入れられる中で最も安上がりな勝利です。

これは通常、プラットフォームを乗り換える話ではなく、AIレイヤーの話です。そしてそのレイヤーに求められる基準は「答えられるか」ではなく「いつ止まるべきかを分かっているか」です。それはまさに、月間7,000件のチケットを扱うサプリメントブランドのあるCXリードが私たちに語ってくれた言葉そのものです。「自信を持って対応できるチケットだけを処理し、それ以外はすべて手を出さないAIが必要なんです」。当時、私たちはその契約を勝ち取ることはできませんでした。しかしその要件は正しいものでした。

既に使っているヘルプデスクでeeselを試す

eeselは、既存のヘルプデスクのチケットシステムを置き換えるのではなく、その上に乗るAIレイヤーです。過去のチケット、マクロ、ヘルプセンターを読み込み、Zendesk、Freshdesk、Gorgias、Front、Jira Service Managementの中でドラフトを作成するか完全に解決します。移行は不要で、エージェントが新しく覚えるツールもありません。

ここまでの内容を踏まえると、2つの点が違いを生んでいます。1つ目はメーターです。処理したチケット1件あたり0.40ドルで、座席ごとの料金はなく、Enterprise未満ではプラットフォーム料金もありません。実際にルーティングしたチケットの分だけ支払うので、1,000件のうち200件をAIに送った場合のコストは80ドルです。2つ目は、すべてのロールアウトが自社の過去のチケットに対するシミュレーションから始まることです。だから顧客より先に、解決率やミスを自分の目で確認できます。この習慣は、本番環境でボットが答えをでっち上げるのを目撃したことから生まれたもので、だからこそ私は、資料の中の見栄えの良い数字よりも、トライアルの中の見栄えの悪い数字をあなたに見せたいのです。

無料で試せて、デモ用のキューではなく、あなた自身のキューで動きます。