Freshdeskナレッジベースの実例10選:実際のヘルプセンターを検証

Freshdeskナレッジベースの実際の姿

エージェント画面の中ではSolutionsタブの下に置かれており、Freshdesk自身のドキュメントでも「Solutions」と「Knowledge Base」は同じ意味で使われている。構造は名前の付いた3つのブロックだけで成り立っている。

• カテゴリ:Freshdeskは「より広い分類、またはトップレベルの階層」と定義している。ecommerceストアの実例として挙げているのはOrders、Refunds & Returns、Pricing。
• フォルダ:「カテゴリ内のサブカテゴリ、または二次的な階層」。Ordersの中にはOrder Creation、Order Managementが入る。
• 記事:顧客が実際に読むもの。

意外な挙動が2つある。カテゴリやフォルダは、その中に少なくとも1件記事を公開するまでカスタマーポータル上で表示されないままなので、作りかけのタクソノミーはそもそも表示されない。そして記事を別のカテゴリに移動させるには、移動先のカテゴリに既にフォルダが存在していなければならず、単純な並べ替えのはずが2段階の作業になってしまう。

公開範囲はフォルダ単位で設定し、Freshdeskは全ユーザー、全エージェント、ログイン済みユーザー、Freshchatボット、指定企業、コンタクトセグメント、企業セグメントという7つの選択肢を用意している。記事の公開範囲を一括変更することもできるが、その判断は通常フォルダ側で行われる。公開向けの層と並行してエージェント限定の非公開層を構築するなら、それはむしろ社内向けナレッジベースの課題に近く、別途計画する価値がある。

3階層というのがFree、Growth、Proでの上限だ。Freshdesk自身のCreate and Organizeドキュメントのコールアウトにこうある。「Multi-level or flexible hierarchies is available only on the Enterprise plan. If you are on other plans, you can organize your knowledge base up to 3 levels.」Enterpriseでは6階層が解放され、1つのカテゴリに加えてフォルダとサブフォルダが最大5段まで深くなる。

この制限は見た目以上に重要だ。なぜなら、手本として持ち上げられているエンタープライズ級のヘルプセンターの多くは、大半の読者が実際には購入できない階層構造をしているからだ。

自分のプランで実際に作れるもの

実例に入る前に、自分のプランでコピーできる範囲について率直に述べておく価値がある。Freshdeskはナレッジベースについてプラン別機能一覧表を公開しており、すべてのプランでチェックが入っている項目は1つだけだ。プラン階層の詳細はFreshdesk Proプランの料金の記事で完全に解説している。

すべてのプランでチェックが入っている唯一の項目がナレッジベースへのメール送信だ。それ以外の、ナレッジベースを単に存在させるだけでなく運用可能にするものは、すべてPro以上にある。この制限がここに辿り着いた理由なら、FreshdeskのAI代替ツールの記事で逃げ道を、ヘルプデスク向けナレッジベースソフトウェアの記事でベンダー間の制限比較をそれぞれ扱っている。

Freshdeskナレッジベースの実例10選

以下のポータルはすべて2026年7月31日時点でアクセスし、実際のカテゴリと記事コンテンツが返ってくることを確認した。それぞれがFreshdeskでホストされていることは、固定ルート/support/solutionsか、Freshdeskのロードバランサーを指すDNSレコードのどちらかで確認した。例えばsupport.hover.comはefc245f4d8c525a4a0e9c5df527a4f59.freshdesk.comに解決される。

はっきり言っておく価値がある。テストした候補の約40%は死んでいたか、ログインでブロックされていたか、単に何も指していなかった。Freshdeskのポータルは静かに朽ちていくので、リストで見つけた実例は何かを計画する前に必ず確認してほしい。

1. Freshworks、リファレンス実装

最適な相手: 自社製品がどう使われるべきかについて、ベンダー自身の意見を知りたい人。

Freshdeskは自社のヘルプセンターをFreshdesk上で運用しており、その結果support.freshdesk.comは事実上の公式リファレンスに最も近い存在になっている。14個のフラットなカテゴリ:Onboarding and Setup、Ticket Management、Freddy AI for Ticketing、Workflows and Automations、Ticketing Channels、Knowledge Base Management、Portal Setup and Customization、Reporting and Analytics、Freshdesk Integrations、The Freshdesk Mobile App、Policies and Data Protection、Freddy AI and Chatbots (Legacy)、Field Service Management、Freshdesk FAQ。

コピーすべき点: すべてのカテゴリに1行の説明が付いており、その説明はそこに何が含まれているかではなく、そこで何をするかを語っている。「Set up your Freshdesk account, configure support channels, customize your portal to reflect your brand」は「Setup articles」に常に勝る。ホームページは14個のうち6個だけを表示し、その下にView all categoriesリンクを置くことで、ランディングページを一目で把握できる状態に保ちつつ、完全な一覧はワンクリックの距離に置いている。

注意点: Freddy AI and Chatbots (Legacy)が、アクティブなFreddy AI for Ticketingカテゴリと同じ視覚的な重みで並んでいる。AIの設定を探している読者は、最新のドキュメントと廃止済みのドキュメントのどちらかにコイントスで振り分けられてしまう。廃止済みのコンテンツは、トップレベルの同格ではなく、アクティブなカテゴリ内のフォルダに置かれるべきだ。

