カスタマーサポートでよくある「このチケットは誰が対応するのか」という問いは、単純に聞こえます。小規模なチームでは、答えは「空いている人」です。しかし大規模なチームでは、その答えは通用しません。パスワードのリセットとデータベースの移行を、同じ人が効率的に処理することはできないからです。
サポート階層は、これに対する構造的な答えです。受信した問題を複雑さに応じて3つの層に分け、適切なスキルレベルが適切な問題を担当できるようにします。本記事では、各階層が実際に何を行うのか、チケットが階層間でどのようにエスカレーションされるのか、そしてチームが分割を誤りやすいポイントを解説します。
主なメリット
- 問題に合ったスキル： 単純な問題は、スペシャリストを待つことなくTier 1で解決されます。複雑な問題は、ジェネラリストが推測するのではなく、適切な注意を払って対応されます。
- 平均解決時間の短縮： チケットの60-80%がTier 1でクローズするため、Tier 2とTier 3のスペシャリストがボトルネックになりません。
- より明確なキャリア形成： エージェントはTier 1からTier 2、Tier 3へと成長し、各移行時には明確なスキル基準があります。
- 予測可能な人員配置： 各階層のボリュームを個別に予測できるため、キャパシティプランニングが実行可能になります。
各階層が実際に担う業務
具体的な分割は業界によって異なりますが、原則は共通しています。
Tier 1 フロントラインのエージェント
Tier 1は最初の接点です。すべての受信チケットはここから始まります（優先度の高いアカウントを明示的に別の場所へルーティングするルールがある場合を除きます）。
Tier 1が担う業務： アカウントに関する質問、パスワードのリセット、注文状況、標準的な製品情報、最初の苦情受付、基本的なトラブルシューティング、およびナレッジベースに解決策が記載されているあらゆる問題。
必要なスキル： コミュニケーション能力、ユーザーレベルでの製品知識、一般的な問題に対する定型回答の遵守、エスカレーションのタイミングを見極める判断力。
一般的な解決率： 適切に設計された構造では、受信チケット全体の60-80%がTier 1でクローズするはずです。Tier 1のクローズ率がそれより低い場合、ナレッジベースが不十分か、エスカレーションのトリガーが緩すぎるかのいずれかです。
Tier 2 プロダクトスペシャリスト
Tier 2は、Tier 1では解決できない問題を引き受けます。より深い製品知識、ワークフローの理解、またはポリシーの例外を認める権限を必要とする問題です。
Tier 2が担う業務： 複雑な設定の問題、ワークフロー固有の問題、返金の例外対応、エスカレーションされた苦情、製品の深い知識を要する技術的な質問、複数のシステムにまたがるケース。
必要なスキル： 深い製品知識、顧客から報告された問題を再現する能力、バックエンドツールと管理画面への習熟、定められた範囲内でのポリシー例外に関する判断力。
一般的な解決率： Tier 2は、エスカレーションされた案件の70-85%をクローズする必要があります。残りはTier 3へエスカレーションされるか、製品／エンジニアリング側の変更を必要とします。
Tier 3 エンジニアリングまたはプロダクトチーム
Tier 3は、コードの変更、インフラストラクチャの作業、または未解決のバグを必要とする問題が行き着く先です。多くの企業では、Tier 3は専任のサポートエージェントによって運営されておらず、エンジニアリングチームまたはプロダクトチームが輪番でサポートを担当しています。
Tier 3が担う業務： 確認されたバグ、コード修正が必要な連携の失敗、データの破損、セキュリティインシデント、製品の根本的な制約を引き起こすエッジケース、および基盤システムの変更を必要とするあらゆる問題。
必要なスキル： エンジニアリングの知識、システムへの直接アクセス、パッチやホットフィックスを作成する能力、インシデント対応の経験。
一般的なボリューム： 受信チケット全体の5%未満であるべきです。Tier 3が溢れている場合、Tier 2のエスカレーション基準が誤っているか、製品にシステム上の問題があります。
エスカレーションの実際の仕組み
エスカレーションは、ほとんどの階層構造が崩れるポイントです。失敗を引き起こすパターンは2つあります。
エスカレーションが早すぎる。 Tier 1が3分以上かかるチケットをすべてエスカレーションすると、Tier 2がボトルネックになり、Tier 1はその目的を失います。適切なエスカレーションのトリガーは具体的です。再現できない、ポリシーの例外が必要、顧客が明示的に上司を希望している、または問題が既知の難易度の高いカテゴリに該当する、といった場合です。
エスカレーションが遅すぎる。 Tier 1が能力を超えた問題に固執すると、解決時間が膨張し、CSATが崩壊します。時間ベースのエスカレーション、つまり解決されないままN分経過したら自動的にTier 2へ引き上げる仕組みが、これを防ぎます。
健全なパターンは、明確なエスカレーション基準と厳格な時間上限です。どちらか一方ではなく、両方が必要です。
チームが分割を誤るポイント
初期段階のチームでTier 1とTier 2を統合する。 小規模なチームは分割を完全に省略しがちですが、それはボリュームが増えるまで機能します。Tier 2を導入する適切なタイミングは、同じスペシャリストが他の業務から繰り返し引き離されているときです。それが専任の階層を設けるべき市場のシグナルです。
Tier 3にTier 2の業務をさせる。 Tier 2で解決すべき問題に何時間も費やすエンジニアは、製品を開発していないエンジニアです。これは通常、Tier 2に知識が足りないからではなく、Tier 2にツールへのアクセスがないために起こります。
引き継ぎプロトコルがない。 コンテキスト、再現手順、顧客履歴なしでエスカレーションされたチケットは、Tier 2をゼロから始めさせます。引き継ぎプロトコル（何を試したか、顧客が何と言ったか、Tier 1が何を結論づけたか）はオーバーヘッドではなく、エスカレーションが機能している証拠です。
ツールが果たす役割
階層構造には、エスカレーションの流れを支えるツールが必要です。新しいチケットを既定でTier 1に振り分けるルーティングルール、完全なコンテキストを引き継ぐエスカレーションボタン、Tier 2とTier 3がTier 1の会話履歴を閲覧できる可視性。
Cekatのようなプラットフォームは、ルーティングと引き継ぎの仕組みを単一のワークスペース内で処理するため、エスカレーション時に顧客レコード、会話履歴、これまでの解決の試みがチケットとともに引き継がれます。これにより、チケットが上の階層へ移動する際の「ゼロから始める」問題が解消されます。
どこから始めるか
チームが小規模（5人未満）の場合、正式な階層構造はまだ早いかもしれません。代わりに、平均時間を一貫して超える2〜3種類のチケットを特定してください。それらが新たに生まれつつあるTier 2のカテゴリであり、いつ正式化すべきかのシグナルになります。
チームがより大きく、ボリュームが増加している場合は、現在の分割を測定してください。今日、各レベルで解決されるチケットはどれくらいあるか。40%以上が最初のエージェントを超えてエスカレーションされている場合、Tier 1にはより良いツールかより良いトレーニングが必要です。10%未満しかエスカレーションされていない場合、Tier 1はスペシャリストが担うべき業務を吸収している可能性があります。
カスタマーサービス、カスタマーケア、カスタマーサポートが統一されたチーム内でどのように責任を分担するかについては、カスタマーサービス vs カスタマーケア vs カスタマーサポートをご覧ください。
サポート階層は官僚的な層ではありません。これは成長問題に対する構造的な答えです。複雑さに関係なくすべての問題に同じだけの注意を払うことなく、より多くのボリュームを処理する方法です。
コメントを残す