サポートチケットシステム:定着する仕組みの作り方

サポートチケットシステムの正体

サポートチケットシステムとは、突き詰めれば、会話を記録に変えるものです。メール、チャット、WhatsAppのメッセージ、ウェブフォームはすべて同じ場所に集約され、番号、担当者、ステータス、時間の計測が付与され、誰かがクローズするまでそこにとどまります。

当たり前に聞こえるかもしれませんが、それが置き換える共有受信箱と実際に比較してみると違いがわかります。受信箱では、リクエストの状態は誰かの頭の中か、スレッドが既読に見えるかどうかにしか存在しません。チケットシステムでは、状態はフィールドです。それだけの話です。この一つの変化こそが、ルーティング、SLA、レポート、そしてあらゆる種類のチケット自動解決を可能にします。なぜなら、ソフトウェアはフィールドを読み取れても、勘を読み取ることはできないからです。

実際にお金を払っている対象はこちらです:

• 流入チャネル。 メール、チャットウィジェット、カスタマーポータル、WhatsApp、電話、そして最近では自社アプリからのAPI経由も増えています。
• チケットのデータモデル。 フィールド、ステータス、優先度、種類、タグ。ここは誰もが軽視しがちな部分です。
• ルーティングとSLA。 誰が、どの順番で、いつまでに対応するか。
• ナレッジレイヤー。 ヘルプセンターと、エージェントが実際に使うマクロや定型返信。
• レポート。 Excelにエクスポートせずに「先月何が起きたか」に答えられるかどうか。
• AIレイヤー。 今や標準機能ですが、料金は別立てで従量課金されます。

その図にあるループが、後になって痛手となる部分です。フィールドが何をレポートできるかを決め、そして半年後になって、今まさに必要な1つのフィールドを一度も取得していなかったことにレポートの段階で気づくことになります。

共有受信箱を卒業すべきサイン

正直なところ、件数はここで最も当てにならない指標です。1日40件のメールを処理する2人チームでも、本当にデスクを必要としていないケースを見たことがありますし、1日200件の5人チームが、実際に導入した時期より1年早くデスクを必要としていたケースも見てきました。本当のトリガーは数字ではなく構造的なものです。

サポートチケットシステムが必要になるのは、担当者が1人不在でもリクエストが滞りなく処理される必要が出てきたとき、2人のエージェントが同じ顧客に返信し続けてしまうとき、誰かに出せない数字を求められ始めたとき、あるいは顧客に対して書面で対応時間を約束するときです。最後のものは本当に明確な境界線です。タイムスタンプ付きの記録のないSLAは、ただの願望にすぎません。

もうひとつ、静かなトリガーもあります。それは、今使っているツールが合わなくなったときです。これは、私が読んだ中で最もわかりやすい表現のレビューです:

"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

一息に4つもの理由が挙げられていますが、そのどれも「チケットを保存できない」ではありません。これこそが、実際にデスクを卒業する瞬間の姿であり、今後5年間使うプラットフォームを決める前に一読する価値があります。すでにその段階にいるなら、ヘルプデスクソフトウェアの比較記事とチケッティングシステムソフトウェアの比較記事を、まず見るべきショートリストとしておすすめします。

この順番でセットアップする

私が見てきた失敗したロールアウトは、どれもステップ2を飛ばして自動化にいきなり進んでいました。以下が私が従う順番と、各ステップで実際に決めるべきことです。

ステップ1:チャネルと、それらがすべて集まる1つの場所

機能一覧に載っているからではなく、実際に人員を配置できるチャネルだけを有効にしましょう。有効にしたチャネルはすべて、誰かが見張らなければならないキューになり、コンタクトあたりのコストはチャネルによって大きく異なります。HDIの2021年のデータでは、セルフヘルプは1チケットあたり2.37ドル、ウェブ送信は15.07ドル、チャットは15.72ドル、メールは16.13ドル、音声は17.19ドル、来店対応は37.52ドルとなっており、出典自身がこの差を「100倍」と呼んでいます。

