ブログ

顧客がWhatsAppで会話を始めます。2日後、同じ件についてサポート窓口に電話をかけます。その週の後半には、追加の質問をメールで送ります。多くの企業では、これら3つの接点を3人の異なる担当者が対応し、他の2人が何を話したかを誰も把握していません。

これが、オムニチャネル型コンタクトセンターが解決するために設計された課題です。すべてのチャネルからの音声とテキストメッセージを単一のエージェントワークスペースにルーティングするため、応答する担当者は、各メッセージがどこから届いたかに関係なく、会話の完全な履歴を目の前にして対応できます。

この用語は「マルチチャネル」と同義に使われることがよくありますが、両者には明確な違いがあります。本ガイドでは、オムニチャネル型コンタクトセンターとは実際に何か、メッセージをどのようにルーティングするか、そしてマルチチャネルとの違いがどこで重要になるかを解説します。

主なメリット

• 単一の顧客ビュー： エージェントは、チャット、通話、メール、フォームなど、顧客との過去のすべてのやり取りを1つのスレッドで確認でき、別々のツールに分散されることはありません。
• 一貫した引き継ぎ： 案件がエージェント間またはチャネル間で移っても、コンテキストは自動的に引き継がれます。
• 遜速な解決： エージェントは顧客に同じ説明を繰り返させる必要がなくなり、これは低いCSATの最大の原因の1つです。
• よりクリーンなレポート： 件数、応答時間、解決の指標は、サイロ化されずチャネル横断で測定されます。

「オムニチャネル型コンタクトセンター」の実際の意味

オムニチャネル型コンタクトセンターとは、音声、WhatsApp、ライブチャット、メール、SNSのDM、アプリ内メッセージなど、すべての顧客チャネルが単一のエージェントワークスペースと単一の顧客レコードに集約されるシステムです。

重要なのは「単一」という言葉です。エージェントは1つのキューと1つのインターフェースで作業します。顧客履歴はチャネル横断で統合されます。ルーティングルールは、メッセージがどのチャネルから届いたかに関係なく、同じロジックを適用します。

これは「多くのチャネルをサポートする」コンタクトセンターとは異なります。サポートと統合は同じものではありません。

マルチチャネルとオムニチャネル：違いが重要になる場面

マルチチャネル型コンタクトセンターは、顧客が企業に連絡するための複数の手段を提供します。通常、各チャネルには独自の受信箱、独自のチーム、独自のレポートがあります。

オムニチャネル型コンタクトセンターは同じチャネルを提供しますが、それらすべてを1つのワークスペースと1つの顧客レコードにルーティングします。

実際の違いは3つの点に現れます。

顧客体験。 マルチチャネルの構成では、WhatsAppから電話に切り替えた顧客は問題を再度説明しなければなりません。オムニチャネルの構成では、電話に出るエージェントがすでにWhatsAppの履歴を確認しています。

エージェントの作業負荷。 マルチチャネルでは、エージェントはチャネルごとに専門化します。1つのチームがチャット、別のチームが電話を担当します。あるチャネルで急増が起きても、他のエージェントは簡単には支援できません。オムニチャネルでは、インターフェースが同じであるため、エージェントはチャネルをまたいで柔軟に動けます。

レポート。 マルチチャネルでは、「応答にどれだけ時間がかかるか」の答えはチャネルごとに1つずつあります。オムニチャネルでは、答えはただ1つです。

マルチチャネルが間違っているわけではありません。チャネルの切り替えが少ない企業にとっては十分な場合もあります。オムニチャネルが必要になるのは、同じ顧客が複数のチャネルに定期的に現れる場合です。

メッセージルーティングの仕組み

すべてのチャネルが1つのキューに集約されると、ルーティングルールがシステムの重要な部分になります。

一般的なルール：

