サービスデスクのチケッティングシステムとは何か、費用はいくらか

サービスデスクのチケッティングシステムとは実際には何なのか

私はeeselでインテグレーションを開発しています。つまり毎日、これらの製品のランディングページではなくAPIを読んで過ごしているわけで、その両者のギャップが最も大きいのがまさにこの部分です。ベンダーのホームページはどこも「ITサポートを効率化する」というような似たような文言を並べています。実際に自分が何を買っているのかは、その裏側のデータモデルが教えてくれます。

重要な違いから始めましょう。ヘルプデスクは壊れたものを直します。サービスデスクはそれに加えて、人が頼んだものを届けます。その後半部分こそが、このカテゴリーが存在する理由のすべてであり、作業の構造もまったく異なります。注文できるものを公開したリストが必要で、それぞれを適切な人の承認でゲートする仕組みが必要で、さらにキューを共有していないチーム間へと作業を振り分ける仕組みも必要になります。

Atlassianは名称がぐちゃぐちゃであることを潔く認めています。同社はHDIの調査を引用し、41%のデスクは「別の名前で呼ばれている」としたうえで、「このHDI調査で報告されているサービスデスクやヘルプデスクが、我々の定義と一致している保証はない」と付け加えています。つまり、箱に書かれた言葉で選んではいけません。そのツールがリクエストをカタログエントリー、承認者、子タスクを持つ第一級のものとしてモデル化しているのか、それとも単にステータス欄付きのメールとして扱っているだけなのかで選ぶべきです。この議論の長いバージョンは、別記事のヘルプデスク対サービスデスクにまとめています。

1つの依頼、3つのレコード番号

この違いを見る一番わかりやすい方法は、たった1つの文がどうなるかを追いかけることです。

「ノートPCが起動しない」はインシデントです。レコード1件、担当者1人、解決策1つです。「新しいノートPCが必要」はリクエストで、ServiceNowの中では3つの異なる採番シリーズを持つ3つのレコードになります。まずリクエスト(sc_request、REQ接頭辞)、これは1回のチェックアウトに対するカート単位のコンテナです。次にリクエストされたアイテム(sc_req_item、RITM接頭辞)、注文されたカタログアイテムごとに1つ作成されます。そしてカタログタスク(sc_task、SCTASK接頭辞)、これはアイテムのフローが生成する実際のフルフィルメント作業です。ServiceNow自身のService Catalog APIリファレンスには、"number": "REQ0010012"と"table": "sc_request"を含むチェックアウトのレスポンス例が載っており、これは伝聞ではありません。

1回のチェックアウトでノートPCとモニターを注文すると、REQが1つ、RITMが2つになります。それぞれのRITMは複数のSCTASKを生み出すことがあります。調達・イメージング・発送はそれぞれ別の担当者の仕事だからです。レポートを作る前に押さえておきたい癖が1つあります。カタログの回答項目はRITMにしか存在しません。ServiceNowは「変数はリクエストされたアイテム[sc_req_item]テーブルにのみ紐づく」と明言しており、これが理由でSCTASKを処理する技術者は、誰かが意図的に表示させない限り、その人が実際に何を頼んだのかを見られないことが多いのです。

レコード数を気にすべき理由は、整理整頓のためではありません。MetricNetの技術者あたりのチケット数ベンチマークによれば、キューのうちリクエスト側の作業量は、インシデント側のおよそ3〜5倍で、そこからチケットあたりのコストも導かれます。デスクトップサポートではサービスリクエスト1件113ドルに対し、インシデントは48ドルです。これらの金額は2011年のものと理解し、金額そのものより比率のほうを持続的な数値として扱ってください。

カタログこそ、ベンダー間で密かに意見が割れる場所

どのベンダーも「サービスカタログ」を売り物にしていますが、その意味するところはほとんど一致していません。しかもその違いは、どのツールを買うべきかを左右するほど大きなものです。

