返信を見逃さずに Zendesk® インスタンスをマージまたは分割する
Zendesk® から Zendesk® への移行

返信を見逃さずに Zendesk® インスタンスをマージまたは分割する

データ損失、ダウンタイム、運用中断なしに、 Zendesk® から Zendesk® への移行を実現します。買収後の統合、ブランド、地域、コンプライアンス要件に基づく環境の分離など、どのような場合でも、このデータ移行アプローチは、エージェントの業務継続と顧客への返信提供を円滑に行うように設計されています。.

相談を予約する →

クレジットカードは不要です 素早いセットアップ

40,000社以上の企業から信頼されています

Zendesk® インスタンスを統合または分割する理由

組織は、合併・買収、内部統合、または複数のシステムを維持するコストを削減する場合などに、 Zendesk® アカウントを統合します。.

チームが Zendesk® インスタンスを統合することを選択するのは、次のような場合です。

別の会社を買収したため、エージェントが履歴情報を完全に保持したまま閲覧および返信できるように、 Zendesk® アカウントを統合する必要があります。.

Zendesk® インスタンスの統合後、チームはすべてのサポート機能にわたって、共通の可視性と統一されたレポートダッシュボードを必要とします。.

複数の Zendesk® インスタンスを使用すると、ワークフローの重複、自動化の冗長化、レポートの精度低下につながります。.

Zendesk® インスタンスを統合することで、チームは重複するワークフローを排除し、自動化の乱立を抑制し、SLA管理を一元化すると同時に、過去のデータを保持し、業務の中断を最小限に抑えることができます。.

ブランド、地域、またはコンプライアンス上の義務によって独立性が求められる場合、 Zendesk® インスタンスの分割は不可欠となります。.

チームが Zendesk® インスタンスを分離するのは、次のような場合です。

部門間または地理的地域間でワークフローまたは SLA が競合します。.

チームには、地域の規制やコンプライアンスの要件を満たすための運用の自律性が必要です。.

顧客向けのサポート エクスペリエンスには、個別のレポートまたはブランディングが必要です。.

この管理された Zendesk® 移行アプローチにより、ワークフローの競合、チケットの誤配、レポートエラーが削減されると同時に、各部門やブランドが必要とする自由度が確保されます。.

Zendesk® から Zendesk® への移行がリスクを伴うと感じる理由(そして、そのリスクを排除する方法)

Zendesk® から Zendesk® への移行は、可視性や検証なしに行うとリスクが高いと感じられる。.

リスク: 重要なデータの損失

チケット、添付ファイル、プライベートメモ、通話録音、履歴情報が失われるかもしれないと考えるだけで、チームは躊躇してしまいます。一度の誤クリックで取り返しがつかなくなるかもしれません。.

Help Desk Migration 処理方法:

当社のデータ移行サービスは、すべてのチケット、添付ファイル、会話が正確に移行されることを保証します。デモ移行では、実際のデータが安全に移行される様子をご確認いただき、実際に移行を確定する前にご確認いただけます。何も残らず、何も壊れません。.


リスク: ダウンタイムとサポートの中断

エージェントは引き続き業務を行い、顧客からの返信も継続します。Zendesk®インスタンス Zendesk® 統合中にサポート業務が中断されることは許容されません。.

Help Desk Migration 処理方法:

Zendesk® データ移行はすべてバックグラウンドで実行され、 Zendesk® 稼働状態を維持します。差分移行中は新しいアクティビティを移行できるため、サポートが中断されることはなく、SLAもそのまま維持されます。.


リスク: ワークフローの中断、チケットの誤ルーティング、マッピングの誤り

ブランド、フォーム、担当者、ステータスが間違っていると、 Zendesk® インスタンスの統合中にチームの作業が滞り、混乱、意思疎通の誤り、報告エラーが発生する可能性があります。.

Help Desk Migration 処理方法:

移行ウィザードは、チケット、ユーザー、カスタムフィールド、マクロ、トリガーを正確にマッピングするのに役立ちます。チケットの統合、フォローアップ、一時停止中のユーザーといったエッジケースも自動的に処理されます。すべてのマッピング手順を検証することで、リスクをゼロに抑えます。.