• スキルベースのルーティング： メッセージは、関連する製品、言語、問題の種類に習熟したエージェントにルーティングされます。
• 空き状況ベースのルーティング： メッセージは、現在オンラインで処理能力に余裕のあるエージェントにルーティングされます。
• 履歴ベースのルーティング： メッセージは、以前に同じ顧客を担当したエージェントが対応可能な場合、そのエージェントにルーティングされます。
• 優先度ベースのルーティング： 重要顧客、緊急チケット、SLA違反はキューを飛び越えます。

ほとんどのコンタクトセンターはこれらを組み合わせています。典型的なルールは次のようになります。*顧客に未解決の案件がある場合は同じエージェントにルーティングし、そうでない場合は製品ラインに習熟した次に対応可能なエージェントに、SLAの優先順位に従ってルーティングする。*

統合ルーティングの目的は、ルールを複雑にすることではありません。同じ顧客からのWhatsAppメッセージと電話が同じ場所に届くように、すべてのチャネルで同じロジックを適用することです。

実例

顧客が小売業者にInstagramのDMで配送遅延についてメッセージを送ります。

メッセージはエージェントAにルーティングされ、エージェントAは遅延を確認し、翌朝に状況を更新することを約束します。案件は未解決のままです。

翌朝、同じ顧客が約束の更新前にサポート窓口に電話をかけます。通話が空いている担当者に回される代わりに、ルーティングはまず未解決の案件を確認し、エージェントAがこの顧客を担当していることを把握して、通話をエージェントAにルーティングします。

エージェントAは、顧客が誰で、問題は何で、何を約束したかをすでに把握した状態で電話に出ます。自己紹介の繰り返しも、二度目の説明もありません。

この1つの流れが、オムニチャネル型コンタクトセンターがもたらす違いです。小さなことに聞こえますが、顧客がそのやり取りをどう受け止めるかを変えます。

導入前に確認すべきこと

すべての企業がオムニチャネルルーティングを必要とするわけではありません。導入前に、3つの質問に答える価値があります。

顧客はどのくらいの頻度でチャネルを切り替えますか？ ほとんどの顧客が1つのチャネルしか使わないのであれば、統合の価値は限定的です。

エージェントは何人いますか？ 1人か2人であれば、規律によって統合を容易に実現できます。10人以上になると規律だけでは拡張できなくなり、システムがそれを強制する必要があります。

同じ質問を繰り返すコストはどれくらいですか？ 高額な検討を要する購入や規制業界では、同じ説明を繰り返すよう求められることは、軽微なサポートよりも深刻です。コンテキストが顧客に追随する価値はより高くなります。

これらの答えのうち2つが統合を示唆するなら、オムニチャネル構成に変える価値があります。

オムニチャネルと既存スタックの関係

オムニチャネル型コンタクトセンターは、すでに導入しているツールの代替ではありません。それらをつなぐレイヤーです。

チャネルはそのままの場所にとどまります。WhatsAppはWhatsAppのまま、電話システムは電話システムのままです。変わるのは、それぞれからのメッセージが1つのワークスペースに表示され、1つの顧客レコードと1つのルーティングエンジンで扱われることです。

Cekatのようなプラットフォームは、音声とテキストのチャネルを統合された顧客レコードを備えた単一のエージェント受信箱にまとめるため、WhatsAppのスレッドを担当するエージェントは同じ画面で顧客の通話履歴を確認できます。これにより、マルチチャネル構成を実際に遅くする切り替えコストがなくなります。

どこから始めるか

チームがすでに2つか3つのチャネルを別々に運用しているなら、最初の一歩はソフトウェアを変えることではありません。顧客がどのくらいの頻度でチャネルをまたぐかを特定することです。

直近100件の顧客対応からサンプルを抽出します。そのうち何件が複数のチャネルに関係したかを数えます。その数が意味のある水準、たとえば15%を超えるなら、オムニチャネルの根拠は現実的であり、ROIは対応時間の短縮と初回接触解決率の向上として測定できます。

カスタマーサービス、カスタマーケア、カスタマーサポートが統合されたチームでどのように責任を分担するかについては、カスタマーサービス、カスタマーケア、サポートの違いとは？をご覧ください。