Jira Service Managementにはカタログ製品というものがありません。Atlassianはそれを率直に認めています。ITSMテンプレートには「よくあるリクエストのサービスカタログが付属しており、これらはリクエストタイプと呼ばれる」とあり、カタログを見るにはスペース設定からリクエスト管理、リクエストタイプへと進みます。専用のビルダーは存在しません。旧set-up-a-service-catalogというドキュメントURLは404になります。そもそもそんなものが存在しないからです。これは必ずしも悪いことではなく、カタログにプランのゲートがかからないということでもありますが、カテゴリーや価格が並ぶショッピング体験を期待してくると驚くことになるでしょう。あるAdmin(管理者)は、Atlassianのトレーニングコールでリストは小さく保つべきだと言われたと報告しています。

"The answer that I got was like, 'You shouldn't have more than 8-10 requests in your help center so if they need unique workflows then it shouldn't be a problem.'"

u/Hefty-Possibility625, r/jira, Reddit

8〜10件というのはヘルプデスク相当の受付件数です。エンタープライズ向けカタログとは言えません。これをガイダンスと見るか構造的な上限と見るかは人によりますが、いずれにせよ製品の重心がどこにあるかを物語っています。

Freshserviceはカタログを2番目のティアの後ろに置いています。エージェント1人あたり月額19ドルのStarterアカウントでは、インシデント、ナレッジ、タスク、ポータルが使えますが、カタログもサービスアイテムもなく、したがってカタログフォームから起票するサービスリクエストもありません。カタログが使えるようになるのはGrowth、49ドルからで、これはサービスデスクたらしめるたった1つの機能のために、エントリー価格から158%も跳ね上がることを意味します。SLA管理も同じライン上にあり、これがさらに影響を大きくします。子リクエストは「対応するSLA」に対して強制適用されるからです。

**ManageEngineはそれを別料金にしています。**ServiceDesk PlusはStandardで技術者1人あたり13ドル、Professionalで27ドルと表示していますが、サービスカタログはアドオンとして販売されており、クラウドのアドオン表では年間1,595ドル、年間契約表では1,195ドルです。バンドルされているのは67ドルのEnterpriseのみです。CMDBはさらに年間1,595ドルで、こちらはProfessional限定です。

**SolarWindsは最下位プランから含めています。**そのサービスカタログとAdvanced Approval Workflowsは、Essentials、Advanced、Premierのいずれでも「含まれる」と表示されており、これが39ドルのEssentialsプランをこのリストの中で最も安く本物のカタログと承認の組み合わせを手に入れられるプランにしています。承認に関連する2つの項目、Service Portal TasksとApprovals、そしてPortal Designerだけはゲートされたままで、いずれもAdvancedが必要です。

**ServiceNowはそれを含めつつ、別の場所で課金します。**Service CatalogとRequest Managementは、Incident ManagementやAsset Managementと一緒に、ベースティアであるITSM Foundationの中に含まれています。しかし価格ページには金額の記載が一切なく、「Get Custom Quote」ボタンが1つあるだけなので、カタログにプランゲートがないことはあまり慰めになりません。

**Haloは文字通りすべてをバンドルしています。**プランは1つだけ、年間契約でエージェント1人あたり月額69ポンド、承認ワークフロー、CMDB、プロジェクト管理、AIはすべて基本料金に含まれており、「ティアなし、アドオンなし、機能の囲い込みなし」と明言されています。落とし穴は脚注にあります。オンボーディングパッケージは購入時に個別見積もりの費用で必須となり、米ドルの金額はクライアント側で挿入されるため、実際に表示されるのはGBP(英ポンド)価格だけです。

承認、経過時間と請求額の両方を決めるステップ

これらのAPIのほとんどに対して開発してきた私の正直な感想を言うと、承認こそが、サービスデスクを購入するうえで最も研究されていない要素であり、遅延と想定外の請求の両方がそこに潜んでいます。

承認の扱いはベンダーごとにまったく異なります。Jira Service Managementでは、承認はフォームの設定ではなくワークフローのステータスのプロパティとして存在します。Atlassianのワークフロー承認ドキュメントは率直に、「承認ステップを含める」チェックボックスは、ステータスがすでに少なくとも2つの遷移(承認用と却下用)を持っている場合にのみ利用できると述べています。つまり複数段階の承認は、実はビルダー機能ではありません。承認付きのステータスを自分の手でいくつも連結していく作業なのです。定足数は設定可能ですが、却下だけは絶対的です。承認者の1人でも却下すれば、設定した数にかかわらず作業アイテムは却下されます。