リスク: コスト、報告の継続性、歴史的背景

移行するデータが多すぎるとコストが増加する可能性があります。Exploreレポートはデフォルトでは移行されません。添付ファイル、スクリーンショット、メモが失われる可能性があります。.

Help Desk Migration 処理方法:

当社のデータ移行サービスでは、チケットとデータをフィルタリングし、レポートの整合性を維持し、関連するすべての履歴詳細を取得できます。スコープとコストをコントロールできます。.

かつてはリスクが高いと感じられたことが、予測可能で安全、かつ可逆的なものへと変わります。エージェントは業務を継続でき、顧客は引き続き返信を受け取ることができ、経営陣は Zendesk® から Zendesk® への移行が成功するという確信を得られます。.

Help Desk Migration デモでは、問題が発生する前に、それがどのように機能するかを推測するのではなく確認できます。.

クレジットカードは不要です 素早いセットアップ

Zendesk® から Zendesk® への移行の仕組み

準備 · マッピング · テスト · 運用開始 · 検証

準備する

Zendesk® から Zendesk® への移行を成功させるには、綿密な準備が不可欠です。

  • ビジネス要件に基づいて、対象となる Zendesk® インスタンス(統合または分割)を選択します。.
  • 意図したアーキテクチャに合わせて、ブランド、フォーム、グループ、SLA を調整します。.
  • ソース側とターゲット側の両方の Zendesk® インスタンスに対して、管理者レベルのアクセス権があることを確認してください。.
  • 移行範囲を定義します: 全履歴、または最近のオープンチケットのみ。.
  • 依存関係を含むすべてのカスタム フィールド、マクロ、トリガー、自動化をインベントリします。.
  • アーカイブされたチケット、マージされたチケット、一時停止されたユーザー、およびカスタム処理が必要な可能性のあるエッジケースを識別します。.

地図

マッピングは、移行後のデータの動作を正確に定義します。

  • チケット: ステータス、ブランド、フォーム、担当者。.
  • ユーザーと組織: 重複排除、複数企業の関連付け、一時停止されたユーザーの処理。.
  • カスタム フィールド: ドロップダウンの正規化、タグの動作、および複数フォーム フィールドの処理。.
  • ルール: マクロは完全に移行されます。自動化は移行中に無効になり、手動で再度有効になります。.

テスト

テストにより正確性を確認し、信頼を構築します。

  • マルチブランド チケット、統合されたユーザー、フォローアップなどのエッジ ケースを含む 20 件の実際のチケットを移行します。.
  • 会話、添付ファイル、カスタム フィールド、ステータスの一貫性を確認します。.
  • 結果に基づいてマッピングを調整し、必要に応じてデモ移行を再実行します。.
無料デモを始める

稼働開始

フル移行は、ソースとなる Zendesk® 稼働状態を維持したまま実行されます。

  • デルタ移行は、カットオーバー中に新しい返信とエージェントの更新を移動するのに役立ちます。.
  • エージェントはワークフローを継続し、顧客はサポートを受け続けます。.
  • 移行はバックグラウンドで実行され、完全な運用継続性が維持されます。.

検証

これは、セルフサービスのギャンブルではなく、管理された顧客サービス データ移行プロセスです。

  • チケットとユーザー数を調整して、すべてのデータが正しく移行されたことを確認します。.
  • レポート データはデフォルトでは移行されないため、Explore レポートを再構築します。.
  • 予期しないトリガーを防ぐために、自動化を意図的に再度有効にします。.
  • コンプライアンスまたは記録保持のニーズに合わせてソース インスタンスをアーカイブします。.
  • これは、セルフサービスのギャンブルではなく、管理された顧客サービス データ移行プロセスです。.
サポートされているプラ​​ットフォーム
データマッピング
無料デモ移行
完全移行
結果を確認する

Zendesk® から Zendesk® への移行でよくある問題に当社が対応いたします。

問題 1: 非アクティブまたはデフォルトのブランドが誤ルーティングの原因となっている

問題:

ソースインスタンス上の非アクティブなブランドは、ターゲット上で選択されたブランドにデフォルト設定され、ブランド間でチケットが混在する可能性があります。.

