マルチブランドのカスタマーサポート:1つのチームで複数のブランドの声を使い分け、取り違えを防ぐ

マルチブランドのカスタマーサポートとは(そして何でないか)

私は毎日eeselのサポートキューを担当していますが、お話しするチームの意外に多くが単一ブランドではありません。3つのShopifyストアを持つ会社、5つの製品ラインを持つウェルネスグループ、2つのZendeskブランドを1つのチームで回しているドイツのイベント会社などです。これがマルチブランドのカスタマーサポートです。1つの会社、複数のブランド、1つのサポート運営。

代理店やアウトソーサーの構成と混同されやすいですが、あちらは別々の会社が所有するブランドを1つのチームが支える場合です。そこで問題になるのは壁です。クライアントAのデータ、スタッフ、レポートをクライアントBから遠ざけることです。これはマルチクライアントのヘルプデスクのガイドで取り上げました。マルチブランドはその逆の課題です。ブランドは同じオーナーを持ち、顧客を共有することも多く、ほぼ必ず同じサポートチームを共有します。購入者には別々に見え、対応する側には一体になっていてほしいのです。

ZendeskでふたつのブランドをもつG2のレビュアーは、その目標をこう表現しています。

「同じ会社の下で2つの別々の消費者向けブランドを運営していて、片方の顧客はもう片方の存在をまったく知りません。まさに私たちが望む形です。」

Alex M., G2

これが基準です。外から見れば別々、内側では1つの運営です。

ブランドごとに共有するものと分けるもの

マルチブランドの失敗の多くは、分ける対象を間違えることから生まれます。チームは顧客レコードを壁で囲い(これは悪影響)、AIの知識は共有のままにします(これはもっと悪影響)。

共有するもの:

• チームとキュー。 1つのキューなら、ブランドではなく件数で人員を配置できます。ブランドAが暇な週は、ブランドBに手が回せます。ルーティングのルールは共有キュー管理の記事を参照してください。
• 顧客プロフィール。 同じ購入者が2つのブランドで買い物をしているなら、エージェントは両方のやり取りを見られるべきです。それは文脈であって、漏えいではありません。
• レポート(ブランドフィルター付きの統合ビュー)。 人員計画のための全体件数と、各ブランドオーナーのためのブランド別の数字の両方が必要です。

分けるもの:

• メールアドレスと署名。 間違ったブランドのアドレスから返信が出るのが、マルチブランドのサポートで最も目立つミスです。
• ヘルプセンター。 各ブランドには専用の記事、デザイン、ドメインが必要です。
• ポリシー。 返品期間、返金ルール、配送の約束はブランドごとに違うことが多く、顧客が引用して返してくるのもそこです。
• AIの知識とトーン。 共有のナレッジベースから答えるAIは、ブランドBの顧客にブランドAの60日返品ルールを平気で伝えます。

共有の1チームか、ブランドごとのチームか

これはマルチブランドのリーダー全員が抱える人員配置の問いで、答えは2つの要素で決まります。ブランド間で商品がどれだけ違うか、各ブランドのチケット量がどれだけあるかです。

まず共有から始めましょう。マルチブランドのチームの多くは小規模で、小さなチームには手の空いたブランド専任者を置く余裕がありません。r/ecommerceのReddit投稿者は、Gorgiasで4ブランドを「フルタイム2人、パートタイム1人」で回していると書いていました。別のスレッドのShopify事業者は、12のストアを1か所から運営しています。

「12のストアをGorgiasの1つの画面から運営しています。完璧ではありませんが、かなり満足しています。ライブチャットだけは本来あるべきほどうまく動きません。」

u/TopSunBrands, Reddit r/shopify

共有の規模は、多くの人が思う以上に伸びます。大企業のゲストサービス部門のアプリケーションアナリストはG2に、Freshdeskで「15以上のブランドを1つのプラットフォームで」支え、「少人数のチームで年間17万件以上のチケット」を処理し、ブランド別のワークフローはグループで分けていると書いています。

「15以上のブランドを管理し、一貫したブランド別の返信を維持しながら、応答時間を大幅に短縮できています。これにより平均初回応答時間を37%短縮できました。」

Yashshvi S., Application Analyst, G2

