Zendesk移行のためのデータマッピング方法：完全ガイド

データマッピングは、Zendesk（ゼンデスク）移行の成否を分けるステップです。正しく行えば、サポートチームは中断したところから再開でき、過去のコンテキストはそのまま維持されます。間違えると、ワークフローが中断し、顧客履歴が失われ、レポートが意味をなさなくなります。

このガイドでは、Zendesk移行のためのデータマッピングプロセス全体を説明します。現在の設定の監査から最終的な転送の検証まで、チームが依存する関係性とコンテキストを維持する方法を学びます。

Zendeskへの移行が正しい選択かどうかをまだ評価している場合は、一部のチームが移行の頭痛の種を完全に回避していることを考慮してください。eesel AIのようなツールは、既存のヘルプデスクに接続して、レコードを1つも移動せずに価値を提供し始めることができます。しかし、Zendeskがあなたの目的地であるならば、データをそのままにしてそこにたどり着けるようにしましょう。

必要なもの

マッピングを開始する前に、いくつかの必需品を集めてください。

• エクスポート機能またはAPIアクセスを備えたソースシステムへのアクセス
• 管理者権限を持つZendeskアカウント
• 現在のカスタムフィールド、タグ、およびデータ構造のドキュメント
• 選択した移行方法：APIスクリプト、サードパーティサービス、または手動CSVインポート
• データの正確性を検証できる関係者

ステップ1：ソースデータを監査する

まず、自分が何に取り組んでいるかを正確に理解することから始めます。移行作業の約60％はデータの移動前に行われ、そのほとんどが準備です。Zendesk自身の移行ドキュメントによると。

現在のヘルプデスクからすべてのカスタムフィールドをエクスポートします。各フィールドのタイプ（テキスト、ドロップダウン、チェックボックス、日付、整数）、その目的、およびそれがアクティブに使用されているかどうかを文書化します。タグを生成するフィールド（ドロップダウン、複数選択、チェックボックス）に特に注意してください。これらは、ほとんどのシステムで自動化、トリガー、およびレポートを推進するためです。Zendeskのカスタムフィールドドキュメントを確認して、フィールドタイプがシステム間でどのように変換されるかを理解してください。

データ関係をマッピングします。チケットはユーザーに接続します。ユーザーは組織に属します。コメントはチケットの下にスレッド化されます。ナレッジベースの記事には、カテゴリとセクションがあります。これらの関係はデータにコンテキストを与え、それらを失うと、検索可能な履歴が、接続されていないレコードの山に変わります。

移行前にクリーンアップします。冗長、古い、または些細なデータ（ROT）を探します。重複するフィールドを統合します。何年も使用されていないタグを削除します。移行は新たに始めるチャンスなので、長年の不要物を持ち込まないでください。

ステップ2：フィールドをZendeskのデータ型にマッピングする

Zendeskには、すべてのチケットに存在するシステムフィールド（件名、ステータス、優先度、担当者、リクエスタ）と、ビジネス固有のデータをキャプチャするために作成するカスタムフィールドがあります。あなたの仕事は、ソースフィールドを適切なZendeskの同等物にマッピングすることです。

一般的なフィールドタイプの変換のリファレンステーブルを以下に示します。

タグを生成するフィールドは、特別な注意が必要です。Zendeskでは、ドロップダウンフィールドは自動的にタグを作成します（「問題タイプ」ドロップダウンから「バグ」を選択すると、タグissue_type_bugが作成されます）。これらのタグは、トリガー、自動化、およびビューを強化します。移行中にこれらをフリーテキストフィールドに変換すると、その自動化機能が失われます。

ステータスのマッピングは重要です。Zendeskは、特定のライフサイクルを使用します：新規、オープン、保留中、保留、解決済、クローズ済。ソースステータスをこれらに注意深くマッピングします。古いシステムで「解決済」とマークされたチケットは、Zendeskでは「クローズ済」ではなく「解決済」になるはずです。チケットがZendeskで「クローズ済」になると、変更できなくなり、マッピングが正しくないとワークフローが中断する可能性があります。

1つの戦略的な決定：現在の構造を正確に維持しますか、それとも移行をより良いレポートのために再構築する機会として利用しますか？正確な構造を維持すると、中断が最小限に抑えられます。再構築（類似のフィールドの統合、タグの構造化フィールドへの変換）は、長期的なレポートを改善しますが、より多くの計画とユーザートレーニングが必要です。

ステップ3：Zendeskでカスタムフィールドを作成する

マッピング計画を手元に用意して、宛先構造を構築する時が来ました。

管理センター>オブジェクトとルール>チケット>フィールドに移動します。各カスタムフィールドを作成し、フィールドタイプをソースシステムに正確に一致させます。フィールドが以前にドロップダウンだった場合は、同じオプションを使用してZendeskでドロップダウンにします。Zendeskのフィールド構成ガイドで詳細な設定手順を参照してください。

移行中はフィールドをオプションとして設定します。必須フィールドは、過去のデータが欠落している場合にインポートエラーを引き起こします。移行が完了したら、フィールドを再度必須にすることができます。

デフォルト値が意味をなす場合は、それらを使用します。ほとんどのチケットが「標準」の優先度を持つ必要がある場合は、空白のままにするのではなく、それをデフォルトとして設定します。

類似のフィールドの統合を検討してください。「製品エリア」と「製品カテゴリ」に大きな重複がある場合は、これらをマージするチャンスです。チームが必要なものを見つける場所を知っているように、変更を文書化するだけです。

ステップ4：関係の維持を計画する

データ関係は、データベースを有用なシステムに変えるものです。それぞれをどのように維持するかを計画します。