オムニチャネル型コンタクトセンターは、チャネルそのものよりも、それらすべてが指し示すレコードが重要です。そのレコードが統合されれば、その後のすべて、つまりエージェントの作業負荷、顧客体験、レポートが管理しやすくなります。

顧客がWhatsAppでメッセージを送ってきます。「注文の状況を教えてもらえますか」。担当者はそのメッセージに目を向けます。画面にはほかに何も表示されていません。注文番号も、過去の購入履歴も、先週から未解決のクレームが残っているかどうかの記録もありません。

担当者は、聞くことのできる唯一の質問で返信します。「こんにちは、注文番号を教えていただけますか」。3件の注文と未解決のチケットを1件持つリピーターである顧客は、いら立った様子で返信します。実際の対応が始まる前に、会話はすでに悪いスタートを切ってしまっています。

顧客情報の一元管理（シングルカスタマービュー）は、担当者が返信している同じ画面の中に顧客の文脈をすべて表示することで、この問題を解決します。これはカスタマーサービスツールにおいて最も投資が不足している改善のひとつであり、初回返信の品質を最も確実に変える改善のひとつでもあります。

主なメリット

• 初回返信で完全な文脈: チャットが届いた瞬間に、担当者は顧客の直近の注文、未解決のチケット、プロファイルを確認できます。
• 同じ質問の繰り返しがない: 企業がすでに持っている情報を、顧客に何度も尋ねることがなくなります。
• 遜速なエスカレーション: スーパーバイザーは複数のツールを探し回るのではなく、同じ画面で履歴を確認できます。
• より明確なレポート: 指標はチャネル単位やセッション単位ではなく、1顧客につき1レコードで集計されます。

シングルカスタマービューとは実際に何か

シングルカスタマービュー（SCV）とは、顧客ごとに1つの統合されたレコードであり、チャットスレッド、注文、クレームチケット、支払い、プロファイルデータといったすべての接点をつなぎ合わせ、必要な瞬間に関連する情報を表示するものです。

重要なのは、データがどこかに存在することではありません。ほとんどの企業は、注文データをあるシステムに、チャット履歴を別のシステムに、クレームチケットをさらに別のシステムにすでに持っています。重要なのは、チャットが届いたときに、担当者がメッセージと同じ画面で、意味のあるデータを確認できることです。

SCVはデータウェアハウスではありません。ウェアハウスは分析のためにすべてを保存します。SCVは、担当者が次に何を言うべきかを変える情報のごく一部だけを表示します。

なぜ接点の瞬間が重要なのか

同じやり取りの2つのバージョンを考えてみましょう。

バージョンA、SCVなし。 WhatsAppのメッセージが届きます。担当者が注文番号を尋ねます。顧客が番号を返信します。担当者は別のWMSタブを開き、番号を貼り付け、読み込みを待ちます。ステータスを確認します。返信を入力します。合計経過時間は4〜6分。本来30秒で答えられるはずの質問に。

バージョンB、SCVあり。 WhatsAppのメッセージが届きます。担当者の画面にはすでに、顧客名、ステータス付きの直近3件の注文、先週からの未解決クレームチケット1件、LTV階層が表示されています。担当者は具体的な更新情報と、未解決チケットに関する先回りの一言を添えて返信します。合計経過時間は60秒未満です。

違いは、バージョンBで担当者がより熱心に働いたことではありません。情報がすでにそこにあったということが違いです。担当者がタブを切り替えたり、識別子を再入力したり、顧客に同じことを聞き直したりする一秒一秒は、本来の課題を解決していない時間です。

SCVに含めるべきデータ

すべてを表示したくなりますが、それは誤った直感です。顧客に関するあらゆるデータポイントを表示するSCVは、担当者が選別しなければならないノイズになります。

役立つSCVは、次の5つのカテゴリーを表示します。