Freshserviceは旧来の逐次モデルを承認グループとチェーンに置き換えました。グループルールが4種類、チェーンルールが4種類あり、グループはチェーンの中で並行して実行されますが、アクティブなチェーンは一度に1つだけです。まだレガシーモデルを使っていますか?日付を控えておいてください。Freshserviceは、レガシー承認の廃止に対する最後の延長は2026年8月で、「それ以降はこれ以上の延長は行われない」としています。この移行にはAPI周りの厄介な副作用もあります。旧来の単一承認者エンドポイントは一度に1人の承認者しか受け付けませんが、移行後はすべての呼び出しが独自のグループを作成し、チェーンルールはデフォルトで「すべてのグループの承認が必要」になるため、以前は「誰か1人」でクリアできていた承認が静かに滞留するようになります。

ここからが商業面の話で、契約書にサインする人にこそ見せたい部分です。

Jira Service Managementでは、承認者は無料です。Atlassianははっきりと述べています。「承認者にJira Service Managementのライセンスは不要」で、サービススペースの顧客であればよいだけです。

ServiceNowでは違います。承認専用のユーザーは、代わりに別途課金されるBusiness Stakeholderクラスに分類されます。ServiceNowの社員自身によるライセンスガイドは、その仕組みをこう説明しています。

"Business Stakeholder (BSH): This one catches people off guard because it is measured across two separate tables - one for role assignment and one for approval activity. A user qualifies as a BSH if they hold an Approver role but hold no Fulfiller role. The moment a BSH user gains a Fulfiller-mapped role, they move out of BSH measurement entirely."

About ServiceNow Licensing Guide, ServiceNow Community

承認チェーンが、普段はチケットに一切触れない60人のマネージャーへとルーティングされているなら、この一文がそのままあなたの予算になります。そして無料リクエスター分の節約は、良いエンプロイーポータルを追加した瞬間に完全に消え去ります。Employee Center ProやHRSDのような製品はUnrestricted Userモデルで課金され、そのインスタンス上のアクティブユーザー全員がカウントされるからです。

実務担当者は、最初のカタログアイテムを作る瞬間にこれにぶつかります。2025年12月、あるAdminが当然の疑問を投げかけました。

"I know I need the itil role for approvers to approve the requests, but, is that it? Isn't there like a 'lower' role that I can assign them that is enough for them to view the answers of the item and approve/reject the catalog task instead of assigning them the itil role?"

u/edoo_stuff, r/servicenow, Reddit

以前の回避策は「メール承認」で、ロールの制約を完全に迂回するものでした。そのスレッドへの返信は、その抜け道が閉じられたと報告しています。"Email approvals require the business stakeholder license to be assigned. This has come up for a ton of my clients recently." つまりServiceNowの承認チェーンは、その中にいる全員の価格を先に把握しない限り設計できないということです。

フルフィルメント、1件のリクエストを10件に変えるチェックボックス

承認が下りたら、ツールはその作業を分岐させなければなりません。ここは購入者が最も評価せず、それでいて最も長く付き合うことになるレイヤーです。

Freshserviceの仕組みは、カタログアイテム上のたった1つのチェックボックスです。**「上記の各アイテムに対して子リクエストを作成する」**というものです。オフのままなら、すべての行アイテムは1人のエージェントに割り当てられた1件のチケットの中に収まり、そのエージェントが各アイテムを手動でDeliveredかCancelledに切り替えます。オンにすると、各アイテムは個別の子チケットになり、Systemがリクエスターとして設定され、それを所有する部署へとルーティングされ、それぞれが独自のSLAクロックを持ちます。Freshservice自身が示す実例では、New Employee Hireという親から、New CRM Account、Apple MacBook、Adobe Photoshop CS6という子が生まれます。

私にとって、このチェックボックスはこのカテゴリー全体を最も鋭く象徴するものです。スイッチ1つが、共有受信箱とサービスデスクの違いになるのです。