あるブランドが本格的な商品知識を要するもの(用量の質問が来るサプリメント、設定ガイドが必要な電子機器など)を売るなら、ブランド担当のスペシャリストへ移行します。専任ポッドへ移るのは、ブランドの件数だけでチームが埋まるときだけです。分ける前に、夜間や週末にポッドが穴を作らないようサポート体制の計画のガイドを読んでください。

本当の漏れはデータではなく声

マルチブランドのサポートを心配する人は、エージェントが別の顧客のデータを見てしまう場面を想像します。マルチブランドの構成では、たいていそれは問題ありません。自社であり、自社の顧客だからです。実際に起きるのは、返信が間違ったブランドのように聞こえることです。

ブランドは、チケットがブランドのメールアドレスやウィジェットに届いた時点で刻印されます。署名、マクロ、SLA、AIエージェントなど、その後のすべてがこの刻印を基にします。転送メール、共有のソーシャルアカウント、統合を経由して届いたチケットは刻印を失うことがあり、そうなるとデフォルトが働きます。各ヘルプデスクでデフォルトが牙をむく場所は次のとおりです。

• Zendeskはアカウント全体でメールテンプレートが1つ。 Zendesk自身のガイドは、「このメールテンプレートはブランドに関係なくすべてのメッセージに適用されるため」、ブランドカラーやフッターをテンプレートから外すよう案内しています(Zendeskのメールテンプレートに関するドキュメント)。ブランド別の通知メールにするには、各通知トリガーを「Brand is X」の条件付きで複製する必要があります。
• Zendeskのブランド署名は自動メールには付かない。 Suite Growth以上でブランドごとに署名を設定できますが、エージェントがエージェント画面から返信したときだけ表示されます。「トリガーや自動化によって自動送信される通知メールには含まれません」(Zendeskの署名に関するドキュメント)。
• Zendeskのマクロは1つのブランドに限定できない。 マクロの条件にブランドは使えますが、「このブランドで利用可能」という設定はありません。2025年6月に出された要望がZendeskのコミュニティボードで今も未対応のため、多くのチームはマクロ名の先頭にブランド名を付けています。
• Freshdeskのデフォルト通知は製品別ではない。 Freshdeskの対処法は、通知をオフにして「Product is」条件付きの自動化として作り直すことで、ProとEnterpriseで可能です(Freshdeskの製品別通知)。製品別の署名にはMarketplaceのアプリが必要です。
• Help Scoutは設計の段階でこれを正しく解決している。 署名は個人ではなく受信箱に属するため、「その受信箱からのすべてのメールは、どのユーザーが返信しても同じ署名になります」(Help Scoutの署名に関するドキュメント)。ブランドごとに受信箱1つ、署名1つです。

先ほどのG2のレビュアーは、この問題のトリガー版に直面しました。1つのブランド用にルールを作り、もう一方に同じものを作るのを完全に忘れ、気づくまで「数週間」チケットに誤ったタグが付いたといいます。1つのブランド用に書いたルールは、すべて対になるルールか、明示的な「全ブランド」条件が必要です。このためのチェックリストはカスタマーサポートSOPのガイドに載せています。

ブランドをまたいで1人の顧客を共有する

ここでマルチブランドとマルチクライアントのサポートは正反対の方向に引っ張られます。代理店にとって、2つのクライアントの間で顧客レコードが共有されるのは問題です。マルチブランドの会社にとって、2つのブランドで買い物をする購入者は1人の人物であり、エージェントはその全体像を見るべきです。

ほとんどのヘルプデスクはこちらに有利です。