解決:

Help Desk Migration サービスは、要件に応じて非アクティブなブランドをフィルタリングしてマッピングし、チケットが混乱なく正しいブランドに届くようにします。.


問題2: ドロップダウンフィールドが不要なタグを生成する

問題:

複数のチケット フォームにわたるドロップダウン フィールドでは、移行後に不要なタグが作成されることがあります。.

解決:

マッピングをカスタマイズして無関係なフィールドを削除し、オプションでコンテンツの自動タグ付けを無効にして、タグのノイズを削減します


問題3: アーカイブされたチケットがビューに表示されない

問題:

アーカイブされたチケットはシステム内に存在しますが、デフォルトのビューには表示されないため、「チケットが失われた」という懸念が生じます。

解決:

アーカイブされたチケットはすべてデータ移行に含まれており、ID 検索またはワイルドカードを使用して確認する方法をご案内します。.


問題4: 解決済みチケットとクローズ済みチケットの不一致

問題:

解決されたチケットは28 日後に自動的に閉じられる、ステータスの追跡に影響します。

解決:

Zendesk® 自動化動作を考慮し、チケットのステータスをマッピングすることで、過去の記録の正確性を維持しながら、将来の自動化を制御できます。.


問題5: タイムゾーンの違い/UTC変換

問題:

API は UTC を使用するため、移行後にチケットのタイムスタンプが 1 時間ずれて表示される場合があります。.

解決:

当社のサービスはタイムゾーンの正規化を処理し、移行後の検証を提供して、タイムスタンプがチームのローカル設定と一致することを確認します。.


問題6: ライトエージェントの制限

問題:

ライトエージェントは、クローズされたチケットを所有したり、パブリックコメントを投稿したりできないため、割り当て内でのチケットの表示方法が制限されます。.

解決:

ライトエージェントのチケットとコメントを適切なエージェントに事前にマッピングし、説明責任のギャップを回避します。.


問題7: IP制限または接続エラー

問題:

ソースまたはターゲットの Zendesk® インスタンスが特定のIPアドレスを制限している場合、移行ツールが失敗する可能性があります。.

解決:

IP ホワイトリストと安全な構成をガイドします


問題8: Zendesk® 検索インデックスの不一致

問題:

検索に基づくチケット数は実際のチケット数と一致しない場合があります。.

解決:

Help Desk Migration ウィザードは API データを介してカウントを検証し、必要に応じて再インデックスの支援を行います。.


問題9: カスタムチケットステータス

問題:

一度にマッピングできるのは、カスタム ステータスまたはデフォルト ステータスのみです。.

解決:

カスタム ステータスを無効にしてアカウントを再接続し、正しいチケット ステータスのマッピングを確実に行うようクライアントに指導します。

Zendesk® から Zendesk® への移行の成功事例

UrbanYouはアカウント統合後、20万件以上のチケットを保存しました

業界:

家庭サービス

問題:

UrbanYouは買収後、20万件を超える過去のチケット、連絡先、添付ファイル、メモ、ナレッジベースコンテンツを、古い Zendesk® アカウントから新しく作成されたアカウントに移行する必要がありましたが、 Zendesk®のネイティブツールでは十分な詳細情報が保持されませんでした。.

解決方法:

UrbanYou は無料のデモ移行を実施してチケットの整合性を検証し、その後、専門家のサポートによる各ステップのガイドを受けながら完全に自動化された移行を実行しました。.

結果:

チケット、添付ファイル、メモなどのすべての過去のサポート コンテキストがシームレスに移行され、エージェントは中断することなく顧客履歴にすぐにアクセスできるようになりました。.


「 Help Desk Migration を使って Zendesk® データを移行したのですが、全く問題なくスムーズに移行できました。」

ノガ・エデルシュタイン
UrbanYou 共同創設者

ノガ・エーデルシュタイン

ローランド株式会社は、グローバルサポートプラットフォームの複雑なインスタンス統合を実施しました。

業界:

電子機器と楽器

問題:

