ナレッジベースソフトウェアの料金と選び方

ナレッジベースソフトウェアは1つのカテゴリとして売られていますが、実際には3つの異なる製品として動きます。公開ヘルプセンター、社内Wiki、製品ドキュメントサイトは、どのカタログでも同じ見出しの下に並んでいますが、権限、検索、請求書を見ていくと、ほとんど共通点がありません。

形を取り違えることが、高くつく失敗です。しかもトライアル中にはまず気づけません。見えてくるのは2年目の請求書で、そのころにはコンテンツがすでに書かれていて、移行はひとつのプロジェクトになっています。

以下の料金はすべて、2026年9月5日に提供企業自身の料金ページから読み取ったもので、いずれ変わります。数字ではなく、料金モデルを読んでください。

数字で見るナレッジベースソフトウェア

提供企業との商談に持ち込む価値のある6つの数字です。すべて2026年9月5日時点のものです。

月額0ドルから799ドルが、10人のチームにとって現実的な幅のすべてです。違いは、提供企業がどの単位で課金するかだけで決まります
0.75ドルから0.99ドルが、料金を公開している2社でのAI解決1件の費用です。Help Scoutは0.75ドル、Intercomは0.99ドルです
1エージェントあたり月額55ドルが、本格的なサポートスイートに組み込まれたナレッジベースの入門価格です（Zendesk Suite Team、年払い）
1サイトあたり月額65ドルに編集者1人あたり12ドルが、閲覧者が無料のドキュメント製品の費用です（GitBook Premium、年払い）
月額249ドルの定額が、席数ではなくユーザー数の区分で課金する専用ナレッジベースツールの出発点です（Helpjuice、30ユーザーまで）
**提供企業の5社に1社は、価格をまったく公開していません。**Document360は、料金表を構成に関する質問票に置き換えました

この開きは、機能の差ではありません。提供企業が誰を数えると決めたか、の差です。

1つのカテゴリ名の裏にある3つの製品

3つを分けるのは、機能の一覧ではありません。コンテンツを誰が読むかです。それによって、提供企業が誰の分を請求するかが決まります。

公開ヘルプセンターはサポートツールに付属します。顧客が読み、サポート担当が書き、全体が、質問がチケットになるのを防ぐために存在します。検索は、こちらの用語を知らない人向けに調整され、分析が答える問いは1つだけです。どの記事のおかげで、チケットが開かれずに済んだか。

社内Wikiは、ノートとWikiツールの多くが取る形で、従業員が読み、全員が書きます。難しいのは公開ではなく、権限です。コンテンツは本質的に雑然としていて、半分は1年以内に古くなり、ツールの本当の仕事は、古い版の隣で最新版を見つけられるようにすることです。

製品ドキュメントサイトは、あなたの製品と連携する人が読みます。リポジトリの隣にあり、リリースごとにバージョン管理され、たいていはリッチテキストエディタを受け入れない人たちがMarkdownで書きます。

	公開ヘルプセンター	社内Wiki	ドキュメントサイト
読む人	顧客（未認証）	従業員	開発者と連携担当者
書く人	サポートチーム	全員、ばらつきあり	エンジニアリングとテクニカルライター
請求の対象	サポートエージェント	全従業員	サイトと編集者
検索が対応すべきもの	自社ではなく顧客が使う言葉	古い版と最新版の区別	正確なAPI名とコード
期待されるエディタ	リッチテキスト	リッチテキスト	リポジトリ内のMarkdown
バージョン管理	ほぼ不要	ほぼ不要	リリースごと、必須
よくある失敗	公開後、誰も更新しない	権限の乱立	ドキュメントがリリースに遅れる

どれか1つのために作られたツールは、他の2つをうまくこなせません。しかもデモではそれが見えません。社内Wikiを顧客向けに使えば、望んでいなかった認証の壁が現れます。ヘルプセンターにエンジニアリングのドキュメントを置けば、コードブロックを崩すエディタに当たります。

30人を超えた会社の多くは、3つのうち2つを持つことになります。それは調達の失敗ではありません。読者が求めるものが違い、1つのツールで両方をまかなうと、たいてい社内コンテンツが整いすぎて更新が続かないか、公開コンテンツが粗すぎて出せないかのどちらかになります。

請求書は実際に何を数えているのか

