マルチチャネルカスタマーサポートとは何か、うまく行う方法

マルチチャネルカスタマーサポートが本当に意味すること

マルチチャネルカスタマーサポートとは、複数のチャネルで同時にサポートを提供し、顧客が単一の受信箱に誘導されるのではなく、自分に合ったチャネルを選べるようにする実践だ。実際には、メール、あなたのサイト上のライブチャット、WhatsAppなどのメッセージングアプリ、SNSのダイレクトメッセージ、電話、そしてアプリ内・セルフサービスヘルプの組み合わせになる。

これは明らかに良いことに聞こえるし、需要も本物だ。人々はあなたがすでにいる場所で連絡できることを期待している。しかし、「マルチ」という言葉の裏には、これが助けになるか害になるかを左右する区別が隠れており、ほとんどのコンテンツはそこをすっ飛ばしている。

マルチチャネルとは、単にチャネルを持っていることを意味するだけだ。それぞれが依然として独自の島でありうる。別々のキュー、別々のエージェント、別々のコピーの回答、そしてチャネルを切り替えるたびに問題を再説明しなければならない顧客。オムニチャネルとは、それらのチャネルが接続されており、顧客が最初からやり直すことなく、一つの会話がメールからチャット、電話へと完全なコンテキストを保ち続けることを意味する。

チャネル数はどちらでも同じでありうる。違いはコンテキストが共有されているかどうかであり、問い合わせページに並ぶロゴの数ではない。これは本記事の残りを通じて持ち続ける価値のある捉え直しだ。メールとチャット間ですでにコンテキストを失っているサポート体制にWhatsApp番号を追加しても、オムニチャネルにはならない。単にコンテキストを失う三つ目の島が増えるだけだ。

サポートする価値のあるチャネル(それぞれの得意分野)

すべてのチャネルが同じ重みに値するわけではない。それぞれが異なる種類の会話を運んでおり、すべてを同じように人員配置することがサポート予算を膨らませる原因になる。主要なチャネルの実際の振る舞いは以下の通りだ。

実践的な読み方はこうだ。メールとセルフサービスのヘルプ層が件数を担い、ライブチャットとWhatsAppは顧客がますますいたいと思う場所であり、電話は本当に人間を必要とする会話のために温存する高コストなチャネルだ。初日から六つすべてが必要なわけではない。顧客が実際に使う二つか三つを、しっかりとやり切ることが必要だ。

マルチチャネルサポートが破綻する場所

これはサポートの現場から最もよく目にする部分だ。あるチームがチャネルを一つずつ、それぞれ最善の意図を持って追加していき、最終的に四つのツール、四つのログイン、そして同じ回答の微妙に異なる四つのバージョンを抱えることになる。昨日チャットで質問した顧客が今日メールで再び質問し、矛盾する回答を受け取る。なぜなら二人のエージェントはお互いの会話を見たことがないからだ。

三つの失敗パターンは常に同じだ。

• コンテキストの喪失。 顧客はチャネルを切り替えるたびに同じことを繰り返し説明する必要があり、これは良いサポートを悪く感じさせる最も速い方法だ。
• 回答の不一致。 異なるチャネルの異なるエージェント(または異なるボット)が同じ質問に異なる回答をし、信頼が損なわれる。
• 不均一な人員配置。 昼休みにチャットが放置され、夜間にSNSのダイレクトメッセージが積み上がり、メールは静かに48時間待ちのキューになる。

よくある本能的な対応は、人をもっと雇ってチャネルごとに割り振ることだ。これはコストを件数に比例して線形に増加させるだけで、一貫性はまったく解決しない。なぜなら人間が増えるほど回答が乖離する余地が増えるからだ。これはまさに多くのeeselの顧客が別の手段を探すきっかけとなった痛点だ。EcosaのCTOであるWesley Wang氏はこう述べている。「私たちがeesel AIを選んだのは、マルチチャネルのデータ入力オプションを提供しているからだ……CSV、Zendesk、Google Docsをソースとして連携させることで、たとえ散在していても膨大なドキュメントを最大限に活用できる。」散在している状態こそが本当の敵であり、チャネル数ではない。

AIがマルチチャネルの方程式をどう変えるか

AIがもたらす変化は、言葉にするのは簡単だが過小評価しがちなものだ。各チャネルに人員を配置する代わりに、一つの知識体系でエージェントを学習させ、それがどこでも同じように答える。チャネルは入力となり、回答は一箇所から生まれる。

