マルチクライアント対応ヘルプデスクとは何か、誰に必要か
マルチクライアント対応ヘルプデスクとは、1つのヘルプデスクアカウントを、1つのサポートチームが複数の独立した企業（それぞれ固有の顧客、トーン、ルールを持つ）に対応できるように設定したものです。「クライアント」の呼び方はヘルプデスクごとに違います。ZendeskとDeskproではブランド、Freshdeskでは製品またはWorkspace、Help ScoutではInbox、Frontではワークスペース、Gorgiasではストア、Zoho Deskでは部署、HaloPSAではカスタマーです。
次の4種類のチームが運用しています。
- 代理店：複数のブランドにサポートをサービスとして販売し、マーケティングや開発の仕事と並行することが多い形です。このビジネスモデルは私の代理店向けAIサポートの記事で扱っています。
- アウトソースのサポートチーム（BPO）：クライアント企業のキューを担当します。私のカスタマーサービスのアウトソーシングのガイドをご覧ください。
- MSP：多くのクライアント企業のITサポートを、通常はPSAツールで運用します。MSP向けチケットシステムのまとめで詳しく扱っています。
- 複数ブランドを持つ企業：複数のストアや製品ラインの背後に1つのサポートチームがある形です。
私はこの数年、eeselの裏側にあるヘルプデスク連携を作ってきましたが、最も多くを学んだのは複数ブランドの構成でした。今年初め、3ブランドを持つGorgiasのチーム、記事セットの異なる2つのエージェントを必要としたZendeskのチーム、ブランドを分けたZendesk構成のチームが、eeselで同じ壁にぶつかりました。ブランドごとの設定は自力で行うには難しすぎ、同じアカウントの2人のユーザーがそれが原因で解約しました。そのため、現在はZendeskの各ブランドを個別にeeselへ接続でき、それぞれ専用のエージェントを指定できます。現在、Zendeskを使う複数ブランドのウェルネス企業が、eeselでブランドごとに1つ、計5つ専用のAIエージェントを稼働させ、それぞれがそのブランド自身のチケットから学習しています。
これらの導入から得た教訓が、この記事の主張です。受信トレイを分けるのは半日で終わります。クライアント同士が混ざらないようにするのが、本当のプロジェクトです。
受信トレイは簡単な部分
私が調べたどのヘルプデスクも、各クライアントに専用の玄関を用意できます。問題は、その奥の部屋です。
ほとんどのツールで、クライアントごとにきれいに分けられるものは次のとおりです。
- メールアドレスと受信トレイ。 Zendeskはブランドごとにサポートアドレスを作成し、Help Scoutは各Inboxに専用の共有メールボックスを持たせ、Gorgiasは各ストアに専用のサポートメールと署名を持たせます。
- ヘルプセンター。 Zendeskの各ブランドは専用のヘルプセンターを持て、Freshdeskの各製品にはポータルがあり、Zoho Deskの各部署はEnterpriseでブランド化したポータルを持てます。
- SLA目標。 Help ScoutはInboxごとにSLAポリシーを設定し、Deskproはブランドごと、HaloPSAはサイトごとです。
- 保存済み返信とマクロ。 Help Scoutは保存済み返信をInboxごとに分け、Gorgiasにはブランド固有のマクロとルールがあります。
そして、各ベンダーのドキュメントから見て、共有されたままになりがちなものは次のとおりです。
| 共有されたままのもの | ベンダーがそう述べている場所 |
|---|---|
| 顧客レコード | Zendesk：「エンドユーザーや組織をブランドで分けることはできません」（マルチブランドのドキュメント）。Front：ワークスペースは「連絡先データのサイロを提供しません」（Frontヘルプ）。Freshdesk：連絡先と会社はWorkspaceの範囲に限定されません。HubSpot：連絡先はBrandsプロパティでフィルタされるだけで、分離はされません |
| 管理者アクセス | Zendeskの管理者はすべてのブランドに追加され、外せません。Freshdeskの管理者は自動的にすべてのWorkspaceに参加します。HubSpotのスーパー管理者は、制限されたアセットを常に閲覧できます |
| チケットフィールドとテンプレート | FreshdeskはWorkspace間でチケットフィールド、フォーム、テンプレート、ロール、グローバル自動化を共有します（Workspacesのドキュメント）。Zendeskはアカウント全体で1つのメールテンプレートです |
| ナレッジの編集 | Help Scoutでは、1つのクライアントのInboxに限定された一般ユーザーでも「すべてのDocsサイトで記事を作成・編集」できます（ロールのドキュメント） |
これらはいずれも、その製品の欠陥ではありません。複数ブランドを持つ1つの会社向けに作られており、10社の無関係なクライアントのデータを預かる代理店とは、信頼モデルが違うだけです。どちらのモデルを買うのかを知っておく必要があります。
マルチクライアント構成が漏れる3つのパターン
マルチクライアント対応ヘルプデスクがうまくいかないとき、ほぼ必ず次の3つのどれかです。構成は、これらから逆算して設計することをおすすめします。
1. 間違ったブランドから返信が送られる
クライアントが気づくのはこれです。顧客が、他社の署名入りのメールを受け取ってしまうからです。原因はありふれています。Zendeskではアカウントにメールテンプレートが1つしかないため、ブランド固有のメールには別々のトリガーが必要で、「トリガーのセットは1つしかない」ため、ブランド条件で絞り込む必要があります。サポートアドレスのブランドは後から変更できず、削除して作り直すことになります。トリガーが、ブランド外の担当者にチケットを割り当ててしまい、その担当者がアクセスエラーに遭遇することさえあります。
これはブランドだけの問題ではありません。Redditで、あるMSPが、クライアントが別のベンダーのチケットメールを転送し、それが自社PSAのチケット番号と一致した事例を書いていました。
「そのメールの件名にあるチケット番号が、別のクライアント向けにクローズしていたチケットを再オープンさせ、その後、うちのクライアントが、なぜフォローしなかったのかと不思議がることになった」
対策は地味ですが効きます。クライアントごとに1つのサポートアドレスを持ち、メールを送るすべてのトリガーにブランド条件を付け、変更のたびに各クライアントのアドレスへテストチケットを送ることです。
2. 顧客レコードがクライアント間で共有される
2つのクライアントが同じエンド顧客を共有している場合（同じ親会社の複数ブランドに対応するBPOや、クライアントのスタッフが会社間を移るMSPでよくあります）、連絡先レコードは通常アカウント内に1つだけ存在します。Frontは、同じ連絡先が2つのワークスペースにメッセージを送ると、カスタムフィールドが共有されると警告しています。HubSpotのブランドに関連づけられた連絡先プロパティは「ブランドに関連づけられた連絡先だけでなく、すべての連絡先で利用可能」です（HubSpotのドキュメント）。
複数ブランドを持つほとんどの企業にとっては、それで問題なく、むしろ便利です。無関係なクライアントのデータを預かる代理店にとっては、別アカウントにする最も強い理由になります。
3. AIが間違ったクライアントのナレッジから回答する
これは最も新しい漏れ方で、私が最も心配しているものです。AIの返信を1件ずつ読む人はいないからです。1つのAIエージェントが5クライアントのヘルプセンターを見られる状態だと、遅かれ早かれ、クライアントAの返金ポリシーをクライアントBの顧客に伝えてしまいます。
各ヘルプデスク自前のAIは、これを別々の方法で扱います。Zendeskは1つのAIエージェントを1つのブランドのヘルプセンターに紐づけ、チャネルごとに有効なAIエージェントを1つだけにし、メールでは複数ではなくブランドごとに調整した1つのエージェントを推奨しています。Freshdeskは各FreddyのAIエージェントが学習するポータルを選べますが、ウェブサイトのソースはアカウントあたり25件までで、10クライアントが3つのURLずつ持つと収まりません（Freshdeskのドキュメント）。AI側については後ほど詳しく扱います。
2つの地域向けにZendeskを設定していたサポートリードが、Redditでまさにこれに遭遇していました。
「Zendesk AIは、言語や地域にかかわらず、同じブランドにリンクされたヘルプセンターから知識を引き出します。だから、ブラジルの顧客が何か質問すると、AIは関連するすべてのコンテンツ、米国向けに作ったばかりの記事まで根拠にして回答するかもしれません。」
その人の代替案は、地域ごとに1ブランドを置き、ヘルプセンターとAI設定を分けることでした。マルチクライアント構成では、私が信頼できるのはこの形だけです。
各ヘルプデスクは複数のクライアントをどう扱うか
並べて比較します。価格は各ベンダーの料金ページの2026年10月時点の、年払いでの担当者1人あたり月額で、「厳格な壁」とは、担当者が別のクライアントのチケットを見られなくする設定のことで、表示フィルターではありません。
| ヘルプデスク | クライアント単位 | 対応する最安プラン | 含まれるクライアント数 | 担当者の厳格な壁 | クライアントごとのAI | 共有されたままのもの |
|---|---|---|---|---|---|---|
| Zendesk | ブランド | Suite Professional $115 | 5（Enterpriseは300） | Enterpriseのみ（部署スペース） | ブランドのヘルプセンターごとにAIエージェント、チャネルごとに1つ | エンドユーザー、組織、メールテンプレート、管理者 |
| Freshdesk | 製品またはWorkspace | Pro $55 | 5製品（Enterpriseは無制限）、EnterpriseでWorkspace 30 | Workspaces、Enterprise $89、リクエスト制 | FreddyのAIエージェントがポータルを選択、アカウントあたりURL 25件 | 連絡先、ロール、チケットフィールド、テンプレート |
| Help Scout | Inbox | Standard $25（Inbox 2つ） | 2 / 5 / 10、追加Inbox $10 | すべてのプラン | クライアントのBeaconごとにAIエージェント1つ | すべてのサイトにわたるDocsの編集 |
| Front | ワークスペース | Professional $65 | 5（Enterpriseは無制限） | ワークスペースのロール、Enterpriseはカスタムロール | ワークスペースごとのナレッジソース | 連絡先、請求、連携 |
| Gorgias | ストア | 任意のプラン（チケット従量課金、300チケットで$50から） | 「1ストアでも30ストアでも」 | 記載なし | Shopifyストアごとに1つのAIエージェント | アカウント全体のロール |
| Zoho Desk | 部署 | Professional $23 | 10（Enterpriseは50） | 部署の割り当て | 部署ごとのAnswer Bot | ドキュメントに記載なし |
| HubSpot Service Hub | ブランド（アドオン） | Marketing Hub Enterpriseでブランドあたり月額$1,000 | 最大100 | ブランドベースのルールは見つからず | ブランドごとに1つのカスタマーエージェント | 連絡先 |
| Deskpro | ブランド | Team $39（最低5担当者） | ヘルプセンター 3 / 10 / 無制限 | ブランドごとの権限 | ブランドごとの記載なし | 記載なし |
| HaloPSA | カスタマー > サイト | £69、単一ティア | 無制限、カスタマーは無料 | 担当者ごとのクライアント制限 | カスタマーごとのKBリスト | 記載なし |
私の見立てです。Zoho DeskとHelp Scoutは、実際に機能する壁としては最も安く、FreshdeskのWorkspacesは最も深く、Zendeskは最も高機能ですが、壁のためにEnterpriseの料金を求められます。以下では、それぞれで実際に何をクリックするかを見ていきます。
Zendesk
Zendeskはこれをマルチブランドと呼び、Admin Center > Account > Brand managementで管理します。Suite GrowthとProfessionalには5ブランドと5つのヘルプセンターがあり、Suite EnterpriseとEnterprise Plusは300です。現在のZendesk料金ページではSuite Teamのヘルプセンターは1つなので、複数を持てる最安の公開プランは$115のSuite Professionalです。
1つのキューからブランドを運用するのは、設定が済めばうまく機能します。G2のあるZendeskレビュアーは、2つのブランドにわたって「1つのチームが同じキューから働く」ことを気に入っていましたが、複数ブランドの管理者なら誰もが覚えのある正直な注意点も述べていました。
「2つのブランドでトリガーと自動化の一貫性を保つのは、思っていたより手間がかかった。1つのブランド用にルールを作って、もう一方に反映するのをすっかり忘れていた」
落とし穴はアクセスです。担当者を所属ブランドに限定する部署スペースには、Customer Service Suite EnterpriseまたはSupport Enterpriseが必要です。新しいチームメンバーはデフォルトですべてのブランドに参加し、管理者は「すべてのブランドのメンバーでなければなりません」。GrowthとProfessionalでの回避策は、ブランドごとにグループを作り、各担当者のプロフィールで「所属グループのチケット」に設定することです。クリック単位の手順は、私のZendeskマルチブランド設定の記事にあります。
Freshdesk
Freshdeskには2つの層があります。Multiple Productsは、各クライアントにメールボックス、ポータル、ナレッジベースを与え、Pro（$55）では最大5つ、Enterprise（$89）では無制限です。ただし、ルーティングとチケットスコープのルールを追加しない限り、「担当者はチケットビューですべての製品のチケットを見られます」。
新しいほうの層がWorkspacesです。1つのアカウント内に最大30の独立したサポート運用を作れ、それぞれが専用の担当者、グループ、SLA、自動化、メール、ポータル、ナレッジベースを持ちます。Enterprise限定で、リクエストにより有効化されます。1つの担当者ライセンスで、その担当者が所属するすべてのWorkspaceをカバーできるため、スタッフを共有するBPOには重要です。
導入を決める前に知っておきたいWorkspaceの2つの点があります。Workspaceは作成後に削除できないこと、そしてFreshdesk自身が、請求の分離や法的所有権が必要なら別アカウントが適切かもしれないと述べていることです。Freddyのプランごとの制限は、私のFreshdesk AIの解説で扱っています。
Help Scout
Help Scoutの単位はInboxで、私が見つけた中で最も代理店向きのデフォルトを備えています。すべてのプランで、ユーザーは「指定されたInboxにしかアクセスできません」。プランには2、5、10のInboxが含まれ、追加は月額$10、Docsサイト（ヘルプセンター）は2、3、5つで、追加は$20です。保存済み返信とSLAはどちらもInboxごとに設定されます。
AIについては、クライアントごとに専用のナレッジソースを持つAIエージェントを1つ作り、そのクライアントのBeacon（チャットウィジェット）にリンクします。AI AnswersはHelp Scout料金ページで1解決あたり$0.75です。
抜け穴はDocsが壁で隔てられていないことです。ユーザーをクライアントAのInboxに限定しても、クライアントBのヘルプセンターの編集は止められません。クライアントが自分の記事を誰が触るかを気にするなら、編集権限は少人数のグループに限ってください。詳しくは私のHelp Scoutの代替の記事をご覧ください。
Front
Frontはクライアントをワークスペースに分け、それぞれが「独自のワークフロー、分析、タグやメッセージテンプレートなどのリソース」を持ちます。Starterは1つ、Professional（$65）は最大5つ、Enterpriseは無制限です。各チームメンバーにはワークスペースごとにロールが付きます。アクセスなし、管理者、メンバーのいずれかです。
FrontのAIナレッジソースはワークスペース設定にあるため、クライアントごとに1つのワークスペースを置くことが、各クライアントに専用のAIナレッジを持たせる方法にもなります。プランは組織レベルで設定されるので、1つのクライアントをStarter、別のクライアントをEnterpriseにはできません。Autopilotの料金は、1会話$0.05から始まり、私のFront AIの記事で扱っています。
Gorgias
Gorgiasは、複数のECストアを運用する代理店に自然に合います。担当者ではなくチケット単位で課金されるからです。「1ストアでも30ストアでも、1つのGorgiasヘルプデスクですべて管理できます。」各ストアは専用のチャネル、サポートメール、マクロ、ルールを持ち、「接続するShopifyストアごとに専用のAIエージェントを持てます」。ストアあたりガイダンスは最大100件です。
ドキュメントから2つの注意点があります。ストアごとのAIエージェントはShopifyストア向けの記述であること、そしてエージェントを1つのストアのチケットに限定する設定は見つからなかったことです。ストアを削除すると「関連するすべての連携とデータが削除される」ため、クライアントの契約終了時の処理は慎重に行ってください。さらに詳しくは、私のGorgiasで複数ブランドを管理するガイドをご覧ください。
Zoho Desk、HubSpot、Deskpro、HaloPSA
- Zoho Deskは部署を使います。Professional（
$23）で最大10、Enterprise（$40）で50、アドオンで最大500です。割り当てられると、担当者は「その部署に属するチケットだけにアクセスして閲覧できます」（Zohoのドキュメント）。部署ごとのブランド化したヘルプセンターにはEnterpriseが必要で、ブランドごとの別ログインへの切り替えは、Zohoサポートなしでは元に戻せません。Ziaについては、私のZoho Desk AIの記事で扱っています。 - HubSpot Service Hubは、HubSpot Brandsで複数のブランドを扱います。これはMarketing Hub Enterpriseでのみ販売されるブランドあたり月額
$1,000のアドオンです。ブランドごとに1つのカスタマーエージェントが使えるようになります。より安い選択肢は、私のHubSpot AIの代替の記事で扱っています。HubSpot自身の比較表も、Brandsは「大きく異なるビジネス・データモデル」には向かないと述べており、これはほとんどの代理店に当てはまります。 - Deskproは、各ブランドに専用のヘルプセンター、SLA目標、レポートを与え、ブランドAの担当者は「明示的に付与されない限りブランドBのチケットを一切見られません」と述べています。料金ページでは、ブランド化されたヘルプセンターの数がプランごとに
3、10、無制限に制限されています。 - HaloPSAはMSP向けに作られています。カスタマー、サイト、ユーザー、サイトごとのSLA、カスタマーごとのKBリスト、担当者ごとのクライアント制限があり、担当者1人あたり
£69の単一価格で、カスタマーとポータルユーザーは無料です。
1つのアカウントに複数ブランドか、別アカウントか
設定に触れる前に答えを出すべき問いです。元に戻すのに費用がかかるからです。2つの質問で決まります。
- クライアントは、専用の請求やデータの法的所有権を必要としますか？ そうなら、専用のアカウントを与えてください。FreshdeskのWorkspacesガイド自身もこの方向を示しており、共有される連絡先レコードが問題でなくなる唯一の構成です。
- 担当者が他のクライアントのチケットを見られないようにする必要がありますか？ そうなら、厳格な壁があるプランを予算に入れてください。ZendeskやFreshdeskならEnterprise、Help Scoutならどのプランでも、Zoho Deskなら部署の割り当てです。表示フィルターは壁ではありません。
両方の答えがいいえなら、1つのアカウント内のブランドのほうが安く、クライアントをまたいで人員配置しやすく、レポートも1か所にまとまります。複数ブランドを持つほとんどの企業はここに落ち着きます。無関係なクライアントと厳格な契約を持つ多くの代理店は、そうなりません。
2つ目の質問が、人々がつまずくところです。パートナーが、紹介した顧客のデータをオフショアの担当者から遠ざけたいと求めたZendesk管理者は、アプリ内のツールではそこまで届かないことに気づきました。
「簡単に使える標準の解決策が見当たらない…ブランドや組織では足りない。2つ目のZDインスタンスなら可能かもしれないが」
クライアントの契約に「この担当者のみ、このデータのみ」とあるなら、別アカウントから始めて逆算してください。オンショアとオフショアの分担は、私のオフショアサポート向けAIの記事でさらに詳しく扱っています。
マルチクライアント対応ヘルプデスクを7ステップで構築する
1つのアカウントにするか複数にするかを決めたら、私ならこの順番で進めます。ステップ1〜3は間違ったブランドからの返信を防ぎ、ステップ4〜7は各クライアントのサービスレベルを正直に保ちます。
- クライアントごとに1つのクライアント単位を作り、クライアントの呼び方で名前を付ける。 ブランド、製品、Inbox、ワークスペースのいずれかを1つずつ。メールやヘルプセンターのヘッダーに表示されるので、クライアントが顧客向けに使う名前にしてください。
- 各クライアントに専用のサポートアドレスと署名を与える。 その後、メールを送信するすべてのトリガーやチケットルーティングルールにブランド条件を追加します。すべてのアドレスにテストチケットを送ってください。
- 担当者を追加する前に、デフォルトのアクセスを変更する。 Zendeskでは、変更しない限り新しいチームメンバーはすべてのブランドに参加します。担当者ごとに対応するクライアントを決め、ほとんどのツールで管理者はすべてを見られるため、管理者は可能な限り少人数に絞ってください。
- 契約に基づいてクライアントごとにSLA目標を設定する。 クライアントごとに支払う応答時間は異なります。クライアントごとのSLAポリシーを使います（Help ScoutはInboxごと、Zendeskはブランド条件付き、FreshdeskはWorkspaceごと）。目標設定は私のSLAのベストプラクティスのガイドで、ブランドフィルターはZendeskのSLA条件で扱っています。
- クライアントごとに別のナレッジベースを作る。 クライアントごとに1つのヘルプセンターを置き、そのクライアントをよく知る人が管理します。共有ナレッジベースは、人間でもAIでも、クライアントをまたぐ誤答のほとんどの根本原因です。所有者の決め方は、私のナレッジベース管理の記事で扱っています。
- 各クライアントに専用のAIエージェントを与え、そのクライアントの過去のチケットでテストする。 クライアントをまたぐ1つのAIエージェントにはしないでください。詳しくは次のセクションで説明します。
- 毎月、クライアントごとにレポートする。 クライアント単位で絞り込んで、件数、初回応答、解決、CSATを見れば、請求と契約レビューを同じ数字から作れます。チケットが移動してもレポートが保たれるよう、作成時にすべてのチケットへクライアントのタグを付けてください。
クライアントをまたいでオフショアやシフト制のスタッフを追加する場合は、私のフォロー・ザ・サン型サポートとサポートのシフト引き継ぎの記事が引き継ぎ面を扱っています。
クライアントごとに違うとき、AIはどこに入るのか
マルチクライアント対応ヘルプデスクがAIから得るものも、AIで抱えるリスクも最大です。件数の面は簡単です。eeselとの営業電話で話した、複数ブランドを持つあるEC事業者は、返金、配信停止、注文追跡を中心に、複数のブランドで1日500件以上のチケットを処理しています。これらのチケットはどのクライアントでも似て見えます。回答は違います。クライアントごとに返金期間、配送パートナー、トーンが違うからです。
だから私は、3つのルールを守ります。
- クライアントごとに1つのAIエージェントを置き、そのクライアントのナレッジだけを持たせる。 「どのブランドか確認して」という指示を持つ1つのエージェントではありません。
- クライアントごとのアクション。 クライアントAは
$50未満の自動返金を許可し、クライアントBは一切許可しないかもしれません。権限は共有プロンプトではなく、クライアントのエージェントに置くべきです。 - まず各クライアントの履歴で証明する。 1つのクライアントでうまくいった導入は、次のクライアントについて何も教えてくれません。
これをeeselでどう実現するかを説明します。私が一部を作ったので、具体的に述べます。
各クライアントは、1つのワークスペース内で専用のエージェントを持ちます。 Zendesk、Help Scout、Frontのどれを使っていても、すべてのeeselプランに無制限のエージェントと席が含まれ、ヘルプデスクのエージェントは1つのアカウントで「それぞれが専用のナレッジと指示を持って」稼働します。Zendeskの場合、「各ブランドは個別に接続され、それぞれが専用のトリガーとアクションを持つ別のエージェントに振り分けられます」。eeselはそのブランドのチケットとヘルプセンター記事だけをインポートします（eeselのZendeskドキュメント）。Freshdesk、Gorgias、Zoho Deskは、1つのワークスペースに複数の接続アカウントを受け付け、各自動化は1つのアカウントに属します。構築した立場から注意点を1つ挙げます。接続するブランドの担当者としてZendeskに先にサインインしてください。そうしないと、Zendeskがデフォルトのブランドに誘導し、接続されるのはそちらになります。
ナレッジは置いた場所にとどまります。 連携は、あるエージェントから外して、他のエージェントには残せます。クライアントのチケット履歴をエージェントに学習させたくない場合は、そのTicketsソースをオフにしてください。指示の中で過去のチケットを無視するよう伝えても、学習は止まりません。あなたのデータは自分のエージェントにのみ使われ、基盤モデルの学習には使われません（eeselのセキュリティドキュメント）。
アクションはエージェントごとです。 「すべてのアクションは、自動で実行するか、先に確認を求めるか、オフのままにするかを選べます。エージェントごとに選びます」（eeselのアクションドキュメント）。そのため、クライアントAの返金ルールがクライアントBに影響することはありません。
公開前に各クライアントをテストします。 Simulationスキルは、実際の過去のチケットをリプレイし、エージェントの回答をチームが実際に送った内容と比較します。BPOにとっては、クライアントに見せられるクライアントごとの稼働前チェックになり、ミスの扱いは私のサポートのエラー分析のガイドで扱っています。ドキュメントでは、1つのキューや1つのブランドずつ展開することも推奨しています。その範囲外はチームの担当のままで、費用もかかりません。
多くのクライアントを扱うならスクリプト化します。 数週間ごとに新しいクライアントを迎えるなら、eesel CLIでターミナルから行えます。eesel agents createが新しいクライアント用に新しいエージェントを作成し、すべてのコマンドが--agent <name>を受け付けるので、他に触れずに1つのクライアントの指示やナレッジを更新できます。EESEL_API_URLとEESEL_API_TOKENを設定すれば、同じコマンドをスクリプトやCIジョブから実行できます。すべてのワークスペースはMCPサーバーでもあるため、Claude CodeやCursorのようなコーディングエージェントも同じセットアップを操作できます。毎回同じ手順でクライアントを迎える代理店なら、チェックリストがスクリプトになります。
料金はクライアント間でプールされます。 eeselの料金は固定の月額クレジットプランで、チケットまたはチャット1件が1クレジットです。100クレジットのFree、500クレジットの$299から5,000クレジットの$1,899までのTeammateがあり、席料やプラットフォーム料はなく、超過分は1クレジット$0.80で任意に利用できます。クレジットはワークスペース単位なので、6つの小さなクライアントが6つのサブスクリプションではなく1つのプランを使います。
eeselにできないことも述べておきます。計画に織り込んでください。現時点では、リセラーやホワイトラベルのプログラムはありません（10社以上のクライアント企業にわたって22のワークスペースを運用する代理店がeeselに求めましたが、違うかのように匂わせるより、はっきり言うほうがよいと考えます）。チームロール（Owner、Editor、Viewer）はワークスペース全体に適用され、1つのクライアントのエージェントには適用されないため、クライアントが専用の権限を持つ専用ログインを必要とするなら、そのクライアントに専用のワークスペースを与えてください。また、今年初め、eeselをコパイロットとして使う民泊サポートのアウトソーサーが、顧客が「頻繁にスクリーンショットを共有する」ため、担当者が手で書き起こす必要があるとeeselチームに伝えました。クライアントのチケットが画像中心なら、完全自律に切り替える前にサンプルで試してください。リセラーの問題は、私のホワイトラベルAIの記事でより広く扱っています。
マルチクライアント対応ヘルプデスクにeeselを試す
複数のクライアントやブランドのサポートを運用しているなら、eeselは1つのワークスペースで、それぞれに専用のAIヘルプデスクチームメイトを提供します。Zendeskの各ブランドを個別に接続し（または複数のFreshdesk、Gorgias、Zoho Deskアカウント）、各エージェントをそのクライアントのチケットとヘルプセンターだけで学習させ、アクションとトーンを別々に設定し、誰かに返信する前に過去のチケットをリプレイできます。100クレジットで無料で試せ、すべてのプランに無制限のエージェントが含まれるため、次のクライアントの追加は、そのチケットが届き始めるまで費用がかかりません。