ここでの実践的なルールは2つです。5つの異なる経路から届いたものであっても、すべてを1つのキューにルーティングしましょう。2つ目のキューは、金曜日に誰もチェックしない2つ目のバックログになるだけです。そしてメールに関しては特に、件名にチケットIDを入れた受領確認をすぐに送りましょう。そのIDこそが、返信を重複チケットとして開かせず正しい記録に紐づけ続ける仕組みです。この仕組みが、スレッドとチケットの違いのほぼすべてであり、メールヘルプデスクソフトウェアのガイドで詳しく解説しています。

ステップ2:何よりも先にフィールド

フィールドは業務全体のスキーマです。Zendeskの標準セットは、リクエスト送信者、フォロワー、担当者、CC、共有、件名、説明、ステータス、種類、優先度、タグ、承認ステータス、解決タイプ、解決ティア、チャネルグループで構成され、チケットフィールドのドキュメントによると、件名は255文字まで、説明は最初のコメントを兼ねます。Freshdeskは削除できない11個のデフォルトフィールドを標準搭載しています。

自分でフィールドを追加し始める前に知っておくべき、2つの落とし穴があります:

• フィールドを無効化すると、気づかないうちに他の機能が壊れることがあります。 Zendeskの優先度フィールドを無効にすると、Zendesk自身の言葉で「SLAの目標は適用されなくなります」。種類を無効にすると、すべてのチケットがデフォルトでIncidentになります。
• ドロップダウンを編集すると履歴が壊れます。 Freshdeskはこれについて率直にこう述べています。「既存のチケットで使用中のドロップダウンの選択肢を変更または削除すると、そのフィールドの値はnullに変更されます。」

カスタムフィールドもプランのゲートになっているので、事前に知っておく価値があります。Freshdeskでは、種類ごとの上限付きでGrowthプランから利用でき、一行テキストフィールド80個、複数行10個、ドロップダウン80個で、Proと Enterpriseではさらに増えます。実際にレポートで使うフィールドを少数に絞り込み、一度きちんと命名し、エッジケースごとに新しいフィールドを追加したくなる衝動は抑えましょう。ロングテールのケースにはタグがあり、チケットタグは、誰かがすでにワークフローを組み上げてしまったドロップダウンよりも、後から整理するのがはるかに簡単です。

ステップ3:ステータスと、クローズに関する2つのルール

ステータスは、ベンダー間で密かに意見が食い違っている部分であり、ほとんどのキューが結局腐っていく原因でもあります。誰の「オープン」も、あなたの「オープン」と同じ意味ではありません。

Zendeskには6つのステータス(New、Open、Pending、On-hold、Solved、Closed)があり、そのうち3つのルールは意表を突かれがちです。Newは一方通行のドアで、「ステータスをNewから別のものに変更した後は、Newに戻すことはできません」。On-holdは顧客からは見えず、顧客側には引き続きOpenと表示されます。そして「チケットを手動でClosedに設定することは一切できません」。クローズは自動化によって行われ、デフォルトではSolvedから4日後、解決後28日でクローズするハードキャップがあり、それを超えて延ばそうとするルールは「反映されません」。

Freshdeskは4つのステータスを保持しており、線引きの仕方が少し異なります。Resolvedは「エージェントから見て」完了、Closedは「顧客から見て」完了を意味し、Resolvedから72時間後に自動クローズされます。Jira Service Managementは1つの状態に2つの名前を使っており、内部の「Waiting for Customer」はリクエスト送信者には「Requester Action Needed」と表示されます。HubSpotに至っては実質的にステータスフィールドすら存在せず、デフォルトでステータスと呼ばれているのはパイプラインの段階だけです。

同じやり取りを、4つの異なるデスクで見てみましょう。自分の使っているものを選んでください:

これが単なる豆知識以上に重要な理由は、レポートがこれらの定義をそのまま引き継ぐからです。あなたのデスクで「オープン」が、応答のない顧客の待ちチケットもすべて含んでいるなら、バックログの数字は虚構であり、それでも誰かはいずれその数字であなたを評価するようになります。

ちなみに、この内訳は仮定の話ではありません:

"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

解決策は自動クローズルールと、それを実際に信頼する規律です。あるITマネージャーはr/ITManagersに投稿し、5日以上経過したチケットを自動クローズしたところ「あるグループのバックログが即座に54%減少した」と述べています。返信があればいずれにせよチケットは再オープンされるため、顧客にとって不利益になることもありませんでした。

ステップ4:ルーティング、優先度、SLAは1つのシステム

この3つを別々の設定として扱うと、遅かれ早かれ互いに衝突します。優先度はSLAポリシーに反映され、ルーティングは実際に時間を見張るのが誰かを決めます。

まずは優先度の問題から始めましょう。これは政治的になりがちなテーマです。リクエスト送信者自身に優先度を設定させてはいけません。これはこのテーマに関する371アップボートを獲得したトップコメントで、今も色あせていません:

"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

優先度は自分で、実際に観測できる項目、プランのティア、注文金額、キーワード、チャネル、すでに3回返信している顧客かどうかなどのルールから設定しましょう。Freshdeskが4つの優先度値をハードコードしているのは、まさにそれらが「SLAポリシー機能に直接紐づいている」からで、実際のところ、意図するとしないとにかかわらずSLAを設定していることになります。

次はSLAそのものです。ベストな週ではなく、最悪の週でも達成できる目標を設定し、営業時間は正直に定義し、顧客側がボトルネックになっている間は時間を止めるためにPendingが存在することを忘れないようにしましょう。Freshdeskの複数SLAポリシーはProプランから利用可能で、Growthプランでは組み込みのSLAレポート自体はあるものの、顧客や製品でセグメント分けすることはできません。もっと詳しく知りたい場合は、AIによるSLA管理とSLAエスカレーションの自動化の記事を個別にまとめています。

正直なところ、ルーティング自体は簡単な方の半分です。スキルまたはグループ、マッチしなかったものに対するフォールバック担当者、そして1時間担当者が付かないままのチケットに対するアラートです。何十ものルールを自分で書かずに済ませたいなら、AIチケットルーティングとチケットの優先度付けは、どちらもキーワードリストではなくチケットの文章そのものを読み取り、チケット分類が受信時点でタグ付けを行います。

ステップ5:ナレッジベースと、誰も公表しない数字

どのベンダーもデフレクションのグラフを見せてくれます。しかし正直な数字はそれよりずっと小さいものです。MetricNetのベンチマークデータベースによると、セルフサービスの平均完了率は10.4%で、セルフサービスのないデスクでの0%から、上位では55%までの幅があります。それより前の2018年の調査では8.9%と測定されており、その自己解決したインシデントの大半は単なるパスワードリセットでした。

つまり、ナレッジベースを構築する価値は確かにありますが、それだけでキューが半分になるかのように思い込む価値はありません。実際に届いたチケットをもとに、顧客が実際に使う言葉で構築しましょう。そして、劣化(rot)も見越しておく必要があります。これはほぼ普遍的な現象だからです:

"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ナレッジベースチャットボットの発想です。

コンテンツが5つの異なる場所に散らばっているなら、どのヘルプセンターのテーマを選ぶかよりも、検索の仕組みの方がずっと重要です。整理された社内ナレッジベースこそが、それ以外のすべてを実際に機能させる土台になります。

ステップ6:レポート、後から修正できないレイヤー

これは、四半期が終わるまで後回しにされがちなステップです。その頃にはもう手遅れで、レポートはすでに存在していたフィールドでしかグループ化できません。

さらに悪いことに、レポートビルダー自体がプランのゲートになっており、そのゲートの価格も決して小さくありません。