2. Hover、ここで最も完成度の高いカスタムテーマ

最適な相手: 製品範囲が小さく、タクソノミーをファーストビューに収めたいチーム。

Tucows傘下のドメインレジストラHoverは4つのカテゴリを運用しており、それがタクソノミーのすべてだ。

コピーすべき点: カテゴリは顧客が今立っている製品領域の名前で名付けられており、Getting Startedが最初に固定されている。だがこの記事全体で最もコピーする価値があるのは、Hoverの記事の書き出し方だ。Vistaprint移行に関する記事は何が変わったかを平易な言葉でまとめた要約から始まり、その後、読者が手元に用意すべきものを正確にリストした太字のBefore you beginブロックが続く:Hoverのウェルカムメール、元のアカウントメールの受信箱へのアクセス。これはヘルプセンターの最も一般的な失敗、つまり読者が4ステップ進んでから資格情報が足りないと気づく事態を根絶している。

Hoverはまた、放置すればチケットになる境界事例に向けてNote:という注釈を書いている。例えばドメインがHoverではなくExact Hostingに移った場合などだ。それぞれの注釈が、誰も申請しないチケット1件分に相当する。

注意点: 4つのカテゴリのうち説明文があるのは1つだけだ。Freshdeskはすべてのカテゴリにこのフィールドを提供しているが、Hoverは4つ中1つしか埋めていない。

3. TeamViewer、ルーターとしてのポータル

最適な相手: 記事がマーケティングサイト側にあり、Freshdeskを純粋にナビゲーションとチケット処理のためだけに使いたい企業。

TeamViewerはナレッジベースにFreshdeskのカテゴリをまったく使っていない。/support/homeは、まず製品ライン、次にタスクで整理されたルーティングハブだ。TeamViewer Remoteの下にはDownload and installation、Remote session、Device managementがある。すべてのリンクはFreshdeskの記事ではなくteamviewer.com/global/support/knowledge-base/に出ていく。

コピーすべき点: 3つのリンクの後に「See more」が続く、繰り返されるブロック。これはフォルダの一覧を丸ごと出すのではなく、タスク領域ごとに最も要望の多い記事3件を表示することにコミットしており、すべての製品ラインで同一に繰り返されるため、そのパターンを一度学んだ読者は15秒で5製品を見渡せる。ステータスページに接続された予定メンテナンスのバナーもう一つの良い工夫で、「自分の側の問題なのか、それとも向こう側の問題なのか」という疑問に、誰かが検索するより前に答えてくれる。

注意点: そしてこれは実際に起きていることだ。support.teamviewer.com/support/solutionsは「You must be logged in to access this page.」を返す。Googleの検索結果から読者が着地するまさにその場所であるカテゴリ一覧がログイン制限されている一方で、ホームページは公開されている。ナレッジベースを2つのシステムに分割していることは、ポータルの検索が何かをする前に「Where would you like to search?」と尋ねる必要があることも意味する。読者にどの検索インデックスを使うか選ばせることは、すべてのクエリに課される税金であり、顧客サポートポータルがトラフィックを失う静かな方法の一つだ。

4. Chargebee、規模を持った質問形式のタイトル

最適な相手: 顧客が具体的で言語化可能な質問を持って訪れる技術系プロダクト。

Chargebeeは標準のFreshdeskテーマと24個のフラットなカテゴリを使っており、これは多すぎる。だがここでは誰よりも上手くやっていることが一つある。

コピーすべき点: Chargebeeはほぼすべての記事に、顧客が実際に入力するであろう文字通りの質問をタイトルとして付けている。疑問符も含めてだ。「What is an SPF Record and how do I add it?」「How can I change my Chargebee account password?」「Does Chargebee support recurring billing?」これは検索において利用可能な中で最もレバレッジの効く一手だ。Freshdesk自身の検索ボックスでもGoogleでも、タイトル自体がすでにクエリと完全一致するからだ。これは移行ドキュメントの問題も解決する。「PC 1.0 to PC 2.0」という質問だけを集めたフォルダ丸ごとが、仕様書ではなくFAQのように読める。

Chargebeeはインテグレーションも、200記事の1つの箱ではなく、General、E-Commerce、Accounting、CRMという4つの別々のカテゴリに分けている。インテグレーションのカタログが大きいなら、顧客がすでに使っているシステムの種類で分割すべきだ。同じ発想は良いecommerceのFAQ実例にも見られ、そこでは分割が社内組織ではなく顧客のコンテキストに従っている。

注意点: 問題は2つあり、2つ目のほうが深刻だ。グループ化のない24個のフラットなカテゴリは一覧を壁にしてしまう。FrameworkとTransfer Configurationのどちらが自分向けなのか、何も教えてくれない。そして顧客向けの一覧に堂々と**Internal Repo**という名前のカテゴリが公開されている。中身が何であれ、その存在は社内向けと顧客向けのコンテンツが同じツリーを共有していることを読者全員に伝えてしまい、自分のフォルダ公開設定を監査しに行くべきだというワンクリックの警告になっている。

5. Exotel、名詞ではなく指示

