Zendeskからの移行方法:2026年完全ガイド

Zendeskの価格には問題があり、それは年々悪化しています。r/helpdeskのサポートチームは、毎年20%の値上げがあると報告しており、あるユーザーは更新見積もりが年間1,500ドルから7,000ドルに跳ね上がったと述べています。別のユーザーは、10名のエージェントチームで年間15,000ドルを払っていたが、はるかに低コストなFreshServiceに切り替えたと述べています。

不満は価格だけではありません。"Zendesk is incredibly flexible but that flexibility requires someone to configure it well, and a small team does not have that person,"とr/helpdeskのあるコメント投稿者は率直に書いています。専任のZendesk管理者がいないチームにとって、このプラットフォームの強力さはむしろ摩擦になります。

もし乗り換えを検討しているなら、あなたは一人ではありません。このガイドでは、現在の設定の監査、データのエクスポート、移行先の選定、移行の実行、そして自動的には移行されないものの再構築まで、移行プロセス全体を解説します。切り替えが実際にどのようなものか―ほとんどの移行ガイドが省略している部分も含めて―現実的に把握したいなら、続きを読んでください。

移行する前に:何が本当にあなたを遠ざけているのかを理解する

正しい道筋は、根本原因によって変わります。

ZendeskのAIが高すぎる。 Copilotアドオンは月額50ドル/エージェントに加え、プランの少ない月間割り当てを超えると自動解決1件あたり1.50〜2.00ドルかかります。Suite ProfessionalでCopilotを使う10名のエージェントチームは、AR超過分を除いても月額1,650ドルに達します。AIの価格が主な問題なら、そもそも移行の必要がないかもしれません―既存のZendesk環境(またはよりシンプルなヘルプデスク)にサードパーティのAIレイヤーを追加する方が、はるかに安く済みます。

Zendeskは自社のボリュームに対してオーバースペック。 月間チケット数が数百件未満なら、あなたはおそらくオムニチャネルルーティング、ワークフォースマネジメントツール、エンタープライズ規模の分析機能に対して料金を払いながら、一度も使っていない可能性が高いです。Help ScoutやZoho Deskのような軽量なプラットフォームなら、必要なものを大幅に低いコストで手に入れられます。

Zendeskは自社に合っていない(ITヘルプデスク由来で、ECやSMBには不向き)。 複数のRedditスレッドで、ZendeskはもともとITサポートや大企業向けに作られたと指摘されています。主に注文状況、返品、商品に関する問い合わせを扱うチームは、目的特化型の代替ツールの方がこれらのワークフローに自然にフィットすることが多いです。

以下の移行ステップはこの3つのシナリオすべてに当てはまります。ただし、自分の理由を常に念頭に置いてください―それによって、どの代替ツールがあなたに最も適しているかが決まります。

移行の実際のコスト

切り替えを決める前に、両方の数字を計算しましょう。

中規模チームの典型的なZendeskの請求は次のようになります。

チケット量が多い場合は、自動解決の超過分($1.50〜2.00/AR)がこれに加算されます。

移行済みのチームは大幅な節約を報告しています。ある企業はBoldDeskへ移行し、コストを年間7,000ドルから1,500ドルに削減しました。別の企業はFreshServiceに移行し、年間15,000ドルの請求を大幅に減らしました。Help Desk Migrationのようなツールの移行費用(500〜2,000ドル)を加味しても、ほとんどのチームは半年以内に元が取れます。

移行先を選ぶ

適切な移行先は、チームの規模、サポートチャネル、そしてEC向けのネイティブ連携をどれだけ重視するか対一般的なチケット管理を重視するかによって決まります。

注目すべき点をいくつか挙げます。

FreshdeskはZendeskからの移行先として最も一般的です。管理コンソールにネイティブのZendeskインポートウィザードがあり、チケット、連絡先、ナレッジベース記事、添付ファイルを扱えます。また、どの料金プランでもより安価です。

Help Scoutは本当にセットアップがシンプルです―数週間ではなく数日で本番稼働にたどり着いたというチームの報告もあります。サポートの大半がメール経由で、複雑なルーティングが不要な場合に最適です。