ナレッジベースソフトウェアの課金方法は6通りあり、モデル間の差は、機能一覧の差よりはるかに大きいです。

ツール	課金の対象	2026年9月5日時点の料金
Zendesk	サポートエージェントごと	Suite Teamは$55/エージェント/月、Suite Professionalは$115/エージェント/月（年払い）
Help Scout	ユーザーごと、無料プランあり	5ユーザーとDocsサイト1つまで無料。Standardは$25、Plusは$45、Proは$75（ユーザー/月）。追加のDocsサイトは1つあたり$20/月
Intercom	席ごと、加えてAI解決ごと	Essentialは$29、Advancedは$85、Expertは$132（席/月）。Finは1解決あたり$0.99
Helpjuice	ユーザー数による定額区分	30ユーザーまで$249/月、100ユーザーまで$449、無制限で$799
GitBook	サイトごと、加えて編集者	Premiumは$65/サイト/月（年払い）に加えて1ユーザー$12。Ultimateは$249/サイト/月
Notion	メンバーごと、Wiki中心	個人は無料。Plusは$10、Businessは$20（メンバー/月）。AIエージェントは1,000クレジットあたり$10
Document360	見積もりのみ	公開価格なし。営業との会話のあと、構成に応じて価格を決定

エージェントごとは、最も隠し事の少ないモデルです。その人たちにはもう給料を払っていて、ナレッジベースはそれに付いてくるだけで、記事を1本足す費用はゼロです。落とし穴は、書く人全員がサポートの席である必要があることです。1段落だけ直したいプロダクトマネージャーは、55ドルの席を取るか、席を持つ誰かに頼むことになります。

ユーザーごと、無料の下限ありは、多くの小規模チームが始めるべきモデルです。Help Scoutの無料プランは5ユーザーとDocsサイト1つを含み、これは無料で完結する公開ヘルプセンターです。1ユーザー25ドルへ跳ね上がるのは、サポートチームが大きくなったときだけです。

解決ごとは、ソフトウェアがうまく動いたときにだけ提供企業が報酬を得る唯一のモデルです。IntercomはAIエージェントが人手なしで会話を終えるたびに0.99ドル、Help Scoutは0.75ドルを請求します。これは誠実ですが、予算化もできません。セルフサービスがうまくいった月のほうが、うまくいかなかった月より請求額が大きくなり、その数字は人数ではなくトラフィックに連動して動きます。

ユーザー数による定額区分は、中間では安く、端では崖になります。30ユーザーで月額249ドルのHelpjuiceは、4人のチームには高く、28人のチームには安いです。確認すべき数字は、今の人数ではなく、次の区分を超える人数です。

サイトごとは、読者と書き手を切り離します。公開するものなら、これがスケールするモデルです。GitBookの公開ページは閲覧数が無制限なので、トラフィックが増えても費用はかからず、執筆チームが増えると1人あたり12ドルかかります。

メンバーごと、Wiki中心は、ナレッジベースが製品ではなく、ワークスペースの1機能であるときに得られるものです。Notionのメンバーあたり10ドルは、社内ドキュメントには安く、顧客向けヘルプセンターには扱いにくいものです。何かを書くかどうかにかかわらず、会社全員が請求書に載るからです。

見積もりのみは、数字を聞く前から何かを教えてくれます。Document360は公開価格をやめて、構成に関する質問票に切り替えました。つまり価格は、売り手があなたについて知ったことで決まります。それ自体が悪いとは限りませんが、最初に聞く数字は出発点の提示であり、営業の電話の前に予算を立てることは不可能になります。

Zoho Deskは、地域によって価格が変わるため、この表からは少し外れます。無料プランは3エージェントまでで、ナレッジベースはStandardプラン以上に現れますが、表示される数字はページを開く場所によって変わります。IPアドレスで価格が変わる提供企業は、比較する前に書面の見積もりが必要です。

3つの規模での費用

4つの製品を、3つの形のチームで見積もりました。提供企業が用意している場合は年払いです。

	3人、公開ヘルプセンター	12人、ヘルプセンターと社内Wiki	40人、ドキュメントとサポート
Help Scout	無料プラン、$0	Standard、$300/月	Pro、$3,000/月
Zendesk Suite Team	$165/月	$660/月	$2,200/月
GitBook Premium	$65/月に編集者2人、$89	$65に編集者11人、$197	$65に編集者39人、$533
Notion Business	$60/月	$240/月	$800/月