最適な相手: 購入者がまだ習得していない語彙を使う技術系プロダクト。

Exotelは標準テーマで14個のカテゴリを運用するクラウド電話プラットフォームだ。

コピーすべき点: 最初のカテゴリは**Start here**という名前だ。たった2語だが名詞ではなく指示であり、新規ユーザーがどこから始めればいいかという曖昧さを完全に取り除いている。アルファベット順リストの4番目に置かれたGetting Startedが決して達成できないやり方だ。中にはGetting Started(39記事)、Cloud telephony(6)、Trial account(17)、Dashboard(6)がある。注目すべきは、このオンボーディングが仕組みだけでなく概念もカバーしていることで、「How is cloud telephony different from internet telephony, VOIP, and services like Skype?」のような記事がある。購入者がそのカテゴリの存在すら知らないかもしれない技術系プロダクトにとって、この概念フォルダこそが、営業チームが同じ質問に50回答え続けるのを防ぐものだ。

Data Securityをそれ自身のトップレベルカテゴリとして持つことは、あらゆるB2Bツールが真似すべきもう一つの妙手だ。調達担当者やセキュリティレビュアーは固定されたリストの質問を携えて訪れるが、カテゴリが一つあれば、彼らがチケットを開くことは決してない。それはチケットの偏向を情報アーキテクチャだけで実現した例だ。

注意点: Other Frequently Asked Questionsは雑多な引き出しになっており、それがStart hereフォルダとも共存しているせいで、同じ質問がもっともらしくどちらにも存在しうる状態になっている。後半の複数のカテゴリ、AgentStream、vSIP、Legs Platformは、顧客には認識できない社内コードネームで名付けられている。

6. cult.fit、時間の瞬間としてのフォルダ

最適な相手: 顧客の質問がジャーニーのどの地点にいるかに左右される消費者向けサービス。

cult.fitは製品ラインごとに1つ、合計12個のカテゴリを運用しており、それぞれに手描きのアイコンが付き、一覧の見出しもFreshdeskのデフォルトであるKnowledge baseではなくFrequently asked questionsにしている。

コピーすべき点: cultカテゴリだけで17個のフォルダがあり、その分割は顧客ジャーニーの瞬間に沿っている。順にBooking cult classes、次にAttending cult classes、次にClass cancellation or Dropout feature、次にNo Show policy。40記事入りの単一のClassesフォルダではなく、3つの別々の時点に対応する3つの別々のフォルダだ。朝6時にジムの外で予約トラブルに直面している人は、参加関連の記事にたどり着くために予約関連の記事を読み飛ばす必要がない。各フォルダにはリアルタイムの記事数も表示されるので、読者はどこが深いかを見て取れる。

注意点: COVID-19 Precautionsは2026年になっても9記事を抱えるアクティブなフォルダのままで、スマートウォッチ関連のカテゴリもcult.sport smartwatchとCult Smartwatchの2つある。カテゴリ名の大文字小文字の使い方も一貫していない。

7. Noise、SKUで整理されたナレッジベース

最適な相手: 顧客が型番は知っていてもそれ以上はあまり知らないハードウェアブランド。

ウェアラブルとオーディオを販売するNoiseは、Shopifyの店頭に合わせてポータルを完全に再スキンしている。製品の形状別に分けられた8個のカテゴリがあり、Smart Wearablesの中のフォルダは個々のモデル名で分けられている:NoiseFit Endure(25記事)、ColorFit Pro 2(29)、Noise Colorfit NAV(29)、他多数。

コピーすべき点: 2つの工夫がある。/support/homeページは記事とはまったく関係のない5つのアクションアイコンの列から始まる。Track Your Order、Raise Your Complaint、Track Your Complaint、Service Center、Warranty Registrationだ。これらはハードウェアの顧客が実際に来訪する目的そのものであり、これをナレッジベースより上に置くことで、記事が取引的なニーズと競合するのを防いでいる。

2つ目は、モデルフォルダ内の記事タイトルがモデル名を添えた症状として書かれていることだ。「Frequent disconnection / audio cutting / short range - ALT Buds S」「Only one earbud working (TWS pairing) - ALT Buds S」。顧客が説明するのは症状であって原因ではないので、彼ら自身の言葉がタイトルと一致する。Noiseはまた、101記事のUser Manualフォルダと、日本市場向けのInternational User Manualフォルダを維持しており、これはナレッジベース全体を翻訳せずに第二の市場に対応する安上がりな方法だ。これがここで重要なのは、Freshdeskがどの価格帯でもソリューション記事の機械翻訳を一切行わないからで、この隙間をZendeskの多言語ヘルプセンターは異なる方法で埋めており、これについては後で改めて触れる。

注意点: SKUごとのタクソノミーは終わりなく成長し、廃番製品のアーカイブ経路がない。そしてGeneralとGeneric FAQsという2つの別々のトップレベルカテゴリは、どの顧客も決して理解できない区別だ。

8. Portronics、標準テーマ上での症状優先

最適な相手: コンテンツがテーマ設定に勝ることを証明したい人。