• 識別情報: 氏名、連絡先番号、顧客タグ、言語設定。
• 直近の注文: ステータスと金額を含む直近3〜5件の注文。
• 未解決チケットと最近のクレーム: 未解決のものすべてに加え、過去30日間に解決した案件。
• コミュニケーション履歴: 顧客が利用したチャネル、最後の接触日時。
• 希望とオプトイン: 言語、マーケティングへの同意、製品への関心。

経験則として、担当者の対応を変える情報であればSCVに含めます。月次レポートにしか関係しない情報はウェアハウスに置きます。

SCVはどのように構築されるか

このビューが機能するには、3つの条件を満たす必要があります。

1つの識別キー。 顧客には、システム間でレコードをつなぐ単一の識別子が必要です。WhatsApp中心の企業では、通常は正規化された形式の電話番号です。共通のキーがなければ、あるシステムの注文と別のシステムのチャットは1つのレコードに統合されません。

同じレコードに書き込むシステム。 注文システムがCRMとは異なるIDで独自の顧客レコードを作成すると、SCVは不完全または断片化したデータを表示します。共通の識別情報にマッピングする連携があるかどうかが、機能するSCVと理想にとどまるSCVの分かれ目です。

インラインでの表示。 データは、チャット対応を行っている同じ画面に表示される必要があります。担当者がクリックして開く別タブはSCVではなく、単なる2つ目のアプリケーションです。情報が1クリック先にあると、時間に追われる状況では一貫して使われません。

よくある失敗パターン

多くのSCV導入は、次の4つのいずれかの形で失敗します。

重複レコード。 あるシステムでは+62812…、別のシステムでは0812…として電話番号が登録されたため、同じ顧客が2つ存在します。取得時点での正規化がこれを防ぎます。

古いデータ。 SCVの注文が昨日の状態を反映しており、今朝出荷された便が反映されていません。大量の履歴データよりもリアルタイム同期が重要です。

表示するデータが多すぎる。 担当者は40のフィールドを見せられ、重要な3つを見つけられません。段階的な開示、つまりコンパクトな初期表示と展開オプションの組み合わせは、すべてを一度に表示するよりうまく機能します。

書き戻しのループがない。 担当者はチャットで問題を解決しますが、レコードには何も記録されません。次の担当者は何が起きたのか分かりません。SCVは、新しい情報がそこに戻ってくる場合にのみ役立ちます。

CRMスタックとの関係

シングルカスタマービューは、CRMの設定方法の特性であり、独立した製品ではありません。ほとんどのCRMは技術的にはSCVを生成できますが、実際に業務が行われる場所にインラインで表示しているものはほとんどありません。

Cekatのようなプラットフォームは、オムニチャネルの受信トレイとCRMを1つのワークスペースに統合しているため、顧客レコードは別タブではなく、進行中の会話の隣に表示されます。注文履歴、未解決チケット、プロファイルデータは、検索後ではなく、担当者がメッセージを読む瞬間に確認できます。

どこから始めるか

チームに現在SCVがない場合、データプロジェクトから始めないでください。診断から始めてください。

直近10件の顧客チャットを集めます。それぞれについて、担当者が初回返信時に必要だったが持っていなかった情報をリストアップします。同じ3〜4項目が繰り返し現れる場合（注文ステータス、過去のクレーム、製品の希望など）、それらがSCVの最初のバージョンに含めるべきフィールドです。

まずはそれらから始めます。フィールドの追加は、明確なパターンがそれを正当化する場合にのみ後から行います。適切に選ばれた5つのフィールドが確実に読み込まれるSCVは、40のフィールドが不安定に読み込まれるSCVよりも価値があります。

SCV自体を設計する前に、連絡先データをどう構造化すべきかを考えたいチームは、CRM連絡先データを構造化する方法をご覧ください。

シングルカスタマービューは、企業に新しい能力を加えるものではありません。すでに存在する能力の間にある摩擦を取り除くものです。サービス品質の最大の飛躍は、通常まさにそこから生まれます。

