2026年のチケット管理システムの例8選:実際のチケット、実際のシステム

「チケット管理システムの例」が実際に意味すること

2つの異なる検索意図が同じフレーズにたどり着きますが、どちらも正当なものです。

ある人はシステムの例を求めています。どんなツールがあるのか、画面はどう見えるのか、12人規模のサポートチームに合うのはどれか、といったことです。また別の人はチケットの例を求めています。実際の記録はどう見えるのか、その後どうなるのか、といったことです。私はeeselでサポートキューを担当しているので、主に後者に関心があり、それについて自分なりの考えを持っています。ツール比較は、良いチケットとはどういうものかを知った先にあるものです。だからこそチケット管理システムソフトウェアのまとめ記事は、この記事の前より後に読んだほうが理解しやすいのです。

3年間、実際のキューに向き合って学んだことがあります。サポートチームが静かにお金を失っているのは、チケットの記録の部分だということです。返信の内容ではありません。誰もクローズする担当を決めなかったために9日間Pendingのまま放置されたチケット、依頼者全員がUrgentに設定してしまう優先度フィールド、2人の別々の依頼者が同じ問題について起票した2件のチケット、そういったところです。

この違いは見た目だけの問題ではありません。Zendeskは6つのステータスを標準搭載しています(New、Open、Pending、On-hold、Solved、Closed)。Freshdeskは削除できない4つのステータスを備えており、HubSpotにはステータスフィールド自体が存在しません。HubSpotにおけるチケットはサポートパイプラインを進むCRMレコードだからです。

Jira Service Managementは3つのオブジェクトを積み重ねています。ワークフロー上のワークタイプの上にあるリクエストタイプです。リクエストタイプの階層を省略すると、その作業項目はサービスデスク機能に一切アクセスできなくなります。

あなたのキューに合う例を選ぶ

以下の8つの例のうち6つを、実際に届く形のまま紹介します。長いバージョンを読む前に、ぜひクリックして試してみてください。

8つのチケット管理システムの例を最初から最後まで見る

以下のそれぞれは同じ構成をたどります。実際に届くリクエスト、それが作る記録、ステータスパス、そして3か月目にチームを悩ませる落とし穴です。

1. Eコマースのキューにおける「注文はどこですか?」

小売のキューでは最も件数が多く、回答するうえで最も面白みのない例です。顧客が注文番号を貼り付け、担当者は配送業者のタブを開き、日付をコピーして返信します。Gorgiasでは、注文情報が会話の隣にあるサイドパネルに表示されます。これこそ、汎用のヘルプデスクではなくEコマース特化のヘルプデスクを選ぶ理由そのものです。

記録はごくシンプルです。依頼者、注文番号、タグ、公開返信1件。ステータスはNewからOpen、Solvedへと進み、ほとんど再オープンされることはありません。これはAI注文追跡を導入する決め手になる形です。答えが判断ではなく検索だからです。あるチケットの種類が一度も意見を必要としないなら、それは担当者を必要としないはずです。

落とし穴は計測方法です。Zendeskのワンタッチ解決のドキュメントによれば、ワンタッチ解決とは「担当者の返信が1件、または返信なしで解決またはクローズされたチケット」とされています。つまり、この種のチケットで埋まったキューは、実際以上にチームを速く見せてしまいます。

2. 返品期間を過ぎた返金

この例は丁寧な問い合わせとして届き、やがてポリシー判断へと変わります。顧客は返品期間を11日過ぎており、それなりの理由を持っています。

この記録には承認ステータスが付与され、Zendeskのチケットフィールドでは4つの値(Pending、Approved、Denied、Withdrawn)を取ります。多くのチームは、経理が後でフィルタできるように「返金処理済み」といったカスタムステータスを追加します。それを作る前に知っておくべきことがあります。Zendeskは最大100個のチケットステータスを許可していますが、ステータス管理のドキュメントによれば「ステータス選択メニューには最初の10個のみが表示される」とのことです。また、カスタムステータスで解決されたチケットは、クローズ後もそのラベルを保持します。