Portronicsはまったく手を加えていない標準のFreshdeskテーマを使っているが、それでもこのリストに載っている複数のカスタムテーマのポータルより内容がよく整理されている。カテゴリはデバイスクラスごとのトラブルシューティングガイドとして名付けられており、例えばTroubleshooting Guide - Audio Devicesは製品タイプ別のフォルダに分かれていく。

コピーすべき点: 記事タイトルは顧客の声そのままの、純粋な症状の記述だ。「Speaker is not turning on.」「Speaker gets warm during use or charging.」機能名もなく、専門用語もなく、「Troubleshooting power issues in the XYZ series」のような表現もない。プロダクトが繰り返し発生するクレームのリストを生み出すなら、タイトルがそのクレームそのものになる。これは利用できる中で最も安い検索面の勝ちパターンで、実装コストはゼロだ。カテゴリをAudio DevicesではなくTroubleshooting Guide - Audio Devicesと名付けることも期待値を設定する。ここは何かが壊れたときに来る場所であって、機能を学ぶ場所ではない、と。

注意点: ブランディングが皆無なので、ヘルプセンターは顧客をそこに送り込んだ店とまったく似ていない。ホームページはFreshdeskのデフォルトの2タイルレイアウトで、注目記事も人気記事もない。

9. Shiprocket、教訓的な事例

最適な相手: クリーンアップ作業なしで再構築が公開されるとどうなるかを研究したい人。

Shiprocketには本物の強みがある。最初のカテゴリはHome、最初のフォルダはGetting Startedで、最初の2記事は「How do I sign up for a Shiprocket account?」と「What is Shiprocket and how does it work?」だ。語彙のハードルが高いプロダクトにとって、これは知識ゼロから始められる本物のオンボーディングだ。それ以降のカテゴリ名は製品内の画面に対応しており、Orders、Shipments、Billing、Settings、Mobile Appと続くため、行き詰まったユーザーはアプリで使っているのと同じメンタルマップでヘルプセンターをナビゲートできる。「Important Terms All Shiprocket Users Should Know」という記事さえあり、これは独自の専門用語を持つあらゆるプロダクトにとって正しい答えだ。

注意点: さて、カテゴリ一覧を見てみよう。Billingと末尾にピリオドの付いたBilling.。SettingsとSetting。Mobile App、Shiprocket Mobile App、そしてmyShiprocket Mobile App。Shiprocket FulfillmentとShiprocket Fulfilmentという2つの綴り。記事IDがそれを裏付けている。152000000xxxのブロックが新しいタクソノミーで、43000xxxのブロックが古いもの、そして両方が同じ一覧上でアクティブになっている。27個のトップレベルカテゴリのうち複数が重複だ。

これは、削除とリダイレクトのパスなしで再構築が公開されたときのFreshdeskナレッジベースの姿であり、重複カテゴリはずさんに見える以上の実害をもたらす。同じ答えの2つのコピーの間で検索の関連性が分散するため、どちらもうまくランクせず、あなたのコンテンツを読むAI層は同じ質問に対して競合する2つのソースを抱えることになる。この曖昧さはヘルプセンターでAIを学習させる際に既知の失敗モードだ。検索・取得のステップは、どちらの重複が最新なのかを判断できない。

10. Unacademy、「これは誰のためのものか」という失敗

最適な相手: 「とりあえずヘルプセンターを立ち上げて、後から埋めよう」と誰かが言ったときに必要な反論材料。

Unacademyは数百万人の学習者を抱える消費者向けedtechプラットフォームだ。その公開ヘルプセンターにはちょうど1つのカテゴリ、Educator Support、2つのフォルダ、合計7記事しかない。

コピーすべき点: うまくやっている小さな点は誠実な範囲設定だ。実際にある記事は教育者側で最も頻発する失敗であり、実際のルールを公表するポリシーフォルダもある。「Penalty rules for Unacademy Educators」と「Raising penalty waiver request」を、サポートの奥に隠すのではなく公開している。双方向のマーケットプレイスを運用しているなら、ペナルティと免除のルールを堂々と公開することはコピーする価値がある。

注意点: 数百万人の学習者を抱えるプラットフォームが、教育者にしか対応しないヘルプセンターを運用している。検索から辿り着いた学習者は7記事を見つけるが、どれも自分に関係するものではない。7記事という数はまた、ナレッジベースが何らかの役割を果たすための閾値を下回っている。Freshdeskの検索、カテゴリ一覧、そしてどんなAIによる偏向層も、機能するためのコンテンツを必要とする。コンテンツの薄さは、セルフサービスプロジェクトが停滞する最も一般的な理由だ。

良いものと壁を分けるパターン

13件すべてを通しで読んで、5つのことが繰り返し現れた。

カテゴリ数が品質を予測する。 Hoverの4、cult.fitの12、Exotelとfreshworksの14はすべてナビゲート可能だ。Chargebeeの24とShiprocketの27は壁だ。Unacademy、Mamaearth、greytHRの1は、そもそもタクソノミーですらない。4〜14の範囲から外れているなら、それが最初に直すべきことであり、真のナレッジベース管理の実践の核心だ。

タイトルがクエリだ。 強い実例はすべて、顧客自身の言葉での質問や症状としてタイトルを書いている。弱い実例はすべて、社内的なトピックラベルを書いている。これはAIの有無にかかわらず、AIによるナレッジベース記事の執筆に持ち込むべき唯一のルールだ。