この表が示すのは、機能比較では決して見えない2点です。読者側に面した席で課金される製品は、ドキュメントの量とは無関係の速さで高くなります。サイトごとに課金される製品は、会社が3倍になってもほとんど変わりません。

大事なのは、書き手と読み手がどこにいるかです。10人が読み、2人が書くなら、2人分を課金するモデルを買ってください。

実際に差がつく機能一覧

このカテゴリで宣伝されているものは、ほとんどどこにも備わっています。以下は短い一覧で、製品を本当に分ける機能と、それが通常どのプランの裏にあるかです。

機能	備えている製品	通常、制限されるプラン
公開ヘルプセンター	すべてのツール	なし
リッチテキストエディタ	すべてのツール	なし
記事の分析	すべてのツール	なし
独自ドメイン	大半のツール	最初の有料プラン
検索結果ゼロのレポートを含む検索分析	一部のツール	中位プラン
複数のサイトまたはブランド	一部のツール	中位プラン、またはサイト単位の課金
言語ごとのワークフローを持つ多言語対応	少数のツール	最上位プラン、または言語ごとの料金
記事のバージョン管理と定期レビュー	少数のツール	最上位プラン
管理者と編集者を超える細かな権限	少数のツール	最上位プラン
SSOと監査ログ	大半のツール	最上位プラン、またはエンタープライズ
自分で管理できるリダイレクト	少数のツール	まちまち、ないことが多い
オープンな形式でのセルフサービスのエクスポート	少数のツール	まちまち、ないことが多い

本当の差は下の3行にあり、どのデモでも触れられないものです。リダイレクトとエクスポートは、乗り換えにいくらかかるかを決めます。権限は、ツールが40人の会社の現実に耐えられるかを決めます。

多言語対応と、その費用

翻訳は、ナレッジベースの価格を倍にする最も確実な方法ですが、料金モデルがトップページでそう言うことはまずありません。ツール自体にワークフローがない場合は、専用の翻訳とローカライズツールがそれを担うことになります。

パターンは3つあります。言語ごとを別のサイトやワークスペースとして扱う提供企業があり、その場合はサイト単位の料金が言語数だけ倍になります。言語は含めておいて、翻訳をAI機能として、単語数やクレジット単位で課金する提供企業もあります。上位プランからしか言語に対応しない提供企業もあり、これは明細の1行ではなく、プランの跳ね上がりになります。

あとから複数言語にする可能性が少しでもあるなら、契約前に次の点を確かめてください。

言語は、請求書上で新しいサイトになるのか、1つの記事のバリエーションなのか
検索は1つの言語の中で機能するのか、ドイツ語で検索すると英語の記事が返るのか
翻訳した記事に、元の記事が変わったときに古いと印を付けられるか
URLの構造に言語が含まれるか、それはインデックスさせたい構造か

最後の点をあとから直すのは高くつきます。言語をパスではなくクエリ文字列に置くヘルプセンターは、すべての言語が検索でゼロから始まり、変更するには手持ちのすべての記事をリダイレクトしなければなりません。

権限と、非公開ナレッジベースが破綻する場所

公開ヘルプセンターの権限は1つだけで、公開か非公開かです。社内ナレッジベースには権限モデルがあり、Wikiツールが40人、50人の規模で静かに使えなくなるのはそこです。

ここでのアクセス制御は、弱すぎて失敗するのではありません。手作業が多すぎて失敗します。新しいページはどこかから権限を引き継ぎ、誰かが正当な理由で1度だけ上書きし、18か月後には、給与テーブルを誰が読めるのか誰にも言えなくなっています。

これに耐えられるツールとそうでないものを分ける問いは3つあります。

**権限は構造から継承されるか、それともページごとに設定するのか。**スペースやセクションからの継承なら維持できます。ページごとの権限は、誰も更新しないスプレッドシートです。

**誰が何を見られるかのレポートがあるか。**なければ、アクセス権の見直しは人がページを1つずつクリックして回る作業になり、つまり実施されません。

**誰かが辞めたらどうなるか。**無効化されたアカウントが所有するページは、孤児になったり、もっと悪いことに見えなくなったりしてはいけません。