写真や注文確認を待つ間、ステータスパスはPendingを経由しますが、Pendingこそ返金チケットが立ち消えになる場所です。Freshdeskは「顧客が返信するたびに」チケットをOpenへ戻します。これは便利ですが、顧客が二度と返信しないチケットを救う手立てはありません。下書きの自動化はここでは問題ありません。詳しくは返金の自動化の解説をご覧ください。ただし、例外の判断を自動化するのはおすすめできません。

3. パスワードリセットとMFAロックアウト

ITの中で最も語られてきたチケットであり、コストのばらつきが最も大きいものでもあります。同じ質問でも、入り口は6通りあります。

HDIの2021年のデータでは、セルフヘルプが2.37ドル、窓口対応が37.52ドルとされています。HDIのコスト分析の執筆者はこの差を「2桁以上(100倍)」と表現しています。答えの中身は何も変わっていません。変わったのはユーザーが通った入り口だけです。

ただし注意点があります。デフレクションによってキュー全体の平均コストが下がるとは限りません。HDIはセルフサービスのベンチマークの中でこう率直に述べています。「処理時間の短いインシデントがセルフサービスに移行するにつれ、有人担当者が引き続き対応するインシデントの平均的な複雑さと平均処理時間は増加する」。つまり、総コストが下がる一方でチケット1件あたりのコストは上がる可能性があるということです。セルフサービスポータルを公開する前にレポーティングの説明を用意しておかないと、最初の月次レビューが失敗に見えてしまいます。

期待値も現実的に設定しておく価値があります。MetricNetのベンチマークデータベースによれば、平均的なセルフサービス完了率は10.4%であり、ベンダーの資料が謳う60%や80%とはかけ離れています。私たちのチケットデフレクションガイドでも、この数値を基準として使っています。

4. 新入社員のアクセス権と備品リクエスト

マネージャーが「月曜日に新入社員、いつもの機材一式」と一行を起票するだけで、1週間分の作業が発生します。これはインシデントではなくサービスリクエストであり、この区別にはコストがかかります。MetricNetのボリューム調査の現場データによれば、インシデントの作業時間が12.3〜21.5分であるのに対し、サービスリクエストは35.4〜95.9分かかります。

Jira Service Managementはこれを適切にモデル化しています。新しいスペースには標準で5つのワークタイプ(IT Help、Purchase、Change、Fault、Access)と2つのリクエストタイプが用意されており、リクエストタイプのフィールドはそのワークタイプから引き継がれます。また、依頼者向けにステータス名を変えて表示する機能もあります。内部的にはWaiting for Customerと表示されるチケットが、デフォルトのJSM設定ではポータル上で「Requester Action Needed」と表示されます。小さな違いですが、「進捗どうですか?」という返信の数に大きく影響します。

この形がキューの大半を占めているなら、次にアクセス申請とハードウェア申請の解説を読んでください。HRのオンボーディングも、承認者が違うだけの同じパターンとして捉えられます。

5. エンジニアリングへのエスカレーションになるバグ報告

顧客が本物の不具合を発見します。サポートがそれを再現し、エンジニアリングの課題に紐づけますが、そのチケットはもうクローズできなくなります。

Zendeskの標準フィールドセットでは、Typeフィールドは4つの値(Question、Incident、Problem、Task)を取り、一度設定すると空に戻すことはできません。このフィールドを無効化すると、すべてのチケットがデフォルトでIncidentになります。一方Jira Service Managementは2つの軸を分けています。ステータスは作業がどこにあるかを、解決状況はどう終わったかを表し、原因と回避策が文書化されているケース向けにKnown errorという解決値が用意されています。

ここでの落とし穴はOn-holdです。Zendeskのライフサイクルドキュメントによれば、これは「チケットの依頼者には決して表示されない」任意の内部ステータスです。依頼者側の表示は依然としてOpenのままです。つまりチケットは棚上げされているのに、顧客はまだ対応中だと思っているのです。定期的に進捗を知らせる仕組みを用意しましょう。ルーティングについてはエスカレーション管理とバグ報告のトリアージを参照してください。