これには本番環境で噛みつかれる点が2つあり、どちらもFreshservice自身のドキュメントに書かれています。親チケットをクローズすると、紐づく子チケットもすべて自動クローズされます。ドキュメントには「親チケットをクローズする前に、すべての子サービスリクエストが完了していることを確認してください」という警告があります。さらに、親エンティティの下には100タスクという上限があり、これは大量のオンボーディングの波が来るまでは十分に思えます。

ServiceNowにおける相当機能は、アイテムのフロー内にあるCreate Catalog Taskアクションで、作業ステップごとにsc_taskレコードを生成します。特筆すべきは、Jira Service Managementにはこの形の分岐機能がネイティブにはまったく存在しないことです。リクエストタイプごとに得られる作業アイテムは1つだけで、複数チームにまたがるフルフィルメントは、自動化や子課題を使って自分で構築するものになります。

資産、誰も予算を組んでいない2つ目のメーター

サービスデスクのチケッティングシステムが配布したものを追跡するなら、CMDBが必要になり、そのCMDBには独自の価格表が付いてきます。

• Freshserviceはデバイスを個別に計測しません。代わりに独自のライセンス指標である**Asset Units**で課金し、500単位のパックで購入します。パックの価格も、プランごとに含まれる割り当て量も、その価格ページのどこにも公開されていません。
• SolarWindsは、最も明確でありながら最も見積もりゲートがかかっているという両立を果たしています。IT資産管理は「追加購入として利用可能」で、すべてのプランカードに「資産価格はお問い合わせください」と書かれており、カウントのルールは広範です。ネットワークにアクセスできるデバイスはすべて資産上限にカウントされ、「IPアドレスが実際に追跡されていなくても」対象になります。
• Jira Service Managementは価格の代わりにオブジェクトの割り当て量を公開しています。Standardで5,000、Premiumで50,000、Enterpriseで500,000、そしてサイト全体で1,000万という上限がその上にあります。上限を超えるとインポートが失敗します。Assetsも会社管理スペース限定の機能で、チーム管理スペースにはCMDBがありません。
• ManageEngineは、技術者に加えてもう1つの単純な次元として、管理下のIT資産に課金します。同社の価格ページにはまさにこう書かれています。「IT資産管理を使う場合、管理するIT資産の数に応じて課金されます」。
• HaloとServiceNowはどちらも基本プランにCMDBを含めており、それぞれ69ポンドのシート料金と非公開の見積もりの中に組み込まれています。

サービスデスクのチケッティングシステムが2026年にいくらかかるか

これは、私がこれらの価格ページを読み始めたときにあってほしかった比較表です。すべての数値はベンダー自身のページに掲載された定価で、2026年7月31日時点で確認したものです。

この表から読み取れることが2つあります。

第一に、最も安いシートと最も安いカタログが同じ製品であることはほとんどありません。ManageEngineはシート価格で勝ちますが、サービスデスクたらしめる部分には年間1,595ドルを請求します。Freshserviceのカタログの実際の入口は19ドルではなく49ドルです。Zendeskも29ドルと59ドルで同じ手を使っています。SolarWindsは39ドルで高く見えますが、実はカタログと承認エンジンの両方がすでに含まれていることに気づくはずです。

第二に、AIや資産をオンにした瞬間、シート価格は請求額を予測する指標ではなくなります。カウンターは1つではなく4つあり、価格ページに大きなフォントで載っているのはそのうちの最初の1つだけです。

AIレイヤーには独自のメーターがあり、単位がレートに勝る

これらのベンダーはいずれも、いまやサービスデスク向けにAIを販売していますが、それぞれ数え方が異なります。数字そのものより、単位のほうが重要です。

ServiceNowは2026年7月23日、assistsのレートカードを公開の法的PDFとして公表しており、これが現時点で大手プラットフォームの中で最も透明性の高いものになっています。ITSMに関連する行を挙げると、インシデントの要約は1 assist、承認の推奨は1、カタログフォームの事前入力は1、Virtual Agentのトピックをエンドツーエンドで実行すると10、複数ターンにわたるカタログ注文は10、そしてエージェント型ワークフローは触れるツールの数に応じて25、50、150のいずれかです。Assistsは本番環境とサブ本番環境をまたいでアカウント単位でプールされます。ワークフローは完了時、20アクション到達時、または1時間のアイドル状態で終了します。つまり21番目のアクションは2つ目の課金対象ワークフローを開始することになります。