ここで、マルチチャネル対オムニチャネルの区別は理論ではなくなる。一つのAIヘルプデスクエージェントがメール、チャット、WhatsApp、その他の背後に座っているとき、「共有されたコンテキスト」は別途購入する機能ではなく、それがただ機能する仕組みそのものになる。同じ知識が、顧客の言語で、WhatsAppのメッセージにもメールにも回答し、引き継ぎで話の筋が失われることもない。

私たちは何年もライブサポートキューにAIを導入してきており、何千件もの実際のチケットにわたって、具体的な結果がそれを裏付けている。smavaは完全自動化されたZendeskエージェントを運用し、月10万件以上のドイツ語チケットを処理している。Design.comはFreshdesk上のマルチエージェント構成で月5万件以上のチケットを処理している。Gridwiseはeeselが導入初月にTier-1リクエストの73%を解決するのを見た。これらはいずれも単一チャネルの数字ではない。かつてチームとツールの山に分散していた件数を、一つの学習済みエージェントがカバーするとどうなるかを示している。

正直な留保点であり、私が最もよく耳にする反論がある。すべてに自信満々に答えるAIは、AIがないよりも悪い。これを信頼するチームは、信頼度ベースのルーティングを設定できるチームであり、エージェントは確信のある質問だけを自動で回答し、残りは人間に任せる。あるeeselの顧客、DTCサプリメント企業のCXリードは、この論点全体を一文に要約した。自信を持って対応できるチケットだけを扱い、それ以外には手を出さないAIが欲しい。この制御こそが、マルチチャネルAIを実際に有効化しても安全なものにする。

混乱なくマルチチャネルサポートを展開する

私がチームによく見かける間違いは、目新しさでチャネルを追いかけることだ。メールキューが制御下に入る前に、目新しいSNS連携を追加してしまう。実際にうまくいく順序は逆で、件数によって決まる。

最も多くのチケットを抱えるチャネル(メールとセルフサービスのヘルプ層)から始め、そこで回答を一貫させ、その後同じナレッジベースをライブチャットとWhatsAppに拡張し、最後にSNSと電話で締めくくる。回答が一箇所に存在するため、新しいチャネルはそれぞれ接続であり、新しいチームではない。

どれだけ投資すべきかを決める前に、自分たちが実際に抱えている問題は何かを正直に見極める価値がある。

その結合組織となるのがあなたのヘルプデスクだ。eeselはZendesk、Freshdesk、Gorgias、Front、Help Scoutの上に乗り、さらにWhatsAppやSlackといったチャネルにも対応し、100以上の連携と80以上の言語をカバーする。つまり、マルチチャネル化のために何かを取り外す必要はない。すでに運用しているものの背後に一つの頭脳を追加するだけだ。

注視すべき数字

マルチチャネルの成功とは「五つのチャネルを立ち上げた」ということではない。顧客にとって重要な指標が、すべてのチャネルで安定しているかどうかだ。これらは集計だけでなくチャネルごとに追跡すべきだ。平均値は静かに失敗しているチャネルを隠してしまうからだ。

• 初回応答時間、チャネルごとに。遅れているチャネルを見つけるためだ。
• 解決率と初回接触解決率。回答が実際に的を射ているかどうかを示す。
• デフレクション率、セルフサービスとチャットにおいて。ナレッジベースがその役割を果たしている最良のシグナルだ。
• 一貫性。 同じ質問がすべてのチャネルで同じ回答を得ているか?これはほとんどのチームが測定しておらず、オムニチャネルが解決すべきとされている項目だ。

より詳しい全体像が必要なら、AIカスタマーサービスの指標と、サポート予算においてAIが実際にどれだけ節約になるかについて深く掘り下げている。

マルチチャネルサポート向けにeeselを試す

あなたのチャネルが静かにサイロと化してしまったなら、eeselはまさにそのために作られている。既存のヘルプデスクに接続し、初日から過去のチケット、ヘルプ文書、散在するソースから学習し、その後メール、チャット、WhatsAppなどにわたって80以上の言語で一貫して回答する。確信のあることだけを自動処理する信頼度ベースの制御付きだ。

まず注目してほしいのはシミュレーションモードだ。実際の顧客に触れる前に、過去の本物のチケットに対してエージェントを走らせ、チャネルとテーマ別のカバー率を確認し、隙間を埋めてから本番運用に移行する。料金は使用量ベースなので、席数ではなく解決した会話に対して支払い、クレジットカードなしの無料トライアルから始められる。eeselを試す。