6. CRM重視のヘルプデスクにおける請求トラブル

「6月に二重に請求されました」というのは、実質は経理のチケットであるサポートチケットです。だからこそチームはこれをCRM形式のシステムで扱います。

HubSpot Service Hubでは、チケットはパイプライン上のオブジェクトであり、デフォルトのSupport Pipelineには4つのステータス(New、Waiting on contact、Waiting on us、Closed)があります。チーム間を行き来するトラブルにとって重要な挙動がいくつかあります。Close dateは双方向であるため、チケットをオープンな段階に戻すと値がクリアされます。Categoryは最初のメッセージからAIが設定するもので、Enterpriseプランにのみ存在します。そしてhs_ticket_owner_typeは、その記録にHuman rep、Customer Agent、Rule-based botのいずれが触れたかを記録します。これは、主要なヘルプデスクの中でAIが処理したチケットについて私が見た初めての正直な監査証跡です。

この形については、デフレクションの目標は控えめに設定すべきです。プランごとの制限については私たちのHubSpotチケットデフレクションの記事に、CRM重視モデルが実際に有利になる場面についてはカスタマーサービスCRMに詳しく書いています。

7. 40件のチケットとして届く障害

1つの障害、40件の記録、そして試されようとしている優先度フィールド。

Jiraの5段階の優先度には、JSMの優先度スキームにあるAtlassian独自の説明が付いています。Highest(「この問題は作業の進行を妨げます」)からLowestまでです。Freshdeskの4段階の優先度は、SLAポリシーがそれに依存しているため「システムにハードコードされている」と、そのチケットフィールドガイドに記載されています。Zendeskにはもっと厄介な依存関係があります。Priorityフィールドを無効化すると、SLAのターゲットが一切適用されなくなります。

依頼者自身に優先度を設定させると、そのフィールドは意味をなさなくなります。

"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管理ガイドを、自動的に導き出す方法についてはAIチケット優先順位付けを参照してください。

8. 決して実装されない機能リクエスト

キューの中で最も丁寧なチケットであり、最も塩漬けになりやすいものでもあります。誰かがダークモードを求め、プロダクトチームがノーと答え、その記録は行き場を失います。

Jira Service Managementには明快な答えがあります。ステータスとは別に解決状況としてWon't doがあり、解決済みになると作業項目のキーに取り消し線が表示されます。ZendeskとFreshdeskはSolvedやResolvedへと誘導しますが、これは実際には対応していないのに「対応した」と暗に示すことになります。Freshdeskは少なくともこの区別を明示しており、その説明によれば、Resolvedは「担当者から見て」完了、Closedは顧客から見て完了を意味し、72時間後に自動クローズされます。

そもそも、クローズするかどうかを決めるのは担当者ではないことが多いのです。Zendeskはチケットライフサイクルのドキュメントで「チケットを手動でClosedに設定することはできない」と明言しています。デフォルトの自動化により、Solvedから4日後にクローズされ、この自動化をオフにした場合でも、変更できない28日間の上限が適用されます。

同じチケットが6つの実システムでどう扱われるか

ここからはこのキーワードのもう一つの読み方、つまりシステムの例です。顧客との商談で最もよく目にする6つのツールを対象に、同じリクエストがどのようなコストと見た目になるかを見ていきます。

価格は各ベンダーの料金ページに掲載されている年間契約時の定価で、今週確認したものです。2点、注意が必要です。Jira Service Managementは1エージェントあたり平均20ドルと表示していますが、これは段階的なボリューム課金におけるデフォルトの75エージェントのスライダーでのレートであり、10エージェント規模のチームが支払う金額ではありません。またZendeskの主要な課金単位であるautomated resolutionについては、料金ページのどこにも金額が公開されていません。そのため、AIレイヤーの予算組みは営業への問い合わせが必要になります。

評価や機能一覧を見ても、どれが自分に合うかはわかりません。それを教えてくれるのは、上で見てきたチケットの形です。注文状況の確認が60%を占めるEコマースのキューにはGorgiasのモデルが向いており、承認業務であふれる社内ITデスクにはJira Service Managementが向いています。