カテゴリの説明文は、最も見過ごされがちな無料の勝ち筋だ。 Freshdeskはすべてのカテゴリに1行の説明文を用意している。Freshworksは14個すべてを埋めている。Hoverは4つ中1つを埋めている。それ以外の大半はゼロだ。

重複と旧式のカテゴリは、目に見える劣化の最たるものだ。 Shiprocketの4組の重複ペア、cult.fitの2つのスマートウォッチカテゴリ、Freshworksがトップレベルに残したままのLegacy AIカテゴリ。再構築するなら、同じ一手の中で削除とリダイレクトを行うこと。

取引系のショートカットはナレッジベースより上にあるべきだ。 Noiseの Track Order の列とHoverのSubmit a Ticketの列は、どちらも記事を提示する前に「あなたは実際何をしに来たのか」に答えている。

そして、どんな構造でも直せない失敗もある。

私はしばらく前から、実際のサポートキューにAIエージェントを投入する仕事をしてきたが、ヘルプセンターが期待どおりの成果を出せていないときに最もよく見つかることは、タクソノミーとは何の関係もない。ある通話で、月200〜250件のチケットを処理している交通位置追跡サービスの会社のサポートマネージャーが、その全体が管理者向けに書かれたナレッジベースを案内してくれたことがある。すべてのチケットは乗客からのものだった。記事は正確で、よく整理されていたが、誰も尋ねていない質問に答えていた。カテゴリの再構築をいくら重ねても、これは直らない。チケットを提出した本人のために書き直す必要がある。

これの最も痛烈なバージョンは、たった一文で表される。あるB2Bの車両テレマティクスチームは、自社のボットが「はい、そのお車のモデルには対応しています」と自信満々に、実際にはデータベースにないブランドの顧客に対しても答えていることを発見した。ナレッジベースのある記事が「すべてのモデルに対応しています」と書いていたからだ。AIがヘルプセンターを読むようになると、すべての記事の文言は、人間だけが読んでいたときには決してなかったほどの重みを帯びるようになる。それがサポートにおけるAIの幻覚の大半の背後にあるメカニズムであり、モデルの問題というよりコンテンツの問題だ。

Freshdesk自身のヘルプセンターからコピーできる5つの記事の型

Freshdeskは自社のHow-to、User guide、FAQテンプレートの中身を公開していない。だが自社のポータルをこの製品上で運用しているので、型はページから直接読み取れる。私は実際に公開されている4つの記事を分解してみた。

すべての記事は同じ外枠をまとっている。パンくずリスト、次にH1タイトル、次に目に見えるModified on:のスタンプとプラン別の利用可否マトリックス、次に本文、ファイルサイズ付きの添付ファイルカード、「Did you find it helpful?」ウィジェット、そして最後に閲覧トラッキングピクセル。日付のスタンプは度を越して正直だ。バージョン管理に関する記事は今でもModified on: Fri, 6 Mar, 2020のままだ。

How-toの型。 1行の範囲を示す文、次に「see also」のポインター、次にUser Requirements:の行、次にページ内アンカーリンクをまとめたThis article contains:ブロック。各トップレベルセクションの前に水平線。番号付きの手順は1つずつ1アクション、UIラベルをそのまま太字にし、スクリーンショットは最後にまとめるのではなくほとんどの個別ステップの後に配置される。グレーのNote:とTip:のコールアウト。締めくくりには関連記事2〜3件の「Learn more」リスト。

FAQの型。 これはほとんど攻撃的なまでにミニマルだ。タイトルは顧客の質問そのまま、疑問符も含む。目次なし、見出しなし、スクリーンショットなし。本文は2文だけ:何が起きるか、次にそれに対して何をすべきか、正確なボタン名を太字にして。それが記事の全部だ。

トラブルシューティングの型。 「Why...」で始まるタイトル、コンテキストの段落1つ、チェックリストへの橋渡しの一文、箇条書きで名前を挙げた考えられる原因、それぞれ「Check if」で始まる番号付きのチェックリスト。エスカレーションの明示的なステップで締めくくられ、添付すべき正確な成果物を名指ししている。エラーのスクリーンショット、メールヘッダー、そしてサポート宛先だ。この最後の部分こそ、大半のトラブルシューティング記事が省略しているものであり、だからこそ、まさにその同じ3つを求めるフォローアップチケットを生み出してしまう。

リリースノートの型。 FreshdeskはProduct Announcementsフォルダを維持しており、その今後の変更に関する記事は盗む価値のある型だ。「Why are we making these changes?」というセクション、太字のDate and timeline:とIntended audience:の行を含むRollout plan、そして変更ごとに1セクション。各変更セクションには**What's available today? | What's new?**という見出しの2列表があり、その後にメリットのリストとビフォーアフターのスクリーンショットのペアが続く。この2列表は、このポータル全体で最もコピーする価値のある成果物だ。

ホームページの型。 検索のヒーローセクション、それぞれ「中に何があるか」の1行説明が付いた6枚のカテゴリカード、View all categoriesリンク、コミュニティとシステムステータスを指すクイックリンクの列、そしてCTAバンド。