この画面で注目すべき点があります。実際にティア1のボリュームを解決するL1 Service Desk AI Specialistは、Prime限定です。FoundationとAdvancedが手にするのはアシスト型のAIです。

Freshserviceはセッション単位で数えます。これは、ユニークユーザーが24時間の枠内でAIエージェントと行うあらゆるやり取りと定義されており、結果ではなく試行に課金することになります。各Enterpriseライセンスには年間1,200セッション(月100セッション相当)が含まれており、超過レートはどこにも公開されていません。Freddy AI CopilotはProとEnterpriseで別途エージェント1人あたり月額29ドルで、Proのシート料金は128ドルまで押し上げられます。

Jira Service Managementは同時に3つのメーターを走らせます。シートにバンドルされたRovoクレジットに加えて、月1,000件を超えると1対応会話あたり0.30ドルからのバーチャルサービスエージェント、さらに1解決あたり1ドルのRovo Customer Serviceがあります。落とし穴は「対応」の定義にあります。Atlassianは、エージェントが解決したかエスカレーションしたかにかかわらず、意図にマッチしたすべての会話をカウントします。つまりエスカレーションされたチケットにも課金されるということです。

それが購入判断を一言でまとめた質問です。解決メーターはうまくいったときに課金します。セッションや会話メーターは、試みただけで課金します。

デフレクションについてベンチマークが正直に語ること

デフレクションの数字を根拠に何かを買う前に、営業資料ではなく調査データに照らして基準を合わせてください。

MetricNetのベンチマークデータベースによれば、世界のサービスデスクの平均セルフサービス完了率は10.4%で、セルフサービスをまったく持たないデスクの0%から、最高で55%までの幅があります。以前の調査では8.9%という数字が出ており、「これら自己解決されたインシデントの大部分はパスワードリセットである」と指摘されています。ネットの一次解決率は平均74.3%で、95%を超えるサービスデスクはわずか1.4%にとどまります。

同じ調査には、ほとんど誰も言及しないのに誰もが体感している二次的な効果があります。簡単なチケットがデフレクションされるにつれ、「生身のエージェントが引き続き対応するインシデントの平均的な複雑さと平均対応時間は増加する」というものです。デフレクションはキューを縮小するだけではありません。それを濃縮するのです。だから、残る難しい案件の組み合わせを前提に人員配置を計画してください。

この話が財務的に重要になる理由はエスカレーションのはしごにあります。MetricNetはレベル1サポートを1チケット22ドル、デスクトップサポートを62ドル、レベル3を85ドル、フィールドサポートを196ドル、ベンダーサポートを471ドルと価格づけしており、このはしごは累積的です。レベル1でログされ、レベル2にエスカレーションされたチケットは、62ドルだけでなく62ドルに22ドルを足したコストになります。これらは2011年のドル建てと理解したうえで、その結論は持続的なものとして読んでください。「FLRを最大化することは、TCOを最小化することと同義である」。

これらのデスクを実際に運用している人たちが本当に言っていること

ベンダーのページはこうしたことを何も教えてくれないので、ここでは過去12か月の実務者の声を紹介します。

カタログがうまく機能しているかどうかについて、私が見つけた最も鋭いテストは機能ではまったくありません。誰も報告しない数字です。

"Every incident/request should narrow down to an obvious CSI that an idiot in a hurry could categorise, consistently and repeatedly. If everyone is just hitting other, other, other then it's failed. Capital F."

u/gumbrilla, r/ITManagers, Reddit

自分のリクエストの何パーセントが汎用バケットに入っているかを確認してください。もしそれが高いなら、カタログアイテムを増やしても助けにはならず、誰も迷わず辿れないような分類体系の上にAIルーティングを重ねても同じことです。