**ユーザーとチケット：**最初にユーザーをインポートし、次にチケットをインポートします。すべてのチケットにはリクエスタが必要なため、チケットがそれらを参照する前にユーザーが存在する必要があります。

**組織とグループ：**組織階層を注意深くマッピングします。ソースシステムにネストされた組織がある場合は、それがZendeskのよりフラットな構造にどのように変換されるかを決定します。

**コメントのスレッド化：**内部メモが内部に留まり、公開コメントが公開されたままになるようにします。この区別を失うと、顧客に機密情報が公開されます。

**添付ファイル：**ファイルストレージを計画します。大きな添付ファイルは、移行を遅らせ、かなりのストレージを消費する可能性があります。一部のチームは、古い添付ファイルを移行するのではなく、個別にアーカイブすることを選択します。

**ナレッジベースの構造：**Zendesk Guideは、カテゴリとセクションを使用します。既存のKB構造をこの階層にマッピングします。記事はカテゴリに直接存在することはできず、セクションにのみ存在できます。

ステップ5：実行と検証

最初にテストせずに完全な移行を実行しないでください。デモ移行を使用して、マッピングを検証します。

ほとんどの移行ツールはデモ機能を提供しています。Help Desk Migrationを使用すると、60,000件を超える移行が完了し、40,000社以上の企業向けに、20件のランダムなチケットと20件のナレッジベースの記事を無料で移行できます。2011年に設立されたImport2は、50,000人以上の顧客向けに、最大100件のチケットを含む無料のサンプル移行を提供しています。これらを使用して、完全なデータセットに影響を与える前にマッピングエラーをキャッチします。

デモでこれらの特定の要素を確認します。

• フィールド値がZendeskに正しく表示される
• チケットの割り当てがマッピングと一致する
• コメントが正しい作成者とプライバシー設定で表示される
• 添付ファイルにアクセス可能で、破損していない
• カスタムフィールドの値が期待どおりに入力される
• ステータスが正しいZendeskの状態にマッピングされる

自動化がインポートされたデータでトリガーされていないことを確認します。Zendeskのデフォルトのトリガーは、チケットが作成されたときに顧客に通知を送信する可能性があります。これは、移行中は望ましくありません。インポートする前にトリガーを無効にするか、トリガーをバイパスする移行ツールを使用します。

デモが正常に検証されたら、完全な移行をスケジュールします。タイミングが重要です。チームは、転送されない新しいデータを作成しないように、移行が開始されたら古いシステムでの作業を停止する必要があります。

避けるべき一般的なデータマッピングの間違い

他者のエラーから学び、頭痛の種を回避してください。データ移行調査によると、データの品質が低いと、組織は平均して年間1,290万ドルのコストがかかります。

• ステータスマッピングのずれ。「解決済」を「解決済」ではなく「クローズ済」にマッピングすると、チケットが変更できなくなり、フォローアップワークフローが中断します。

• **構造化フィールドをフリーテキストに変換する。**10個のオプションを持つドロップダウンは、数百のバリエーションを持つテキストフィールドになります（「高」、「high」、「緊急」、「URGENT」）。レポートは不可能になります。

• **必須フィールドを無効にするのを忘れる。**過去のデータには、現在必須のフィールドの値がないことがよくあります。移行中のオプションフィールドは、インポートの失敗を防ぎます。

• **Zendeskの28日間の自動クローズを考慮しない。**解決済みのチケットは28日後に自動的にクローズされ、120日後にアーカイブされます。レポートとアクセスニーズをそれに応じて計画してください。

• **保留中の連絡先を移行する。**Zendeskは、インポート中に保留中の連絡先を保留解除済みに変換します。最初に連絡先リストをクリーンアップしてください。

• **インライン画像と通話録音がない。**これらには、特別な処理と特定の移行オプションが必要です。標準のチケット移行では、これらをキャプチャできません。

移行ツールとサービス

移行を実行するためのいくつかのオプションがあります。

Help Desk Migrationは、デルタ移行（移行ウィンドウ中の変更をキャプチャするため）やインターバル移行（営業時間に合わせてスケジュールするため）など、最も包括的な機能セットを提供します。Import2は、50,000件未満のレコードの簡単な移行には、よりシンプルで手頃な価格です。移行を完全に回避したいチームのために、eesel AIのAIエージェントは、データを移動せずに既存のヘルプデスクに直接接続します。DIYアプローチを好む場合は、Zendeskのネイティブインポートツールを調べることもできます。

eesel AIがデータ移行を簡素化する方法

移行について言えば、最高の移行は移行しないことである場合があります。

現在のヘルプデスクが制限されていると感じるためにZendeskを検討している場合は、別のオプションがあります。すべてのデータを新しいプラットフォームに移動する代わりに、eesel AIを招待して既存の設定で連携させることができます。

Freshdesk、Zendesk、または別のプラットフォームであるかどうかにかかわらず、現在のヘルプデスクに直接接続し、既存のデータから自動的に学習します。フィールドマッピングは不要です。エクスポート/インポートサイクルはありません。ダウンタイムはありません。当社のAIは、チケット履歴、カスタムフィールド、およびナレッジベースを取り込み、すぐにチームを支援し始めます。

送信する前にエージェントが確認するAIが作成した返信から始めることができます。私たちが自分自身を証明したら、完全な自動化にレベルアップします。複雑な問題をチームにエスカレートしながら、最前線のサポートを自律的に処理します。プラットフォーム間でレコードを1つも移動せずに。

主に優れたサポート機能を得るために移行に直面している場合は、話し合いましょう。移行の頭痛の種を完全に回避できる可能性があります。

より簡単なオプションを検討する準備はできましたか？eesel AIを無料で試すか、デモを予約するして、移行の複雑さなしに現在のヘルプデスクをどのように強化できるかをご覧ください。