GorgiasはShopify連携が最優先事項であれば有力です。注文データがチケットに直接表示されますが、Zendeskで同じことを実現するにはカスタム連携作業が必要です。

社内向けサポートを行うITチームなら、Jira Service Managementも検討する価値があります。無料プランでもエージェント3名分をカバーし、ITILの全機能セットが含まれます。

ステップ1:Zendeskで実際に使っているものを監査する

エクスポートに手を付ける前に、チームが日常的に依存しているものを文書化しましょう。

• チャネル:メール、チャット、音声、ソーシャルメッセージング―どれが稼働中か?
• 連携:CRM、ECプラットフォーム、Slack、分析ツール―アクティブな連携をすべてリストアップ
• 自動化:トリガー、マクロ、SLAルール、エスカレーションロジック―これらは移行できません
• ビューとレポート:チームが実際に見ているカスタムダッシュボードとレポート
• ナレッジベース:記事数、対応言語、更新頻度

この監査には2つの目的があります。第一に、移行がどれほど複雑かを把握し、適切な移行方法を選ぶ助けになります。第二に、自動移行ツールでは対応できない業務ルールなど、新しいプラットフォームで再現すべきすべてを洗い出します。

正直な監査を行うと、実は自分たちがZendeskをどれほど使っていなかったかが明らかになることもあります。多くのチームが、エンタープライズ規模の機能に料金を払いながら、実際にはプラットフォームの20%しか使っていなかったことに気づきます。

ステップ2:Zendeskのデータをエクスポートする

Zendeskでエクスポートできるものと、その方法を紹介します。

まずデータエクスポートを有効にする。 Zendeskのデータエクスポートはデフォルトでは有効になっていません。Zendeskサポートに連絡し、この機能をリクエストする必要があります。これはProfessionalおよびEnterpriseプラン(と全Suiteティア)でのみ利用可能です。

「Admin Center > Account > Tools > Reports > Export」タブに移動します。

3つのエクスポート形式が利用可能です。

ほとんどのチームには、JSONが推奨形式です。CSVにはないコメントを含む、完全なチケット履歴が含まれます。

きれいにエクスポートされないもの:

• 添付ファイルは別途処理が必要―標準のCSVエクスポートには含まれません
• AIエージェントが解決したチケットはまったくエクスポートできません
• カスタムユーザーフィールドと組織フィールドにはAPIが必要(ユーザーのXMLエクスポートには含まれません)
• トリガー、マクロ、業務ルールはプラットフォーム固有のため移行できません

Zendeskアカウントが下位プランの場合や、より細かい制御が必要な場合は、Zendesk APIを使えばどのプランでもデータを取得できます。大規模アカウントには、増分エクスポートエンドポイントが適切な出発点です。

ステップ3:移行を実行する

3つのアプローチがあり、それぞれトレードオフが異なります。

選択肢A:専用の移行ツールを使う(ほとんどのチームに推奨)

Help Desk Migrationは認定Zendeskパートナーであり、この用途で最も一般的に使われるツールです。チケット、連絡先、組織、ナレッジベース記事、添付ファイル、インライン画像、通話録音を扱えます。ワークフローは次の通りです。

1. Zendeskアカウントと移行先プラットフォームの両方を接続する
2. ソースフィールドを移行先フィールドにマッピングする(カスタムフィールドも含む)
3. 20件のランダムなレコードで無料のデモ移行を実行する
4. サンプルを検証する―チケット構造、コメント、添付ファイルを確認
5. 本番移行を実行する
6. 初回取得以降に作成・更新されたレコードを取り込むため、差分移行を実行する

このツールは間隔移行(最大5回まで一時停止可能)に対応しており、強制的な一括切り替えなしで段階的に移行できます。価格はデータ量に応じて変動し、デモ移行は無料で約5分で完了します。

データ転送速度は平均で1時間あたり2,000チケットなので、15,000チケットなら実転送時間は約7〜8時間かかります。

選択肢B:移行先プラットフォームのネイティブインポーターを使う(Freshdeskへの移行に最適)

