チケット履歴を失わずにヘルプデスクを切り替えるには？

まとめ

はい、チケット履歴を失わずにヘルプデスクを切り替えることはできます。そしてそれは主に技術的な問題ではなく、規律の問題です。APIを通じてすべてをエクスポートし（表示されているメッセージテキストだけでなく）、ファイルを検証し、新しいツールにインポートして、切り替える前に両方のシステムを並行稼働させてください。旧ヘルプデスクはセーフティネットとして数週間読み取り専用のまま維持しましょう。

しかし、ほとんどの「移行チェックリスト」記事が省略しているポイントがあります：多くの場合、恐れている移行は実際には必要ないのです。切り替える唯一の理由がより良いAIを得ることであれば、現在のヘルプデスクを維持し、既存のチケットでその場でAIエージェントをトレーニングできます。どちらの道を選んでも、古いチケットは冷たいアーカイブよりもAIトレーニングデータとしてはるかに価値があります。

私はここ数年、Zendesk、Freshdesk、Help ScoutなどのヘルプデスクにAIを導入するサポートチームを支援してきましたが、どんな変更の前でも最大の懸念は常に同じです：「履歴はどうなるの？」では、それをきちんと解決しましょう。

本当のリスクは移行ではなく、残していくもの

チームがヘルプデスクの切り替えを怖がっていると言うとき、UIのことをほぼ意味しません。彼らが意味するのはチケットに蓄積された年月のコンテキストです：2024年のスレッドにしか存在しない奇妙なエッジケースの返金ポリシー、常に長い説明を必要とする顧客、「注文はどこにありますか」の返信でチームが落ち着いた正確な言い回し。それが組織の記憶であり、ずさんな移行はそれを焼き尽くします。

私はこれが両側から崩壊するのを見てきました。私たちが見る最も一般的なきっかけは、チームが自ら去ることを選ぶのではなく、追い出されることです。ある半導体ハードウェアチームは、既存のAIベンダーがビジネスモデルを変更してツールからの強制移行を迫り、4つの言語で月に約250枚のチケットを抱えた状態でパニックの中私たちに相談してきました。移行があなたのスケジュール通りでないとき、「とにかく終わらせよう」という圧力は、まさに履歴が失われるタイミングです。

ですからエクスポートボタンを押す前に、実際に何を保護しているのかを明確にしてください。それは一つのことではありません。

チケットは小さなデータの束であり、返信テキストだけを取得する移行は静かにそのほとんどを失います：

• 会話 - 完全なやり取り、公開返信と顧客メッセージ、順番通りに。
• 添付ファイル - スクリーンショット、ログ、領収書。実際の問題はここに存在することがほとんどです。
• タグとカスタムフィールド - ルーティングロジックとレポートカテゴリ。これらを失うと、チケットのタグ付けとレポートがゼロからやり直しになります。
• 内部メモ - エージェント同士が残したプライベートなコンテキスト。顧客には見えないが、チームには非常に貴重。
• CSATと評価 - 過去の品質ベースライン。古いスコアを削除したら、新しい設定が良くなったかどうかわかりません。
• 監査証跡 - 誰がいつ何をしたか。規制対象チームにとって監査ログエクスポートは交渉の余地がありません。

エクスポート計画が6つすべてを考慮していなければ、チケット履歴ではなくトランスクリプトを保存しているに過ぎません。

ステップバイステップ：チケット履歴を失わずにヘルプデスクを切り替える

私たちが推奨するワークフローをご紹介します。意図的に退屈な内容ですが、それがデータを無傷に保ちます。

1. 実際に保持する必要があるものを監査する

2019年のすべてのチケットを移行する必要はありません。カットオフ日を決定し（ほとんどのチームは2〜3年分の履歴をアクティブに保持し、残りをアーカイブします）、実際にレポートしたり参照したりする上記セクションのデータタイプをリストアップします。これはナレッジベースも取得する機会です：ヘルプセンターの記事はチケットとは別にエクスポートされ、忘れがちです。例えばZendeskでは、ヘルプセンターのエクスポートと記事のインポート/エクスポートはそれぞれ独立した作業です。