ライセンス面では、このカテゴリーで最も高くつく誤解は「誰がエージェントとしてカウントされるか」です。あるAtlassianの購入担当者は、自分の試算をクラウドエンジニアの試算と並べて投稿しました。

"What I think I need (for starters): $ 8500 / year

What the cloud engineer thinks I need (for starters): $ 40,750 / year

JSM Standard - 10 agents - annual cost $2000

Confluence Standard - 10 users - annual cost $ 500

Atlassian access - 200 users - $6.000 (this one hurts)

JSM Standard - 200 agents - annual cost $25,750

Confluence Standard - 200 users - annual cost $ 9000

Atlassian access - 200 users - $6.000" -- u/LooselySubtle, r/atlassian, Reddit

これは200人の従業員がエージェントなのかリクエスターなのかだけで生じる4.8倍の振れ幅です。どんな2つのツールを比較する前にも、まずこの点を文書で確定させてください。

そしてAIについて。今年読んだ中で最も有益だったスレッドは、あるServiceNowのプロダクトデザイナーが、参考にできるNow Assistの成功事例を自分たちのコミュニティに求めたものでした。返ってきた返信は、期待していたものとは違いました。

"These features all seem like things that make for a cool demo but don't actually save a company much time or money. Most of our closed incidents never get looked at again, and when they need to be looked at it's not particularly hard to read the history."

u/pnbloem, r/servicenow, Reddit

同じスレッド内の別の返信は、精度に関する主張を直接突きました。

"There is a persistent belief in the big tech bubble that it can, but it simply isn't good enough. It's auto prediction on steroids. Traditional automation is far more effective than chained ai agents that are only 50% accurate."

u/paablo, r/servicenow, Reddit

私はサポートキュー向けのAIを売る立場ですが、その返信は基本的に公正なものだと思います。要約とドラフト作成は、デモでは最も映える一方で、実際にはほとんど何も変えない機能です。サービスデスクの数字を本当に動かすのは地味なことです。誰かが開く前に、繰り返される質問に正しく答えることです。それ以外はすべて、規模が変わらないキューの上の装飾にすぎません。

契約前に実際に確認すべきこと

本番のサポートおよびITキューにAIエージェントを導入してきた3年以上の経験から言うと、私がベンダーに投げかける質問は、機能比較表とはまったく似ていません。

1. **トライアル中にオンボーディングリクエストを起票してみてください。**パスワードリセットではありません。1回の申請の中でノートPC、アカウント、電話をまとめて注文し、2人の別々の人物として承認し、その後いくつのレコードが存在するか、そしてどのフルフィルメントタスクがまだ未完了かを一目で判別できるかを確認してください。
2. **承認者の数を数えて、それがどうライセンスされるかを尋ねてください。**ほとんどのツールではこれは無料です。ServiceNowでは課金対象のクラスであり、良いエンプロイーポータルを使うと、さらにアクティブユーザー単位の課金へと移行します。
3. **AIメーターが何をカウントするのかを、書面で確認してください。**セッション、会話、assist、それとも解決なのか。そのうえで超過レートを尋ねてください。FreshserviceとZendeskはどちらも割り当て量は公開していますが、レートは公開していません。
4. **資産の価格を尋ねてください。**SolarWindsとFreshserviceはどちらも見積もりゲートをかけています。これは小さな項目ではありません。
5. **契約に縛られる前にエクスポート経路を確認してください。**Freshserviceにはカタログ用のUIエクスポートがまったくなく、ドキュメント化された回避策はAPIコールです。エンジニアが手元にいるなら問題ありませんが、いなければ厳しいものです。

そして自分自身のカテゴリーについて、正直な注意点を1つ。サービスデスク上のAIは魔法ではなく、私にはそれを証明する傷跡があります。有償の顧客の中には、デンマークの太陽光発電会社もありましたが、そのボットは回答をでっち上げ、ナレッジベースに一致がなかったときに、それを実際の顧客に送ってしまったことがあります。だからこそ、あらゆるeeselの導入は必ず過去のチケットに対してシミュレーションされますし、自分自身のチケット履歴でテストされていないデフレクションの主張は、自分のものも含めて信用しません。