コンプライアンス上の義務がある会社には、4つ目があります。誰がいつ何を読んだかを示す監査ログです。この機能はほぼどこでも最上位プランにあるので、監査人に聞かれてからではなく、製品を選ぶ前にそのプランの価格を確認してください。これを第一級の機能として扱うツールは、セキュリティのカテゴリにあります。

検索は製品そのものであり、誰もデモしない部分

提供企業のデモはエディタを見せます。そこは2週間しか使わない部分です。誰かがあなたの書いたものを読むかどうかを決めるのは、検索です。

機能する検索と、何も返さない検索を分けるものは3つあります。

**顧客の語彙に対応できること。こちらの語彙ではなく。**記事の題名が「アウトバウンドSMTPリレーの設定」で、人が「メールが送れない」と入力します。ツールが本文にある語としか照合しなければ、その検索は失敗し、チケットが開かれます。ギャップを埋めるのは、同義語リストと、近年増えている意味ベースの照合です。

**誤字や途中までの単語に耐えられること。**多くのサイト内検索は、1文字入れ替わっただけで結果がゼロになり、訪問者には「このヘルプセンターには何もない」と映ります。

**何が失敗したかを報告できること。**価値のあるレポートは、人気記事の一覧ではなく、何も返さなかった検索や、誰も結果をクリックしなかった検索の一覧です。この一覧が、答えを必要とした人たちが書いた、あなたのコンテンツのバックログになります。

3つとも、提供企業のサンプルではなく自社の言葉でトライアル中に試してください。実際の記事を20本取り込み、その製品に関わっていない人に、5つの答えを探してもらいます。

報告する価値のある4つの数字

ナレッジベースの分析画面の多くは、グラフを載せたページビューのカウンターです。実際に意味を持つ数字は4つで、そのうち3つはダッシュボードから読み取るのではなく、組み立てる必要があります。

**デフレクション率。**記事を読んでチケットを開かなかったセッションを、記事を読んだセッションで割ったものです。計算するツールもありますが、ほとんどはしません。ない場合の現実的な代用は、あるトピックについて、それを扱う記事の公開前と公開後のチケット件数です。

**検索結果ゼロ率。**何も返さなかった検索を、全検索で割ったものです。数パーセントを超えるなら、コンテンツの穴か語彙の穴で、どちらかは検索ログが教えてくれます。

**記事対チケット比。**あるトピックのチケット数を、同じトピックの記事閲覧数で割ったものです。ドキュメント化済みのトピックでこの比が高いなら、記事はあるのに、質問に答えていません。

**陳腐化率。**公開済みの記事のうち、12か月間編集もレビューもされていないものの割合です。投資全体が劣化するかを予測するのはこの数字ですが、デフォルトで表示するツールはほとんどありません。

この4つは最初の月に設定してください。これがないナレッジベースは、予算の時期に誰も擁護できない文書の山です。またアナリティクスツールもこれらを供給しません。これらの数字は、ヘルプセンター自身の検索ログとチケットログから得られるものです。

AI回答が変えたことと、変えなかったこと

このカテゴリのほぼすべてのツールが、今はAI層を宣伝しています。正確に言えば、あなたの記事を読み、1文で返す検索システムであり、公開していないことは何も知りません。

そこから導かれる帰結が1つあり、どの売り込みでも飛ばされます。**AIナレッジベースツールは、コンテンツが元々どうであったかを増幅します。**薄い記事は自信に満ちた薄い回答を生み、2つのページの矛盾は、どちらかを無作為に選ぶ回答を生みます。AI層が放置されたドキュメントを補ってくれると期待したチームは、逆の結果を得ます。放置が引用可能になるのです。

2つ目の帰結は課金です。セルフサービスを自動化するAIツールが基本料金に含まれることはほとんどありません。解決ごとの課金、クレジットパック、上位プランのいずれかで現れ、利用量を決めるのは自社ではなく顧客です。

ヘルプセンターの自動化をオンにする前に、次の4つの問いへの答えを書面で入手してください。

課金の対象となる出来事は何か。質問されたこと、回答したこと、それとも顧客が解決したと確認した会話か
クレジットが尽きたらどうなるか。強制停止か、超過料金か
月額の上限を設定できるか。上限に達したとき、人によるサポートに切り替わるのか、何もなくなるのか
回答は出典の記事を示すか。間違った回答を、修正できるページまでたどれるか