2. APIですべてをエクスポートする

ヘルプデスク管理画面のCSVダウンロードボタンは罠です。通常、添付ファイルやメタデータを含む完全なスレッド形式の会話ではなく、フラットな概要が提供されます。完全なエクスポートはほぼ常にAPIから取得します。Zendeskにはまさにこのための増分エクスポートエンドポイントがあり、チケットデータのエクスポートと会話履歴専用のフローもあります。Freshdeskにはカスタムフィールドを含むチケットデータエクスポートがあります。スクリーンショット向けのバージョンではなく、構造化データを取得してください。

BIツールでもレポートしている場合、この機会にExcelまたはPower BIへのデータエクスポートのセットアップをするのに良いタイミングです。初日から分析がゼロにリセットされないようにしましょう。

3. 信頼する前に検証する

エクスポートを開いてください。本当に開いてください。チケットを数えて管理ダッシュボードと比較してください。異なる年度とカテゴリの10枚のチケットをスポットチェックしてください：添付ファイルはありますか？内部メモは？タイムスタンプは？「正常に完了した」が静かにすべての添付ファイルが消えていた移行は悪夢のシナリオであり、見て初めて気づきます。

4. 新しいヘルプデスクにインポートしてフィールドをマッピングする

フィールド名が一対一で一致することはほとんどないため、ここで最も多くの履歴が損なわれます。古い「優先度：緊急」は新しいツールでは「重要度：P1」かもしれません。インポートする前に各フィールドを意図的にマッピングし、まず小さなテストバッチ（50枚のチケット、5万枚ではなく）を実行してください。2つの特定のツール間で移行する場合、通常はZendeskからFreshdeskへの移行やZendesk ChatからMessagingへのような文書化されたパスがあります。トリガーと自動化も移行します：トリガーのエクスポートと再インポートとマクロを忘れずに行い、ワークフローが生き残るようにしてください。

5. 並行稼働させ、その後切り替える

インポートが完了した瞬間に切り替えないでください。新しいシステムが受信チケットを処理する間、旧ヘルプデスクをライブで読み取り専用のまま維持してください。数週間は、詳細を確認したりインポートが見逃したスレッドを取得するために旧システムを参照したくなるでしょう。数週間必要なくなったら、完全に切り替えても安全です。並行稼働期間は移行後の後悔に対して買える最も安価な保険です。

誰もが忘れる部分：履歴はトレーニングデータ

これは私がより多くのチームに最初に気づいてほしいことです。チケット履歴を救出するのは、それが新しいデータベースで何もしないために座っているだけのためではありません。過去のチケットはサポートAIが得られる最高のトレーニングデータです。

解決済みのチケットはそれぞれ、あなたのトーンで、実際のポリシーに対して、チームがどのように回答するかの実例です。それをAIサポートエージェントに入力すると、汎用モデルから回答を作り上げるのではなく、あなたがすでに行っているように繰り返しのティア1の質問を処理することを学びます。これは後付けで追加した機能ではありません。共同創業者の一人がデモコールの連続の後に言ったように：「また過去チケットのトレーニングが効いた。定番だ。本当に、本当に、本当に過去チケットでトレーニングしたいんだよね」。これは私たちが聞く中で最も一貫して要求される機能です、断言できます。

実践での効果を見てきました。ZendeskのマルチブランドのHealth & Wellness企業は5つの別々のAIエージェントを運営しており、それぞれ自社ブランドのチケット履歴のみでトレーニングされているので、サポートする製品を実際に理解しています。オランダの施設管理会社は解決済みチケットでエージェントをトレーニングし、サービスデスクが同じ質問への回答を繰り返すのを止め、本当に難しい問題に集中できるようにしました。アーカイブの負債として扱っていた履歴が実は資産だったとわかります。