• Zendesk: 「エンドユーザーと組織にはブランドの値がありません。ブランドではなくアカウントに属します」(Zendeskのmultibrandに関するドキュメント)。エージェントは購入者のプロフィールで全ブランドのチケットを見られます。顧客側では、Suite Growth以上で、各ヘルプセンターで購入者が1つのブランドのリクエストだけを見るか全ブランドを見るかを設定で決められます(Zendeskのリクエスト表示設定)。
• Gorgias: Customer Timelineは、顧客のチケットとShopifyの注文を1つの画面で表示します(全プラン)。チケットは「連絡先のメールアドレスで結び付けられる」ため、別のメールやInstagramのDMを使った購入者にはプロフィールの統合が必要です(Gorgiasの顧客履歴)。
• Help Scout: 顧客リストは見える範囲の全受信箱をカバーしますが、「ユーザーは、権限のある受信箱の会話履歴しか見られません」(Help Scoutの顧客リスト)。エージェントが1つのブランドの受信箱に限定されていると、もう一方のブランドの履歴を見逃します。
• Front: 「ワークスペースは連絡先データのサイロを作りません」と明言しています(Frontのワークスペースに関するドキュメント)。2つのワークスペースが同じ連絡先とやり取りする場合、カスタムフィールドは共有されます。

粗い部分は購入者側にあります。Zendeskで「数十のブランド」を支えるG2のレビュアーは、こう書いています。

「最大の懸念は、複数のブランドで同じ顧客をサポートするのがどれだけ難しいかです。Zendeskでは、同じメールアドレスを別々のブランドに登録できません(ブランドは認証の種類として扱われないため)。」

Ivan G., G2

Redditの管理者も、ヘルプセンターのログインについて同じ指摘をしており、製品間で顧客を共有するならブランドよりグループを勧めています。

「製品間で共有される顧客にとって、ポータルがより複雑になりました。まったく別のポータルにサインインしなければなりません。ナレッジベースもチャットボット機能も同様です。」

u/Music_hippie6, Reddit r/Zendesk

そこで、多くのガイドが飛ばす判断をひとつ。ブランド同士が顧客のほとんどを共有しているなら、ヘルプデスク上で別々のブランドは不要かもしれません。ブランド別カテゴリと「ブランド」チケットフィールドを備えた共有のヘルプセンターのほうが、フルのmultibrandよりサブブランド群には合うことがあります。別々のブランドが価値を持つのは、購入者から見てブランドの見た目が違う、売るものが違う、ポリシーが違うときです。

各ヘルプデスクはマルチブランドのサポートをどう扱うか

各ベンダーのブランド単位と、ブランドの声が置かれる場所を一覧にしました。価格は各ベンダー自身の料金ページに基づく年払いです。

表を読むよりクリックしたい方は、お使いのヘルプデスクを選んで、各ブランド設定の場所を確認してください。

Gorgias

Gorgiasはこのために作られています。マルチストアのページは「1ストアでも30ストアでも」使える1つのヘルプデスクをうたい、メインのコピーでは全プランでブランド数が無制限だと述べています(Gorgiasのマルチストアページ)。

各ストアに専用のサポートメールと署名があり、「エージェントが正しいブランドとして返信することを気にする必要がなくなります」。マクロとルールはブランド別にできます。AI AgentはShopifyストアごとにドロップダウンで設定し、4種類のパーソナリティ、最大3,000文字のカスタムトーン、各最大600文字の挨拶・結び・ブランド用語リストが使えます(Gorgiasのトーンオブボイスに関するドキュメント)。課金はエージェント単位ではなくチケット単位で、Basicは300チケットで月$50、Proは2,000チケットで$300です(Gorgiasの料金)。詳しくはGorgiasで複数ブランドを管理するで解説しています。

知っておくべき限界があります。ストア単位のAI AgentはShopifyストアを前提とした設計で、Gorgiasに「ストア」という単位があるのはECプラットフォームだけです。ストアではないブランドには、自然な居場所がありません。その他の点はGorgiasのレビューで扱っています。

Zendesk

Zendeskのmultibrandは、各ブランドに専用のヘルプセンターとサポートアドレスを提供します。Suite Professional(エージェント1人あたり月$115)は最大5ブランド、Suite Enterpriseは最大300ブランドに対応します(Zendeskのmultibrandに関するドキュメント)。

声のコントロールはAI側が最も強力です。各AIエージェントは独自のアイデンティティ(名前、会社、事業プロフィール)とトーン(Professional、Informal、Enthusiastic、Custom)を持ち、回答の長さや敬称の丁寧さも設定できます。Team以上のすべてのSuiteプランで利用できます(ZendeskのAIエージェントのトーンに関するドキュメント)。