オンにする前に計算してください。1解決0.99ドルなら、月2,000件のデフレクションは1,980ドルで、上の表のサブスクリプションの多くより高くなります。それでも最も安い選択肢でありうるのは、同じ2,000件を人が対応すればはるかに高くつくからです。ただそれは、驚きではなく、判断であるべきです。

セルフサービスのAIツールは持つ価値があります。ただし2番目にです。最も多い20件のチケットを扱う20本の記事が存在し、正しい内容になってからです。

人にもAI回答にも使える記事の書き方

流し読みしやすい記事の構造は、検索システムが正しく引用しやすい構造でもあります。費用はかからず、効果は大きいです。

**最初の2文で答える。**解決方法を先頭に置き、背景を下に置きます。検索システムは質問に最も近い一節を取り、検索から来た読者は導入文を読みません。

**1つの記事に1つの質問。**4つのゆるく関連するテーマを扱う記事は、4つすべてで検索に引っかかり、どれにもうまく答えません。

バージョンと日付を書く。「2026年3月時点、プランXの場合」と書けば、読者もモデルも、その答えがまだ当てはまるかを判断できます。日付のない手順は、製品についての自信満々の誤ったAI回答の主な原因です。

**制限のあるものは表にする。**表の中の数字は抽出に耐えます。同じ数字を段落に書くと、崩れて出てきます。

**顧客の呼び方で名前を付ける。**顧客が「請求書」と呼び、画面が「課金ドキュメント」と表示するなら、記事には両方の語を1回ずつ、文を不自然にせずに入れる必要があります。

**1つの事実に正規のページを1つ。**同じ上限について異なる数字を載せた2つのページは、検索でもAI回答でも、コイン投げになります。

セルフホストとオープンソースの実際

ライセンス費用が無料のナレッジベースソフトウェアは存在し、実在するソフトウェアですが、費用は消えるのではなく移ります。

サブスクリプションは節約できます。代わりに、ホスティング、アップグレード、バックアップ、TLS証明書、検索インデックス、そのすべてを担当する人にお金を払います。小規模では、その人は夜に作業する創業者で、会社で最も高価なエンジニアリングの時間です。

開発者ツールのカテゴリにある製品は、これを過小評価しやすくします。セルフホストが妥当なのは、2つの条件のどちらかを満たすときです。他のサービスを運用するプラットフォームチームがすでにいる、またはデータ所在地の規則によって、ホスト型の製品が事実上使えない。

この2つ以外では、計算が有利になることはまずなく、失敗の形は具体的でよくあるものです。アップグレードが誰の仕事でもないために、ナレッジベースがパッチの当たっていない版のまま2年動き続けます。

移行の手順

ドキュメントソフトウェアは、カタログのほとんどのカテゴリより、静かに乗り換えコストを積み上げます。1年分の記事、画像、リダイレクト、社内リンクは、移すのが本当に難しいもので、提供企業もそれを知っています。

契約の前に、移行の最中ではなく、答えを得ておくべき問いが4つあります。

**どんな形式で出てくるか。**Markdownか、提供企業のソフトウェアなしで読めるHTMLのファイルが望ましい答えです。内部IDに紐付いたJSONの塊は、技術的にはエクスポートでも、実質的には人質です。

**画像も付いてくるか。**添付ファイルはしばしばエクスポートから除外され、提供企業のドメインにホストされています。乗り換えると、すべての記事のすべての画像が壊れます。

**URLは生き残るか。**ヘルプセンターが自社のサブドメインにあれば、リダイレクトは自分で管理できます。提供企業側のドメインにあるなら、これまで誰かが共有したすべてのリンクが、解約の日に死にます。

**エクスポートはセルフサービスか。**サポートチケットが必要なエクスポートは、速く欲しいまさにそのときに、提供企業が遅らせられるエクスポートです。

実際に移行するときに、空白の1か月を避けられる順番は次のとおりです。

新しいツールに触れる前に、すべてをエクスポートしてバージョン管理に入れる。自分のものと言えるコピーを持つため
旧ツールを公開のまま稼働させた状態で、新しいツールに取り込む
URL対応表を、誰もリンクしていないものも含め、記事ごとに作り直す
リダイレクトを設定し、うち20件を手作業でテストする
ドメインを切り替え、旧サブスクリプションは1請求サイクル分維持する
2週間、検索結果ゼロ率を見守る。取り込みの不具合はそこに最初に現れる

