ヘルプデスク移行に関するアドバイスの多くは、スピードを重視しています。しかし、この包括的なヘルプデスク移行ガイドは、利便性よりも完全性を優先するチーム向けです。コンプライアンス義務を負うサポート業務、長年蓄積されたチケット履歴、そしてエージェントが業務を遂行するために顧客の状況を完全に把握する必要があるという現実的な課題など、様々な状況に対応する必要があります。
ヘルプデスクデータの完全移行は 、ワンクリックで完了するものではありません。Oracleの業界データ Oracle よると、 80% が予定期間超過または予算超過となっています。同様に、USC Dataの報告では、 83% が当初の目標を達成できていません。移行は日々の業務と長期的なコンプライアンスに影響を与えるため、最初から戦略的なプロジェクトとして取り組む必要があります。
このガイドでは、データの整合性を損なったり、対象プラットフォームで混乱を引き起こしたり、半年後に問題となるようなサポート履歴の空白を生み出したりすることなく、それを実行するための具体的な方法を解説します。成功するには、データの監査、対象プラットフォームの設定、レコードの選択、デモの実行、完全な移行の実行、結果の検証という6つの段階に従ってください。
ヘルプデスク移行における「完了」とは実際には何を意味するのか
作業を開始する前に、範囲を明確にしてください。完全なデータ移行はデータ転送操作であり、プラットフォーム構成サービスではありません。転送後にチケット数が一致していることを確認しただけでは、移行が成功したとは証明されない、というのもよくある誤解です。.
人間関係は静かに崩壊する。ここでは、完全性を確認するために考慮すべき4つの側面を紹介する。.
- 記録の完全性。 ステータス（オープン、保留中、クローズ済み、解決済み、マージ済み、スパム）に関わらず、すべてのリクエスト、スレッド、チケット類似のエンティティが記録されます。すべての顧客レコードと組織、すべてのチームメンバーとチーム構造は、対象プラットフォーム内の対応するレコードと照合されます。すべての言語バージョンのすべてのナレッジベース記事が対象となります。
- 関係性の完全性。 企業に紐づく連絡先に紐づくチケットは、それらの関係性が損なわれることなく、ターゲットプラットフォームにそのままの状態で到着する必要があります。何の繋がりもない、孤立した3つのレコードとして到着してはいけません。 Helpdesk 移行レコードの関係性は、急いで移行を行った場合に最もよく失われる問題です。
- コンテンツの完全性 とは、新しいヘルプデスクが以前のヘルプデスクと完全に一致することを意味します。移行ウィザードは添付ファイルを転送し、インライン画像を保存するため、リンクが切れることはありません。タイムスタンプを正確にマッピングすることで、会話の時系列を維持します。エージェントは初日から完全なコンテキストを利用できます。
- コンプライアンスの完全性により、 データは法的にも健全な状態に保たれます。このツールは、厳格な規制上の保存期間を満たすために履歴記録を保持します。元のタイムスタンプとシステムログを移行することで、監査証跡を完全に保持します。これにより、規制当局による審査において検証可能な履歴が提供されます。
これら4つの要件のうちいずれか1つでも満たしていない場合、移行は完了しません。データが破損している場合、進捗状況バーが100%完了していても意味がありません。.
ヘルプデスクの完全移行では何がカバーされないのでしょうか？ データ移行ツールはデータを移行しますが、設定は移行しません。
ワークフロー、SLAポリシー、ルーティングロジックは移行されません。新しいプラットフォームで手動で再構築する必要があります。移行前にこれらの作業を行ってください。そうすることで、レコードが到着した際にシステムが正しく動作します。.
チームは、新しいヘルプデスクが以前のヘルプデスクと同じように自動的に機能すると思い込んでいる場合があります。データは移行されますが、運用ロジックはそのまま残ってしまうのです。.
ロジックの再構築でお困りの場合は、弊社の導入パートナーにご相談ください。FayeFayeZendesk 、 Freshdesk、 Freshservice、 Salesforce Service Cloud。Envoy を取り扱っていますEnvoyこれらのプラットフォームに加え、 ServiceNow。GrowthDot にも対応していますGrowthDotを専門としています Zendesk、 Freshdesk、 Intercom、 Jira。Aktie Aktie Now北米、ラテンアメリカ、ヨーロッパ、中東全域でエンドツーエンド Zendesk 導入に注力しています。各パートナーは、お客様の構成ニーズを把握し、新しいプラットフォームを以前のプラットフォームと同じように稼働させることができます。
フェーズ1：まずソースプラットフォームを監査する
移行では、データは現状のまま転送されます。整理されていないソースプラットフォームからヘルプデスクデータを完全に移行すると、移行先のプラットフォームは完全ではあるものの、整理されていない状態になります。データ探索とデータクレンジングを省略したチームは、本番稼働後にエラーのトラブルシューティングに2倍の時間を費やすことになります。包括的なデータ探索フェーズにはプロジェクト予算の5～10%が必要ですが、USC Dataの調査によると、一般的な移行失敗の50%以上を防ぐことができます。このフェーズは完全な helpdesk 、データ損失のない移行を実現するために不可欠です。
レコードの種類と量を一覧する
転送を開始する前に、すべてのレコード数を数えてください。この数は、最終的な移行後チェックにおける検証基準となります。.
以下の項目を記録してください。
- チケットのステータス別分類：オープン、保留中、クローズ済み
- 連絡先と企業
- 言語バージョン別のナレッジベース記事
- 添付ファイル
- カスタムフィールドタイプ
この在庫情報をエクスポートしてください。フェーズ6で、移行後のレポートと比較します。.
移行前にデータ品質の問題を特定し、修正する
他の作業を行う前に、まずソースプラットフォーム固有の移行前チェックリストを確認してください。移行後に発生する最も一般的な問題は、重複した連絡先、チケット間の関連付けの破損、孤立したレコードなどです。まずはクリーンアップを行い、次に移行してください。.
実行前に修正すべき3つの事項：
- 重複する連絡先を統合します。 顧客1人につき、レコードは1つです。重複があると、関係性の完全性が損なわれ、移行後に混乱が生じます。
- 重複するタグを標準化しましょう。billing_issue 、billing-problem、billingなどの類似タグを1つのラベルに統合してください。タグが統一されていないと、対象プラットフォームでのレポート結果が歪んでしまいます。
- 不要なデータを削除します。 無効化された自動化設定、空のカスタムフィールド、未使用の定型応答を削除してください。これらは移動時に保持する必要はありません。
データ移行は、データ品質の問題を露呈させます。事前にソースデータのプロファイリングとクレンジングを行わないと、後で予期せぬエラーが発生する可能性があります。この作業に費やす時間は、ヘルプデスクの移行が完了した後に問題解決に費やす時間よりも常に短くなります。.
コンプライアンス上のデータ保持義務を明確にする
移行またはアーカイブする記録を決定する前に、法的保存要件を明確にしてください。.
| 規制 | 最低保存期間 | コンプライアンス重視 |
|---|---|---|
| HIPAA | 作成または最終使用から6年 | 保護された医療情報 |
| ホワイトソックス | 7年 | 財務および監査記録 |
| PCI DSS | 利用可能期間1年（うち3ヶ月は即時利用可能）、合計3年間 | カード所有者データ環境 |
| GDPR 第20条 | データポータビリティは保証されていますが、ユーザビリティは保証されていません。 | データへのアクセス権と消去権 |
HIPAA 準拠のヘルプデスク移行では、 転送を開始する前に、どのチケットが特定の義務に該当するかを特定する必要があります。GDPR Helpdesk 準拠のヘルプデスク移行 GDPR 、データインポート前に、削除要求や保持期間の上限を超えるレコードを削除する必要があります。
フェーズ2：移行前の設定
ターゲットプラットフォームを正しく設定することで、データ移行全体を保護できます。
データは孤立して存在することはできません。すべてのチケットは、正しくロードされるために特定のフレームワーク（割り当てられた所有者、有効なステータス、および一致するカスタムフィールド）を必要とします。このフレームワークが欠けている場合、APIはレコードを拒否します。
移行を保護するためには、移行を実行する前に次の3つの設定手順を完了する必要があります。
対象プラットフォームで自動化とトリガーを無効にする
アクティブなヘルプデスクは、トリガーと時間ベースのルールを使用してワークフローを自動化します。インポート中にこれらをアクティブなままにしておくと、ターゲットシステムは受信した過去のチケットをまったく新しいイベントとして扱います。.
このシステムは、数年前にクローズされたチケットについても、顧客に自動通知メールを送信します。また、SLAタイマーを即座に超過し、過去のレポート指標を破損させます。.
プラットフォームによっては、インポート中に自動的に通知が停止する機能があります。これは、新しいヘルプデスクに組み込まれたスイッチのようなものだと考えてください。プラットフォームは大量のデータインポートを認識し、インポートが完了するまで通知システムを自動的に停止します。ご自身のプラットフォームでも同様の機能があるかどうか、事前に確認してください。.
移行チームに、お使いのプラットフォームの組み合わせがリクエストレベルの通知抑制をサポートしているかどうかを確認してください。サポートしている場合は、実行前に有効にしてください。.
対象プラットフォーム上にすべてのカスタムフィールドを作成します。
カスタムフィールドのランクを指定しないことは、非常によくある設定ミスです。対象システムに存在しないフィールドを指定すると、エラー警告が表示されることなくデータが静かに削除されてしまいます。.
カスタムフィールドのヘルプデスクレコードを正しく移行するには：
- 対応するフィールド名をマッピングしてください。.
- 開始する前に、ターゲットにすべてのカスタムフィールドを作成してください。.
- 移行ウィザードを使用して、ソースフィールドをターゲットフィールドにマッピングします。.
移行ウィザードを使用して、カスタムフィールドを直接作成できます。これはデモ移行の前に行ってください。移行後に行わないでください。.
マッチエージェント
エージェントが一致しないと、チケットが未処理のままになります。エージェントが新しいシステムにアカウントを持っていない場合、チケットは所有者不明のまま届きます。これを回避するには、両方のプラットフォームで同じメールアドレスを使用し、移行ツールが自動的に照合するようにしてください。.
退職者については、レコードを空白のままにせず、汎用受信トレイまたはアクティブなエージェントにマッピングしてください。または、移行ウィザードの設定でデフォルトのエージェントを選択して、未割り当てのレコードを捕捉してください。
フェーズ3：移行対象の選択
ヘルプデスクのデータを完全に移行するには、オブジェクト選択画面のすべてのチェックボックスを選択する必要があります。.
それぞれの物が何を表しているのか、なぜそれが必要なのか、そしてそれを手放すとどうなるのか、以下に説明します。.
すべてのチケット
デフォルトでは、移行ツールはステータス（オープン、保留中、クローズ済み、解決済みなど）に関わらず、すべてのチケットを転送します。転送対象を特定のステータスに限定したい場合は、フィルターを適用して範囲を絞り込むことができます。ただし、例外なくすべてのステータスを移行することを強くお勧めします。.
クローズされたチケットには、過去の顧客とのやり取りの履歴が保存されています。エージェントは、過去の 顧客とのやり取り、エスカレーションを管理したり、コンプライアンス監査の証拠を提供したりするために、これらのチケットを毎日参照します。ステータスグループを除外してもストレージ容量は大幅に削減されませんが、レポートの精度と検索機能が著しく低下します。
すべてのチケット履歴を新しい helpdeskに移行する際は、明確な理由が文書化されていない限り、ステータスフィルターを適用しないでください。.
すべての連絡先と関係のある企業
チケットは、関連付けられた連絡先がないと移行できません。すべてのチケットは、移行先のプラットフォームの連絡先レコードにリンクされている必要があります。リンクがない場合、チケットは所有者や顧客の識別情報がない状態で移行されます。.
企業はチケットに直接紐づけられるのではなく、連絡先に紐づけられます。関係性は「企業 → 連絡先 → チケット」という流れになります。企業との関連付けなしに連絡先を移行すると、B2Bサポートチームのアカウントレベルのコンテキストが損なわれます。エージェントは連絡先がどの組織に属しているかを把握できなくなるため、アカウント管理やエスカレーション処理が著しく困難になります。.
連絡先と企業情報を、すべての関係性を維持したまま一括して移行してください。関係性が損なわれた連絡先リストは、単なるアドレス帳であり、サポート履歴とは言えません。.
すべての言語バージョンのナレッジベース記事
ナレッジベースを言語ごとに移行する場合は、公開済みの記事、下書き、カテゴリ、サブフォルダをすべて一度に選択してください。記事を言語ごとに別々に移行しないでください。すべてのバージョンをまとめて移動することで、異なる言語オプション間の構造的なつながりが維持されます。
記事間の相互リンクを更新するオプションを有効にします。この機能は内部URLを自動的に書き換え、すべての参照先が対象プラットフォーム内の正しい場所を指すようにします。.
チームは時間を節約しようとして、記事を手作業でコピー＆ペーストしようとすることがよくあります。しかし、このミスは数週間にも及ぶ面倒な作業につながります。さらに、画像パスや内部リンクが壊れてしまい、検索エンジンのランキングにも悪影響を及ぼします。.
添付ファイル、インライン画像、コメント
helpdesk 添付ファイルとコメントを正しく移行するには、開始する前に次の3つの点を確認してください。.
- 新しいプラットフォームにすべてのファイルを受け入れるのに十分な空き容量があることを確認してください。 移行中にストレージ容量の上限に達すると、転送が停止し、システムエラーが発生します。
- インライン画像をソースプラットフォームへの参照として残すのではなく、添付ファイルとして移行してください。 インライン画像はソースシステム上でホストされ、ソースベースのURLを使用します。
- ソースプラットフォームを廃止すると、これらのURLは解決されなくなり、すべてのインライン画像が破損したアイコンになります。 添付ファイルとして移行することで、ファイルはターゲットプラットフォームに再ホストされ、切り替え後もアクセス可能な状態が維持されます。
- 完全移行を実行する前に、プライバシー設定を確認してください。 この設定により、レコードが到着した際に、顧客から内部コメントが非表示になります。
添付ファイル、インライン画像、コメントを移動する際、チームはストレージ容量を節約したり、作業時間を短縮したりするために、しばしば手抜きをしがちです。よくある3つの手抜きミスを避けましょう。
- 古いプラットフォームを廃止する際に、画像アイコンが破損するのを避けるため、インライン画像を生のHTMLリンクとして残さないでください。.
- エージェントが繰り返し発生する問題を解決するために必要な重要なコンテキストを失わないように、大容量の添付ファイルや過去の添付ファイルは除外しないでください。.
- エージェントの内部的な非公開メモが顧客に直接公開されるのを避けるため、コメントの表示設定のテストは必ず行ってください。.
カスタムフィールドとその値
カスタムフィールドの種類ごとに、特定のマッピング方法が必要です。.
- テキストと数字： 単純な1対1対応。
- 複数選択とドロップダウンリスト： ツールを実行する前に、対象プラットフォームですべてのオプションを再作成してください。
- 日付： 両アプリケーション間でフォーマットの互換性を確認してください。
- チェックボックス： 真偽値を対応するターゲット状態に一致させます。
- 欠損データ： 空のレコードを含むフィールドにデフォルト値を割り当てます。
転送を実行する前に、ターゲットフィールドを設定してください。コンテナが存在しない場合、移行ウィザードはデータを移動できません。また、両方のプラットフォームで同じ日付レイアウトが使用されていることを確認してください。フォーマットが一致しない場合、APIはチケット全体を拒否します。.
フェーズ4：デモ移行とフィールドマッピングの検証
すべての移行は、まず試用サンプルを通して実行する必要があります。デモ移行は、オプションの形式的な手順ではなく、必須の安全対策です。このツールは、約20件のチケットとナレッジベース記事、およびそれらに関連する連絡先、エージェント、添付ファイルといった、代表的な小規模サンプルを移行します。このテスト実行により、本格的なデータ転送を実行する前に、データの動作を検証できます。.
実用的なデモの実行方法 マイグレーション
移行ツールによるサンプル実行が完了したら、データマッピングレポートをダウンロードし、新しいプラットフォーム上のレコードを手動でスポットチェックしてください。.
デモでは、この helpdesk 移行データ検証チェックリストを使用してください。
- 会話の順序： スレッドの空白がなく、正確な時系列順になっていることを確認してください。
- カスタムフィールドの値： すべての値が正しい属性にマッピングされていることを確認します。
- 添付ファイル： ファイルを開いて、アクセス可能で破損していないことを確認してください。
- 内部メモ： プライベートなコメントは顧客から非表示のままにしておくこと。
- 連絡先： チケットが正しい顧客および企業プロファイルにリンクされていることを確認してください。
チェックリストでデータ破損が判明した場合は、最終転送に進まないでください。このツールは無料かつ無制限のデモ実行機能を提供しているため、出力が正常になるまでマッピングを調整して再テストできます。.
フェーズ5：データ完全移行
ヘルプデスクデータの完全移行中も、チームは引き続きソースプラットフォームで作業を行います。移行後の検証が完了するまで、チームはレガシーシステムを使用し続けてください。.
完全な移行を開始する
開始ボタンをクリックする前に、以下の5つの記述すべてが正しいことを確認してください。いずれか1つでも誤りがある場合は、作業を中断して問題を解決してから先に進んでください。.
- 対象プラットフォームにはカスタムフィールドが存在します。.
- 各エージェントプロファイルは、ターゲットアカウントまたは指定されたデフォルトユーザーにマッピングされます。.
- 対象システムの自動化、トリガー、および通知は完全に無効化されています。.
- デモ移行はすべての検証チェックに合格しました。.
- ソースヘルプデスクから完全なデータバックアップをダウンロードしました。.
大規模データセット向けの高度なスケーリング
大量のレコードを移動する場合は、以下の2つのアーキテクチャ機能を使用してAPI制限を管理してください。なお、これらの機能はSignatureプランでのみ利用可能です。.
- インターバルマイグレーションは、業務のピーク時間帯にデータ転送を一時停止し、夜間または週末に処理を再開します。これにより、稼働中の業務を保護し、APIクォータの枯渇を防ぎます。.
- マルチスレッド移行では、複数の並列データスレッドを同時に実行することで、ターゲットプラットフォームのAPIを最大スループットまで引き上げます。転送速度は、ターゲットプラットフォームのプランティアに大きく依存します。これは、厳しい期限内にヘルプデスクのデータ移行を完了させるための最速の方法です。.
Delta Migrationは、切り替え時の変更点を捕捉します。
デルタ 移行では、 完全移行開始後にソースプラットフォームに表示された新規レコードまたは変更されたレコードがすべてコピーされます。デルタ移行を実行する前に、チームを新しいヘルプデスクに移動しないでください。プラットフォームを早々に切り替えると、完全移行期間中に作成されたすべての顧客とのやり取りが失われてしまいます。
知っておくべき2つのこと：
- データ転送が完了してから10日以内に、デルタ移行を実行する必要があります。.
- Deltaへの移行は、Signatureプランでのみご利用いただけます。.
フェーズ6：移行後の検証
進行状況バーが100%に達したからといって、移行が完了したわけではありません。検証によって、すべてのチケット履歴とカスタムフィールドが正しい場所に移行されたことが確認されます。すべてのレコードを検証するまで、既存システムを稼働させたままにしてください。.
記録件数の照合
最終データ照合レポートをダウンロードしてください。フェーズ1で作成した移行前のベースラインと、目標値を直接比較してください。
- 移行済みチケット総数と移行元チケット数の比較
- 移行された連絡先および企業プロファイルの総数とソース数の比較
- 言語バージョンごとの移行済みナレッジベース記事数とソース数の比較
従来のヘルプデスクを停止する前に、統計上の不一致を調査し、解決してください。.
KB記事の検証
helpdesk 移行に関するナレッジベースコンテンツのデータ検証チェックリスト：
- すべての記事は、あらゆる言語オプションで利用可能です。.
- ターゲットプラットフォームは、あなたのフォルダとカテゴリの構造を忠実に再現します。.
- ハードコードされたURLを新しいプラットフォーム構造に合わせて更新すると、すべての内部ハイパーリンクが正しく機能するようになります。.
- テキスト内に埋め込まれた画像は正しく表示されます。.
- 下書き記事は自動的に公開されず、下書き状態のままになります。.
専門サービスを利用するタイミング
自動化された移行ウィザードは、標準的なデータ移行には最適です。しかし、大規模なプロジェクトや複雑な database 構成では、データ損失やダウンタイムを避けるために手動での対応が必要です。
ここでは、セルフサービスツールでは対応できない4つのシナリオ、手抜きをすることのリスク、そしてそれらへの対処法について説明します。
シナリオ1：複数のヘルプデスクを統合する場合
買収後に2つ以上のプラットフォームを統合すると、データの重複が大量に発生します。連絡先プロファイルの重複を排除し、異なるシステム間で競合するカスタムフィールドを解決する必要があります。
一部の管理者は、 databaseを順次インポートする方法を選択しますが、これはアクティブなユーザープロファイルを上書きし、重複した顧客アカウントを作成することになります。
シナリオ2：複雑なカスタムフィールドの依存関係がある場合
非標準データ型、複数のプロジェクトにまたがる一括移行、条件付きフィールドは、標準のマッピングテンプレートを迂回します。
一部のチームは、複雑なリレーショナルデータを標準の自由記述フィールドに無理やり押し込もうとします。しかし、新しいシステムはネストされたデータ構造を解釈できないため、これはデータ損失を静かに引き起こします。
シナリオ3：規制監査証跡が必要な場合
厳格なコンプライアンス体制では、企業はインフラ変更時にすべての顧客記録について正式な保管管理記録を提供することが求められます。
一部のチームは基本的な自動化ツールのログに頼ろうとしますが、これらは厳格なコンプライアンス監査に合格することはほとんどありません。
結論：データ移行は単一のエクスポートではなく、6段階のプロセスである。
ヘルプデスクのデータ移行は、6つの段階に分けて実施されます。その理由は単純です。移行初日からデータを保護し、サポートチームの業務を中断することなく継続させ、エージェントに正確な記録を提供するためです。.
手順が固定されているのは、最初のステップでフィールドのマッピングと基盤構築を行い、後のステップで実際の処理を行うためです。この手順に従うことで、テストされていないシステムにデータを投入してしまうことを回避できます。.
フィールドの動作を確認したいですか？ 無料のデモ移行を開始して、 マッピングウィザードが実際のチケットや記事をどのように処理するかを、導入前にご確認ください。
複雑なシステム構成でお困りですか？ 弊社の専門サービスについて、ぜひご相談くださいを明確にするお手伝いをいたします database サービス開始前に、
ヘルプデスクの完全な移行が現在のスケジュールに合わない場合は、他の戦略を検討してください。より迅速な切り替えをご希望の場合は、エクスプレス移行ガイドをご覧ください。自動化に重点を置きたい場合は、 AIファースト移行ガイドをご覧ください。
Help Desk Migration よくある質問
処理にかかる時間は、レコード数とプラットフォームの組み合わせによって異なります。5万件未満の小規模データセットは通常1～3日で完了します。10万～50万件の大規模 databaseは1～2週間かかる場合があります。データセットの正確な所要時間を知るには、無料のデモ移行を実行してください。.
いいえ。各ヘルプデスクは独自の内部ID構造を使用しているため、新しいプラットフォームはインポート時に新しいIDを生成します。このツールは、件名、タイムスタンプ、会話スレッドを完全に保持します。移行後のレポートをダウンロードして、古いIDと新しいIDを照合できます。.
はい、ただし、まずターゲット環境をセットアップする必要があります。転送を開始する前に、新しいヘルプデスクでカスタムフィールドをすべて作成してください。移行ウィザードでフィールドマッピングを確認し、デモを実行してデータが正しい場所に配置されることを確認してください。.
GDPR 第20条は構造化された形式でのデータポータビリティを義務付けており、第17条は消去要求への対応を規定しています。消費者の権利を保護するため、リレーショナルデータ構造を維持する移行ツールを使用してください。データ転送前に、保持ルールを超えるレコードは削除してください。コンプライアンス義務を網羅するため、移行プロバイダーとデータ処理契約を締結してください。.
移行ツールは、添付ファイルとインライン画像を親チケットと一緒に移動するため、アクセス可能な状態が維持されます。転送後、10～20個の添付ファイルを抜き取りチェックして、正しく開くことを確認してください。特に大きなファイルを移行する前に、新しいプラットフォームのファイルサイズ制限を確認してください。.
はい。自動化エンジンはソフトウェアベンダーによって全く異なるロジックを使用しているため、自動的に移行することはできません。作業を開始する前に、現在の業務ルールを文書化してください。多くのチームは、古いルールの最大40%がすでに時代遅れになっていることに気づきます。そのため、移行はワークフローを整理する絶好の機会となります。.
