分散型サポート運用とは？
分散型サポート運用とは、複数の場所にメンバーがいるカスタマーサポートチームを運営することです。同じ国内の2つのオフィス、24時間キューを受け渡す3つの拠点、大陸中に散らばるリモート担当者、夜間や週末を担うオフショアパートナーを持つ社内チームなど、さまざまな形があります。
私はこの分野の検索データを数多く見ていますが、このテーマで人々が尋ねるのは「他の国でどう採用するか」ではほとんどありません。運用面の質問です。拠点間でチケットをどうルーティングするか、なぜ拠点ごとに回答が違うのか、なぜレポートが合わないのか。このガイドが扱うのはそこです。
ほとんどの分散型チームは次の4つの形のどれかに当てはまります。それぞれに弱点があり、多くはより詳しいガイドがすでにあります。
| 形態 | 概要 | よくある破綻点 | 次に読む |
|---|---|---|---|
| 複数拠点、同じ営業時間 | 2つ以上のオフィスが同じ営業日をカバー | 作業の重複、オフィスごとに異なる習慣 | このガイド |
| フォロー・ザ・サン | 2〜3の拠点がタイムゾーンをまたいでキューを受け渡す | 拠点間の引き継ぎ | フォロー・ザ・サンサポート |
| 社内＋外部委託 | 自社チームとBPOまたはオフショアパートナー | ナレッジと品質のギャップ | オフショアのナレッジ移管 |
| 完全リモート | 多くの場所に担当者がおり、非同期で働くことが多い | 担当の所在と応答の約束 | 非同期サポート |
実際のチームはこれらを組み合わせています。よく見るのは、リモートのコアチーム、夜間を担うパートナー、言語対応の地域スペシャリスト数名という構成です。以下の運用ルールはどれにも当てはまります。
分散型サポートチームがバラバラになる理由
どの拠点も同じプレイブックから始まります。6か月後には、もう同じプレイブックではなくなっています。誰かが決めたわけではなく、小さな回避策が積み重なって起きたことです。ある拠点が速いマクロを見つけても共有しない。別の拠点は、もう一方の拠点が参加していなかった通話でポリシー変更を知る。3つ目の拠点は、マネージャーが新しいレポートを欲しがったためにタグ付けの方法を変える。
小規模なマルチリージョンチームのエンジニアが、根本原因を的確に言い表しています。
"The communication costs from time zones are real, and it makes everyone's context on what is going on different because they see updates from different regions."
ドリフトは、あなたより先にお客様が感じ取ります。同じ質問を2回すると、どの拠点が対応したかによって2つの異なる回答が返ってきます。そして拠点ごとに評価方法が違えば、行動も違ってきます。外部委託のTier 1チームがほとんどエスカレーションしない理由を説明したHNのコメント投稿者は、それを評価のされ方のせいだとしました。
"The problem, of course, is that Tier 1 support are outsourced and a huge part of their evaluations are how many tickets they close. Escalating hurts their numbers, so it's hard to get cases escalated"
これは人の問題ではありません。ある拠点にはクローズを、別の拠点には解決を評価するような仕組みを作っておきながら、結果が違うことに驚いているのです。以下の内容の大半は、本来違ってはいけないところで拠点間の違いが許されている箇所を取り除くことに関するものです。
全拠点で同じものと、ローカルで決めるものを分ける
分散型チームのために費やせる最も有益な1時間は、2つのリストを書き出すことです。1つ目は、どの拠点でも同一でなければならないもの。2つ目は、各拠点が自分で決めてよいもの。それ以外は、決着するまで何度も繰り返すことになる議論です。
私ならこの分け方から始めます。
どこでも同じもの：
- 1つのキュー。 すべての拠点が同じヘルプデスクのインスタンスで働き、顧客の履歴全体が見える状態にします。
- 1つのナレッジベース。 社内向け・社外向けの記事は、拠点ごとのドキュメントではなく、担当者を明記して1か所に置きます。構成については社内ナレッジベースのガイドをご覧ください。
- 1つのQAスコアカード。 同じ基準を、どの拠点でも同じ方法で採点します。
- 指標の定義。 「初回応答」が何を指すか、どの時間を数えるか、レポートにどのタイムゾーンを使うか。
- エスカレーション経路。 どの拠点が見つけたかに関係なく、請求トラブルやバグを誰が担当するか。部門横断のエスカレーションを参照してください。
拠点ごとに決めるもの：
- 営業時間と祝日。 各拠点には独自のカレンダーがあり、SLAもそれを尊重すべきです。
- 言語。 言語別のキューは、その言語を話せる拠点へルーティングします。
- 現地の連絡先。 当番リーダー、現地の経理担当、その市場で返金を承認できる人。
データの所在地は、このパターンが崩れることがある項目です。規制のある市場に販売する場合は、ヘルプデスクがデータをどこに保存するかを確認してください。ZendeskのData Center Locationアドオンは"free of charge for Zendesk Suite Professional or higher plans, but it is not automatically activated"で、米国、EEA、英国、日本、オーストラリアに対応しています。Freshdeskではサインアップ時にデータの所在地を選べます。さらに詳しくはFreshdeskのデータレジデンシーのガイドをご覧ください。なお、Zendeskはサービスデータを1か所でホストするため、1つのインスタンスを同時に2つのリージョンに置くことはできません。
拠点ごとの受信箱ではなく、1つのキューで運用する
最もよくある初期の間違いは、各拠点に専用の受信箱やメールアドレスを与えることです。整然として見えます。各オフィスが自分の仕事を見て、誰も邪魔し合いません。しかし実際には、チームの他のメンバーから作業量が見えなくなり、誰のものでもないチケットが生まれます。ある小規模事業のオーナーが、まさにこれをRedditで述べていました。
"We are looking for a way to manage out digital customer interactions in three offices, for one business. Each office has its own email address with multiple employees using the same email address. We are constantly failing to respond to 100% of customer messages because one employee will open the email of another's and then it will never been seen by its intended target."
より良いパターンは、1つのキューをルーティングで分けることです。すべてのチケットが同じ場所に届き、その後ルールが次の3つの基準で適切な拠点へ振り分けます。
- スケジュール。 今まさに稼働しているのは誰か。各拠点の営業時間と組み合わせて、拠点が閉まっている時間をSLAが数えないようにします。
- 言語。 スペイン語はマドリードのチームへ、ドイツ語はベルリンの時間帯へ、といった具合です。
- スキル。 請求、技術、VIP、特定の製品ラインなど、拠点を問いません。
各拠点には、自分たちの仕事のビュー（自グループで絞り込んだビューやフォルダ）が引き続き用意されるため、「整然とした」感覚は保たれます。変わるのは、マネージャーがキュー全体を一度に見渡せること、そして1つの拠点で対応できないチケットを、顧客の履歴を置き去りにせず別の拠点へ移せることです。ルーティングルールが働くようにチケットへタグを付ける方法は、チケットトリアージのガイドで解説しています。
各ヘルプデスクのマルチ拠点スケジュールとルーティングの扱い
ここでプランが重要になります。分散型チームに必要な機能（複数の営業時間カレンダー、スキルや言語によるルーティング）は、小規模チームが使い始めるプランより1〜2段階上にあることが多いです。2026年10月時点で各ヘルプデスクが文書化している内容は次のとおりです。
| Zendesk | Freshdesk | Help Scout | Gorgias | Front | |
|---|---|---|---|---|---|
| 複数の営業時間 | Enterpriseのみ | Pro（$55）以上 | Plus（$45）以上 | Basic（$60/月）以上 | Professional（$65）以上 |
| チケットがスケジュールを選ぶ方法 | スケジュールごとに1つのトリガー（グループ、ブランド、ステータス） | グループに紐付け | 受信箱ごと | 連携（ストアまたはチャネル）ごと | 受信箱ごと |
| スキルまたは言語によるルーティング | Suite Professional（$115）以上でスキル | Enterprise（$89）でスキル | スキル機能なし。PlusでTeamsとワークフロー | ルール内の言語検出、全プラン | ルールと負荷分散。スキル機能なし |
| レポートのタイムゾーン | 閲覧者ごとのプロフィールのタイムゾーン | ヘルプデスクの1つのタイムゾーン | 会社の1つのタイムゾーン | 未確認 | 未確認 |
| 組み込みのQAスコアリング | QAアドオンまたはWEMバンドル（$50） | 人間の担当者向けはなし | なし | Auto QA（AI Agentサブスクリプション付き） | Smart QA、$20/シートまたはEnterpriseに含む |
価格は年払いの1エージェントあたり月額です。ただしGorgiasはチケット量で課金されます。各列の詳細は以下のとおりです。
Zendesk
Zendeskの制限は驚かれることがあります。スケジュールに関するドキュメントははっきり述べています。"On Suite Growth and Professional or Support Professional, you can set only one schedule. On Enterprise plans you can set multiple schedules." つまり、Suite Professionalを使う3拠点のチームは、全員で1セットの営業時間しか持てません。
Enterpriseでは、最初のスケジュールがデフォルトとなり、"you need to create a trigger for each schedule"、通常はチケットのグループ、ブランド、ステータスに対して作成します。ルーティングは下位プランのほうが強力です。スキルベースのルーティングでは、Suite Professional（$115）以上で"define up to 10 skill types. Each skill type can contain up to 30 skills"ができます。言語は自然なスキルタイプです。オムニチャネルの設定はZendeskのルーティングのガイドで解説しており、Zendesk自身のフォロー・ザ・サンの記事でも、リージョンごとのグループを推奨しています。
Freshdesk
Freshdeskでは、Pro（$55）から早めに複数の営業時間が使えます。注意点は、その適用方法です。Freshdeskのドキュメントによれば、営業時間は"cannot be applied to tickets unless they are first mapped to a group. Each group can be assigned its own business hours (for example, EU, North America, or Asia)."とされています。
つまりFreshdeskでは、グループがあなたの拠点です。グループを所在地（または所在地とティア）を軸に設計すれば、SLAポリシーもそれに従います。スキルベースのルーティングはEnterprise（$89）限定で、最大180のスキルを設定でき、ドキュメントでは言語を例に、"every ticket from a French-speaking customer"を"French"スキルへ送る方法が示されています。
1つ落とし穴があります。どのスキルにも一致しないチケットは"remain unassigned until it is manually assigned"となるため、Freshdeskはグループごとにフォールバック用のスキルを用意することを勧めています。分散型チームでは、このフォールバックが拠点間の空白時間のセーフティネットになります。完全な設定はFreshdeskのスキルベースルーティングのガイドに、EnterpriseでのシフトごとのタイムゾーンはFreshdeskのエージェントシフトにまとめています。
Help Scout、Gorgias、Front
この3つは、スケジュールをグループではなく受信箱やチャネルに紐付けます。
- Help Scout： カスタムのInbox Hoursは"are available on Plus and Pro plans"です。そのため、拠点または地域ごとに1つの受信箱を置くパターンになります。ドキュメントにスキル機能はありません。ルーティングはPlusでRound Robin、ProではさらにBalancedが使え、Teams（Plus以上）には専用のフォルダと会社レポート内のセクションが用意されます。
- Gorgias： Basic以上で連携ごとにカスタムの営業時間を設定でき、ストアやチャネルごとに独自のタイムゾーンを持てます。ルールでは検出された言語（"up to 54 languages"）を使って、全プランで"assign Spanish tickets to a team"ができます。Gorgiasの自動割り当てのガイドをご覧ください。
- Front： 営業時間はワークスペースと受信箱のレベルで機能し、Frontはこれを"useful for global organizations with distinct business hours per office or time zone"と説明しています。Professional（
$65）から利用可能です。会話が複数の受信箱にある場合は、アルファベット順で最初の受信箱の営業時間が適用されるため、受信箱に名前を付ける前に知っておく価値があります。
レポートのタイムゾーンの落とし穴
最初の拠点間レビュー会議の前に、私ならこの問題を直します。各拠点は数字を比較しますが、同じ数字を見ているとは限りません。
ZendeskのAnalyticsのタイムゾーンに関するドキュメントには"Analytics uses the Timezone in the user profile"とあり、これはダッシュボード、エクスポート、レポートビルダーすべてに当てはまります。マニラのマネージャーとオースティンのマネージャーが同じダッシュボードを開くと、ピーク時間帯も、1日の件数も、「今日」の合計も異なって見えることがあります。どちらも間違いではありません。1日を切り分ける位置が違うだけです。
他のツールは逆の方式です。Freshdeskのチケットタイマーは"the Helpdesk time zone"を基準にしています。Help Scoutの会社のタイムゾーンは"is shown on reports"で、一方でXLSXエクスポートはUTC、CSVエクスポートは会社のタイムゾーンを使います。そのため、Help ScoutのチームがXLSXエクスポートをダッシュボードのスクリーンショットの横に貼ると、気付かないうちに2つの異なる日を比較していることがあります。
私なら次の3つのルールを文書にします。
- レポート用のタイムゾーンを1つ決め（UTCが最も中立的です）、拠点間のすべての数字にそれを使います。Zendeskのマネージャーには、共有レポートを作る際にプロフィールをそのタイムゾーンに設定してもらうか、Zendeskが"the recipient's time zone"を使うと述べているダッシュボード配信を利用します。
- SLAは営業時間で測定し、各拠点の独自カレンダーを使うことで、閉まっていた時間について拠点がペナルティを受けないようにします。方法はZendesk Exploreの営業時間指標のガイドで説明しています。
- まず拠点を自分自身と比較します。 夜勤では件数もチケットの種類も異なります。公開サポート指標についてのRedditの返信が簡潔にまとめていました。
"Someone who's working part-time or working the graveyard shift will likely have fewer messages sent than someone full time, CSAT can be skewed by one (or more) unfair review, etc."
すでに追跡しているカスタマーサービスKPIを使いつつ、人を比較する前にグループとシフトで切り分けてください。
拠点間で品質の一貫性を保つ
ナレッジベースが回答の源だとすれば、QAは各拠点が実際にそれを提供しているかを確かめる手段です。分散型チームの罠は、各拠点が独自のレビュアーと独自の「5段階の4」の感覚でQAを行うことです。そうなると、スコアは比較できるように見えて、実際にはできません。
解決策は2つの習慣、共通のスコアカードと定期的な拠点間キャリブレーションです。Zendeskはキャリブレーションを"having all your reviewers rate the same batch of conversations and compare their scores"と説明しています。これを毎週、各拠点から最低1人のレビュアーを加えて行えば、スコアの差が拠点間でズレが生じている箇所を教えてくれます。
組み込みのQAツールは大きく異なります。
- Zendesk QAにはQAアドオン（価格非公開）か、
$50のWorkforce Engagementバンドルが必要です。ZendeskのQAガイドとスコアカード基準の記事で解説しています。 - Front Smart QAはアドオンで1シートあたり
$20、またはEnterpriseに含まれます。選んだ基準に沿ってAIが会話を採点します。 - Gorgias Auto QAは"available on all Helpdesk plans with an AI Agent subscription"です。クローズの12時間後に、解決の完全性、コミュニケーション、言語能力でチケットを採点します。
- FreshdeskとHelp Scoutは、ドキュメント上、人間の担当者向けのQAスコアカードがないため、スプレッドシートや別のQAツールを使うことになります。
担当者の側からの警告が1つあります。QAは、スコアカードとナレッジベースが一致していると担当者が信頼できてはじめて機能します。「BPOのように」運営されている社内チームのサポート担当者が、QAをめぐる争いについての投稿で、そうでない場合に何が起きるかを述べていました。
"...even if it's clearly a system fault or not even in the knowledge base, agents still get blamed. Even when we point out that it's not in the knowledge base, they still make excuses."
したがって、QAレビューで誤った回答が指摘されたら、まず正しい回答がどこかに書かれていたかを確認してください。なければ、それは担当者の問題ではなくナレッジのギャップです。両者は別々に記録します。担当者とのフィードバックループを閉じる方法は、Zendesk QAの担当者フィードバックのガイドで解説しています。
全員が所有する1つのナレッジベース
分散型チームのドリフトの大半は、1つの拠点の頭の中、チャット、非公開ドキュメントにとどまっている知識に行き着きます。ポリシー会議に出席した拠点は知っていて、他の拠点は怒ったお客様から知ることになります。
ルールは言うのは簡単ですが、守るのは困難です。共有ナレッジベースにない回答は、存在しないのと同じです。各記事には担当者を明記します。どの拠点も変更を提案できます。ポリシー変更は、記事が更新されるまで「完了」ではありません。所有とレビューのサイクルについてはAIナレッジ管理のガイドで、監査についてはナレッジベース管理の記事で解説しています。
逆の失敗にも注意してください。1人が黙って全体を支え続けている状態です。個人のガイドが、外部委託アカウントを支えていたことが判明したコールセンターのトレーナーへのRedditの返信が、こう要約していました。
"Love how everyone took your knowledge base and its regular updates for granted and no one at any level questioned who was maintaining that or where."
新しいパートナーや拠点を立ち上げる場合は、オフショアサポートのナレッジ移管の計画が30日間の進め方を示します。複数言語の市場では、多言語ヘルプセンターを使えば、拠点ごとにコピーを持つのではなく、翻訳付きの1つの情報源を維持できます。
拠点の足並みをそろえる運用リズム
共有ツールはドリフトの発生を防ぎます。定期的なリズムは、それでも漏れてくるドリフトを捕まえます。私ならこのサイクルから始めます。
- シフトごと：引き継ぎブリーフ。 次の拠点向けに、未解決のエスカレーション、期限が迫る約束、キューの異常を1通のメッセージにまとめます。サポートのシフト引き継ぎのガイドには、テンプレートと45分のルーティンがあります。
- 毎週：拠点間QAキャリブレーション。 全拠点のレビュアーが同じ5〜10件のチケットを採点し、差を話し合います。
- 毎月：ナレッジギャップレビュー。 「no article」または「wrong article」とタグ付けされたチケットを見直し、ナレッジベースを修正します。各拠点から何件あったかも数えます。
- 四半期ごと：カバレッジと人員の確認。 1つのレポート用タイムゾーンで時間帯別の件数を見て、各拠点が稼働している時間と照らし合わせます。拠点を増やすか、重なる時間を延ばすか、静かな時間帯をAIに任せるかを決めるのはここです。
このスケジュールでは、重なる時間を守る価値があります。Redditのネットワーク運用チームのメンバーが、1時間の重なりがうまく機能する理由を述べていました。
"It works well, there is approximately an hour overlap on each shift so if there is a fire or ongoing WebEx the new shift can be briefed on what's been done to troubleshoot the issue already and have a decent understanding."
ただし、重なりは安くありません。2つのタイムゾーンにまたがるチームのエンジニアは、分割した体制が"works well, but it is expensive"だと指摘しています。このコストこそ、四半期ごとの確認が重要な理由です。実際にどの時間帯に人が必要かが見えるからです。
分散型サポート運用におけるAIの役割
分散型チームでAIが役立つ点は2つあります。拠点間の空白時間を埋めることと、ドリフトの最大の原因の1つ、つまり異なる人が同じ質問に異なる回答をすることを取り除くことです。
eeselでは、これが重要になるキューで、eeselのAIヘルプデスクチームメイトが稼働するのを見てきました。Anytime Fitnessは40か国以上、5,000以上のジムの会員をサポートしており、eesel導入前は午後10時に質問した会員は朝まで待っていました。Gcoreは、顧客向けと自社の担当者向けの2つのボットで、グローバルな24時間365日のサポートを運営しています。また、Zendeskを使うB2Bハードウェアメーカーは、同じエージェントで4言語のチケットを処理しています。
上記の体制にAIチームメイトがどう収まるかを示します。
- どの拠点でも同じ回答。 過去のチケット、ヘルプセンター、マクロ、ドキュメントから学習するため、お客様がどの時間帯に書き込んでも1つの回答を返します。一貫性の問題を根本で解決します。
- 拠点間の空白をカバー。 定型的なチケットには時間を問わず回答し、残りはタグを付けて次の拠点のシフトに残します。
- 言語カバレッジ。 お客様の言語で返信するため、24時間体制で人員を置けない言語別キューの代わりになり得ます。
- 引き継ぎサマリー。 eeselのスケジュールジョブは、過去24時間のチケットの日次サマリーなどのプロンプトを、決まったタイムゾーンの決まった時刻に実行し、次の拠点のブリーフ用に出力できます。
- 担当者向けの社内回答。 Gcoreのように、同じナレッジベースから担当者の質問に答える2つ目のボットがあれば、別の地域が起きるのを待たずに、新しい拠点が立ち上がるのを助けます。
実際の導入から得た教訓を1つお伝えします。営業時間とルーティングのロジックは、ヘルプデスク自体の設定に持たせてください。eeselの長年のお客様は、これらのルールがAIの指示にしかなかったとき、営業時間とタイムゾーンの動作が一貫しない問題に直面しました。スケジュール、SLA、ルーティングは、Zendesk、Freshdesk、またはお使いのヘルプデスクに置くべきです。回答とサマリーはAIに、時計はヘルプデスクに任せましょう。
ドラフトモードから始めてください。AIが担当者の確認用に社内メモとして返信を書くモードです。お客様に回答する前に、過去のチケットでシミュレーションします。導入の詳細は、AIヘルプデスクエージェントのレビューとAIによる24時間365日サポートのガイドをご覧ください。
分散型サポートでよくある間違い
- 拠点ごとに1つの受信箱。 作業量が見えなくなり、チケットが宙に浮きます。1つのキューを使ってルーティングしましょう。
- お使いのプランが複数のスケジュールに対応していると思い込む。 Zendesk Professionalは対応していません。設計の前提にする前に確認してください。
- 異なるタイムゾーンで拠点を比較する。 まずレポート用のタイムゾーンを1つに決めましょう。
- 拠点ごとに別々のQA。 同じスコアカードと共通のキャリブレーションがなければ、スコアを並べても意味がありません。
- 拠点ごとのナレッジ。 拠点固有のドキュメントは、拠点固有の回答の始まりです。
- ある拠点ではクローズを、別の拠点では解決を評価する。 拠点は測定されるものを最適化します。同じ方法で測定してください。
- 時計をAIの指示に置く。 営業時間はヘルプデスクの設定に置くものです。
そもそも拠点を増やすべきか迷っている場合は、AIとオフショアのコスト比較で数字を試算し、リモートチーム向けヘルプデスクソフトウェアでツールを比較しています。
分散型サポートチームのためのeesel
拠点ごとに同じ質問へのわずかに異なる回答が出ている、またはどの拠点もうまくカバーできない時間帯がある場合、eeselのAIヘルプデスクチームメイトはまさにそのギャップのために作られています。Zendesk、Freshdesk、Gorgias、Front、Help Scoutの既存のキューに参加し、全拠点がすでに回答したチケットから学習して、どの時間帯でもお客様の言語で同じ回答を返します。
実際のチケットに触れる前に、過去の数百件のチケットでテストできます。また、料金は処理したチケットごとでシート数は無制限なので、全拠点の全担当者を追加しても追加費用はかかりません。
eeselを無料でお試しいただき、すべての拠点が同じ回答から始めたときにキューがどう変わるかをご確認ください。