ベストヘルプデスクソフト:9製品を徹底比較

ヘルプデスクソフトは、単なるメールボックスを業務の仕組みへと変える。依頼には担当者、状態、期限、そしてキュー内の位置が与えられ、チームは「誰かが覚えているだろう」に頼らずに済むようになる。

以下では、9つのプラットフォームを同じ基準で比較する。競合製品の価格は掲載していない。ページを改訂するより速いペースでプラン変更が行われるためだ。

チケットの構造

このカテゴリーのどのプラットフォームも同じオブジェクトをモデル化しており、違いはその周囲に何を備えているかにある。

チケットには担当者、ステータス、優先度、依頼者という要素がある。この4つのフィールドこそがヘルプデスクをメールボックスと区別するものであり、それぞれがメールでは答えられない問いに応える。誰が担当しているか、どこまで進んでいるか、どれほど緊急か、誰の課題を解決するものか、という問いだ。

次の層は時間軸だ。SLA目標は「緊急かどうか」を意見ではなく測定可能な指標に変え、エスカレーションは古くなったチケットを、顧客の苦情になる前に誰かの責任にする。

さらにその先にあるのが文脈だ。自分のスレッドしか知らないチケットは単なる作業項目にすぎない。顧客レコードに紐づいたチケットは、直近3件の依頼や電話でのやり取り、アカウントの契約レベルまで把握しており、その結果として対応内容も変わってくる。

共有受信箱かチケット管理システムか

このカテゴリーは2つの思想に分かれており、選択を誤ると、ベンダー選びを誤るよりも大きな摩擦を生む。

共有受信箱型のソフトはメールの形式を保つ。件名にチケット番号は付かず、顧客の目に触れる場所にステータス用語も現れず、返信は人が書いたもののように読める。ボリュームが少なく、堅苦しさが不自然に感じられる関係性に向いている。

チケット管理システムは作業対象を明示的なものにする。ステータス、キュー、SLAポリシー、一括操作がエージェントに見える形で存在し、あらゆる状態変化が記録されるためレポートも充実する。

決め手となるのはボリュームだ。月間およそ500件を下回る依頼数であれば共有受信箱の方が快適に感じられることが多く、それを超えると、状態管理の欠如が形式的な手間を上回るコストになり始める。

一部のプラットフォームは両方を兼ね備えており、表面上は受信箱の形を保ちながら、内部にチケット構造を持つ。これがRolChatの採用している方式だ。

9製品の概要

RolChat

RolChatは、表面は受信箱の形を保ちながら、内部にチケット構造を持つ。あらゆるメッセージは担当者、優先度、SLA目標、エスカレーション経路を持つ追跡対象アイテムとなり、ケース番号に変わることなくスレッドはそのまま続いていく。

その受信箱には11のチャネルが集約され、IVR、録音、文字起こしを備えたクラウド電話システムも含まれる。同じ依頼に関する通話とメールが1つのレコード上に並ぶ。

CRMは外部連携ではなくネイティブに組み込まれている。会社、連絡先、案件、パイプラインが同じワークスペースに存在し、これによって同期処理を必要とせずにアカウントの契約レベルごとにSLAを変えることができる。

AIはユーザー自身が用意するキーを使い、7社が提供する62のテキストモデル上で動作する。料金はシートではなく会社単位で、月額$19、$49、$99の3プラン、Enterpriseは個別見積もり。

向いているのは:チケットの規律は欲しいが形式張りたくないチーム、そして音声とCRMを同じサブスクリプション内に収めたいチーム。

Zendesk

Zendeskはこのカテゴリーの基準となる実装だ。トリガー、自動化、マクロ、ビュー、SLAポリシーは、このリストの中でも群を抜いて深く作り込まれており、レポート機能もそれに見合う。

エージェントワークスペースは大量処理を前提に設計されており、大規模なマーケットプレイスがコア製品でカバーしきれない部分を補う。

その代償は設定の複雑さだ。導入には数週間かかるのが一般的で、セールス面もこれまで別製品として扱われてきた。

向いているのは:専任の管理者を置ける、チケット量の多い組織。プランはZendeskの公式サイトで確認を。

Freshdesk

Freshdeskは成熟したチケット管理と強力な自動化を、主要な競合よりも軽い導入コストで実現しており、これが多くの中堅企業の候補リストに入る理由だ。

姉妹製品であるFreshworksファミリーは、チャット、電話、CRM、分析へと拡張しており、それぞれが独自の料金階層を持つ。

AI機能はスイート全体を横断してFreddyが提供し、条件はベンダーが公開している。