Freshdeskへ移行する場合、管理画面にはネイティブのZendeskインポートウィザードが用意されています。チケット、連絡先、会社情報、エージェント、カスタムフィールド、添付ファイル、定型文、シナリオ自動化、ナレッジベースのコンテンツを扱え、サードパーティアカウントは不要です。

既知の制限:ナレッジベース記事内の内部リンクは自動的には更新されません。Zendesk形式のURLが記事本文に残るため、手動またはリダイレクトルールで修正する必要があります。

選択肢C:移行専門業者を雇う(大規模または複雑なアカウントに最適)

チケット数が5万件を超える、カスタマイズが大量にある、またはコンプライアンス要件が複雑なアカウントには、HelpandoやGravity CXのような会社がエンドツーエンドの移行サービスを提供しています。費用は複雑さに応じて5,000〜20,000ドル以上かかります。切り替えによって年間5万ドル以上を節約できるエンタープライズアカウントにとっては、理にかなった投資です。

必ず最初にデモ移行を実行する。 これは、このプロセスを経験したチームからの最も重要なアドバイスです。デモ移行では、何千ものレコードに影響が及ぶ前に、カスタムフィールドの不一致、添付ファイルの破損、日付やタイムゾーンの問題を発見できます。

ステップ4:移行されなかったものを再構築する

これは、多くの移行ガイドが軽視しがちな部分です。チケットデータとナレッジベース記事はきれいに移行されます。しかし、以下は新しいプラットフォームで手動作業が必要です。

トリガーと自動化。 Zendeskのトリガーと自動化ロジックはプラットフォーム固有です。新しいシステムのワークフロービルダーを使って、各ルールを再作成する必要があります。これを機に、実際に機能している自動化を監査してみましょう―誰も作った覚えのないルールの墓場が見つかるチームがほとんどです。

マクロと定型文。 これらはエクスポートしてテンプレートとして再インポートできる場合もありますが、構造はプラットフォームによって異なります。すべてを見直して調整する必要があると想定してください。

SLAポリシー。 ZendeskのSLA設定は他のプラットフォームのモデルにマッピングされません。新しいツールでSLAをゼロから設定することになります。

ナレッジベースの内部リンク。 他の記事を指す記事内リンクは、依然としてZendeskのURLを参照したままです。301リダイレクトを設定するか、ツールを使って古いURLを検索・置換するか、手動で監査するかのいずれかが必要です。記事が数百件あると、これはコストがかさみます。

サードパーティ連携。 Zendeskで接続していたすべての連携(Salesforce、Shopify、Slackなど)は、新しいプラットフォームで再接続してテストする必要があります。連携の数に応じて、テストに1〜3日を見込んでください。

チーム権限とエージェントロール。 エージェントのロール構造はプラットフォームによって異なります。ロール、グループ、権限をゼロから設定する必要があります。

有用なショートカット:以前の設定を1対1で再現しようとしないことです。移行は簡素化するための自然な機会です。あるトリガーが2年間編集されていないなら、再構築する前に本当に必要かどうかを確認しましょう。

ステップ5:本番移行前にテストする

以下の5点を確認するまでは、新しいプラットフォームに切り替えないでください。

1. チケット数が一致していること。 移行先プラットフォームのレコード数を、Zendeskのエクスポートと比較します。差異があれば、レコードが欠落している可能性があります。
2. コメント履歴が保持されていること。 ランダムに10〜20件のチケットを開き、会話の全スレッドが存在するか確認します。
3. 添付ファイルが読み込まれること。 添付ファイルの移行は最もエラーが起きやすいステップです。ファイルがあったことがわかっているチケットを抜き打ちで確認しましょう。
4. ルーティングがエンドツーエンドで機能すること。 すべてのチャネル(メール、チャット、ソーシャル)からテストチケットを送信し、正しい場所に届くか確認します。
5. 自動化が正しく発火すること。 主要な自動化を起動させるはずのテストチケットをいくつか送り、想定通りに動作するか確認します。

新しいプラットフォームにステージング/サンドボックス環境があるなら、まずそこでテストを実行してください。

タイミング:いつ移行すべきか