人間による返信側は、上の声のセクションで述べたとおり手間がかかります。アカウント全体で1つのメールテンプレート、自動メールに付かないブランド署名、1つのブランドに限定できないマクロです。Zendeskで複数ブランドを管理するとZendeskのマルチブランド設定のガイドでトリガーを順に説明し、Zendesk Guideのマルチブランドヘルプセンターではヘルプセンター側を扱っています。

Freshdesk

FreshdeskはこれをMultiple Productsと呼び、製品ごとに専用のメールボックス、ブランド付きポータル、ナレッジベースを持てます。Pro(エージェント1人あたり月$55)で最大5つ、Enterpriseで無制限です(Freshdeskのmultiple productsに関するドキュメント)。より大きな構成では、Enterpriseでブランドごとにエージェント、SLA、自動化を分けるWorkspacesを依頼できます。AI側では、Freddy AI Agent Studioで各AIエージェントが学習するポータルを選び、指示の中でトーンと丁寧さを設定でき、アカウントごとに最大50のAIエージェントを持てます(FreshdeskのAIナレッジに関するドキュメント)。

製品別の署名やメールテンプレートは標準では用意されておらず、Freshdesk自身のヘルプセンターもそのためにMarketplaceのアプリを案内しています。詳しくはFreshdesk AIとFreshdeskの料金の記事をご覧ください。

Help Scout

Help Scoutの受信箱モデルはブランドにきれいに当てはまります。ブランドごとの受信箱が、専用のメールアドレス、署名、保存済み返信、SLAポリシーを持ちます。Plusには5つ、Proには10の受信箱が含まれ、追加は月$10です(Help Scoutの料金)。AI Agentは独自のソースと声を持ち、ブランドのBeaconに紐づけられるため、各ブランドが専用のAIを持てます(Help ScoutのAI Agentsに関するドキュメント)。

マルチストア向けヘルプデスクを巡るRedditのスレッドで、あるShopify事業者はこうまとめています。「5つの異なるShopifyストアにHelpscoutを使っていて、うまくいっています」(u/maydaygames, Reddit)。引き換えに生じるのは、すっきりした受信箱の裏返しです。1つの受信箱に限定されたエージェントは、別ブランドの受信箱にある購入者の履歴を見られません。残りはHelp Scoutのレビューをご覧ください。

Front

Frontはブランドをワークスペース(Professionalで最大5つ、1席月$65。Enterpriseで無制限)か、1つのワークスペース内の共有受信箱で分けます(Frontのワークスペースに関するドキュメント)。デフォルト署名はチャネルごとに設定され、差出人名も同時に決まるため、各ブランドのアドレスがそのブランドとして署名できます(Frontの署名に関するドキュメント)。ブランド別のAIトーン専用設定は見つかりませんでした。ナレッジソースはワークスペース設定にあります。詳しくはFront AIの記事をご覧ください。

マルチブランドのカスタマーサポートを6ステップで設定する

どのヘルプデスクを使っていても、私ならこの順番で進めます。

1. ブランドごとに、トーンとポリシーを1ページにまとめたカードを書く。 声、挨拶、結びの言葉、避ける言葉、返品期間、返金ルール、配送の約束。以降のすべてのステップは、このカードから貼り付けます。カスタマーサービスのトーンガイドにテンプレートがあり、AI側はAIサポートエージェントのブランドボイスで扱っています。
2. 入口でブランドを刻印する。 ブランドごとにメールアドレス、ウィジェット、ヘルプセンターを1つずつ用意し、すべてのチケットにブランドの必須フィールドかタグを付けます。ブランドなしで届いたチケットは、デフォルトを割り当てずにトリアージ用のビューに入れます。そのビューはチケットのトリアージを参照してください。
3. ルールを対にする。 トリガー、自動化、SLAごとに、ブランドごとに1つか、明示的な「全ブランド」条件付きの1つかを決めます。偶然1つのブランドにしか存在しないルールを残してはいけません。ブランド別の目標はSLAのベストプラクティスのガイドで扱っています。
4. マクロに接頭辞を付ける。 ブランド固有のマクロにはすべてブランド名を付けて(「ブランドA: 返品ラベル」)、エージェントが間違ったものを選ばないようにし、共有マクロはブランドに依存しない内容にします。命名のコツはマクロ入門にあります。
5. ブランドごとに専用のAIエージェントを置く。 ブランドごとに1つのエージェントを置き、それぞれをそのブランドのヘルプセンターと過去のチケットに向け、そのブランドのトーンカードを貼り付けます。誰かに回答する前に、過去のチケットで各エージェントをテストします。
6. ブランドフィルター付きでレポートし、毎月見直す。 ブランドごとの件数、初回応答時間、CSATと、人員計画のための統合ビューを1つ。ブランドの件数が共有チームで吸収できる量を超えて伸びたら、それがスペシャリストを加えるサインです。