ある顧客が午前9時にWhatsAppで同じ企業にメッセージを送り、5分で返信を受け取ります。同じ顧客が午前10時にInstagram DMでその企業にメッセージを送り、返信を3時間待ちます。同じチーム、同じ製品、まったく異なる体験です。

顧客はチャネルを見ていません。目に映るのは、ある時は素早く答え、ある時は姿を消す一つの企業です。そのばらつきこそ、チャット応答SLAが防ぐために設計されているものです。

本記事では、チャット応答SLAとは何か、なぜチャネルごとの目標よりもチャネル横断の一貫性が重要なのか、そしてチームが実際に達成できる数値をどう設定するかを解説します。

主なメリット

• 一貫した顧客体験： 応答速度が、顧客が選んだチャネル次第の運ではなく、企業そのものの特性になります。
• 現実的なキャパシティプランニング： 実際の量に紐づいたSLA目標により、勘ではなく正確に人員を配置できます。
• 明確なエスカレーションのトリガー： メッセージがSLAの上限に近づくと、ルーティングがエスカレーションを判断します。静かに遅れ続けることはもうありません。
• 測定可能な説明責任： 階層ごとに一つの数値があれば、「私たちは速い」は証明も反証もできるものになります。

チャット応答SLAが実際にカバーする範囲

チャット応答SLAは「X分以内に返信する」だけではありません。有用なSLAは4つの項目を定めます。

• 初回応答時間： 顧客のメッセージが届いてから、最初の人的対応（またはボット）の返信が顧客に届くまでの速さ。
• 解決時間： 単に確認するだけでなく、問題がどれだけ早くクローズされるか。
• 対応時間帯： SLAが適用される時間帯。その時間外には、別の（あるいは何の）約束も適用されません。
• 優先階層： 顧客セグメントや問題の種類ごとに異なるSLAを設定できます。VIPアカウントと初回購入者は同じではありません。

「15分以内に返信」のような単一の数値だけのSLAは、これらの軸がなければ抜け穴を生みます。どう返信するのか。何時から何時までか。確認だけのメッセージも含むのか。その具体性こそがSLAです。

なぜチャネルごとの速度よりもチャネル横断の一貫性が重要なのか

ほとんどのチームは、意図せずチャネルごとに最適化してしまいます。WhatsAppは目立ち、クローズもしやすいので注目されます。Instagram DMは小さな赤いバッジのまま、誰にも無視されます。ウェブサイトのライブチャットは独自のタブにあり、今それを見ている人はいません。

その結果、チャネルごとのSLAは桁違いにばらつきます。WhatsAppのp90初回応答時間は3分。Instagram DMのp90は4時間。ライブチャットのp90は45分です。

顧客の視点では、記憶に残るp90は最も遅いものです。目立つチャネルで速いことは、静かなチャネルで遅いことを埋め合わせません。チャネル横断のSLAは、遅いチャネルを速いチャネルの水準まで引き上げます。そして改善の作業の大半はまさにそこにあります。

数値の設定方法

SLAを設定する間違った方法は、願望的な数値を選ぶことです。「5分以内に返信」は聞こえは良いですが、半年間すべてのSLAレポートが赤を示し、チームがその指標を無視することを学ぶまでです。

正しい方法は、現在のパフォーマンスを測定し、その後段階的に厳しくしていくことです。

ステップ1：ベースライン

過去30日間の受信チャットを抽出します。チャネルごとにp50とp90の初回応答時間を計算します。p50はメッセージの半分が収まる位置、p90は最も遅い10%が始まる位置です。

ステップ2：達成可能な最も厳しい目標を選ぶ

初期SLAは、最も速いチャネルのp90に設定します。そうすれば、チームがどこかで実現済みの目標になります。

ステップ3：周知し、監視し、調整する

最初の1か月は毎週コンプライアンスを追跡します。SLAの未達は診断であり、罰則ではありません。ルーティング、人員配置、ツールのどこが失敗しているかを示します。

