他のアプリケーションからIntercomに移行し、履歴データを保持したいと決めたら、次は何をすべきでしょうか？
一般的なプロセス概要
ステップの説明
計画 - どのような方法で進めるかを定義します：移行の責任者、Intercomで会話とticketsのどちらを作成するか、Intercomでの連絡先の作成方法など。
Intercom設定 - マッピング作業を完了するために、少なくとも基本的な属性はIntercomで設定しておく必要があります。
マッピング - 現在のアプリケーション設定に存在するエンティティと属性が、新しいIntercom設定のエンティティと属性にどのようにマッピングされるかを定義する作業。
エクスポート／インポートスクリプト作成（このステップの最も技術的な部分） - ZendeskのエクスポートをJSONに変換するプロセスとスクリプトを作成するか、ZendeskのAPIを呼び出して連絡先とticketデータを取得し、IntercomのAPIを呼び出して会話／ticketsを作成します。
バッチテスト（UAT：ユーザー受け入れテスト） - スクリプトのv1が完成したら、一部のticketsでバッチテストを実行し、スクリプトの更新と反復を行います。
初回実行 - スクリプトが完成したら、「デルタ日付」を固定の時点として設定し、その日時までのClosed ticketsのみを収集します。これらのClosed ticketsは、起動準備ができているがまだライブではないIntercomの本番環境に移行できます。
切り替え＆デルタ - Zendeskからの切り替え準備ができたら、サポートメールをIntercomに転送したり、Intercom Messengerをライブチャット用に起動したりします。その後、デルタ日付以降にClosedになったticketsとOpen／Pendingのticketsを残りすべて移行します。
計画
最初に自問すべきは「なぜこのデータが必要なのか？」です。この答えが移行の構造とスタイルに影響します。
規制遵守のためだけにデータが必要な場合は、Intercomではなくクエリ可能なデータベースにデータを置くかどうかを検討してください。
新しいIntercomのレポートに履歴データを含めたいだけなら、データは最もシンプルな形で移行することを推奨します（メッセージ単位の移行は避ける）。重要なのは、移行後の属性値が新しいプロセスと整合し、レポートが一貫することです。
ユーザーの過去のやり取りの文脈を把握して現在の問題を解決するためにデータが必要な場合、ticketsは最もシンプルな形で移行できますが、メッセージ単位の移行が必要な場合の正当な理由となります。ただし、これによりIntercomへのAPIコール数が10〜100倍に増加することに注意してください。
上記のいずれかの理由がある場合は、Intercomへの移行を推奨します！
マッピング
なぜデータを移行するのかを確認したら、次に「どのデータをどの形式でソースシステムから移行するか？」を自問してください。
注意すべき点：
すべてのticketまたは会話は既存のuserまたはleadに関連付けられている必要があります（識別可能なエンドユーザーごとに連絡先レコードがあります）。
これらの連絡先は移行の一環として作成されるのか、それとも事前にインポートされるのか？
これらの連絡先には最低でもuser_id（あなたの製品から）またはメールアドレスが必要です。
各ソースのticket／チャットなどはIntercomのConversationとして移行されますか、それともIntercomのticketとして移行されますか？
会話とtickets：どちらを選ぶべきか？
これはスクリプト作成前に最も重要な決定の一つです。この選択は使用するAPIエンドポイント、Intercom内のデータ構造、および顧客とエージェントの表示に影響します。
会話 — Zendeskのticketsが主にカスタマーサポートのやり取り（メールやチャット）であった場合に最適です。会話はIntercom Messengerで表示され、リアルタイムのコミュニケーションをサポートします。Create conversation、Update conversation、Reply to conversation、Manage conversationのエンドポイントを使用します。
tickets — Zendeskのticketsが構造化された追跡可能なリクエスト（例：bugレポート、機能リクエスト、バックオフィスタスク）で、ライブの顧客向けスレッドを必要としない場合に最適です。ticketsには定義された状態とカスタム属性があります。Create ticket、Update ticket、Reply to ticketのエンドポイントを使用します。
一部の履歴データを会話として、一部をticketsとして移行することも可能ですが、スクリプト作成とデータ検証の複雑さを増すため、異なる構造の数はできるだけ制限してください。
Intercomでticketsと会話の両方にわたる履歴データを保持したい場合（例：ZendeskのticketsからIntercomの会話に移行しつつticket記録も保持）、各構造ごとに別々のインポートスクリプトを実行する必要があります。これはスクリプト作成前のマッピング段階で計画してください。
Zendeskからusersをインポートするには、以下の方法があります：
ZendeskからusersをCSVファイルとしてエクスポートする
IntercomのContacts > Peopleに移動し、「New Users or Leads」をクリックしてから「Import People」を選択する
CSVファイルをアップロードし、属性を適切にマッピングする
Zendeskでticketだったものが必ずしもIntercomでticketである必要はありません。チャットやメールの一時的な会話、顧客向けtickets、バックオフィスticketsなど、すべて顧客とコミュニケーションする方法があります。
作成する構造の数はできるだけ制限してください。複雑さが増すだけです。
移行する属性と、それらがIntercomのticketsおよび連絡先にどのようにマッピングされるかを特定してください。
潜在的なエッジケースを特定し、計画してください。
この段階の終わりには、移行したいすべての項目とそのIntercomでの対応が表や図で明確になっています！
重複プロフィールを防ぐために：
Zendeskのuser IDがIntercomのものと一致していることを確認する
同期を開始する前にZendeskとIntercom間の属性マッピングを定義する
移行後にCSV経由でuser IDを変更することはサポートされていません（代わりにIntercomのAPIを使用してください）
スクリプト作成
今度は実装エンジニア（IE）と計画を見直す時です。
注意：操作の順序 — APIを使って手動で移行する場合、以下の順序でステップを完了しないとインポートが失敗します：
まず連絡先を作成またはインポートします。すべての会話やticketは既存の連絡先にリンクされている必要があります。連絡先には最低でもuser_idかメールアドレスが必要です。
カスタムデータ属性（会話データ属性を含む）を作成します。これらは会話をインポートする前にIntercomに存在している必要があり、属性値が正しくマッピングされます。
会話またはticketsをインポートします。これらは参照する連絡先がIntercomに既に存在している場合にのみ作成できます。
関連する連絡先が存在しない状態で会話やticketsを作成しようとすると、エラーが発生します。
これは、スクリプトを作成する前に両者が計画を確認し、質問を明確にする機会です。
スクリプトは、関連する連絡先を事前にインポートするか、プロセスの一環として連絡先（userまたはlead）を作成するかによって変わります。
会話またはticketの作成の一般的な枠組みは次のとおりです：
Zendeskからticketの詳細を取得します。
リクエスターをIntercomのuserに検索して一致させるか、userレコードを作成して属性を更新します。
チャネルを特定して会話 / ticketを作成します。
顧客からの受信メッセージをシミュレートして会話を作成しています（Messengerでの可視性に重要）。
会話 / ticketの属性、添付ファイル、および割り当て（チームおよびチームメイト）を更新します。
顧客への送信メッセージで会話に返信するか、メモを追加します。
この返信を使って、Zendeskからの会話の全文（本文）をメッセージごとではなく投稿します。
顧客に返信し、メールチャネルの会話を作成した場合、ワークスペースがライブでないか、すべてのメール通知を抑制していない限り、これらの通知は顧客に送信されます（サポート可能です）。
会話 / ticketの状態を管理します。
すべてのクローズされたticketsは、まずこの呼び出しで開かれ、更新され、返信されてからクローズされます。ここで重要なのは、会話に作用するすべてのworkflowsが「Created via API」のトリガールールで例外を持つか、移行中に一時的にオフになっていることを確認することです。
バッチテスト
この時点で、移行スクリプトの動作バージョンが設定され、TESTワークスペースにサンプルデータの一部を移行してテストを開始できます。
これらのテスト結果を徹底的に確認し、必要に応じてIEと協力して調整してください。
Intercom Customer Implementation Servicesから移行パッケージを購入し、当社が代行している場合は、結果の検証のみをお願いし、必要な更新は当社が行います！
カットオーバー
Zendeskのオープンticketsの移行方法は、カットオーバーのタイムライン計画に影響します。
ドレインアンドフィル：
この方法では、公式ローンチ日より前にIntercomにカットオーバーし、新しいサポートリクエストはすべてIntercomに入ります。サポートチームは両方のプラットフォームで作業し、Zendeskの残りのオープンticketsがすべてクローズされるまで続けます。
Zendeskの残りのticketsをすべてクローズした後に最終移行バッチを実行します。実質的にこの方法はオープンticketsを移行せず、すべてのticketsがZendeskでクローズされるのを待ってから移行します。
ライブカットオーバー：
この方法では、チームはオープンticketsのみを含む最終移行を実行するタイミングに合わせてIntercomへのカットオーバーを同期します。
この方法はドレインアンドフィルよりもはるかに調整が必要で、オープンticketsが移行される間にすべてをIntercomに向け直す必要があります。
Zendesk関連のAPIエンドポイント（取得用）
Intercom関連のAPIエンドポイント（作成用）
移行
計画は具体的で、移行スクリプトは完成し調整済みです。さあ、データを転送する時です！
注意点：
最初の移行実行（特定日時までのすべてのクローズされたtickets）と正式なカットオーバー＋デルタ移行実行の手順の「実行手順書」（および「ロールバック計画」）を作成することが重要です。
移行されたticketsのどのコンポーネントをどこでユーザーに見せるか、受け取る通知も含めて計画を立ててください。通常、クライアントは移行中は顧客への影響や可視性を最小限にし、移行後に強化された体験を望みます。
移行完了後、徹底的な検証を行ってください：
userプロファイルが正しくマッピングされているか確認する
会話とticketの履歴が正しく転送されているか確認する
組織の詳細が正確に表現されているか確認する
CSVエクスポートまたはIntercomの管理UIを使って検証する
移行後にticketデータを検証すれば完了です！🎉