これらのいずれかを徹底させたいなら、Freshdeskには単なるガイドラインではなく、本物のテンプレートオブジェクトがある。テンプレートはSolutionsの下、Quick viewsメニューの下、Article templatesにある。1つをdefaultとしてマークすれば、新規記事すべてに自動的に読み込まれるようにでき、これが12人のエージェントが12通りの型を発明するのを防ぐ方法だ。知っておくべき2つの制限がある。1アカウントあたり厳格に30テンプレートまでという上限、そしてテンプレートはPro以上限定だということだ。型を自動的に適用させたいチームは、たいてい手作業で監視するのではなくAIによるナレッジベース記事ライターと組み合わせている。

エディタ自体はリッチテキストとHTMLビューの組み合わせで、markdownはない。対応するのはH1からH4までのみで、<script>、<style>、<form>、<input>、<select>、そしてonclickのようなイベント属性は取り除かれる。つまり、どんな価格帯であっても、Freshdeskの記事内でインタラクティブなウィジェットを使うことはできない。インライン画像は5.2 MB、添付ファイルは1件あたり25 MB、累計100 MBが上限だ。

チケットを記事に変える

私が実際にうまく機能しているのを見てきたナレッジベースはすべて、ドキュメント作成のスプリントではなく、チケットキューによって育てられていた。Freshdeskがこれに用意している経路はEmail-to-KBaseと呼ばれ、Growthを含むすべてのプランでチェックが入っている唯一のナレッジベース機能だ。また、同じステップにおいてZoho DeskのZiaやZendesk Guideが行っていることに最も近いネイティブな相当機能でもある。

チケットへの返信を作成し、BCCフィールドにkbase@yourcompany.freshdesk.comを追加して送信する。すると下書きがDraftsセクションに現れる。

ドキュメントが明確にしている条件が2つある。メールは登録済みのエージェントメールアドレスから送信される必要があり、そのエージェントはAdmin、Team、Rolesの下でSolutionsの公開権限を持っている必要がある。顧客からkbaseアドレス宛に送られたメールは自動的に拒否される。チケットの外にある古いメールでも機能するので、長期にわたるメールスレッドをナレッジベースに転送することは、それを育てる正当な方法だ。

正直な限界は、下書きが生のメールテキストとして届くことだ。結局誰かがそれにタイトル、フォルダ、そして型を与える必要がある。この隙間こそ、まさにSolution Article Generatorが入り込む場所であり、その費用について明確にしておく価値がある。Freshdesk自身のドキュメントははっきりと述べている。それはFreddy AI Copilotのアドオンであり、「accessible to Pro and Enterprise plans through your account manager」だ。CopilotはProのシート料金に加えて月29ドル/エージェントかかり、これにより実質的な最低額は月84ドル/エージェントに加えて、AIが1記事でも書く前に営業との商談が必要になる。この機能を手に入れた後に何をしてくれるかについては、Freddy AIナレッジベースの内訳記事でさらに深掘りしている。

顧客対応側は別課金だ。Freddy AI Agentは100セッションあたり49ドル、つまり1件あたり0.49ドルで、セッションは解決ではなく、24時間のウィンドウ内で1人のエンドユーザーとのすべてのやり取りとして定義される。試行に対してどのみち課金される。料金カードにある「first 500 sessions included」という表記は、プラン購入時の一度きりの付与であり、月次の割り当てではない。これを踏まえて予測を立てる前に把握しておく価値がある。完全なユニットエコノミクスはFreshdesk Freddy AIの料金の記事にあり、予測を試みているならセッション消費についての別の記事もある。

Freshdeskはエージェントの返信の中でもソリューション記事を提案することも触れておく価値がある。これは同じループのエージェント側半分だ。

測定のギャップ

ここが、大半のFreshdeskナレッジベースが静かに停滞していると私が思う場所だ。ナレッジベース分析はProから始まるが、それでもFreshdesk自身のドキュメントはこの機能を今なおベータとラベル付けしている。得られるのは記事ごとのViews、Helpful、Not helpful、そしてSuggestedのカウントで、これはある記事がエージェントの返信にどれだけの頻度で押し込まれたかを追跡する。Suggestedは、Freshdeskが提供するネイティブな偏向アトリビューションに最も近いものだ。

そのスクリーンショットの行を見てほしい:28ビュー、Helpful 0、Not helpful 6。これは人々が見つけて、拒絶している記事であり、誰にも見つけられない記事とはまったく違う問題だ。Freshdeskは前者は教えてくれる。

教えてくれないのは、人々が何を検索して、何を見つけられなかったかだ。Freshdeskには検索失敗レポートがない。ドキュメントは代わりにGoogle Analyticsを使うよう案内している。Zendeskには390日の保持期間を持つ「Searches with no results」があり、Zoho Deskは人気のキーワードと失敗したキーワードを分けており、Help Scoutは検索失敗専用のテーブルを備えている。Freshdeskの答えは、サードパーティの分析ツールを自分で用意しに行くことだ。

このギャップは重要だ。なぜなら、検索の失敗は、あなたが手に入れられる中で最も安上がりな記事バックログだからだ。それらは文字通り、あなたがまだ答えていない、顧客自身の言葉による質問のリストにほかならない。それがなければ、あなたのコンテンツロードマップは、チームがたまたま気づいたことに頼ることになる。検索クエリをコンテンツギャップに対応付ける方法論が丸ごと存在しており、まずはそのクエリを手にすることから始まる。

