この記事は、現在複数のブランドを管理するためにハブアンドスポークセットアップを使用しており、複数のブランドを管理するために複数ブランドへの移行を検討しているSupport Enterpriseのお客様を対象としています。
複数ブランドへの移行の前提条件
ハブアンドスポーク（H&S）から複数ブランド（MB）への移行を検討または計画している場合、アカウントを複数ブランドへ完全に移行することを妨げる主な障害についてご確認ください。
詳細をお読みいただく前に、すべてのスポークを実際に使用しているか確認します。 ハブスポークをセットアップしているにもかかわらず、ハブのみを使用しているお客様もいます。 スポークが使用されていない場合、またはスポークがハブとチケットを共有していない場合は、移行の必要はありません。
- 複数ブランドとハブアンドスポークのいずれか。複数ブランドのインスタンスは、H&Sセットアップ内に存在することはできません。 これらの製品は互いに排他的です。
上記のすべてに問題がない場合、複数ブランド移行についてさらに詳しく知りたい場合は、「複数ブランド移行の手順」の記事から始めてください。
ハブアンドスポークと複数ブランドの比較
このセクションでは、ハブアンドスポーク（H&S）が複数ブランドに移行した後に発生する可能性のある動作の変更について説明します。 以下のいくつかの項目については、複数ブランドの動作を変更する計画がありますが、まだ具体的なスケジュールは決まっていません。
- リモート認証/シングルサインオン。各ヘルプセンターは、同じシングルサインオンプロトコルとデータベースにユーザーをリダイレクトします。これは、ユーザーがブランドごとではなくアカウントごとであるという事実の派生的な影響です。
-
Zopimチャネルブランディング。Zopimを通じて作成されたチケットは、現在ブランド属性を認識しません。繰り返しになりますが、将来的には修正される予定です。 それまでは、Zopim複数ブランドの設定を改善し、提案のサブセットを実装してください。
- エージェントの署名。署名はエージェント一人あたり1つです。 エージェントは個人マクロを利用して、各ブランドのエージェント署名を作成できます。
-
エンドユーザーのブランドID。現在、ブランドIDに基づいてカスタマーリストのエンドユーザーをセグメント化する方法はありません。これは、どのユーザーがどのブランドとやりとりしたかを追跡できないためです。
- エージェントの権限。デフォルトでは、すべてのエージェントがすべてのブランドにアクセスできますエージェントが使用するブランドビューを作成できます。制限が必要な場合は、トリガを使用してブランドチケットをグループに割り当て、そのグループ内のチケットに対するエージェントの権限を制限します。
-
エンドユーザーの権限。特定のヘルプセンターをエンドユーザーのサブセットに対して非表示にすることはできません。これは仕様ですが、Zendeskはユーザータイプに基づいてセグメント化された特権サービスをサポートする方法の開発に取り組んでいます。 ただし、ZendeskのユーザータグとJavaScriptを使用することで、コンテンツ、ユーザーポータル、コミュニティへのアクセスを禁止することは可能です。
-
単一のメールテンプレート。サービス開始当初は、1アカウントにつき1つのHTMLテンプレートに制限されます。将来的には変更を加える予定ですが、現時点では、共有HTMLテンプレートを作成し、マクロを使用して回答のテキストをブランディングすることができます。
- チケットフォーム。ブランドごとに、特定のチケットフォームへのアクセスを制限できます（「ブランド別チケットフォームの作成および適用」を参照）。これにより、ヘルプセンターのブランドや表示中のチケットに基づいて、エンドユーザーやエージェントが利用できるチケットのフォームを制御できます。
-
インテグレーション。Zendeskは、JIRAやSFDCを含む主要なインテグレーションで、ブランド価値が確実に保たれるように取り組んでいます。他のすべてのアプリは、オーナーが更新する必要があります。
- パスワードリセット。エンドユーザーが1つのブランドポータルからパスワードリセットを要求すると、すべてのブランドのパスワードが同時にリセットされます。 パスワードリセットのメールはカスタマイズできませんが、関連するすべてのヘルプセンターのリストが表示されるため、エンドユーザーはどこでパスワードが更新されたかを知ることができます。
移行の手順と制限について
以下は、複数ブランドへの移行の主要な要素です。
-
手順とタイムライン
-
制限事項
標準的な手順とタイムライン
- MBインスタンスを設定します（「設定」、「チャネル」、「ブランド」、「エージェントロール」など）。
- Zendeskはコンテンツのサンプル（チケットとヘルプセンター記事）を移行します。
- サンプルコンテンツが期待どおりに移行されたことを確認します。
- Zendeskは、「終了済み」未満のチケット（＝進行中のチケット）を除くコンテンツの移行を完了します。
- MBインスタンスでワークフローを設定します（マクロ、トリガ、自動化、ビュー）。
- 移行の最終ステップの準備として、カスタマーに今後のダウンタイムについて知らせます。（スポークのヘルプセンターでのメッセージや、警告メールなどを使用します）。
- ダウンタイムタスクを実行します。Zendeskで残りのチケットを移行し、サブドメインを（スポークから複数ブランドに）切り替え、各ブランドのホストマッピングを設定します。
スケジュールに関しては、このプロセスに割り当てられるZendeskのリソース、移行プログラムの複雑さ、お客様のタスク完了への対応力に影響を受けます。 お客様の移行要件を収集した後、初めて移行完了予定日をお伝えすることができます。
- チケット
- すべてのコメント、添付ファイル、メタデータ（つまり、すべてのチケットフィールドとタグの現在の値）を移行します。
- イベントは移行できません（イベントの例：タグ「xyz」が2014年12月12日にトリガ123によって追加された）。
- 複数ブランドのインスタンスで新しいチケットが作成されるため、チケットID番号は移行できません。
- ヘルプセンターのコンテンツ
- 記事（および添付ファイル）を移行します。移行後は、すべての記事の作成者が同じになります（アカウントオーナーまたは指定したユーザー）。
- 記事の作成日、コメント、受信登録は移行されません。 同様に、セクションの設定とコミュニティコンテンツも移行されません。
- テンプレートは移行できません（例：ヘルプセンターで行ったカスタマイズなど）。
- カテゴリまたはセクションの設定は移行できません。移行後にリセットする必要があります。
- カテゴリ、セクション、および記事番号のIDは、移行時に変更されます。以前の外部リンクは更新する必要があります。
- ユーザー情報
- エンドユーザー、エージェント、グループ、組織は移行可能です（ただし、エンドユーザー、エージェント、グループ、組織の詳細情報や、カスタムフィールド、ユーザーメモは含まれません）。
- エンドユーザーのパスワードは移行できません。 そのため、カスタマーがZendeskに直接ログインしている（つまり、Zendeskの認証プロフィールを持っている）場合、移行の完了後にパスワードを一度リセットする必要があります。
- エージェントロールは移行されません。
- 組織、言語、タイムゾーン、詳細 + メモ、プロフィールのカスタムフィールドは移行されません。
- ワークフロー
- マクロは移行されます。
-
ビュー、トリガ、自動化は移行できません（これらはすべて見直し、作成した新しいブランドに合わせて調整することになるため、移行することにあまり意味がありません）。
-
動的コンテンツは移行できません。
- その他
- 満足度評価：移行できません
- 「設定」と「チャネル」の移行はできません（ブランドが増えるのであまり意味がありません）。
- 特定の記事へのブックマークは、ユーザーをブランド化されたヘルプセンターのホームページに誘導します（新しくブランド化されたへルプセンター内の同等の記事には移動しません）。
- Zendeskは、JiraやSFDCを含む主要なインテグレーションで、ブランド価値が確実に保たれるように取り組んでいます。他のすべてのアプリは、オーナーが更新する必要があります。