ステップ4：四半期ごとに厳しくする

コンプライアンスが4週間連続で90%を超えたら、目標を20%短縮します。SLAは固定の数値ではなく、ラチェットになります。

実務でSLAが破綻する要因

SLAが失敗するとき、理由はいくつかのパターンに集約されます。

夜間と週末。 9-5時のみ適用される15分のSLAは正直です。24/7で適用されるのに、チームが9-5時しか働かないのは正直ではありません。営業時間を明示するか、体制に投資するかのどちらかです。

スパイク期間。 フラッシュセール、製品発売、バイラルな瞬間は通常の2倍から3倍の量になります。静的なSLAは破綻しますが、量を考慮したルーティングと事前に予定されたバックアップ体制は破綻しません。

チャネルのサイロ化。 WhatsAppのエージェントがIG DMを見られず、その逆も同様なら、あるチャネルのスパイクを別のチャネルのキャパシティで助けることはできません。統合されたキューがこれを解決します。

スキルのミスマッチ。 SLAは誰かが返信すれば達成されますが、間違ったエージェントが対応したために役に立たない返信になることがあります。初回応答SLAは初回応答の品質チェックと組み合わせる必要があります。そうでなければ、チームは有用性を犠牲にして速度を最適化します。

チャネル横断で一貫して徹底する方法

SLAを設定したら、3つの仕組みがチャネル横断での誠実さを保ちます。

統合アラート。 どのチャネルの新規メッセージも同じエスカレーションロジックを起動します。5分前のIG DMは、5分前のWhatsAppスレッドと同じアラームを鳴らすべきです。

1つのキュー、1つのルーティングルール。 すべてのチャネルが同じキューに流れ込めば、あるチャネルのキャパシティが別のチャネルを助けられます。ルーティングは、エージェントがたまたま開いているチャネルではなく、スキルと負荷に基づいて各メッセージの行き先を決めます。

1つのダッシュボード。 チャネルごとに報告されるSLAコンプライアンスは責任の押し付け合いを招きます。全チャネルをチームごとに報告すれば、議論はツールではなくプロセスに向かいます。

ツールスタックとの関係

チャット応答SLAは、メッセージをエージェントにルーティングするツールによって執行されます。そのツールがチャネルごとに分かれている場合（WhatsApp用、Instagram用、ライブチャット用に1つずつ）、チャネル横断の執行には手動のダッシュボードを重ねる必要があります。

Cekatのようなプラットフォームは、WhatsApp、Instagram DM、ライブチャット、その他のチャネルを1つのキューと1つのルーティングエンジンで処理するため、SLAルールが一律に適用され、アラートも一元化されます。これにより、多くのチャネル横断SLAの失敗の原因である「今日は誰がこのチャネルを担当するのか」という問題がなくなります。

どこから始めるか

SLAから始めないでください。ベースラインから始めます。チームが今どこにいるかを知らなければ、どんな目標も推測です。

先月分を抽出します。チャネルごとにp50とp90の初回応答を計算します。ギャップを見ます。あるチャネルが他より極端に遅いなら、それが制約です。SLAを設定する前に、なぜかを理解してください。通常は上記の4つのパターンのいずれかです。

ベースラインの数値が出たら、初期SLAを最も速いチャネルのp90に設定します。周知し、毎週追跡し、四半期ごとに厳しくします。SLAは目的ではありません。目的は、すべてのチャネルを等しく答える価値があると考えるチームです。

SLAの定義、種類、カスタマーサービス契約での構成についてのより詳しい参考資料は、サービスレベルアグリーメント（SLA）：種類、指標、CSガイドをご覧ください。

また、より速い応答を可能にする運用上の戦術についての関連記事は、CS応答時間を短縮する方法をご覧ください。

チャット応答SLAは書類仕事ではありません。「できるだけ早く返信しよう」を、チームが月曜の朝に説明できる数値に変える仕組みです。