風化対策も同様に薄い。有効期限フィールドもレビューリマインダーもない。唯一の自動的な陳腐化フラグは「Mark other translations as outdated」で、これは翻訳だけをカバーする。レビューキューに最も近いのはLast modified atでの手動フィルタリングであり、そのフィルタもPro以上限定だ。緑と赤の差分表示と復元ボタンを備えたバージョン管理は本物だが、これもPro限定だ。

誰も教えてくれないSEOの問題

記事ごとのSEOフィールドはすべてのプランに存在する。タイトル、説明、キーワードで、Freshdeskはタイトルに50〜60文字、説明に150〜160文字を推奨しており、超えると赤くなるカウンターも用意している。ここまではいい。

問題はURL側にある。Freshdeskの記事は/support/solutions/articles/<numeric-id>-<slug>に存在し、正規なのは数字のIDのほうだ。Freshdesk自身の内部リンクは日常的にスラッグを完全に省略してもそのまま解決されるため、スラッグが単なる飾りであることがわかる。クリーンなキーワードパスは手に入らない。

そのコンテンツを自分がコントロールできる場所に移す必要があるなら、Freshdeskナレッジベースの APIが実用的な脱出ルートだ。

そしてドメインの問題がある。Freshdeskのポータルはサブドメイン上にあり、マーケターはそれに気づいている。

"Hi, I work with freshdesk and they have their own, "help center", which is in their own url, and I can't SEO/GEO optimize it. The thing is we have +70 articules posted there and I want to used them for SEO/GEO. So can I add in my site map their url?"

Top_Watch_9462, "Indexing a CRM help desk to my main URL", Reddit

彼が得た回答は正しいものだったが、誰も聞きたくない類の答えだった。

"You can't add external URLs to your sitemap and have Google attribute that authority to your domain. The content needs to live on your domain to benefit your SEO."

erickrealz, r/b2bmarketing, Reddit

どのみちヘルプセンターは主にブランド検索由来のトラフィックを稼ぐものなので、サブドメインでもそれほどコストにはならないという、それなりに筋の通った反論もある。消費者向けブランドについては私もその見方に傾くが、良いトラブルシューティング記事がカテゴリ語でランクすることもあるB2B SaaSについては逆だ。いずれにせよ、独自ドメインを使うべきだ。私が確認した13のポータルのうち10がそうしている。greytHRとWorksyはそうしておらず、アドレスバーにそれが表れている。設定方法はFreshdeskカスタマーポータルの設定で、テーマ側の話はポータルのカスタマイズで扱っている。

コミットする前に計画しておく価値のあることがもう一つある。サイトマップの自動生成はPro以上限定で、コンテンツのエクスポートは扱いにくい。Exportボタンは記事一覧とそのプロパティのCSVしか生成しない。実際の記事本文を取り出すには、ヘルプデスクのデータ全体をエクスポートして、その中からSolutions XMLファイルを掘り出す必要がある。一方、削除は取り消し不能で、確認のために正確な名前を再入力するよう求められる。

Freshdeskユーザーが実際に語っていること

状況全体を最も明快にまとめているのは、あるCapterraのレビュアーによるものだ。彼らのプロスとコンスは、最も有益な形で互いに矛盾している。まずプロス側。

"After building our knowledge base, we noticed many customers started resolving common issues on their own before contacting support. This reduced ticket volume while allowing agents to dedicate more attention to complex cases."

Mitali J., Specialist programmer, "The self-service portal reduced repetitive customer questions", Capterra

そして同じレビューのコンス側。

"Although the knowledge base is useful, finding the right article isn't always seamless for end users. Improving search relevance and content recommendations would make self-service even more effective."

Mitali J., same review, Capterra

これが2文に凝縮された緊張関係だ。ナレッジベースはチケットを偏向させる。検索・取得が弱点であり、それこそが、すでに書いたコンテンツの前にナレッジベースチャットボットを置くべき理由すべてだ。

ポータルのカスタマイズはもう一つの繰り返し現れるテーマで、これについての最も強い引用は最近のもので、かつ誘導されたものでもない。

"For the cost, FreshDesk is a great ticketing platform. Once fully configured it works well and the support portal you can build for your end users is a great feature to have. Their market place for integrations is pretty good as well with all the common/popular apps. There is a lack in what you can customize though (specifically with the support portal and workflow builders)."

David N., IT Operations Manager, "Very good ticketing platform for SMB", Capterra

一部の人々はエディタの限界にぶつかり、それを回避している。

"The gui used to deploy the solution articles could be a little more friendly to use. Formatting the solution articles can sometimes be difficult and I find myself directly editing the HTML to get the desired look."

Eli S., Engineer, "Freshdesk is just Intuitive", Capterra

そして、ポータルに3年分の執筆を投じる前に真剣に受け止める価値のあるものがある。

"Freshdesk. Can't exit because: we could get off the ticketing system, but the knowledge base is hosted here as well, and that's publicly accessible."

aetherspawn, Hacker News