向いているのは:大量のチケット処理業務、特に他のFreshworks製品と組み合わせる場合。プランはFreshdeskの公式サイトで確認を。

HubSpot Service Hub

Service HubはCRMスイートの中に組み込まれており、初日から顧客レコードがマーケティングやセールスと文字通り共有される。

それが最大の強みであると同時に、主な制約でもある。価値を得るには広いプラットフォーム全体を採用する必要があり、サポート機能は複数のティアに分散している。

すでにCRMを運用している企業にとっては手軽な追加だ。それ以外の企業にとっては、単なるヘルプデスク購入以上に大きな意思決定となる。

向いているのは:周辺のCRMをすでに導入しているチーム。ティアの内容はHubSpotの公式サイトで確認を。

Help Scout

Help Scoutはこのリストの中で最もよく知られた共有受信箱で、メールを中心に構築され、ヘルプセンターを備え、意図的に落ち着いたエージェント画面を持つ。

チケット番号による形式張った運用を完全に避けており、返信がシステム生成のように読まれたくないチームに向いている。

オールインワン型プラットフォームに比べるとチャネル対応は限定的で、電話機能は製品に含まれていない。

向いているのは:キューの仕組みよりトーンが重視されるメール中心のサポート。プランはHelp Scoutの公式サイトで確認を。

Front

Frontはコラボレーション型の受信箱だ。内部コメント、共同下書き、担当割り当てが、別スレッドではなくメッセージのすぐ隣に表示される。

この形式は、アカウントごとに担当者が決まっており、返信を送る前にチーム内で相談するB2Bサポートに向いている。

チケットの形式張った運用や電話機能は上記のチケット管理システムに比べて軽く、ボリュームが増えるとFrontの代替ツールへの関心につながる。

向いているのは:名前の付いたアカウントに対して回答を共同で作成するB2Bチーム。プランはFrontの公式サイトで確認を。

Zoho Desk

Zoho Deskは非常に大きな製品ファミリーの中にある堅実なチケット管理ツールで、価格設定は長らくこのカテゴリーで最も攻めた水準にある。

他のZohoアプリケーションをすでに利用している組織にとっては、データモデルを共有できる点が確かな強みになる。

単体で使う場合、価格帯から想像されるより多くの設定作業が必要になる。

向いているのは:すでにZohoのエコシステム内にいる企業。プランはZohoの公式サイトで確認を。

Gorgias

Gorgiasはオンラインストア向けに特化して構築されたヘルプデスクで、注文データ、返金、サブスクリプション操作がチケット内で直接利用できる。

返品や配送に関する問い合わせを一日中さばくストアにとって、この特化はどの汎用プラットフォームよりも多くのクリックを省いてくれる。

課金はエージェント単位ではなくチケット量単位で行われ、このリストの他製品とは挙動が異なる。

向いているのは:特定のストアプラットフォームと密に連携するEコマースサポート。プランはGorgiasの公式サイトで確認を。

Groove

Grooveは小規模チーム向けのシンプルな共有受信箱で、ナレッジベースとレポートは、設定プロジェクトを必要とせずに基本を押さえている。

意図的に機能範囲を絞っており、それこそが最初のヘルプデスクに求める一部のチームにとってはまさに理想的な点だ。

チャネルの幅と自動化の深さは、同じ選択によって制限されている。

向いているのは:学習コストなしで最初のヘルプデスクを導入したい小規模チーム。プランはGrooveの公式サイトで確認を。

SLA、優先度、エスカレーション

SLAとは時間軸の付いた約束であり、その時間軸こそが多くの導入で最も間違えられやすい部分だ。

目標値はキューやアカウントの契約レベルごとに変えるべきだ。請求に関する問い合わせと障害対応は同じ応答時間を与えられるべきではなく、重要アカウントには通常それを明記した契約がある。

時間軸は勤務時間や休日を考慮しなければならない。そうしなければ、毎週末に誤ったSLA違反が発生し、レポートは誰も読まないノイズと化す。

エスカレーションこそが目標値を実効性のあるものにする。目標達成前に古くなったチケットを上司に引き上げるルールは、SLAを単なるレポート上の存在から実際の運用管理へと変える。

再オープン率は解決時間と並べて見るべき指標だ。解決件数が多くても再オープン率が高い場合、それはチケットが解決されたのではなく、単に閉じられているにすぎない。

組織変更にも耐える自動化

自動化は作るのは簡単だが、維持するのは難しい。ほとんどのヘルプデスクでは、誰も書いた記憶のないルールが積み重なり、その山が「何も変えたくない」理由になってしまう。