5人のCSチームは1日300件のチャットを無理なく処理しています。しかし、量が1日3,000件に増えたとします。そこでエージェントを45人追加するのは正解ではありません。経済的に成り立たず、研修の仕組みが追いつかず、採用のたびに品質が下がるからです。

多くの企業はこの時点で、サービス品質の低下を受け入れるか、カスタマーサービス自動化に投資するかのどちらかを選びます。後者を正しく実行すれば、チームの「人数」ではなく「形」が変わります。

本ガイドでは、「人員を増やさずに拡張する」ことが実際に何を意味するのか、どのチャットがきれいに自動化でき、どれができないのか、そして量の増加カーブが来ると分かっているときにどこから始めるべきかを解説します。

主なメリット

• 量の急増を吸収: 自動化は、コストを比例的に増やすことなく5倍の量を処理します。
• 人を高付加価値業務に解放: エージェントはパスワードリセットや配送状況の更新ではなく、苦情や交渉に時間を使えます。
• 反復的な質問に一貫した回答: 同じ製品に関する質問には、毎回同じ正確な回答が返ります。
• 大多数の顧客への遜速な対応: チャットの70%を占める単純な問い合わせが、数分ではなく数秒で回答されます。

「人員を増やさずに拡張する」とは実際どういうことか

この言葉は誤解されがちです。カスタマーサービスから人を排除するという意味ではありません。人の仕事の中身を変えるという意味です。

一般的な受信チャットの構成では、約70%のメッセージが反復的で文脈の少ないものです。注文状況、製品の在庫状況、営業時間、配送時間など。これらに人の判断は不要です。必要なのは速く正確な回答です。

残りの30%は、人が価値を付加できる領域です。複雑な苦情、高額な交渉、例外的なケース、共感を必要とする状況。これらは顧客が記憶に残すやり取りでもあります。エージェントを70%から解放することが、30%で力を発揮させる鍵です。

人員を増やさずに拡張するとは、自動化が反復的な量を吸収し、チームが重要なやり取りで品質を保てるようにすることです。

量で見る3種類のチャット

受信チャットは3つのカテゴリーに分かれます。

トランザクション型（約40%）

注文状況、配送の更新、支払い確認、配送予定。答えはデータです。システムから取得して返信するだけ。判断は関与しません。

情報型（約30%）

製品仕様、営業時間、返品ポリシー、店舗所在地。答えはナレッジベースにあります。取得して整形し、返信する。判断は最小限です。

例外型（約30%）

苦情、カスタムリクエスト、複雑な質問、交渉、不満を持つ顧客。答えには文脈、判断、そして多くの場合共感が必要です。判断が中心となります。

最初の2つのカテゴリーこそ、自動化がその役割を果たす領域です。3つ目は、人が不可欠であり続ける領域です。

きれいに自動化できるもの、できないもの

有用なテストがあります。人の判断で選択肢を比較検討することなく、構造化データやナレッジベースから答えを生成できるなら、自動化が処理します。口調を判断したり、トレードオフを比較したり、裁量的な決定を下したりする必要があるなら、人間が担当します。

きれいに自動化できる: 注文状況の照会、在庫状況の確認、配送予定の見積もり、返品ポリシーの説明、営業時間の問い合わせ、予約の受付、苦情タイプの初期トリアージ、人への引き継ぎ前の識別情報の収集。

きれいに自動化できない: 返金の例外対応、複雑な苦情の解決、高額顧客へのアップセル、カスタム価格の交渉、感情的なやり取りへの対応、アカウント不正の懸念への対応、製品に関する判断や裁量を要するあらゆる事項。

技術の進歩とともにこの線引きは変わりますが、原則は変わりません。再現可能なものは自動化し、判断は人に残す。

自動化がその役割を発揮する場面

自動化が吸収すべき量の大半は、4つの具体的なワークフローが占めます。

