サポートポリシーの変更管理とは？
顧客向けのルールを変更し、そのルールを繰り返し伝えるすべてのチャネル、人、ツールが、同じ日に新しいバージョンへ切り替わるようにするプロセスです。たとえば、30日の返品期間が14日になる、再入庫手数料が新設される、返金に写真が必要になる、応答時間の約束（SLA）が4時間から1営業日に変わる、といったケースです。
私は毎日 eesel のサポートキューを担当していますが、パターンはいつも同じです。ポリシーの担当部門（経理、法務、オペレーション）がポリシーページを更新し、サポートリーダーに伝えます。サポートリーダーはメインのヘルプセンター記事を更新します。その後の3週間、顧客が古いルールを引用するチケットが届き続けます。顧客は、保存済み返信、フランス語の翻訳、注文確認メール、チャットボットの回答のどこかでそれを読んだからです。
これがこのガイドの中心的な考え方です。ポリシーは1つの文書ではなく、1つの文書の6つか7つのコピーです。変更管理とは、そのすべてを見つける作業です。
古いポリシーのコピーが隠れている場所
何かを変更する前に、棚卸しが必要です。以下は私が毎回確認する場所で、問題になる頻度の高い順におおよそ並べています。
- メインのヘルプセンター記事。 これは誰でも覚えています。
- ルールにさらりと触れている他の記事。 「返品は30日以内なら無料」と書かれた配送FAQ。ギフトカードの記事。海外注文のページ。誰も思い出さないのはこれらです。
- 翻訳。 各言語版は独立したコピーで、英語版を更新しても更新されません。
- マクロと保存済み返信。 たいてい最大の山で、検索が最も難しい部分です（詳しくは下記）。
- AIエージェントのナレッジ。 ヘルプセンター記事、アップロードしたPDF、Google ドキュメント、クロールしたWebページ、AIツールに直接入力したルールや「ガイダンス」。
- チャットボットのフローとメールテンプレート。 注文確認、返品ポータルの文言、タグで起動する自動返信。
- 担当者の頭の中。 記憶だけで400回打ってきたルール。
誰も警告してくれない検索の問題
ベンダーのドキュメントを読んで驚いたのがここです。ほとんどのヘルプデスクは、マクロや保存済み返信を名前で検索する方法しか記載しておらず、中身のテキストでは検索できません。Zendeskのマクロ検索は名前または名前の一部で動きます。HubSpotのスニペットは名前で検索します。Help ScoutとZoho Deskも、保存済み返信とスニペットを名前で検索します。つまり「30日」と入力して、30日を約束しているすべての返信を取り出すことはできません。
回避策はエクスポートです。Freshdeskでは定型返信をCSVにエクスポートし、Content HTML列を編集して再インポートできます。ただしCanned Response IDには触れないでください。Gorgiasも、id をキーにしたマクロのCSVで同じことができます。Zendeskでは、マクロをエクスポートするとCtrl+Fで検索できるファイルが手に入ります。テキストがスプレッドシートに入れば、古いルールのコピーをすべて見つける作業は、クリックで潰れる午後ではなく数分で終わります。
Help Scoutにはさらにもう一つ落とし穴があります。保存済み返信は受信トレイごとに存在し、コピーボタンは別の受信トレイに独立した返信を作ります。受信トレイが5つなら、編集も5回です。
だからこそ、散らかったマクロライブラリは見た目以上に痛手になります。ある eesel の営業通話で、月に約7,000件のチケットを扱うGorgiasのDTCブランドは、ナレッジがSOPツール、文字起こしされていないLoom動画、古くなったマクロに散らばっていると話していました。そうした環境では、ポリシー変更のたびに発掘作業になります。心当たりがあるなら、マクロの管理ガイドが最初の整理に役立ちます。
AIエージェントはどのくらい早く変更に気づく？
すべてのサポートリーダーに2回読んでほしいセクションです。記事を編集すると、人間の担当者は次に開いたときに新しいバージョンを見ます。AIエージェントはそうとは限りません。
ベンダーのドキュメントから分かる目安はこうです。ヘルプデスク内の記事の編集はAIに早く届きますが、外部にあるもの（Webページ、Google ドキュメント、クロールしたポリシーページ）の編集は、誰かが再同期するまで古いまま残ることがあります。
詳細は以下のとおりで、すべて各ベンダー自身のヘルプセンターに基づいています。
| ヘルプデスク | 編集したヘルプセンター記事 | Webページまたは外部ドキュメント | 手動での対処 |
|---|---|---|---|
| Zendesk | "at the time the search is performed" に検索される | 最後の同期、"usually every 24 hours"（出典） | 再インポート（旧Advanced AIエージェント） |
| HubSpot | 更新時に自動で再同期 | 週1回再同期（出典） | ソースごとのRefreshボタン |
| Front | "Typically available to AI within minutes" | 自動同期なし（出典） | 手動で再同期 |
| Zoho Desk | Answer Botが30分ごとに再学習（出典） | 該当なし（記事のみ） | Re-train All |
| Freshdesk | 公開済みのソリューション記事がソースになる | URLとファイルは "Resync and relearn" が必要（出典） | 再同期。SharePointは約15分ごとに再インデックス |
| Gorgias | 記事とガイダンスは公開後に使われる | "Doesn't automatically re-sync"（出典） | 24時間に1回再同期。ストアサイトは数時間かかることがある |
| Help Scout | ドキュメントに記載なし | "a pricing change... changes in procedures" の後に手動で再同期（出典） | ソースを再同期 |
Gorgiasの行は詳しく見る価値があります。Shopifyストアは返品と配送のポリシーをストアのWebサイトに置いているからです。Gorgiasはそれらのページを、編集できないQ&Aスニペットに取り込み、再同期は24時間に1回しか許されません。午前9時に返品ページを変更しても、その日の午後、AIエージェントは古い期間を案内している可能性があります。待てない場合のGorgias自身の代替策は、古い内容のスニペットを無効にすることです。
食い違う2つのコピーは、古い1つのコピーより悪い
Gorgiasは、矛盾するコピーについて、私が見つけた中で最も明確な警告も公開しています。ナレッジのドキュメントには "guidance carries the most weight" とあり、まさにこの例が挙げられています。ヘルプセンター記事には返品期間が30日とあり、ガイダンスには14日とある場合、AIエージェントは "might not respond the same way every time" だというのです。これが、中途半端に終わったポリシー変更の現実的な失敗パターンです。毎回間違った回答になるのではなく、コイントスになります。GorgiasのOpportunities機能（ベータ）は、これらを "Resolve knowledge conflict" として検出し、両方の内容を並べて表示できます。
Help Scoutにも同様の罠があります。AI Answers では、回答を補正する短い "Improvements" を追加できます。Docsの記事を直して古いImprovementを忘れると、AIは古いルールを言い続けることがあります。どのヘルプデスクでAIを動かしていても、ポリシー変更中に最も重要なナレッジベース管理の習慣は、新しいバージョンを足すだけでなく、古いバージョンを削除することです。
以前より重要になった理由
2024年2月、ブリティッシュコロンビア州のCivil Resolution TribunalはMoffatt v. Air Canadaについて判断を下しました。Air CanadaのWebサイトのチャットボットは、身内を亡くした顧客に、搭乗後でも、航空券購入から90日以内なら割引の忌引き運賃を申請できると伝えました。チャットボットがリンクしていた忌引きのページには、搭乗後はポリシーが適用されないと書かれていました。Air Canadaは、審判所の言葉では、"including a chatbot" を含む自社の代理人からの情報について責任を問われるべきではないと主張しました。審判所はこれを "a remarkable submission" と呼び、次のように書きました。"It makes no difference whether the information comes from a static page or a chatbot."また、顧客がWebサイトのある部分を別の部分と照らし合わせて確認する必要はないとも述べました。航空会社は、損害賠償、利息、手数料として812.02ドルを支払いました。
金額は小さいですが、原則は小さくありません。2つのコピーが食い違うとき、顧客は読んだ方に頼ってよいのです。Hacker Newsのコメントは、最も可能性の高い原因を率直に指摘していました。
"I wonder whether the bot hallucinated the wrong information or whether the policy changed and the bot simply wasn't updated / retrained. The latter seems more likely but less interesting, akin to information on a boring HTML page getting overlooked during a site update."
航空会社だけの話ではありません。2025年4月、CursorのAIサポートボットは、ログインは1台のデバイスに制限されていると利用者に伝えました。Cursorの共同創業者はRedditで "we have no such policy" と返信し、それに関するHacker Newsのスレッドは600件を超えるコメントがつきました。古い、または欠けたポリシーしか持たないAIエージェントは黙っていません。空白を埋めてしまいます。
ポリシー変更の展開をステップごとに
顧客向けの変更なら、文言の小さな修正から新しい返金ポリシーまで、このタイムラインを使います。大きな変更なら前半を延ばし、小さな変更なら2日に圧縮してください。順序は変わりません。
1. 1ページの変更メモを書く（マイナス7日）
誰かが何かを編集する前に、次の5点を1ページに書き出します。
- 旧ルールと新ルールを、一字一句そのまま。
- 発効日時を、タイムゾーン付きで。
- **誰に適用されるか。**これが旧ルール維持の問いです。3日に行われた注文には旧来の30日と新しい14日のどちらが適用されるのか。基準日（注文日が最も一般的）を決めて書き留めます。
- 例外と、それを承認できる人を、数字付きで。「チームリーダーは200ドル未満の注文について30日までの返品を承認できる」なら従えます。「判断で対応する」では従えません。
- 顧客に伝えられる、1文の理由。
この最後の一行は、思われている以上に重要です。ルールが変わった理由を説明できる担当者は、反発にも落ち着いて対応できます。説明できない担当者は、結局そのルールを謝ることになり、顧客はそれを「このルールは交渉できる」と受け取ります。返金についてカスタマーサポートのSOPをすでに持っているなら、変更メモはそれに適用する差分になります。
2. すべてのコピーを棚卸しする（マイナス7日からマイナス5日）
上に挙げた7か所を順に確認します。マクロをスプレッドシートにエクスポートし、ポリシー名だけでなく、古い数字やフレーズを検索します。ヘルプセンターでも同じ語句を検索します。すべての言語を確認します。
次に、利用データで優先順位をつけます。Zendeskは、Suite Growth以上で、過去30日間の利用回数でマクロを並べ替えできます。Freshdeskには定型返信の利用レポート、Frontにはメッセージテンプレートのレポートがあり、Gorgiasではマクロ一覧からマクロの利用状況を確認できます。チームが1日に50回送っている返信を最初に直します。
3. 編集を準備し、同時に切り替わるようにする（マイナス5日からマイナス3日）
目標は、すべてのコピーが同じ瞬間に切り替わることです。ヘルプデスクがどれだけ助けてくれるかは、プランに大きく左右されます。
Zendesk は最も優れたツールを持ち、その大半をEnterpriseに限定しています。コンテンツブロックを使えば、ポリシーの段落を1回書いて複数の記事で再利用できます。ブロックを編集すれば、それを使うすべての記事が再公開なしで更新されます。下位プランの場合は、Zendeskのナレッジ管理ガイドで手動の代替手段を扱っています。公開と非公開のスケジュール設定はEnterprise限定で、1時間単位で設定でき、すべての翻訳に一括で適用できます。
Zendeskの落とし穴が1つあります。コンテンツブロックを含んでいた記事の古いバージョンを後から復元すると、Zendeskはブロックのリンクを解除し、その文章を記事に貼り付けます。その記事はブロックの更新を受け取らなくなり、次のポリシー変更で気づかれないまま取りこぼされます。改訂ツールの残りについては、Zendeskの記事バージョン履歴の投稿で扱っています。
HubSpot（ナレッジベースがあるService Hub Pro以上）には便利な機能があります。Schedule updateは、すでに公開中の記事への編集を準備しておき、発効日に公開します。
Freshdesk は、保存した各バージョンに "Show changes" の差分を表示し、メイン記事を編集した後に他の翻訳を古いものとしてマークすることを提案します。正式な承認ステップ（Draft、In Review、Approved）はEnterprise限定です。
Gorgias は、公開済みの記事やガイダンスへの編集を下書きとして保持し、ドキュメントにも "AI Agent does not use drafts in real customer conversations." と明記されています。ナレッジベースの変更を公開するときは、変更の概要を追加できます。Gorgias自身の例は "updated return window from 15 to 30 days" です（出典）。
Front と Help Scout には下書きとバージョン履歴がありますが、私が確認したドキュメントには公開のスケジュール設定がないため、当日に直接編集することになります。Zoho Desk には、期限付きポリシー向けに他にはない機能があります。記事の有効期限で、ヘルプセンターから記事を自動的に取り下げ、7日前、前日、当日に所有者へメールを送ります。年末年始の返品期間延長にぴったりです。
4. 担当者に周知する（マイナス3日）
予想していなかった抜け穴がここにあります。私が最も詳しく調べた3つの大手ヘルプデスク（Zendesk、HubSpot、Help Scout）のいずれも、担当者向けの組み込みお知らせ機能を記載していません。ポリシーの更新はSlack、メール、チームの朝会で伝えられ、ヘルプデスクが役立つのは使う場面だけです。Zendeskのナレッジパネルはチケット内に記事を表示し、HubSpotのプレイブックは記事をチケットレコードに埋め込めます。
つまり、周知は自分でやる必要があります。うまくいく方法は次のとおりです。
- 新しい記事へのリンクだけでなく、1ページの変更メモを社内ナレッジベースで共有する。
- 最も多いと予想される3つのチケットを一緒に確認する。基準日より前に購入した顧客、後に購入して怒っている顧客、そして境界ケース。
- 「なぜ変わったのか」の正確な言い回しと、確認なしに承認できる例外の正確な上限を担当者に渡す。
- 新しいマクロの場所と、古いマクロが廃止されることを伝える。
これを省いたときの失敗は、キューを担当したことのある人にはつらいほど見覚えがあるものです。チームがポリシー変更をどう知るのかを尋ねたr/callcentresのスレッドは、次のような回答であふれていました。
"Emails get buried so fast man I swear I will find a important update like 3 days later after already giving wrong info to 10 customers. The knowledge base is good when they actually update it but half the time someone forgot to change the article and then supervisor says oh yeah they sent email about that last week"
そのスレッドで確実に届くチャネルとして挙がっていたのは、シフト前の短い毎日の朝会でした。普段は朝会をしないチームでも、大きな変更の初日には1回行ってください。
定期的な担当者へのフィードバックを行っているなら、最初の1か月は新しいルールをQAスコアカードに加えます。難しいタイプのチケットから作ったトレーニングシナリオは、新人が自信をつける最速の方法です。
5. 0日目にすべてを公開する
発効日に、すべてを一度に切り替えます。
- 新しい記事を公開し（またはスケジュールに任せ）、古い記事を非公開にするかリダイレクトする。
- 棚卸しした各マクロを更新または置き換える（GorgiasのマクロとFreshdeskの定型返信はどちらもCSVでの再インポートに対応）。履歴が必要になる可能性があるなら、古いマクロは削除せずアーカイブする。Gorgiasではアーカイブは復元可能で、削除は元に戻せません（出典）。
- AIを更新する。AIツールで古いルールを編集または削除し、ポリシーを含む外部ソースをすべて再同期する。Gorgiasならストアのウェブサイトを再同期する。Front、Freshdesk、Help Scoutなら、Webサイトやドキュメントのソースを再同期する。
- 今日直せないものはオフにする。古いスニペットを無効にし、古いPDFを非公開にし、ソースをオフにする。
- チャットボットのフローと自動メールテンプレートを更新する。
Zendesk Enterpriseには、もう1つ真似する価値のある技があります。Zendesk自身が、大きな変更の後に記事の確認を一括で取り消すことを提案しています（例として挙げているのはブランド名の変更です）。確認を取り消した記事はすべて "Needs verification" リストに入り、所有者は確認するまで2週間ごとにメールを受け取ります。ポリシー変更では、キーワード検索に該当した記事をすべて未確認にして、リストに担当者を追いかけてもらいましょう。
6. 顧客より先にAIをテストする（0日目から1日目）
顧客が実際に言いそうな形で、10個のテスト質問を書きます。「2日に買ったけど、まだ返品できますか」「なぜ手数料がかかるようになったのですか」「御社のサイトには30日と書いてありました」。AIに1つずつ尋ね、回答とその出典を読みます。
今ではほとんどのヘルプデスクに、これを安全に行える場所があります。FreshdeskのAI Agent Studioには、一度に最大100件のクエリを実行するTestタブと、返信を非公開メモとして下書きするメールAIエージェントのシャドウモードがあります。Gorgiasでは、公開前にPlaygroundで下書きをテストでき、本番の設定をすべて使い、下書きだけを差し替えて試せます。FrontのAutopilotには、自分で書いたシナリオを実行するシミュレーションがあります。
旧ルール維持のケースには特に注意してください。AIエージェントはルールを引用するのは得意ですが、確認方法を教えない限り、「ご注文日によります」のような判断はあまり得意ではありません。AIが注文日を参照できないなら、正しい指示は、推測させることではなく、それらのチケットをエスカレーションさせることです。
7. 古い文言を検索する（14日目）
2週間後、送信済みの返信から古い数字やフレーズを検索します。ヒットしたものはすべて、見落としたコピーです。よくある取りこぼしは、担当者個人のマクロ、自動化内のテンプレート、翻訳済みの記事、AIがまだ持っているPDFです。
Frontには、自動送信されたコピーを捕まえるうまい方法が記載されています。テンプレート固有の一節を本文に含む送信メッセージにタグを付けるルールを作る方法で、テンプレートレポートは自動返信をカウントしないためです。同じ考え方は、メッセージ内容でタグ付けできる場所ならどこでも使えます。
その後、古くなったヘルプセンターのコンテンツ全般に対するのと同じように、レビューをスケジュールに組み込みます。Frontの記事レビューのスケジュール（Professionalプラン以上）は、期限が来た記事についてレビュアーに毎日リマインダーを送り、Zendeskの確認ルールは、ポリシー記事を数か月ごとに再度フラグ付けできます。
ヘルプデスク別のポリシー変更チートシート
展開には4つの作業があり、ヘルプデスクごとに扱いが異なります。記事の準備、古い返信の発見、AIへの反映、顧客より先のテストです。お使いのものを選んでください。
お使いのヘルプデスクでは、ポリシー変更はどこで問題になる？
ヘルプデスクを選ぶと、各ベンダーのドキュメントに基づいて、記事の準備、古い返信の発見、AIの更新、テストの方法を確認できます。
- 準備：Suite Growth以上で改訂履歴。コンテンツブロック、公開スケジュール、確認ルールはEnterprise限定。
- 古い返信の発見：マクロ検索は名前のみ。利用回数で並べ替える（過去30日、Growth以上）か、マクロをエクスポートしてファイルを検索。
- AIの更新：ヘルプセンターの編集は検索時に反映。外部ソースは "usually every 24 hours" で同期。
- 注意：古い記事バージョンを復元すると、コンテンツブロックのリンクが解除される。
- 準備：Show changes差分付きのバージョン履歴。承認ワークフロー（In Review、Approved）はEnterprise限定。
- 古い返信の発見：定型返信をCSVにエクスポートし、Content HTMLを編集して再インポート。Canned Response IDは絶対に変更しない。
- AIの更新：URLとファイルは "Resync and relearn" が必要。SharePointは約15分ごとに再インデックス。
- テスト：Testタブは1回の実行で最大100件のクエリ。メールAIエージェントのシャドウモードは非公開メモを下書き。
- 準備：編集は下書きのまま残り、AIは本番で使わない。公開時に変更の概要を追加。
- 古い返信の発見：マクロをCSVにエクスポートし、idで再インポート。Opportunities（ベータ）がナレッジの競合をフラグ付け。
- AIの更新：ストアのウェブサイトとURLは自動で再同期されない。24時間に1回再同期。ストアサイトは数時間かかることがある。
- テスト：公開前にPlaygroundで下書きを試す。ガイダンスは記事より重いので、両方を更新。
- 準備：Service Hub Pro以上でSchedule publish、Schedule update、Schedule unpublish。
- 古い返信の発見：スニペットは名前で検索。1アカウントあたり最大5,000件、各2,500文字。
- AIの更新：ナレッジベースの編集は自動で再同期。その他のソースは、Refreshをクリックしない限り週1回。
- 注意：ファイルとしてアップロードした返品ポリシーは、編集後に1週間古いままになることがある。
- 準備：復元機能付きのDocs改訂履歴。ドキュメントには公開スケジュールの記載なし。
- 古い返信の発見：保存済み返信は受信トレイごと。コピーは独立しているので、各受信トレイを編集。
- AIの更新：Webサイトのソースは、料金や手順の変更後に手動で再同期が必要。
- 注意：AI Answersの古いImprovementsが、以前のルールを言い続けることがある。
- 準備：編集すると "Published with pending changes" の下書きが作られる。記事レビューのスケジュールはProfessional以上。
- 古い返信の発見：テンプレートレポートで利用状況を確認。テンプレート固有のフレーズを含む送信メッセージにタグを付けて自動返信を捕捉。
- AIの更新：ナレッジベースの編集は数分でAIに届く。Webサイトやサードパーティのソースは手動で再同期。
- テスト：Autopilotのシミュレーションが、自分で書いたシナリオを実行。
- 準備：カテゴリレビュアー（最大50人）とマイナー/メジャーバージョン。有効期限で期限付きの記事を自動的に取り下げ。
- 古い返信の発見：スニペットは名前で検索。Standard以上で1アカウントあたり最大200件。
- AIの更新：Answer Botは30分ごとに再学習。またはRe-train Allをクリック。
- 注意：所有者は7日前、1日前、当日に有効期限のメールを受け取る。
移行期間中の顧客への対応
最初の2週間のチケットの大半は、古いルールをどこかで読んだ人たちからのものです。いくつかの工夫で、対応はずっと楽になります。
**顧客が見たバージョンを、常識の範囲で尊重する。**顧客が自社のサイトや自社のメールで古い文言を示せるなら、最も安上がりな対応は、ほぼ常に、一度は尊重してコピーを直すことです。それは、Air Canadaの判断が結局あなたに求めることとも、ほぼ同じです。
**移行用のマクロを書く。**出発点が必要なら、これらの返金・返品マクロのテンプレートのいずれかを調整してください。ポリシーがこの日付に変わったこと、その理由、お客様のご注文に適用される内容、私がして差し上げられることを伝える1通の返信です。担当者が1日に40回もこれをアドリブで書くべきではありません。
**担当者に現実的な例外の上限を与える。**旧ルール維持に関する質問をすべてエスカレーションしなければならないなら、キューは2週間倍になります。担当者が自分で承認できる、明確な金額や日数の上限があれば、チケットは滞りません。
一貫しない例外は、ポリシー変更を長い争いに変えてしまいます。小売の現場で働く人はよく知っています。
"Yup, customers have definitely played the "but the other guy did it for me!" card and it sucks because now there's precedent"
同じスレッドの解決策の1つは、ポリシー外の返品にはマネージャーが自分のコードを入力し、すべての例外に名前が残るようにすることです。ヘルプデスクでの同等の方法は、すべての例外チケットに社内メモとタグを付けることです。
**チケットにタグを付ける。**変更に関するすべてのチケットに policy-change-returns のようなタグを付けます。1か月後には、何人の顧客が影響を受け、何に異議を唱え、ポリシーページでより良い説明が必要かどうかが分かります。AIによるチケットのタグ付けを使っていれば、誰も覚えていなくても自動で行われます。
よくある間違い
- **メイン記事を更新して終わりにする。**それは6つか7つあるコピーの1つにすぎません。
- **古いバージョンを新しいバージョンの隣で有効にしたままにする。**矛盾する2つのコピーはAIにコイントスをさせます。Gorgiasの30日対14日の例が示すとおりです。
- **外部ソースを忘れる。**AIツールにアップロードしたポリシーPDF、Google ドキュメント、クロールしたポリシーページ。これらは最も更新が遅いコピーです。
- **旧ルール維持の方針を事前に決めない。**担当者はそれぞれ独自のルールを作り、顧客は情報を突き合わせます。前払いの年間プランを解約して値上げしたプロバイダーに反応したHacker Newsのコメントは、前払いプランが維持されていれば"actually stick with them"と書いていました。
- **古いチケットでAIをトレーニングする。**AIが過去の返信から学習するなら、過去6か月のチケットはすべて古いルールを教えます。ツールが対応しているなら、チケットソースを変更日以降に絞り込んでください。
eesel はポリシー変更をどう扱うか
なぜこのテーマにこれほどこだわるのか、正直に言います。ルール変更をAIチームメイトへ展開するチームを支援することは、私が eesel のサポートキューで行っている仕事の大きな部分です。そしてチームにはここで痛い経験があります。初期の eesel では、以前のチャットですでに保存したつもりだったルールを、顧客がエージェントに教え直していました。だから現在の製品は、保存されたすべてのルールを、読んで編集できる1つのInstructionsページに表示しており、変更のたびにそのページを確認するよう、私は皆に伝えています。
eesel のAIヘルプデスクチームメイトでポリシー変更がどう進むかを、ステップごとに説明します。
**事実はドキュメントに、ルールはインストラクションに。**eesel のドキュメントははっきりしています。価格やポリシーをエージェントのインストラクションに入れないでください。エージェントは接続されたナレッジを検索して事実に関する質問に答え、インストラクションは"tone, policy and escalation"を司ります。ヘルプセンターではファインチューニングよりも検索が優れているのと同じ理由です。変更するのはモデルではなく、ドキュメントだからです。実際には、新しい返品ポリシーの文章はヘルプセンター記事またはドキュメントに置き、振る舞いのルール（「14日を超える返品は承認する前に確認する」）はインストラクションに置きます。
**ルールの変更は、古いルールの編集になる。**チャットでエージェントを訂正すると（「返品期間を14日に変更しました。1日より前の注文は引き続き30日です」）、エージェントはまず現在のインストラクションを読みます。すでにその点をカバーするルールがあれば、新しい行を追加する代わりに、そのルールを編集します。これは先ほどの、競合するコピーの問題を、根本で解決するものです。
実際の設定ではこうなります。Zendeskを使うあるサポート管理者は、エージェントに自社のキャンセルルールを普通の言葉で教えました。
"I have a rule in CS where we do not address a cancel or refund request when there is an issue attached to it."
これは、「キャンセルの前にトラブルシューティングを」というポリシーを組み込んだサポート管理者の例です。その後、エージェントが早すぎるタイミングでキャンセルの返信を下書きしたとき、管理者の訂正は1行でした。"This is incorrect. You have not provided troubleshooting steps yet." インターフェースはそれだけです。何が間違っていたかを伝え、変更を残すかと聞かれたらはいと答えれば、その訂正がInstructionsページのルールになります。
**各ソースがどう更新されるかを把握する。**ここは慎重に進めたいところです。すべてのヘルプデスクが抱える、外部ドキュメントの問題と同じだからです。
| ポリシーの置き場所 | eesel が編集を取り込む方法 |
|---|---|
| お使いのヘルプデスク（ヘルプセンター、マクロ、チケット） | エージェントの作業中に更新される |
| Confluence | 編集は自動で再インデックスされ、1時間ごとにチェックされる |
| Google Drive | 再同期で編集は更新されるが、新規ファイルは選び直す必要がある |
| Webサイト | 自動の再クロールなし。インテグレーションを保存し直す |
| アップロードしたファイル | 同じ名前のファイルをアップロードして置き換える |
これらはすべてeesel のナレッジドキュメントに基づいています。注意すべきはGoogle Driveの行です。新しいポリシーが古いドキュメントの編集ではなく新しいGoogle ドキュメントの場合、再同期では見つかりません。そして古いドキュメントは、削除するまでインデックスされたままです。既存のドキュメントを編集するか、フォルダを選び直してください。Zendeskについてもう一点。ヘルプセンターの下書きは含めない限り除外されるため、新しい記事の下書きが早い段階で回答に漏れることはありません。
**公開前に、実際のチケットでテストする。**eesel のシミュレーションスキルは、過去の実際のチケット（またはエージェントが作成したテストケース）を何も送信せずに再現し、チームが実際に送った内容と照らして各回答を採点します。ポリシー変更に関する注意点が1つあります。基準になるのは旧ポリシー下でのチームの返信なので、変更した話題での「不一致」が正しい回答であることもあります。新しいルールに特化したテストケースの生成を依頼し、それ以外の結果を読んで、他に何も動いていないことを確認するのがおすすめです。
**移行期間中は、リスクの高い話題を承認待ちにする。**各アクションはAuto、Needs approval、Disabledのいずれかに設定でき、返信がAutoでも、「返金に関するものは返信前に確認する」のようなインストラクションで特定の話題だけ保留できます（承認のドキュメント）。返金ポリシーを変更した後の最初の1週間は、私ならそうします。返金依頼向けのAIを一般的に設定するときも同様です。さらに、すべての下書きには使用したヘルプセンター記事が明記されるので、新しいバージョンを読んだかどうかが一目で分かります。
**料金。**eesel のFreeプランには、カード不要で100クレジットが含まれます。Teammateプランは月額299ドルで500クレジットから始まり、チケットまたはチャットは、長さに関係なく1クレジットとしてカウントされます。ダッシュボードで行う質問（10個のポリシー質問のテストなど）は、ほとんど無料です。
eesel がしないこと：ヘルプデスクの記事ツールの代わりにはなりません。コンテンツブロック、公開スケジュール、確認リストは、引き続きZendeskなど、ヘルプセンターがある場所にあります。eesel は、その結果を読み取り、そこから回答するチームメイトです。
次のポリシー変更で eesel を試す
次のポリシー変更で、ヘルプセンターよりAIのほうが気が重いなら、eesel を試してください。既存のヘルプデスクにAIチームメイトとして加わり、ヘルプセンター、マクロ、ドキュメントを読み、ルール変更を普通の文章で受け付けます。顧客が返信を1通も見ないうちに、過去の実際のチケットを新ルールに対して再現テストできます。無料プランには100クレジットとすべてのインテグレーションが含まれます。