ローランドは、サポート業務を統一するために、地域ごとの Zendesk® インスタンスから顧客サービスデータをグローバルな中央インスタンスに統合する必要がありました。この作業には、チケット、連絡先、企業、エージェント、グループなどが含まれます。.

解決方法:

Help Desk Migration 自動化された移行プロセスとカスタマイズされた移行プロセスを組み合わせて適用し、主要なエンティティを慎重にマッピングし、アカウント間でワークフロー構造を維持しました。.

結果:

高度な Zendesk® から Zendesk® への統合が成功裏に完了し、すべての重要なデータが保持され、サポートの継続性が維持されました。.


正直に言って、この会社の対応の速さには本当に驚きました。「寝てるの?」と不思議に思うほどです。タイムゾーンを考慮しても、ほぼすべての質問に対し、毎回数時間以内に回答をもらうことができました。

ポール・マッケイブ
ローランド株式会社 グローバルカスタマーエクスペリエンス担当副社長

ポール・マッケイブ

Ozonics LLCは、機能的な Zendesk®への夜間移行を完了しました。

業界:

アウトドア/消費財

問題:

Ozonics LLCは、既存のサポート体制を Zendesk® に迅速かつ確実に移行し、翌営業日までに完全に稼働させる方法を必要としていました。.

解決方法:

Help Desk Migration チームは、デモと本格的な移行をOzonics社に案内し、Ozonics社が Zendesk® 事前設定して、夜間に移行作業を実行できるようにしました。.

結果:

翌朝までに、 Zendesk® すべての履歴データを含めて完全に機能するようになり、ダウンタイムや手動での再入力作業は不要になった。.


「移行は計画通りに進み、転送されたデータに問題は見つかりませんでした。」

ステイシー・ヒッペン
Ozonics LLC オペレーションディレクター

ステイシー・ヒッペン
移行に関するチームディスカッション

ヘルプセンター(ナレッジベース)の移行

Help Desk Migration 機能は、プラットフォームの制限事項を考慮しながら、記事、翻訳、階層構造、添付ファイル、メタデータを Zendesk® ヘルプセンター間で転送します。完全かつエラーのない移行を実現するために、以下のガイドラインに従ってください。.

API ユーザーに必要な権限がない場合、移行は失敗します。
  • すべてのヘルプセンターコンテンツにはガイド管理者のロールが必要です。.
  • 移行されるすべてのブランドへのアクセス。.
  • 言語とロケールを管理する権限。.
  • 移行が必要な場合にアーカイブされた記事や下書き記事を表示するためのアクセス権。.

  • 各ブランドは、そのブランド URL を使用して個別に移行する必要があります。.
  • 複数ブランドの移行はサポートされていますが、個別に追跡されます。.
  • 異なるブランドの記事がスラッグまたは ID を共有している場合、競合を防ぐために移行中に名前が変更されます。.