移行しようとしていたあるチームは、反対側から同じことを発見した。

"I was able to export all of it to .json from Freshdesk. Still, the issue is that HubSpot is only able to import via two options: either by a CSV or by providing them with the link to the current FreshDesk Knowledge base. It will auto-import it. The issue with number 2 is that it skipped a lot of articles, and they were not correctly categorised."

BanSlam, "Have anyone migrated knowledge base from...", Reddit

Freshdeskに公平を期すなら、多くのレビュアーはナレッジベースを製品の他の部分より高く評価している。あるITサポートアナリストは「Our admin did a good job of integrating the KB with the ticketing systems so the KB was a very reliable point of reference while troubleshooting during a call」と表現しており、コンス側はすべてチケット処理側についてのものだった。ナレッジベースはFreshdeskの弱点ではない。それは単にナレッジベースであり、プラン制限がその量を決めているだけだ。まだ検討中なら、Zendesk対FreshdeskとベストなAIナレッジベースツールの記事で、このレイヤーを直接比較できる。

多言語対応のギャップ、手短に

複数言語に対応するなら、計画する前にこれを知っておいてほしい。Freshdeskはナレッジベースで47言語をサポートしており、そのうち4つはナレッジベース限定だ。そしてどの価格帯でもソリューション記事の機械翻訳は一切行わない。すべての翻訳は人間がタイプする。FreddyのLive Translateはチケットの会話をリアルタイムで処理するが、記事には手を触れない。

伝播も手動だ。マスター版を編集すると、自分でMark other translations as outdatedをクリックする必要がある。そして多言語ナレッジベース全体がPro限定、月55ドル/エージェントだ。これは、英語のままInternational User Manualという別フォルダを維持するというNoiseのアプローチと正直に比較検討する価値がある。後者はコストがかからない。記事ではなくライブの会話については、多言語ライブチャットは別のツールを必要とする別の課題だ。

FreshdeskのためのAI、eesel

すでに難しい部分をやり終えていて、記事は存在するのに顧客がヘルプセンターで答えられるはずのチケットを開き続けているなら、そのギャップはコンテンツではなく検索・取得にある。それこそeeselが解決するために作られた問題だ。

eeselはFreshdeskに接続し、すでに書いたソリューション記事を過去のチケットやマクロとともに読み込み、エージェント向けに返信を下書きするか、顧客に直接応答する。この記事がここまで巡ってきた問題に特に関わる点が3つある。

本番に出る前に、自社のチケット履歴に対してシミュレーションする。 これはロードマップではなく、失敗がきっかけで作った機能だ。ある有料顧客のボットがかつて、サブスクリプションに関する事実無根の主張を実際の顧客に送ってしまったことがある。ナレッジベースに該当する回答がなかったからだ。ロールアウトを先に何千件もの過去のチケットに対して走らせることで、実際のコンテンツに対してAIが何と答えていたかを、顧客の誰かがそれを目にする前に把握できる。それはまた、ベンダーの推定値ではなく、正直なAI解決率の数字を手に入れる方法でもある。

ギャップを表面化させる。 既存の記事からAIが答えられなかった質問は、Freshdeskが提供しない検索失敗レポートそのものだ。それが、実際のチケットから生成された、あなたの記事バックログになる。

作り直しを必要としない。 カテゴリの再編成もなし、Freshdeskポータルからの移行もなし、始めるためにProへのアップグレードを待つ必要もない。すでにそこにあるものを読み込む。それがヘルプセンターにとって検索・取得とファインチューニングの実務的な違いだ。あなたのFreshdeskナレッジベースが3階層でGrowthプラン上にあっても、それで問題ない。

無料で試すことができる。Freshdeskインテグレーションのページで接続の仕組みを解説しており、先に設定を見たいならFreshdeskへのAI導入のステップバイステップガイドもある。

私ならどこから始めるか

ゼロから構築するなら、Hoverをコピーしよう。製品領域の名前を付けた4〜6個のカテゴリ、先頭に固定したGetting Started、すべてのカテゴリの説明文、そしてすべての記事のBefore you beginブロック。これは週末1回分の作業量であり、私が見つけたものの大半に勝る。

すでにナレッジベースがあり、それがチケットを偏向させていないなら、まずは再構築しないこと。チケットキューを開いて、最近の50件を読み、記事がそれを提出した本人のために書かれているかを確認してほしい。私が触れた交通会社は、よく整理されたナレッジベースを持っていたが、対象としていた読者が完全に間違っており、カテゴリ作業をいくら重ねてもそれは直らなかった。この監査は、AIでセルフサービスを改善するためのどんな計画の中でも最も安上がりなステップだ。

Growthプランで不満を感じているなら、正直な見方を言えば、Freshdeskの19ドルの階層はナレッジベースを与えてくれる一方で、それを運用する手段はほとんど与えてくれない。バージョン管理と分析のために55ドルのProに飛びつく前に、実際の問題が顧客があなたの記事を見つけられないことなのかを確かめてほしい。もしそうなら、既存のコンテンツの上にAIレイヤーを載せるほうが、プランを189%引き上げるより安上がりな解決策であり、FreshdeskのためのベストなAIの記事でその選択肢を扱っている。