1番目を飛ばすのが、移行を書き直しに変えてしまう失敗です。GoogleのURL変更を伴うサイト移転に関するガイダンスは、Webサイトと同じようにヘルプセンターにも当てはまり、検索流入が生き残るかを決めるのはリダイレクト表です。

最も高くつく7つの失敗

**読者ではなく形を買う。**顧客向けにWikiを買う、またはエンジニアリングのドキュメント用にヘルプセンターを買う
**今日の席数で数える。**上の表のどのモデルにも境界があります。問いは、18か月後にどこにいるかです
**コンテンツができる前にAIをオンにする。**穴を埋めるのではなく、穴を引用可能にします
**提供企業のドメインで公開する。**登録時は安く、その後のあらゆる場面で高くつきます
**編集責任者がいない。**ナレッジベースは、誰かの悪い判断ではなく、誰の判断もないことで劣化します
**誰も求めていない記事を40本書く。**サポートログがバックログです。それ以外は推測です
**エクスポートを一度も実行しない。**初めて試すのが、乗り換える週であってはいけません

意味のあるトライアルのやり方

適切なことに時間を使えば、ナレッジベースソフトウェアの判断には2週間で足ります。ほとんどのトライアルは、エディタに見とれて終わります。

実際の記事を20本取り込む。最も長い2本と、スクリーンショットが最も多い1本を含める
チーム外の人に、自分の言葉で5つの答えを検索してもらい、入力した内容を記録する
検索をわざと壊す。誤字、複数形、競合が使う自社機能の呼び名
記事を1本公開し、編集して、公開版が更新されるまでの時間を確かめる
エクスポートは13日目ではなく2日目に実行し、出てきたものを開く
2人目の書き手を追加し、請求書がどうなったかを確認する
AI層をオンにして、ドキュメントが答えていない質問を3つ尋ね、返答を読む
1ページに権限を設定し、見られないはずのアカウントから読もうとしてみる
ヘルプセンターがスマートフォンでどう見えるかを確認する。読む人の多くは手に持っている
公開した記事のページの重さを測る。モバイル回線で遅いヘルプセンターは、検索の途中で見限られる

合格の基準は「気に入った」ではありません。4か月目に初めて気づいたであろう驚きが、このリストのどこからも出なかったことです。

ナレッジベースソフトウェアと他のものとの関係

ナレッジベースはサポートチャネルではありません。チャネルが一杯にならないようにするものです。すでに答えているチケットから材料を得て、検索で辿り着いた人に読まれたときに機能します。

そこから順番はかなりはっきりします。プラットフォームを選ぶ前に、最も件数の多い20の答えを書いてください。コンテンツが、どの形が必要かを決めるからです。

会話を扱うものとつなげてください。記事を表示できないライブチャットツールは、同じ質問を毎回人に送ってしまいます。

スイート型の選択肢はカスタマーサポートのカテゴリに、サイト単位で課金されるものはドキュメントとナレッジベースのカテゴリにあります。AI層は、元になる資料が引用に値するようになってから加えてください。

そして、料金ページは契約書を読むように読んでください。実際に契約書だからです。同じSaaSの料金ページが隠している5つのことはここにも全面的に当てはまり、特に最低席数は、ウェブサイトを買っているつもりだったチームを直撃します。

当サイトのカタログにあるナレッジベースツールはすべて、同じ条件で掲載されています。リンクは nofollow で、有料掲載はなく、並び順について言えるのはそれだけです。カタログを見る際は、当サイトの数字を含め、どの数字も信じる前に提供企業自身の料金ページを確認してください。

よくある質問

10人のチームでは、ナレッジベースにいくらかかるべきですか？

同じ仕事でも、2026年9月5日時点で無料からおよそ月額800ドルまでと幅があり、完全にモデル次第です。Zendesk Suite Teamで10人のサポートエージェントなら月額550ドルで、その大半はナレッジベースではなくヘルプデスクの分です。

GitBook Premiumで編集者10人なら、サイト分の65ドルに追加の席が108ドルです。Help Scoutは5ユーザーまで無料で、10ユーザーなら月額250ドルです。2つの数字を比べる前に、自分がどの単位を買っているのかを確かめてください。

Wikiツールは、顧客向けヘルプセンターとして十分ですか？