Zendesk自身のライブダッシュボードも段階的に廃止されつつあります。2026年5月5日以前にExploreにアクセスしたことのあるアカウントのみに限定されており、2027年1月25日には、事前構築済みのライブダッシュボードとそれを作成する機能がExploreから完全に削除されます。

標準のレポート機能が弱いと、回避策はいつも同じで、毎月誰かの1週間分の時間を消費します:

"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

ついでに正しく理解しておく価値のある指標が2つあります。初回接触解決率(First Contact Resolution)は品質指標で、初回レベル解決率(First Level Resolution)はコスト指標です。HDIはこの2つが互換性のあるものではないと明言しており、正味のFLRは平均74.3%で、95%を超えるサービスデスクはわずか1.4%です。ワンタッチ解決率にも注意が必要です。Zendesk自身の定義では「エージェントの返信が1回、または返信が0回」のチケットをカウントするため、削除しただけのスパムチケットも成功としてカウントされてしまいます。

満足度の面では、CSATレポートはそれ自体が独立した設定作業であり、翌四半期ではなく同じ週のうちに整えておく価値があります。

AIレイヤーは第2の価格表

今やどのデスクも座席料金の上にAIを販売していますが、計測方法はベンダーごとにまったく一致していません。正直なところ、料金よりも単位の方が請求額を大きく左右するので、まず単位を確認しましょう。

「解決」と「エンゲージ」の間のギャップこそが、請求書がおかしくなり始めるポイントです。2026年5月18日から稼働しているZendeskの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

上限に関する主張にも、正直なところ同じくらいの懐疑心を持つべきです。Zendeskはサービスページで、AIエージェントが「最大80%のやり取りを自動化」できると謳っていますが、MetricNetの見解では、業界をリードする組織でも自動化率は最大50%程度としています。どちらも同時に真実であり得ます。ただしキューが異なる場合の話です。だからこそ、何かに署名する前に自分のキューでテストすることが重要なのです。もっと詳しく知りたい場合は、現実的なAI解決率の実態と、AIヘルプデスクが実際に何をするかをまとめた記事があります。

もう一つ、理論ではなく経験から強く主張したいことがあります。ナレッジベースに答えがない場合にAIが何をするかを必ず確認してください。デンマークの太陽光発電事業者を含む実際の有料顧客で、ボットがそのギャップを架空の主張で埋めて、それをそのまま実在の顧客に送ってしまったケースがありました。信頼度のしきい値と回答を保留するフォールバックは、あれば嬉しい機能ではなく、ハルシネーションを防ぐことと、まったく新しいカテゴリーのチケットを生み出すことの分かれ目です。

エスカレートしたチケットのコスト

サポートを高コストにしているのは、実は件数ではありません。エスカレーションです。

MetricNetのコストラダーでは、レベル1が22ドル、デスクトップサポートが62ドル、レベル3が85ドル、フィールドサポートが196ドル、ベンダーサポートが471ドルとされており、ここでの重要なキーワードは「累積」です。レベル1で記録され、レベル2にエスカレートされたチケットのコストは「62ドルに22ドルを足して、合計84ドル」になります。これらは2011年時点のドル建てなので、現在の見積もりというよりは比率として捉えるべきです。実際に重要なのはこの比率であり、だからこそMetricNetの枠組みでは、初回レベル解決率を最大化することは、基本的に総コストを最小化することとほぼ同義なのです。

ここで頭に入れておくべき補足的な数字が2つあります。エージェントの給与と福利厚生は、サービスデスクのコストの半分以上を占めており、スーパーバイザー、QA、トレーナーまで含めると、総コストのおよそ3分の2は結局人件費になります。そしてエージェント稼働率は平均48%で、60〜70%に近づくと「エージェントに過度な負荷をかけているため、比較的高い離職率につながる」という警告もあります。