ブランドごとに声が違うとき、AIはどこに収まるか

マルチブランドのサポートで最も早く問題が起きるのはAIです。共有のAIは、自分がどのブランドとして話しているのかを知らないからです。RedditのZendesk管理者がこの知識版を地域について語っていますが、ブランドにもそのまま当てはまります。AIは「言語や地域に関係なく、同じブランドに紐づくヘルプセンターから知識を引き出す」というのです(u/velvetvortext, Reddit r/Zendesk)。ブランドAとブランドBが同じ知識プールを共有していれば、ブランドBの顧客にブランドAの答えが届きます。

解決策は、うまいプロンプト1つではなく、ブランドごとに1つのAIエージェントです。eeselの顧客でこれが機能しているのを見てきました。Zendeskを使うマルチブランドのヘルス&ウェルネス企業は、ブランドごとに1つ、計5つの専用AIエージェントを動かし、それぞれが自分のブランドのチケットで学習して、担当する商品を把握しています。ShopifyとZendeskを使うマルチブランドのガーデニングECは、まずエージェント向けのコパイロットとしてeeselを導入し、その後AIライブチャットへ移行しました。そして今年の初め、GorgiasとZendeskのマルチブランドのチームが、ブランドごとの設定を自力でこなすには煩雑すぎて諦めるのを見ました。だから今は、各ブランドが個別にeeselに接続するのです。

現在のeeselではこうなります。

• 各ブランドを個別に接続する。 Zendeskの場合、ブランドのサブドメインをeeselに渡すと「そのブランドだけのチケットとヘルプセンター記事をインポート」し、各ブランドは「独自のトリガーとアクションを持つ別のエージェントに振り分けられます」(eeselのZendeskドキュメント)。FreshdeskやGorgiasのアカウントも同様に、1つのワークスペースに複数接続できます。Gorgias
• 各エージェントが独自の知識を保つ。 あるエージェントから連携を外しても、他のエージェントでは維持できます。指示の中で別ブランドのチケットを無視するよう伝えても、そこから学習することは止められません。止められるのは、そのチケットソースをオフにすることです。
• アクションはエージェントごと。 ブランドAのエージェントで返金を許可しても、ブランドBでは有効になりません(eeselのスキルに関するドキュメント)。返金ルールがブランドごとに違う場合に便利です。
• すべてのエージェントを最初にテストする。 シミュレーションスキルが各ブランドの過去のチケットを再生し、エージェントの回答をチームが実際に送った内容と比較します。

スクリプトで操作したいなら、eesel CLIもあります。同じワークスペースをターミナルから操作でき、eesel agents createで新しいエージェントを作り、--agent <name>で任意のコマンドを1つのブランドのエージェントに向けられます。6つ目のブランドの設定を、クリック作業の午後ではなくスクリプトで済ませられます。Claude Code、Cursor、Codexからも実行できます。

マルチブランドのサポートにeeselを試す

Gorgias、Zendesk、Freshdeskで複数のブランドを運営しているなら、eeselは各ブランドに専用のAIチームメイトを用意します。そのブランドの過去のチケットとヘルプセンターで学習し、そのブランドの声で書き、独自の返金・アクションのルールを持ちます。数分で既存のキューに参加し、誰かに回答する前に過去のチケットでテストでき、無制限のエージェントと席がすべてのプランに含まれます。料金は固定月額で、チケット1件が1クレジット。100クレジットの無料プランと、500クレジットで月$299からの有料プランがあります(eeselの料金)。

最初のブランドでeeselを無料で試し、仕上がりに納得できたら次のブランドを追加してください。