たいていは足りません。理由は機能とは関係なく、2つあります。Wikiツールはデフォルトで認証を求め、検索は社内の語彙をすでに知っている人向けに作られています。どちらも従業員には正しく、顧客には間違っています。予算の都合でそうするなら、最低限、ログインなしでページを公開でき、検索エンジンにインデックスさせられるかを確認してください。

社内用と社外用のドキュメントに、別々のツールが必要ですか？

20人を超えたチームの多くは2つになりますが、失敗ではありません。読者によって必要な権限、検索の挙動、編集基準が違うからです。1つのツールで両方をまかなうと、たいてい社内コンテンツが整いすぎて更新が続かないか、社外コンテンツが粗すぎて出せないかのどちらかです。

AIナレッジベースツールは、実際に何を加えますか？

公開済みの記事を読み、リンクの一覧ではなく1文で答えます。ドキュメントがすでに答えている質問には本当に役立ち、答えていない質問には役に立ちません。

コンテンツの上にかぶせる表示層として扱い、書くことの代わりにはしないでください。課金はほぼ必ず基本プランとは別で、1解決あたり0.75ドルから0.99ドルです。

ヘルプセンターは、公開前に何本の記事が必要ですか？

実際に届く質問をカバーできるだけの数で、若い製品なら通常15本から30本です。数よりもカバー範囲が重要です。直近のサポート会話を200件取り出してグループ分けし、上位20件を書いてください。誰も聞いていない質問に答える記事を40本公開するのは、四半期をむだにするよくある方法です。

ヘルプセンターは自社ドメインに置くべきですか？

ツールが許すなら、自分で管理できるサブドメインに置いてください。検索の価値が自社側に残り、提供企業を乗り換えても共有リンクが生き続け、リダイレクトを自分で書けるからです。自社ドメインでしか公開できないツールが安いのには、理由があります。

社内でナレッジベースを所有すべきなのは誰ですか？

チケットに答えている人が、共有の責任ではなく、名前のある編集責任者として担います。ナレッジベースは、誰の判断もないことで劣化します。続くメンテナンスの形は小さく地味です。記事は、次にチケットの中で誰かがリンクしたときに見直され、リンクした本人がそこで直します。

無料のツールで始めて、あとで移ることはできますか？

できます。ドキュメントツールの無料プランは、最初の20本の記事を書くには妥当な場所です。Help Scoutは5ユーザーと完全なDocsサイトを無料で提供しています。ただし記事が100本になる前にエクスポートを実行して、移行に何が必要かを、調べるのがまだ安いうちに知っておいてください。

ナレッジベースが古くなるのを防ぐには？

見直しをカレンダーではなく、きっかけに結び付けてください。実用的なルールは、サポートの返信でリンクされた記事を、リンクした人が読み、間違っていればその場で直す、というものです。四半期ごとの総点検は、予定され、動かされ、中止されます。すでに行われている仕事に付いたルールは生き残ります。

公開ヘルプセンターは検索順位に役立ちますか？

役立つことがあり、限られた検索クエリについては、唯一の手段です。ヘルプセンターの記事は、マーケティングサイトでは不自然になってしまう、問題の形をした検索で上位に入り、その検索をするのは、すでに製品を持っている人たちです。サブドメインに置き、クロールさせ、1つの記事に答える質問を1つ与えてください。

元が取れたかをどう測りますか？

チケット数ではなく、顧客1人あたりのチケット数を比べてください。成長している会社でチケット数が横ばいなら、実数が変わらなくてもデフレクションが成功しています。そのうえで、差をサポートの1時間あたりの費用で換算し、サブスクリプション料金の隣に並べます。

多言語対応は、どんなときに価値がありますか？

ある言語がサポート件数の中で十分な割合を占め、翻訳してそれを維持する手間に見合うときです。維持の部分は忘れられがちです。元の記事に追従しなくなった翻訳記事は、自信を持って間違った答えを返すので、ないほうがましです。

追加する言語は1つ、トラフィックの多い20本の記事から始め、2つ目はその最初の言語が最新に保たれるようになってから加えてください。

AIエージェントとヘルプセンターで、1つのナレッジベースを使えますか？

使えますし、そうすべきです。どちらも同じ記事を読み、2つの情報源を維持すれば、2つは食い違い始めます。違いが出るのは書き方です。最初の2文で答える記事は、検索システムにうまく使われ、人にとっても読みやすくなります。

ナレッジベースソフトウェアの選び方