ルールセットを保守可能な状態に保つには3つの性質が必要だ。ルールはグリッドを解読するのではなく、文として読めること。個別に切り替えられること、そうすれば悪い変更を他に影響を与えずに元に戻せる。そして開発者ではなく管理者が編集できること。

適用範囲は文法と同じくらい重要だ。チケット、チャット、CRM、音声通話にまたがるルールエンジンなら、会話にタグを付け、担当者を割り当て、タイマーを開始し、案件を作成することを1つのルールで実行できる。モジュールごとのエンジンでは、各ステップの間に連携処理が必要になる。

対応可能件数の上限と勤務時間は同じエンジンに組み込まれるべきだ。実際に対応できる人を無視したルーティングは、結局キューを生み出すだけのルーティングになる。

ヘルプデスクにおけるAI

AIヘルプデスクソフトは3つの異なる仕事をカバーしているが、ベンダーはそのすべてを同じ言葉で説明する。

トリアージは最も目立たないが、しばしば最も価値の高い機能だ。エージェントが読む前に分類、タグ付け、優先度設定、振り分けを行う。

下書き作成はエージェントが実感しやすい機能だ。モデルが承認済みのコンテンツから返信を書き、エージェントが送信前に編集する。これにより誤った回答のリスクを負うことなく対応時間を短縮できる。

自律的な回答は3つ目の機能で、最も多くのコンテンツを裏付けとして必要とする。6件の記事だけを学習したアシスタントは、6件の記事しか読んでいないツールのように回答する。

商業面の問いはこの3つとは別に存在する。解決済みチケット単位の課金は、請求額を自動化の性能に直接結びつける。自社のモデルキーを接続すれば推論コストを卸値に抑え、モデル選択の裁量を買い手側に残せる。

中小企業向けの選択肢

中小企業向けヘルプデスクソフトには、明示されない3つの要件がある。低い導入価格、プロジェクト化しないセットアップ、そして再度移行せずに成長できる余地だ。

最初の2つは広く満たされている。実際に決め手となるのは3つ目だ。1年後の移行は、ライセンス差額で節約できた額をはるかに上回るコストになるからだ。

現実的なテストは、今後12ヶ月で必要になるものをそのプラットフォームがすでに備えているかどうかだ。通話、アカウントレコード、ティア別のSLA目標、そして第二言語対応は、多くのチームが想定するより早く必要になる4つの要素だ。

シンプルなヘルプデスクソフトは実在するカテゴリーであり、合理的な選択でもある。ただし「シンプル」が「機能が少ない」ではなく「設定項目が少ない」を意味する限りにおいてだ。

無料プランと後にかかるコスト

無料のヘルプデスクソフトは実在し、実際に機能する。ただしその制限はベンダーを問わず似通っている。

まずエージェント数の上限、次に履歴保持期間、そして連携機能の順で制限がかかる。上限は、成長中のチームが導入からおよそ四半期後に到達する水準に設定されている。

見落とされがちなコストはアップグレード価格そのものではない。無料期間中に構築した自動化、保存済み返信、レポートが、アップグレードが魅力的に見えない時点で他ベンダーへの移行時に引き継げない場合がある、という点だ。

RolChatに永久無料プランはない。30日間の無料トライアルはすべての機能を解放し、カード登録が必要で、初回課金は31日目、その3日前にリマインダーが届く。

セルフサービスとチケット削減

チケット削減は、このカテゴリーの中で唯一、作業を移すのではなく減らすレバーだ。

自社ドメイン上のヘルプセンターはトラフィックと検索の評価を自社に蓄積するが、ベンダーのサブドメイン上のものは他社の資産を築くことになる。記事がインデックスされてしまうと、この選択は覆すのが難しい。

記事の分析データと検索結果ゼロ件のレポートは、コンテンツの積み残しをキュー駆動型のリストに変える。繰り返し寄せられているのに対応記事がない質問こそ、次に書くべき記事だ。

アシスタントを同じ承認済みコンテンツに基づかせることで、チャットでの回答と記事内容の整合性が保たれる。1つの質問に2つの答えがある状態は、遅い1つの答えより悪い。

人員配置を変えるレポート

ほとんどのヘルプデスクのレポートは四半期に一度読まれるだけで、何も変えない。実際に意思決定を左右するレポートは、ダッシュボードが示唆するよりずっと限られている。

時間帯別のボリュームはシフトパターンを決める。理由別のボリュームは何を自動化し何を文書化するかを決める。再オープン率は品質が維持できているかどうかを決める。

エージェントごとの業務量よりも重要なのは、エージェント間の業務量のばらつきだ。均一なキューで平均処理時間が長いなら人員配置の問題であり、不均一なら振り分けの問題であり、それぞれ対応策が異なる。