移行エラーを防ぐためのルール:
  • デフォルトの言語はソースとターゲット間で一致する必要があります。.
  • 1対1のロケールマッピングのみ。複数のソースロケールを単一のターゲットロケールにマッピングすることはできません。.
  • ソース内で削除されたロケールが API 内にまだ存在する場合があり、これらを移行すると失敗します。.
  • Zendesk® UI のロケール名は、API コードと異なる場合があります (例: fr-fr → フランス語、fr → フランス語 (フランス))。ナレッジ管理 → 設定 → 言語設定でご確認ください。.
  • デフォルトの言語が設定されていない記事は、手動で割り当てられるか、移行設定によって割り当てられない限り、スキップされます。.
  • 必要ない場合は特定のロケールをスキップできます。.

  • 下書きと公開済みの記事:移行後も状態は保持されます。下書きは下書きのまま、公開済みの記事は公開済みのままです。
  • アーカイブされた記事:移行できません。まずは下書きまたは公開済みとして復元してください。
  • フォルダとセクション:フォルダのない記事はデフォルトのフォルダに移動さ​​れます。セクション/カテゴリの制限と最大ネスト深度は維持されますが、サイレントエラーを回避するために必ず確認してください。
  • 並べ替えと固定された記事:順序は可能な限り保持されます。カスタム位置は移行後に調整が必要になる場合があります。

  • 画像、ファイル、タグ、書式はそのまま移行されます。.
  • Zendesk®で埋め込み動画を使用するには、安全でないコンテンツを有効にする必要があります。.
  • 「クロスリンクの更新」が有効になっている場合は記事内のリンクが更新されますが、有効になっていない場合はリダイレクトを手動で設定する必要があります。.

  • ラベルとタグは保持されます。.
  • カスタム記事フィールドにはマッピングが必要な場合があります。サポートされていないフィールドはスキップされます。.
  • 著者の帰属: ターゲットにユーザーが存在する場合は元の作成者が保持されます。それ以外の場合は、移行によって API ユーザーが割り当てられます。.
  • 記事の作成日と更新日は可能な限り維持されます。.

  • クロスリンクを更新すると内部リンクが保持されます。.
  • 相互リンクが無効になっている場合はリダイレクトが必要です。.
  • 対象のヘルプ センターに重複したスラッグが存在する場合、スラッグの名前は自動的に変更されます。.

  • 同じ記事を再度移行する場合、移行はべき等です。つまり、更新された記事によって以前のバージョンが上書きされます。.
  • ソース内の削除された記事または削除された翻訳は、ターゲットから自動的に削除されません。.
  • 選択的な移行を行う記事のリストをご提供ください。20件未満の場合は、「カスタムデータを使用したデモ」を使用してデモで移行できます。.

  • アーカイブされた記事(最初に下書きまたは公開済みに復元します)。.
  • チャネル フィールド データ。.
  • スパムチケット(一時停止タブ)。.
  • サポートされていない特定のカスタム フィールド。.

  • 新しく移行されたコンテンツが検索結果に表示されるまでには時間がかかる場合があります。.
  • インデックスの遅延は正常であり、移行後には予想されるものです。.
移行できないものは何ですか?
  • アーカイブされた記事:カスタム記事であっても移行できません。アーカイブされた記事を移行するには、まず下書きまたは公開済みの記事として復元する必要があります。
  • チャネルフィールドのデータ: Zendesk®チャネルフィールドへの移行が許可されていないため、この情報をデフォルトフィールドに移動することはできません。
  • スパム チケット: [一時停止] タブ内のチケットは移行されません。
ナレッジ ベースは完全に構造化され、検索可能で、チームが何千もの記事を手動で処理しなくても履歴の整合性が維持されます。.
Help Desk Migration 代替バナー

推測は不要です。ダウンタイムなしで Zendesk® から Zendesk® への移行を検証しましょう。

Zendesk®からZendesk®移行に関するよくある質問:
重要な技術的詳細

はい。非アクティブなブランドのチケットも含め、すべてのチケットが移行されます。移行対象となるブランドとチケットフォームを管理することで、チケットが適切なブランドまたは部門に届くようになります。.

統合されたチケットは個別のレコードとして移行され、履歴のコンテキストが完全に保持されます。フォローアップは、ワークフロー要件に応じて、メインチケットに統合するか、カスタムフィールドに記録することができます。.

未割り当てのチケットは自動的にデフォルトのエージェントに割り当てられます。これにより、チケットが孤立することなく、ワークフローが中断されることなく継続されます。.

複数のチケットフォームのドロップダウンフィールドはタグに変換されます。重要なデータはすべて保持しながら、不要なタグの作成を最小限に抑えます。自動タグ付けは必要に応じて無効にできます。.

はい。通話録音は MP3 添付ファイルとして保存され、インライン画像、動画、ファイルはすべてそのまま移行され、移行先インスタンスで使用可能になります。.

すべてのマクロ、トリガー、およびそれらの条件が移行されます。アクションをスキップするとトリガーが失敗する可能性があるため、移行前にすべてを検証します。必要に応じて、アクティブまたは非アクティブのステータス、カテゴリ、またはグループでフィルタリングできます。.

エージェント以外、リクエスタ、またはCCによって作成されたプライベートメモは、デフォルトのエージェントに再割り当てされます。元のコンテキストは保持されるため、何も失われることはありません。.

予期せぬ事態、データ損失、ダウンタイムを回避できます。すべてのチケット、ユーザー、マクロ、ナレッジベース記事を確実に移行します。デモ移行では結果をプレビューでき、エッジケースは自動的に処理され、ワー​​クフローは中断されません。.