「最初の月で、eeselはティア1リクエストの73%を解決しています。eeselは簡単なZendesk実装とセットアップを提供しています。私たちのチームは7日間のトライアル中に迅速に実装して結果を達成しました。」

Kim Simpson、Gridwise（G2認証レビュー）

まったく不要かもしれない移行

では、逆説的な部分です。ヘルプデスクを切り替える唯一の理由が「より良いAIが欲しい」なら、立ち止まって再考してください。なぜならそれは通常まったくスキップできる唯一の移行だからです。

ほとんどの現代的なAIサポートツールは、eesel AIを含め、自社プラットフォームにいることを必要としません。すでに使用しているヘルプデスクの上に重ねます。私たちはZendesk、Freshdesk、Help Scout、Frontおよび100以上のツールに直接接続し、すでに存在するチケットとドキュメントでトレーニングし、一つもエクスポートせずに下書きや解決を始めます。

それで計算がまったく変わります。完全なプラットフォーム移行は数週間のプロジェクト管理、フィールドマッピング、並行稼働リスクです。AIレイヤーの追加は分から時間で測られる接続とトレーニングの作業です。生のClaudeまたはOpenAI APIで独自のものを構築することを検討したチームがありましたが、その評決はたいていある暗号ハードウェア会社のエンジニアリングリードが言ったものと同じです：「自分たちでLLMアプリケーションを書こうとすることもできましたが、そこに時間を投資したくなかった。メンテナンスを必要としないものが欲しかった。」

ですから正直な意思決定ツリーはこのようになります。プラットフォーム自体が問題の場合はヘルプデスクを切り替えてください：遅すぎる、高すぎる、必要なチャンネルがない、またはベンダーに強制されている。AIを追加するだけのためにヘルプデスクを切り替えないでください、なぜならそれはすでにいる場所でできるからです。そしてライブカスタマーにAIを解き放つことが心配なら、それは公平です—私たちが聞く最大の反対意見でもあります。解決策はまず過去チケットでシミュレーションすることで、ライブな会話に触れる前にAIが本物の過去の会話をどのように処理したかを正確に確認できます。

懸念のあるケースについての現実確認

規制された分野にいる場合、返信ではなく監査証跡に集中すべきです。エクスポートがアクター、アクション、タイムスタンプをキャプチャしていること、そして新しいツールがコンプライアンスチームが受け入れられる形で保存できることを確認してください。

マルチブランドまたはマルチリージョンの場合、移行前にセグメンテーションを計画してください。1つのヘルプセンター内に2つのナレッジベースが必要だったり、ブランドごとに別々のエージェントが必要だったりするチームを見てきました。その要件を移行の途中で発見するのは辛いことです。まず計画を立ててください。

そして専任の運営担当者のいない小規模チームなら、並行稼働期間に大いに頼り、カットオフを控えめに保ってください。太古の昔からのすべてのチケットが必要なわけではありません。直近2〜3年を完全な状態に保ち、残りを参照できる方法が必要なだけです。切り替え前後の実際のチケット1枚当たりのコストとサポート指標を把握することで、変更が価値あるものだったかどうかもわかります。

eeselを試す

切り替えが本当に「より良いAIが必要」な切り替えなら、移行をスキップできます。eesel AIは既存のヘルプデスクに接続し、すでに持っているチケット履歴とドキュメントでトレーニングし、チームの声でティア1チケットを下書き・解決するヘルプデスクAIエージェントを稼働させます—エクスポートなし、フィールドマッピングなし、並行稼働リスクなし。

最良の点は、コミットする前に証明できることです：過去のチケットに対してシミュレーションを実行して自分のデータでの解決率を確認し、準備ができたら本番で有効にしてください。すでに持っているヘルプデスクでeeselを試す。