つまり、サポートチケットシステムの本当のビジネス上の意義は、「1件あたりの返信時間を節約できる」ことではありません。構造そのものが、そもそもチケットがラダーを上っていくのを止めるという点にあります。より高い初回レベル解決率、より少ない再オープン、より少ないハンドオフです。これは、AIをすべてに一気に投入するのではなくティア1の対応に絞る理由でもあり、チケットデフレクションが送信メッセージ数ではなく回避できたエスカレーション数で測られる理由でもあります。

件数ではなくエスカレーションがすでに問題になっているなら、エスカレーション管理こそが、AIの買い物リストにある何よりも先に取り組むべきセットアップの部分です。

契約前に確認しておくこと

デモではエージェント画面を見せてもらえます。以下は、デモでは見せてもらえないことであり、初めてデスクを購入する場合でも、Zendeskの代替ツールへの乗り換えを検討している場合でも当てはまります。

1. 購入するプランで、必要なレポートを作成できるか? 機能名ではなく、正確なプラン名を聞きましょう。回答のスクリーンショットを保存しておきます。
2. 何がチケットをクローズし、それは何日後か? 自動クローズまでの期間と、顧客の返信でチケットが再オープンするのか新規チケットが作成されるのかを確認します。
3. ステータスはいくつまで持てて、いくつ表示されるか? Zendeskは最大100個のステータスを許可していますが、ピッカーにはアクティブな最初の10個しか表示されません。
4. 廃止したドロップダウンの値はどうなるか? 答えが「フィールドがnullになる」であれば、今のうちに分類体系を計画しておきましょう。
5. AIの課金単位は何か、書面で確認できるか? 解決、セッション、エンゲージした会話、それともやり取り単位か。そのうえで、放棄されたチャットが何としてカウントされるかも確認します。
6. AIがわからない場合、何をするか? 信頼度のしきい値がなければ、契約は見送りです。
7. データはどこに保存され、移動できるか? ZendeskのリージョンアドオンはSuite Professional以上で無料ですが、「含まれてはいるが自動的には有効化されない」もので、Freshdeskはサインアップ時にのみリージョンを選べます。
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

そして、スコープについて正直に触れておきます。この異議はもっともなものだからです。月間約7,000件のチケットを扱うサプリメントブランドのCXリーダーは、私たちにはっきりとこう語ってくれました。「自信を持って処理できるチケットだけをAIに任せて、それ以外はすべて手を付けないでほしい」。ベンダーが、何に手を付けないかをどう判断するのかを説明できないなら、それこそが質問6への答えです。

すでに使っているサポートチケットシステムでeeselを試す

この記事を読んでいるチームの多くは、実は新しいデスクを必要としていません。必要なのは、今使っているデスクからティア1のチケットが漏れなくなることであり、それこそがeeselの仕事です。すでに運用しているデスクの上に乗せるAIチケッティングシステムとして機能します。

eeselはZendesk、Freshdesk、Gorgias、Help ScoutなどにそれぞれのAPIを通じて連携し、過去のチケットとヘルプセンターから学習して、反復的な対応は自力で処理しながら、それ以外はすべてエージェントの手元に残します。

すでにプランに含まれているどのAIとも異なる点が2つあります。1人の顧客の目に触れる前に、自社のチケット履歴に対してすべてをシミュレーションできること。そして料金は処理したチケット1件あたり0.40ドルで、座席料金も最低利用料もないため、部分的な導入なら費用も部分的で済むことです。

これが、私が上記のセットアップ順序を信頼している理由でもあります。ZendeskとShopifyを使うドイツの宝飾品小売業者で実トラフィックのトライアルを実施したとき、月間約1,000件のチケットに対して、トリアージの精度は93%、スパム検出は100%だった一方で、そのまま送信されたドラフトはわずか12%でした。トリアージは準備できていましたが、ドラフト作成はまだでした。どちらがどうだったのかを、顧客が気づく前に教えてくれたのがシミュレーションです。無料で始めて、数分で自分のキューに接続できます。