音声がネイティブに統合されている場合、通話の指標も文書ベースの指標と同じレポートに含めるべきだ。2つのコンソールに分けてしまうと、あるチャネルを最適化する代わりに別のチャネルを犠牲にする結果になりがちだ。

メールの到達率と返信元アドレス

メールは今なお多くのヘルプデスクで最大のチャネルであり、返信元アドレスの設定は最も見過ごされがちな部分だ。

自社ドメインから送信するには、プラットフォームが指定するDNSレコードの設定が必要であり、それを省略すると、開設初日ではなく3週間後になって返信が迷惑メールフォルダに振り分けられ始める。

2つ目の注意点はスレッドの管理だ。返信チェーンを分断してしまうプラットフォームは、1つの会話に対して重複したチケットを生み出し、ボリュームレポートを水増しし、顧客を苛立たせる。

旧メールボックスからの転送ルールは一時的なものにとどめるべきだ。恒久的に残すと、2つのシステムが同じ依頼を自分のものだと認識してしまう。

移行とベンダーロックイン

ここに挙げたどのプラットフォームも、導入自体は容易だ。違いが出るのは離脱のしやすさであり、その差は購入時点で価格に織り込んで考える価値がある。

チケット履歴が使える形式でエクスポートできるか、ヘルプセンターの記事がリダイレクトを通じてURLを保持できるか、連絡先がカスタムフィールドを保持したまま移行できるかを確認しよう。

自動化はモデルが異なるため、プラットフォーム間で移行できない。マクロや保存済み返信の中身は移行可能で、再構築の方が元の構築より通常は速い。

2週間の並行運用は、ライセンス料1期間分のコストでリスクの大半を取り除ける。このカテゴリーにおいて最も安価な保険であることに変わりはない。

権限、ロール、監査ログ

ヘルプデスクは企業内のほとんどのシステムより多くの個人情報を保持しており、それを取り巻く管理機能はこのリストの中でも大きく異なる。

ロールは、どのキューを開けるか、どのフィールドを編集できるか、どのレポートを閲覧できるか、どのエクスポートを実行できるかを決めるべきだ。すべてに対する読み取り権限がデフォルトになっている製品は、あるべき数よりも多い。

監査ログは、何が誰によって行われたかを記録する。監査担当者が求める部分でありながら、求められるまで誰も確認しない部分でもある。

マルチブランド・ホワイトラベル設定は、代理店やグループにとって重要だ。1つのアカウント内で複数のブランドを分離しつつ、マネージャーはすべてを横断して見られる。

同意管理はデスクの一部として扱うべきで、別ベンダーに切り出すべきではない。RolChatはCookieバナー、Cookieスキャナー、同意台帳、DSAR対応を、サイトあたり月額$5のアドオンとして提供している。

多言語対応のデスク

第二の市場は、ヘルプデスク選定が2年以内に見直される最も一般的な理由だ。

インターフェースの対応言語がまず求められる条件であり、コンテンツの対応とは別物だ。RolChatは40言語のインターフェースに対応しており、ルーティングは空いている人ではなく、その言語を話せる人へと依頼を振り分けられる。

会話内翻訳は、人員配置の問題を「言語ごとに採用する」から「言語ごとに振り分ける」へと変え、これは新市場を開くか先送りするかの分かれ目になる。

ヘルプセンターの記事は、別サイトとしてではなく、1つのURL構造の下に言語バリエーションを保持すべきだ。そうしなければ、第二の市場は翻訳ではなく移行になってしまう。

他ツールとの連携

ヘルプデスクはCRM、請求システム、ストアプラットフォーム、カレンダーと隣り合って存在し、それらとの接続方法が、エージェントが手作業でどれだけコピーを行うかを決める。

本物の連携と単なる掲載を分ける問いは2つある。書き戻しができるか、つまりエージェントの操作が一方的に読み込むだけでなく他システムを更新するか。そして、どちらか一方のスキーマが変わっても開発者なしで動き続けるか。

連携数を数えることは、能力の指標としては不十分だ。CRM、チケット、音声をネイティブに備えたプラットフォームは、この3つをすべて借り物で揃える製品より必要な連携数が少なく、借り物のシステムはそれぞれが顧客レコードのずれを生む場所になる。

適切なコネクタが存在しない場合、チケット、連絡先、イベントを双方向でやり取りできるAPIとWebhookが、トライアル中に確認する価値のある代替手段だ。

よくある質問

Ruslan Nazarov

RolChatのSEO責任者

カスタマーサポートの運用、ライブチャット、AI支援型サービス、そして優れた顧客体験を支えるツールについて執筆しています。

LinkedIn