より広い選択肢については、トップヘルプデスクソフトウェアがツールごとに解説しており、カスタマーサービスソフトウェアの例が顧客対応側をカバーしています。

チケットがうまくいかない3つの例

うまくいかないケースは、うまくいくケースよりも多くを教えてくれます。そしてこれらはどれも、人員を増やすのではなく設定で解決できます。

誰も待っていないチケット。 あるサポートリーダーが自分のキューを数えたところ、バックログのほとんどが実体のないものであることに気づきました。

"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マネージャーは、5日以上経過したチケットを自動クローズするだけでグループのバックログを54%削減できたと報告しています。私たちのバックログ解消の記事では、この対策をより詳しく解説しています。

誰も更新しないナレッジベース。 上で挙げたセルフサービスの例はすべて、記事が存在し、最新であることを前提としています。

"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

この2つは連動して機能不全に陥ります。社内ナレッジベースは劣化し、人々はそれを迂回するようになります。記事だけでなく過去のチケットにもAIを学習させることが現実的な答えであり、これは私たちのナレッジベース学習ガイドで扱っています。

ツールから引き出せないレポート。 本格的なBIツールでダッシュボードを構築してきたサポートリーダーでさえ、基本的な数値を取り出せませんでした。

"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!!!!!!!!"

u/kayscakes, Reddit

購入する前に、まさにこうした例に照らしてレポーティング機能を確認してください。購入後では遅すぎます。トライアルの初日に検証すべきなのは、ZendeskのレポーティングとカスタマーサービスKPIの2つです。

AIレイヤーがこの8つの例に何をもたらすか

8つすべてではありません。それこそが重要な点です。例1、3、そして6の大部分は、決まった答えとともに永遠に繰り返されます。例2、5、7、8はポリシー判断を担う人が必要です。

この失敗のパターンを間近で見てきました。私たちの顧客の一社であるデンマークの太陽光発電プロバイダーでは、ナレッジベースに該当する記事がなかった際に、ボットがサブスクリプションに関する事実無根の主張をでっち上げ、実際の顧客に送ってしまったことがあります。この一件がきっかけとなり、eeselのすべての導入プロセスでは、実際の顧客に回答する前に必ず過去のチケットに対するシミュレーションを行うようになりました。Gorgiasを使うあるサプリメントブランドのCXリーダーは、この要件を私たちのドキュメントよりも的確に言い表してくれました。

"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

これは至極まっとうな要求であり、まさにここまでの例のリストと一致します。AIには注文状況確認のような形のチケットを任せ、障害対応には近づけないことです。スコープを正しく設定できれば、数字はついてきます。Gridwiseは7日間のトライアル後、初月でtier-1リクエストの73%を解決しました。スコープを誤ると、あの太陽光パネルの話のようになります。

どの形を自動化するか決める前に、サポートにおけるAIハルシネーションとAIから人へのハンドオフをお読みください。

チケット分類とチケットタグ付けは、ほとんどのキューにおいて安全な第一歩です。誤ったタグ付けにはコストがかかりませんが、誤った回答は顧客を失うコストになるからです。

あなた自身のチケット例でeeselを試す

あなたのキューが上のリストのようであれば、有効な一手はヘルプデスクを乗り換えることではありません。今使っているものにAIレイヤーを追加し、繰り返し発生する2〜3の形にそれを向けることです。

eeselは数分でZendesk、Freshdesk、Gorgiasと連携し、過去のチケットとヘルプセンターを学習したうえで、過去の量に対してシミュレーションを行います。これにより、顧客に届く前に、eeselが送っていたであろう回答を確認できます。

eeselがどのチケットの形に触れるかはあなたが選べるため、例7が渡されることはありません。課金は座席課金なしで対応1チケットあたり0.40ドルなので、月間1,000件のチケットのうち200件をルーティングしても、新しいプラン階層ではなく80ドルで済みます。無料でお試しいただけます。

まずは例1か例3から始めてください。最も件数が多く、最もリスクが低く、1週間で効果を証明しやすいものです。