最も重要なタイミングに関するアドバイスは一つだけです。サポートのピーク時期に移行しないことです。あるr/helpdeskのコメント投稿者は、"The risk of breaking something mid-peak is the killer"と端的にまとめています。ホリデーシーズンの繁忙期や製品ローンチのタイミングで移行を誤ると、壊滅的な結果になりかねません。

**良いタイミング:**Q1初旬(ホリデー明けで扱いやすい量)、大きな製品リリースの間、そしてサポート量が予測どおり少ない期間。

**避けるべき時期:**Q4のホリデー期間、計画済みのマーケティングキャンペーン、製品ローンチ、B2Bチームの会計年度末。

どれくらいの期間を見込むべきでしょうか。

本番稼働後30日間は、Zendeskを読み取り専用モードで残しておきましょう。最初の数週間は、ほぼ確実に旧システムで何かを調べる必要が出てきます。アクセスを維持しておくことで、パニックを防げます。

新しいプラットフォームでのAIについて

Zendeskの代替ツールの多くは、基本プランに簡易的なAI機能を追加しています。しかし、月額15ドル/エージェントのプランに含まれる「AI」は、通常インテントベースのルーティングと返信候補の提案程度であり、自律的なチケット解決ではありません。

チケットをエンドツーエンドで処理するAI(返信の下書き作成、単純な依頼の解決、コンテキスト付きでのエスカレーション)が欲しいなら、どのヘルプデスクを選んでも、その上にAIレイヤーを追加する必要があります。

ここで計算が興味深くなります。eesel AIはFreshdesk、Zendesk、Slack、その他100以上のプラットフォームに接続し、チケット1件あたり0.40ドルで処理します―プラットフォーム利用料も座席数による課金もありません。月間1,000チケットを処理するチームなら、月額400ドルです。これを、10名のエージェントに対して月額50ドル/エージェント(月額500ドル)かかるZendeskのCopilotアドオンに、自動解決1件あたり1.50ドル以上が加わる場合と比較してみてください。

Freshdesk(月額15ドル/エージェント)に移行してeesel AIを追加する場合、月間1,000チケットを処理する10名のエージェントチームの支払いは次のようになります。

• Freshdesk Growth:月額$150
• eesel AI:月額$400
• 合計:月額$550(Zendesk + Copilotの月額$1,650と比較して)

同等かそれ以上のAI性能を、約3分の1のコストで手に入れられるということです。

eeselは初日から、既存のチケットとナレッジベース記事から学習します。Smavaはドイツ語で月間100,000件以上のチケットを処理するのにeeselを使っており、Gridwiseは最初の1か月でティア1リクエストの73%を解決したと報告しています。eeselはヘルプデスク内にエージェントとしてインストールされるため、並行して管理すべき別システムも、ワークフローの再学習も必要ありません。

移行する前にZendeskのチケットを自動化する方法を知りたい、またはZendeskのネイティブ AIが実際に何をカバーしているのか理解したいなら、どちらの道を選ぶにせよ、それらのガイドは目を通しておく価値があります。

そもそも乗り換えるべきかどうかを検討しているチームには、Zendesk AIの代替ツールを比較したこちらの記事が、トレードオフをより詳しく解説しています。

eeselを試す

eesel AIは、Zendeskに残るにせよ、Freshdesk、Slack、その他のプラットフォームへ移行するにせよ、あなたのヘルプデスク内で動作するAIサポートエージェントです。過去のチケット、ヘルプセンター記事、ナレッジベースを読み込み、初日からサポート対応を始めます。価格はチケット1件あたり0.40ドルからで、プラットフォーム利用料も座席数課金も契約義務もありません。

Zendeskのネイティブ AIが高すぎることも理由の一つでZendeskから移行するのであれば、eeselなら新しいプラットフォーム上で、アドオン価格なしに同等の機能を利用できます。eesel + Zendesk連携ガイドでセットアップの流れを確認でき、Freshdeskへの移行を検討しているなら、Freshdesk連携も同じくらい簡単です。

無料利用分50ドル、クレジットカード不要。eesel.aiで始める。