こうした購入のほとんどを決める反対意見は、価格ではなくコントロールです。月間およそ7,000件のチケットを抱えるあるサプリメントブランドのCXリードは、私よりうまくそれを言い表しました。AIがすべてに答えることは決してないが、それ以外のすべてに「申し訳ありませんがわかりません」と答えるだけなら、「AIが実際に良い回答をしたかどうかを確かめるために7,000件のチケットを全部チェックするなんてできない、それでは意味が少し失われてしまう」というのです。彼らが求めていたのは、自信のあることだけを処理し、それ以外には手を出さないAIでした。私はその契約を、信頼度ベースのルーティングを理由に失注しましたが、それが製品をより良いものにしました。

2026年に私ならどう選ぶか

キューの大半が障害対応で、技術者が10人未満なら、ManageEngineの無料StandardティアかFreshservice Starterから始め、リクエストが実際にインシデントの数を上回るまではカタログを完全にスキップしてください。中身を入れないカタログを買うことが、このカテゴリーで最もよくある無駄です。

本物のカタログと承認機能を、正直な意味で最も安く手に入れたいなら、39ドルのSolarWinds Essentialsが選択肢です。どちらもベースプランに含まれており、後から売りつけられることがないからです。

すでにAtlassianを使っているなら、Jira Service Managementはコスト構造の面で反論しにくい選択肢です。無料・無制限のリクエスター、無料の承認者、1〜15エージェントで25ドル。ただし価格ページの計算機はデフォルトで75エージェントに設定されているため、表示される20ドルはブレンドレートであって定価ではないことを知っておいてください。カタログはリクエストタイプとして、分岐は自動化として自分で構築するものと想定して臨んでください。

本物の変更管理とCMDBの義務を抱える大規模エンタープライズなら、**ServiceNow**がここで最も完成度の高いモデルであり、インシデント・変更・CMDBの設計が間違っていると本気で主張する人はいません。不満はコストとクリック数と導入期間についてであり、正しさについてではありません。そのG2評価は1,915件のレビューで5点満点中4.5、星5つが70%、星1つはゼロで、これはダメな製品のプロファイルではありません。

そして、何もゲートされていない1つの価格こそが本当に欲しいものなら、Haloがここで唯一それにコミットしているベンダーです。ただし個別見積もりのオンボーディング費用と、GBPでしか公開されていない金額を許容できることが条件です。

すでに運用中のサービスデスクの前にeeselを置く

ここまでの話のどれも、チケッティングシステムを丸ごと入れ替える理由にはなりませんし、私もそれは勧めません。2026年にサービスデスクの経済性を変えるのは、別のキューではありません。技術者がリクエストを開く前に、そのリクエストに何が起きるかです。

それが私が作っているものです。eeselはすでに使っているデスクにそのまま組み込まれ、過去のチケットや、Confluence、Slack、Google Docs、あるいはナレッジベースにある既存のドキュメントから学習し、繰り返されるリクエストにファーストレスポンダーとして回答します。キューが顧客対応であろうと社内ITであろうと、作業の形は同じです。

InDebtedのIT責任者、Jason Loyolaは、まさにこの形のデスクでそれを運用しています。

"We use it to be the first responder to our Helpdesk tickets in Jira. It essentially acts just like an agent would."

Jason Loyola、IT責任者、InDebted

彼のチームは現在、社内ITチケットにおいて15%のデフレクション率で、目標は55%です。私は完成した数字よりも進行中の数字を引用するのが好きです。サービスデスクの導入はスイッチではなく、徐々に立ち上がっていくランプだからです。

この特定の問題にフィットする理由が2つあります。価格にはシートという次元がまったくありません。処理チケット1件あたり0.40ドルで、エージェントごとの料金も最低利用料もないため、承認者を60人追加しても、リクエスターを1,000人追加しても、コストはゼロです。そしてキュー全体ではなく一部だけをルーティングできるので、ティア1の時間を食いつぶしている繰り返しのカタログ質問20件だけに絞り込み、変更承認には手を出さないという選択もできます。Jira Service Managementを使っているなら、接続には数分しかかからず、無料で試せます。