要点
サポートのナレッジ定着とは、担当者が忘れたときも、知識を持ったまま退職したときも、サポートチームの知識をチームの中に残すことです。多くのチームはこれを研修の問題として扱います。実際は、ほとんどが保管の問題です。最高の担当者の回答は、個人マクロ、Slackのスレッド、本人の頭の中にあります。そしてヘルプデスクは、その3つのうち2つを削除したり隠したりするように作られています。
意外だった点がいくつかあります。Zendeskでは、退職する担当者をダウングレードすると個人マクロが削除されます。Frontは非公開テンプレートを共有テンプレートに変換できません。HubSpotは共有していないテンプレートを他の全員からロックし、Slackの無料プランは1年より古いメッセージを削除します。どれもバグではありません。各ツールの設計どおりの動きであり、だからこそ定着は、人がまだいるうちに身に付ける習慣でなければなりません。
効果のある方法は次のとおりです。マクロは共有をデフォルトにする。回答はチケットの中でその場で記録する。すべての記事に担当者とレビュー日を付ける。誰かが退職を告げたら30日間のナレッジ引き継ぎを行う。そして、誰も覚えていなくて済むよう、回答をチケットの中に置く。最後の部分には、eeselのようなAIヘルプデスクチームメイトが役立ちます。過去のチケットから学ぶので、最高の担当者の答え方が、本人が去った後もキューに残ります。
サポートのナレッジ定着とは？
サポートのナレッジ定着とは、サポートチームが持つ知識を失わないための習慣とツールの集まりです。しばしば一緒くたにされる、2つの異なる問題を扱います。
- 担当者が忘れる。 新人が2週間の製品研修を受け、1か月後に例外的なケースに出会い、どの記事に書いてあったか思い出せません。また先輩に聞きます。
- 担当者が去る。 最も経験豊富な担当者が退職を告げ、その人とともに、回避策、「このお客様はいつもXが必要」という文脈、3年かけて磨いた返信が消えていきます。
定着に関するアドバイスの多くは1つ目の問題を扱います。間隔を空けた反復、小テスト、復習研修などです。それは少しは役に立ちます。しかし、eeselのサポートキューでの経験から言えば、本当に痛いのは2つ目の問題で、両方の解決策は結局同じものになります。人にもっと覚えさせるのではありません。覚えておく必要が減るよう、作業する場所に答えが現れるようにするのです。
これはサポートチームのためのナレッジマネジメントの近い親戚ですが、定着が問うのはもっと絞った問いです。この人が明日いなくなったら、私たちは何に答えられなくなるのか。
サポートチームが他より速く知識を失う理由
サポートは離職率が高く、まれな質問が長い裾野を成す仕事です。この組み合わせは知識にとって厳しいものです。よくあることは、毎日出てくるので書き残されます。まれなこと（2023年の請求移行、特定のプランでだけ壊れる連携）は、たまたま担当した人が一度だけ解決し、その答えはそのチケットとその人の記憶の中に残ります。
Redditのコールセンター担当者は、高い離職率がチームの記憶に何をもたらすかをこう書いています。
"the staff cycle pretty often since it's a minimum wage call centre job. It's never going to be long term for many people so like most places after time people slowly start forgetting who implemented what and just assume."
eeselの営業通話で、Freshdeskを使うフランスの公共部門向けITサービス会社が、ほぼこのとおりの話をしてくれました。月に約3,000件、複雑なERPのトラブルシューティングを6人の担当者で処理しており、最も経験豊富な2人がその年に退職する予定でした。私たちと話した理由は、その知識を残るものに移すことでした。こうした話は、数週間おきにキューで耳にします。チームには通常、何千ものドキュメントがあります（その会社は1万件以上）。足りないのは、シニア担当者が実際にどう答えているかの写しです。
もう1つ、静かな流出があります。Slackでの回答です。質問が来て、誰かがチャンネルで尋ね、シニアが完璧な説明を返し、チケットは短い版で閉じられます。良い回答はSlackに残り、次の人はそこを検索しません。
サポートの知識が実際に流出する場所
担当者の最終日の前に、もっと多くの人に知ってほしい部分です。ヘルプデスクにはそれぞれ、退職者のものがどうなるかについてのルールがあり、同じではありません。各ベンダーのヘルプセンターを確認して、実際に何が残るのかを調べました。
| ツール | 退職する担当者の個人返信はどうなるか | ほかに失われるもの |
|---|---|---|
| Zendesk | ダウングレード時："Agents' personal views and macros are deleted"（出典） | その担当者のCSATデータ、削除後は未共有のExploreダッシュボード |
| Freshdesk | 個人の定型返信："others cannot access the personal folder"（出典） | レポートはゴミ箱へ、スケジュールは"permanently deleted"（出典） |
| Front | 非公開テンプレートは共有に変更できず、"copy the content and recreate it"が必要（出典） | 削除時、個人の受信箱のデータは"after a delay of a few days"で破棄（出典） |
| HubSpot | 削除されたユーザーは"must have shared their sales templates prior to removal"（出典） | 削除（無効化ではなく）するとレポートから外れる |
| Help Scout | 保存済み返信は個人ではなく受信箱に属する（出典） | それを参照するワークフローは無効になる（出典） |
| Gorgias | マクロはアカウント全体のもので、管理者とリードが管理（出典） | 統計はユーザーとともに削除、12か月より古いチケットイベントは保持されない（出典） |
| Slack（無料） | 該当なし | 表示は90日、1年より古いデータは削除（出典） |
3つの行は、もう少し詳しく見る価値があります。
Zendesk。 Zendeskが推奨する退職手順は、ダウングレードしてからサスペンドです。チケット履歴にとっては正しい選択です（クローズ済みチケットは担当者を割り当てたまま残り、記事にも名前が残ります）。しかし、そのダウングレードで担当者が作ったすべての個人マクロが削除されます。最高の担当者が変わったケース用に個人マクロを40個持っていたなら、ダウングレードした日に消えます。この区別については、個人マクロと共有マクロのガイドでさらに書きました。やるべきことは、ダウングレードの後ではなく前に、良いものを確認して昇格させることです。
FrontとHubSpot。 どちらも非公開テンプレートを非公開のまま保ちます。プライバシーには良いのですが、定着には不利です。Frontには変換ボタンがまったくありません。誰かが非公開テンプレートを1つずつ開いて共有テンプレートとして作り直す必要があり、これは作成者がまだいるうちにやる仕事です。
Slack。 チームが無料のSlackで動いているなら、無料プランは直近90日の履歴に制限され、2024年8月26日以降は1年より古いメッセージとファイルが削除されます。キャンバスとリストにも同じ1年の制限があります。シニアが請求の例外ケースを説明した2年前のスレッドは、見つけにくいだけではありません。消えています。
評価の時期に痛い点がもう1つあります。Gorgiasはチケットイベントを直近12か月分しか保持せず、ユーザーを削除するとその統計も削除されます。Gorgias自身の回避策は、削除する前にそのユーザーのログインメールをプレースホルダーに変更し、履歴をレポートに残すことです。
サポートの知識を残す方法：効果のある6つの習慣
どれも新しいツールは不要です。主に、回答をどこに書き留め、誰が責任を持つかの問題です。
1. マクロと保存済み返信は共有をデフォルトにする
個人マクロは、最高の担当者が最高の仕事をしまっておく場所であり、真っ先に消えるものです。単純なルールを決めましょう。個人マクロを3回より多く使ったら、共有に昇格させる。Zendeskでは、各担当者に四半期に一度、個人リストを見直してもらい、マクロをエクスポートして、すでに共有されているものを確認します。Help ScoutとGorgiasのマクロは、返信が受信箱またはアカウントに属する設計なので、これをほぼ設計で解決しています。Freshdeskでは、良いものを個人フォルダから共有の定型返信に移します。
共有ライブラリも良くなります。担当者が自分用に書いたマクロは、企画会議で書かれたものより、お客様が実際に聞くことに近いのが普通です。マクロの管理のガイドでは、こうした後にライブラリが何でも入れの引き出しにならないようにする方法を紹介しています。
2. チケットが開いている間に回答を記録する
何かを書き留める最も安上がりな瞬間は、解決した直後です。それがConsortium for Service Innovationが公開している手法、Knowledge-Centered Service（KCS）の核心です。そのSolve Loopは、お客様自身の言葉を含め"capture in the workflow"と述べています。残す価値のあるものについてのConsortiumの言葉は、私がよく繰り返すものです。"If the issue is worth solving, it is worth saving."
ほとんどのヘルプデスクには、そのための近道があります。
- Zendeskでは、Suite Growth以上で、担当者がチケットの中からヘルプセンター記事を作成またはリクエストできます（出典）。
- Freshdeskでは、
kbase@yourcompany.freshdesk.comをBCCに入れると、どの返信もナレッジベースの下書きになります。全プランで利用可能です（出典）。 - HubSpotのナレッジベースエージェント（ベータ、ProとEnterprise）は、クローズ済みチケットから記事を下書きします。最低5件必要で、1記事あたり200 HubSpotクレジットかかります（出典）。
磨き上げた記事を目指さないでください。KCS自身が"up to 80% of KCS articles will rarely or never be reused"と警告しています。誰も書く時間がなかった完璧な記事より、存在する粗い下書きのほうが価値があります。手法の全体像が知りたければ、オフショアのナレッジ移転の記事で、新しいチームにおけるKCSのライセンスの仕組みを説明しています。
3. 良い回答をSlackから取り出す
1つの習慣を決めて守りましょう。Slackのスレッドがサポートの質問に答えたら、チケットが閉じる前に誰かが社内ナレッジベースに移す。「これは記事にすべき」を意味する共有の絵文字リアクション（📌や📝）は、それについての方針ドキュメントより効果的です。
あるいは発想を逆にして、ナレッジベースをSlackに持ち込み、人々がそこで質問して文書化された答えを得られるようにします。ドキュメントを基にしたAI Slackボットがまさにそれをします。スウェーデン、ポーランド、ノルウェーに拠点を持つ350人規模のSimployerは、Confluenceを基にしたボットをSlackで1つ運用しており、チームはドキュメントへのアクセスが"through the Slack interface has been very well-received by employees"と語っています（事例）。
4. 回答をチケットの中に置く
これは「担当者が忘れる」側を解決する習慣です。人は不注意だから忘れるのではありません。記事が別タブの3クリック先にあり、チケットが目の前にあるから忘れるのです。チケットの中に現れた回答は使われます。wikiにある回答は、ときどき思い出されます。
それがエージェントアシストツールの役割です（おすすめのエージェントアシストツールは別記事で比較しました）。担当者が入力している、まさにその場所で、記事、マクロ、または完全な返信の下書きを提案します。YellowdigのDirector of Support and OperationsであるJon Mironは、新入社員への効果を見事に表現しました。"a new customer success hire joked that our eesel AI bot was their best friend during onboarding and interviewing"（事例）。これが機能している定着です。新人は答えを覚える必要がなく、AIが見つけてくれます。立ち上がりの時間が最大の懸念なら、サポート担当者の立ち上がり時間の記事に数字の面があります。
RedditのITマネージャーも、逆の側から同じことを述べました。担当者が作業する場所からナレッジベースを検索しにくいなら、人は記憶に頼ります。
"If your searching capabilities do not allow for quick matching or suggestions to the agents then why would they use a KB versus relying on personal knowledge?"
5. すべての記事に担当者とレビュー日を付ける
知識は、ドアから出ていくだけではありません。全員がまだいる間にも古くなります。2年前に退職した人が書いた、誰の名前も付いていない記事は最も危険な種類です。公式に見えるのに、誰も確認しません。
これを助けるツールもありますが、有料です。
- Zendeskの記事認証では、スケジュール（2週間、6か月、1年）に従って記事を未認証に戻すルールを、リマインダーメール付きで設定できます。Enterpriseのみです。そして罠に注意してください。記事の担当者を、その記事を再割り当てせずにダウングレードすると、Zendeskによればその人は"will still receive article verification emails."となります。
- FrontにはProfessional以上でスケジュールされた記事レビューがあり、期限の来た記事を毎日リマインドします（出典）。
- **Confluence**のPremiumとEnterpriseでは、無効化された所有者でページを絞り込み、一度に最大100ページの所有者を変更できます（出典）。
- **Guru**は2026年1月にデフォルトを変更しました。新しいコレクションはデフォルトで"Does not expire"となりリマインダーはなく、品質チェックにはAIナレッジエージェントを活用する方針です（出典）。Guruの認証リマインダーに頼っていたなら、新しいコレクションを確認してください。
こうした機能がないプランでは、記事、担当者、次回レビュー日を書いたスプレッドシートで十分です。譲れない点は1つ。誰かが辞めるとき、その人の記事は最終日に新しい担当者へ移すことです。古くなったヘルプセンターのコンテンツを見つけるガイドに、最悪のものをより速く見つける方法があります。
6. 誰も答えられない質問に目を配る
最後の習慣は、ギャップが生じたときに、6か月後ではなくその時点で気づくことです。経験豊富な担当者が去ったとき、最初の兆候は、対応に時間がかかり、エスカレーションが増え、再オープンされるチケットの塊であることが多いです。それにタグを付け、月に一度、最大の塊を記事にします。注目すべきレポートは、サポートのナレッジギャップ分析のガイドで取り上げました。
担当者が退職を告げたときの30日間ナレッジ引き継ぎ
良い習慣があっても、退職の申し出は、記録していなかったものに気づく瞬間です。数週間の猶予があるシニア担当者に私が実施するプランはこれです。2週間しかない場合は圧縮してください。
- -30日：その人だけが知っていることを書き出す。 直接尋ねます。「みんなは何のためにあなたのところへ来る？」そのうえで、直近90日のチケットから、他に誰も扱っていない話題を確認します。10〜20項目のリストができます。そのリストがプロジェクトのすべてです。
- -21日：最も難しいチケットで組んで対応する。 難しいカテゴリを後任に割り当て、退職する人には返信を書くのではなくレビューしてもらいます。ドキュメントを読むより、下書きを直すほうが多くを学べます。
- -14日：その人の返信を共有マクロと記事にする。 個人マクロと保存済み返信を確認し、残す価値のあるものを昇格させます。-30日のリストの各項目について、短い社内記事を書きます。粗くて構いません。数百件の返信があるなら、すべてを読む代わりに過去のチケットからマクロを生成することもできます。
- -7日：オープンなスレッドと関係を引き継ぐ。 オープンなチケットは、グループへ一括ではなく、メモを付けて手作業で再割り当てします。Help Scoutでは、ユーザーが削除されると"no way to do this"なので、アカウントがなくなる前にワークフローベースの再割り当てを済ませます。
- 0日：アカウントは最後に処理する。 記事の所有権を再割り当てし、その人が所有するExploreダッシュボードやレポートを移し、それからダウングレードまたは無効化します。Zendeskでは、削除ではなくダウングレードとサスペンド。Gorgiasでは、削除する前にログインメールをプレースホルダーに変更し、統計を残します。
見落とされがちなのは、地味なステップです。この人が保守していたものを今後誰が保守し、どこに保存されているのか。同じRedditのスレッドで、コールセンター担当者は、研修資料の大半が、自分で作って自分のドメインにホストしたガイドで動いていたと説明していました。案件が新しいコールセンターに移り、そのドメインが失効すると、新しいチームは"80% part of the training pack."を失いました。別のコメント投稿者はこうまとめています。
"Love how everyone took your knowledge base and its regular updates for granted and no one at any level questioned who was maintaining that or where."
お使いのヘルプデスクの0日目チェックリスト
最後のステップの順序は思われているより重要で、ツールごとに異なります。アカウントがなくなる前に保存しておくものは次のとおりです。
最終日の前に：ヘルプデスクで保存しておくもの
ツールを選ぶと、担当者のアカウントがなくなるときに何が消えるか、何をどの順序で行うかが分かります。すべて各ベンダーのヘルプセンターに基づいています。
- 個人マクロを確認し、有用なものを共有マクロとして作り直します。
- 記事の所有権を再割り当てします。そうしないと認証メールがその人に届き続けます。
- その人が作ったExploreダッシュボードを移すか共有します。未共有のものは、ユーザー削除後は復元できません。
- オープンなチケットはメモを付けて再割り当てします。クローズ済みチケットはその人が担当者のまま残ります。
- エンドユーザーにダウングレードしてからサスペンドします。削除はしないでください。
- 有用な個人定型返信を共有フォルダにコピーしてもらいます。
- その人が作ったレポート（無効化するとゴミ箱へ移動）とスケジュール（完全に削除）を作り直します。
- オープンと保留のチケットは、状況を添えて再割り当てします。そうしないと未割り当てのキューに入ります。
- 削除ではなく無効化します。削除すると、チケットと記事から割り当てが消えます。
- 有用な非公開テンプレートを1つずつ開き、共有テンプレートとして作り直します。
- 個人の受信箱にある重要なものを移します。チームメイトの削除から数日後に破棄されます。
- チームメイトをブロックまたは削除し、新入社員を新しいチームメイトとして追加します。Frontは古いログインの再利用を勧めていません。
- 削除される前に、テンプレートを共有してもらいます。
- その人のチケットを再割り当てします。削除された所有者は、チケット上で"Deactivated/Removed"と表示されます。
- 履歴をレポートに残したい場合は無効化します。削除するとレポートから外れます。
- ユーザーを削除する前に、オープンな会話を再割り当てします。
- その人を参照しているワークフローを更新します。削除時に無効になります。
- 保存済み返信は受信箱に属するので残ります。過去の返信とメモも残ります。
- 先に、オープンとスヌーズ中のチケットを再割り当てします。削除すると割り当てが外れます。
- 削除する前にログインメールをプレースホルダーに変更し、統計をレポートに残します。
- マクロはアカウント全体のものなので、救い出す個人マクロはありません。
- 残す価値のあるサポートのスレッドは、誰かの退職時ではなく今、ナレッジベースに移します。
- メンバーを無効化しても、そのメッセージやファイルは削除されないので、スレッドは検索できます。
- チャンネルを削除すると、どのプランでもそのメッセージが削除されます。代わりにアーカイブしてください。
30日ない場合は、ステップ1と3を守ってください。リストとマクロは、その人が去った後も機能し続けます。そしてこのプランが新人のオンボーディングを逆にしたものに見えてきたなら、それが狙いです。同じ成果物が両方を支えます。
よくある間違い
- 定着を研修プロジェクトとして扱う。 復習セッションを増やしても、1人の頭の中にしかない知識は解決しません。まず書き出し、それでも必要なら研修ソフトを選びます。
- 担当者のアカウントを先に削除する。 ほとんどのヘルプデスクでは順序が重要です。再割り当ての前に削除すると、履歴、統計、再割り当てする機会を失います。
- チケットのアーカイブが覚えていてくれると頼る。 チケットは理論上は検索できます。実際には、2年前の適切な1件を見つけられる人はおらず、ツールによってはスケジュールで履歴を削ります（Zendeskのチケット削除スケジュールはTeamプラン以上にあり、クローズの120日後にアーカイブされたチケットだけが対象です）。
- 完璧な記事をゆっくり書く。 今日の粗い社内メモは、来四半期の磨かれた記事に勝ります。ナレッジベース管理は反復的なものです。
- 引き継ぎドキュメントを退職者本人のドライブに置いたままにする。 個人フォルダにあると、アカウントが削除されたときに消える可能性があります。初日から共有スペースに置いてください。
eeselがサポートの知識をチームに残す方法
このテーマが私にとって身近な理由を正直に話します。eeselのサポートキューでは、「シニア担当者が辞めるのですが、AIは彼らの知識を学べますか？」が、問い合わせの最も多い理由の1つです。そして営業通話で最も要望が多い機能は、断トツで過去のチケットでの学習です。デモ通話が続いた後に、eeselの共同創業者の1人はこう言いました。"People really, really, really want to train on past tickets."
それが定着という切り口です。eeselのAIヘルプデスクチームメイトは既存のヘルプデスクに参加し、チームがすでに持っているものから学びます。Zendeskでは、フル接続がヘルプセンター、マクロ、過去のチケットを読み込むので、1件のチケットを処理する前に、チームの答え方をすでに把握しています。そこには、シニア担当者が実際に送った返信の中にある答え方が含まれ、本人が去った後も機能し続けます。さらにConfluence、Google Drive、Notion、ウェブサイトにも接続し、散らばった情報を1か所にまとめます。
いくつかの機能は、上の習慣にそのまま対応します。
- チケット内の回答。 eeselは、担当者がレビューする内部メモとして返信を下書きでき、誰でも内部メモで
@eeselをメンションすれば、必要なときに下書きを得られます。新人はシニアを遮る代わりにAIに尋ねます。 - 修正が残る。 エージェントを修正すると、その修正が自身の指示に書き込まれるので、シニアが一度説明したルールが、今後のすべての下書きが従うルールになります。暗黙知が、読んで編集できる文章のルールになります。
- ギャップが知らされる。 eeselのレポートはナレッジギャップ、つまりドキュメントから答えられなかった質問を追跡し、スキルが不足している記事の下書きを作成して、あなたのレビューに回せます。
- Slackでの社内Q&A。 同じチームメイトが、Slackで社内の質問にソースのリンク付きで答え、見つからないときはそう伝えます。
従業員500人以上のクラウド・ホスティング企業Gcoreは、まさにこの分担で運用しています。公開ヘルプセンター向けの顧客対応ボットと、社内のZendeskマクロと"the entire history of past tickets."で学習した社内エージェントボットです。チームは、社内ボットが担当者の返信の下書きを"based on what's worked before, and even get new team members up to speed faster"の形で支援すると述べています（事例）。
eeselがしないこと。ヘルプデスクの退職時設定の代わりにはなりません。eeselは残っているものからしか学べないので、誰かの最終日の前に、ヘルプデスクで個人マクロを昇格させ、記事の所有者を再割り当てしてください。料金：無料プランにはカード不要で100クレジットが含まれ、Teammateプランは500クレジットで月額$299から。返信が何回必要でも、チケット1件が1クレジットとして数えられます。シート数は無制限なので、すべての担当者が使えます。
次の退職の前にeeselを試す
チームの最高の回答が、1人の頭と個人マクロの山の中にあるなら、eeselを試してください。Zendesk、Freshdesk、Gorgias、Front、Help Scoutに数分で接続し、過去のチケットとドキュメントから学び、最高の担当者が去った後も、その人と同じように答え続けます。無料プランには100クレジットとすべての連携が含まれます。