注文状況。 顧客が尋ねると、ボットが注文システムから取得し、現在の状況と次回更新予定を返信します。回答が不明確な場合やシステムエラーが発生した場合は、人にエスカレーションします。これだけで、Eコマースの受信量の20〜30%を吸収できます。

FAQトリアージ。 安定した回答があるよくある質問は、キューに触れることなくナレッジベースから解決されます。新規または不明確な質問だけが人にルーティングされます。

初期情報の収集。 エージェントが引き継ぐ前に、ボットが注文番号、問題の種類、関連する識別情報を収集します。人はゼロからではなく、すでに整理された会話を引き継ぎます。

予約とスケジューリング。 予約枠、サービス予約、予約確認は純粋なデータフローです。これらを人が行うべきではありません。

人が依然として重要な場面

自動化は目的ではありません。より良いカスタマーサービスが目的です。2つのカテゴリーは、自動化すると通常悪化します。

感情的なやり取り。 注文が破損した状態で届いた不満を持つ顧客は、ボットに不満を認めてほしいわけではありません。問題を解決してくれる人を求めています。

重要な商業判断。 年間契約の条件を交渉しているB2B顧客は、AIのカウンターオファーを受け入れることはありません。判断には重みがあります。

うまく設計された自動化の仕組みは、こうした状況を早期に認識し、顧客が人を求める前に人へルーティングします。

避けるべき2つの落とし穴

自動化の導入の多くは、2つの方向のいずれかで失敗します。

過剰な自動化。 感情的なやり取りを含め、すべてがまずボットを通ります。顧客は、助けに辿り着く前に突破すべき壁としてシステムを体験します。応答時間が改善しても、CSATは下がります。解決策は積極的なエスカレーショントリガーです。怒りの言葉、繰り返しの連絡、高額顧客のフラグなどで、早い段階で人を引き込みます。

自動化の不足。 最も些細な問い合わせだけがボットにルーティングされます。人は依然として注文状況の量全体を処理します。やり取りあたりのコストは高止まりし、負荷がかかると応答時間は延び、予算上の「自動化」項目には測定可能なリターンが現れません。解決策は、自動化を拡張した場合に現在のチャットの何割をきれいに処理できるかを正直に測定することです。

適切なバランスは企業ごとに異なります。それは推測ではなく測定から生まれます。

スタックとの位置づけ

カスタマーサービス自動化は単一の製品ではありません。文脈を読み取って応答できるAIエージェント、ボットが注文・製品システムからデータを取得できるようにする連携、そして人へのエスカレーションを判断するルーティング層の組み合わせです。

Cekatのようなプラットフォームは、AIエージェントビルダーをオムニチャネル受信トレイとCRMに統合しているため、自動化は人とエージェントが使うのと同じ顧客コンテキスト上で動作します。つまり、ボットがエスカレーションしたとき、人は繰り返しの自己紹介も、失われた文脈もなく、完全な履歴とともに引き継げます。

どこから始めるか

自動化を追加する前に、現在の内訳を測定します。直近200件のチャットを3つのタイプに分類します。トランザクション型、情報型、例外型。その割合が、量が実際にどこにあるかを示します。

50%超がトランザクション型または情報型であれば、自動化の根拠は数値で示せます。最も多い単一の問い合わせタイプ、通常は注文状況から始め、そのワークフローを完全に自動化します。次の追加前に1か月間効果を測定します。

1つのワークフローずつ自動化を構築するのは、一斉導入より遅いですが、実際に機能する自動化を生み出します。一斉導入は通常、チームが予期しなかった例外ケースの下で崩壊します。

WhatsAppチャットボットがCS運用コストをどう吸収するかについては、WhatsAppチャットボットでCS運用コストを60%削減をご覧ください。

また、ビジネス規模でチャット量を管理する広い視点については、ビジネスチャット管理：サポートとSLAの拡張をご覧ください。

カスタマーサービス自動化は、うまく行えばCSチームを小さくしません。人にしかできない仕事でチームをより良くし、それ以外のことに一日を奪われないようにします。