はい。ユーザーまたは組織に適用されたタグは、そのユーザーまたは組織に対して作成された新しいチケットに自動的に追加されます。.

デフォルトのロールには、エンドユーザー、エージェント、管理者が含まれます。エンタープライズプランでは、チームのニーズに合わせてカスタムロールを作成できます。.

help_center/user_segmentsへのアクセス権限がないことを意味します。この問題を解決するには、ユーザーにヘルプセンター管理者のロールを割り当ててください。

ナレッジベースの記事はフォルダにのみ保存でき、カテゴリには保存できません。記事が移行元システムのフォルダに属していない場合は、移行ツールによって作成されたデフォルトのフォルダに移行されます。.

自動化は時間ベースのイベントに基づいて実行され、トリガーはチケットの作成または更新に応じて実行されます。.

はい。チケットは、非アクティブ化されたブランドも含め、すべてのブランドから移行されます。マッピングには「ブランド」フィールドが表示されます。ブランドが非アクティブな場合は、マッピングには表示されません。そのブランドのチケットは、クライアントが選択したデフォルトのブランドに移行されます。クライアントがすべてのブランドではなく、特定のブランドのみを移行したい場合は、フィルタリングが必要です。移行先の Zendesk®では、チケットマッピングで特定のブランドを選択することで、チケットをそのブランドに移行できます (マッピングには「ブランド」フィールドが表示されます)。.

チケット フォームは、チケットに表示されるフィールドを定義し、部門またはリクエストの種類ごとにチケットを区別するテンプレートです。.
  • フォーム マッピング: チケット フォームはソースとターゲット間でマッピングできます。.
  • ドロップダウンフィールド:他のフォームのドロップダウンリストから選択された値は、 Zendesk®によって自動的にタグとして追加されます。この動作は防止できません。.
  • カスタム マッピング: 不要なフィールドを除外してタグを減らすことができます。.
  • タグの無効化: Zendesk® 自動タグ付けを無効にできます。コンテンツベースの自動タグ(ガイド)も無効にできますが、ドロップダウンフィールドのタグはマッピングから削除しない限り残ります。.

統合されたチケット:個別のチケットとして移行されます。統合を示すプライベートメッセージはプライベートメッセージとして移行されます。フォローアップ:単一のチケットとして移行されます。ID付きのフォローアップは、オプションでプライベートノートまたはカスタムフィールドに移行できます。.

はい、アーカイブされたチケットはデフォルトで移行されます。Zendesk® Zendesk®、アーカイブされたチケットとは、90日間「クローズ済み」ステータスになっているチケットのことです。.

対象の Zendesk® 上で未割り当てのチケットは、デフォルトのエージェントに割り当てられます。.
  • チケットは、割り当てられていない場合のみ、新規ステータスのままになります。.
  • 新規チケットがデフォルトのエージェントに割り当てられると、 Zendesk® 自動的にそのステータスを「オープン」に変更します。.
  • したがって、「新規」ステータスは Zendesk®への移行マッピングから除外されます。.

Zendesk® 、デフォルトのステータス(新規、オープン、保留中、保留、解決済み、クローズ済み)以外にも、カスタムのチケットステータスを作成できます。.
  • マッピング: マッピングにはデフォルト ステータスまたはカスタム ステータスのいずれかが表示され、両方が同時に表示されることはありません。.
  • デフォルトのステータスへの切り替え: デフォルトのステータスをマッピングするには、アカウントでカスタム ステータスを無効にして再接続します。.
  • チケットの動作: カスタム ステータスのチケットは閉じられたものとして扱われます。自動化が存在する場合でも、閉じられたチケットの特性 (編集できず、閉じられたカテゴリのまま) はすべて保持されますが、ステータス名は変更されません。.

はい。必要に応じて組織を除外できますが、ユーザーに事前に通知しないことを推奨します。.

はい。連絡先(ユーザーおよび組織)タグはデフォルトで移行されます。ソースの Zendesk® でユーザーまたは組織に関連付けられているすべてのタグは、ターゲットインスタンスに転送され、ワー​​クフロー、トリガー、およびレポートで引き続き使用できます。.

Zendesk®では、チケットは依頼者の会社とは異なる会社に属することはできません。ソースチケットの会社が連絡先と異なる場合(または連絡先会社がない場合)、複数の会社をチケットから連絡先にカスタムで移行し、チケットに正しい会社を反映させることが可能です。.

一時停止中のユーザーはチケットを作成できないため、一時停止中のユーザーは一時停止解除された状態で抽出され、移行されます。ターゲット上に一時停止中のユーザーが存在する場合は、一時停止を解除してマッピングします。.

Zendesk® ユーザーセグメントは、ユーザーと組織のカスタムタグマッピングを介してのみ移行できます。クライアントは、移行前または移行後に、移行対象の連絡先に対して移行先でユーザーセグメントを作成する必要があります。記事を移行する場合、ソースと移行先のユーザーセグメントがマッピング用に表示されますが、移行先で正しく設定されている場合にのみ機能します。

エージェントがソース側でグループAに属し、 Zendesk®でグループBに属している場合、マッピングに従って、そのエージェントはチケットに関連付けられたグループに割り当てられます。.

はい、チケットは、ドメインが Zendesk®の場合のみ、受信者(サポートメール)でフィルタリングできます。.

トリガーは条件が満たされると自動的に実行されます。移行中は次のようになります。
  • 自動マッピング: すべてのトリガーが移行されます。.
  • 確認可能な詳細: すべての条件とアクションが検証用に表示されます。.
  • 重大: いずれかのアクションがスキップされると、移行後にトリガーが失敗します。.

移行中、マクロはすべてのコアコンポーネントとともに転送され、ターゲットの Zendesk®で正しく機能するためには完全にマッピングする必要があります。
  • 使用可能 - マクロを使用できるロールを定義します。.
  • タイトル — マクロの名前。.
  • 本文 - マクロによって適用されるコンテンツまたは指示。.
  • アクション — すべてのマクロアクションは明示的にマッピングされます。いずれかのアクションがスキップされたり、マッピングされなかったりすると、移行後にマクロは失敗します。.
すべてのマクロアクション、条件、依存関係はマッピング段階で完全に表示されるため、稼働前に検証および調整できます。.

はい。以下の条件でフィルタリングできます。
  • マクロ:アクティブ/非アクティブのステータス、カテゴリ、またはグループ。デフォルトでは、すべてのマクロが移行されます。.
  • トリガー:アクティブ/非アクティブのステータスまたはカテゴリ。デフォルトでは、すべてのトリガーが移行されます。.
エルヴィラ・アジモヴァ
著者

エルヴィラ・アジモヴァ

営業部長

エルビラは、 help desk migration エキスパートとして卓越した実績を持ち、当社の営業・サポートチームのリーダーとして高く評価されています。4年以上の経験と2000件以上の移行成功実績を持つ彼女は、データの完全性と業務継続性を重視しながら、リスクの高いエンタープライズデータ移行を成功に導くことを得意としています。.

Zendesk から Jira Service Management への移行が簡単に

Zendesk から Jira Service Management への顧客レコードの移行は、わずか数クリックで完了します。移行作業は弊社のソリューションにお任せください。お客様は、顧客からのリクエスト解決という重要な業務に集中できます。.

役立つデータ移行ガイドをもっとご覧ください

さらに詳しい情報をお探しですか?弊社の最新リソースでは、顧客サービスの向上やヘルプデスクのデータ移行に関する貴重なガイドを提供しています。ぜひ今すぐご確認ください!

2024年版 最高の無料ヘルプデスクソフトウェア:レビュー、機能、価格

最高の無料ヘルプデスク ソフトウェアの威力を発見し、企業が次のことを実現できるようにします...

Freshdesk 代替製品2026 - 機能、価格、おすすめを比較

企業が優れた顧客サポートを提供することを目指すにつれて、 Freshdesk 代替品に対する需要が高まっています...

無料のチケットシステムで低予算でカスタマーサポートを向上する方法

顧客サービスの成功は、チケット販売ソフトウェアの効率性にかかっています。….