← エピソード一覧に戻る Episode 249 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング
タカシ
今日は SaaS サポートのオムニチャネル対応です。Zendesk の 2026 年調査では、74パーセントの消費者が、同じ説明を何度もさせられることに不満を感じると答えました。窓口を増やすだけでは、むしろ体験は壊れやすいんです。
ミカ
オムニチャネルって、私は単にメールもチャットも電話も受けられる状態だと思っていました。でも今の話だと、入口の数じゃなくて、会話がつながるかどうかが本質っぽいですね。
タカシ
その通りです。SaaS では障害相談がチャットで始まり、ログはメールで送り、最後は通話で詰めることもあります。この途中で履歴や優先度が切れると、顧客は毎回ゼロから説明することになります。
ミカ
今日は、マルチチャネルとの違いと、どう設計すれば本当に解決が速くなるのか、その現実的な考え方を知りたいです。
Chapter 2 オムニチャネルの本質
タカシ
Intercom は、オムニチャネル対応を複数チャネルを一つの連続した体験として扱うことだと説明しています。マルチチャネルは窓口が複数ある状態ですが、チャネル同士が独立していれば、結局たらい回しと同じなんですね。
ミカ
なるほど。電話、メール、SNS を全部持っていても、それぞれが別チーム、別履歴、別ルールなら、顧客から見れば会社が分裂しているのと同じ、ということですね。
タカシ
ええ。Zendesk の同じ調査では、81パーセントが前回の続きから対応してほしいと答え、76パーセントは、文章、画像、動画を同じスレッドでやり直しなく扱える会社を選ぶと答えています。文脈を保つこと自体が競争力になっているわけです。
ミカ
チャネル対応って、便利機能の話じゃなくて、顧客の記憶を切らさない仕組みなんですね。確かにそれなら、継続率や信頼に直結しそうです。
Chapter 3 先進企業の運営例
タカシ
HubSpot の help desk は分かりやすい例です。チャット、メール、フォーム、通話、WhatsApp、Facebook Messenger などを一つのワークスペースに集め、そこから優先順位づけ、トリアージ、ルーティング、営業時間、SLA まで管理できます。
ミカ
それって、窓口ごとに別ツールを持つより、運営ルールを共通化しやすいですね。誰がどこを監視するか、どの時間に返すかも揃えやすそうです。
タカシ
導入事例では BoxyCharm が象徴的です。SNS のプライベートメッセージを Zendesk に統合して、オムニチャネルビューを作った結果、私的 SNS チケットを100パーセント解決し、CSAT を17パーセント改善、初回応答時間を66パーセント短縮しました。
ミカ
SNS を追加しただけでなく、履歴がつながったから速く解けたんですね。しかも、メールの一部は AI で受け流しているなら、原価面にも効いていそうです。
Chapter 4 なぜ経営テーマになるのか
タカシ
Intercom の Smartly は、Facebook Messenger 中心だった体制から、24時間365日に近い multi-platform support へ広げ、初回応答を3分未満、平均 investigation time を90分、CSAT を97パーセント以上で維持しながら、サポート能力を50パーセント増やし、運営コストを30パーセント以上下げました。
ミカ
すごいですね。人を増やしたから回ったというより、チャネルと会話データと自動化を同じ基盤に寄せたから、広げても崩れなかった感じがします。
タカシ
まさにそこです。オムニチャネル対応はサポートの見た目を派手にする施策ではなく、再説明を減らし、一次解決率を上げ、AI と人の分担を整理して、成長しても原価が跳ねにくい運営を作る経営施策なんです。
ミカ
つまり、チャネル戦略とサポート体制とデータ設計が別々だと失敗しやすい。逆にここがつながると、顧客体験もコスト構造も一緒に良くなるわけですね。
Chapter 5 失敗しない進め方
タカシ
よくある失敗は五つあります。マルチチャネルをオムニチャネルと誤解する、チャネル別に別 KPI で回す、顧客 ID が統合されていない、AI から人への handoff で情報が切れる、そして入口だけ増やして監視体制を増やさない。このどれかで体験はすぐ壊れます。
ミカ
明日から着手するなら、まず顧客 ID と契約プラン、過去履歴、優先度を横断参照できるようにする。次に SLA と営業時間を共通化する。最後に AI から人への引き継ぎ要約を必須にする、この順番が良さそうです。
タカシ
その順番が堅いです。加えて、チャネル別初回応答時間だけでなく、再説明率、チャネル跨ぎ回数、一次解決率、CSAT をセットで見てください。オムニチャネル対応は、窓口拡張ではなく、顧客文脈を守る運営づくりなんです。
ミカ
入口を増やすほど、裏側の設計力が問われるんですね。今日の話で、オムニチャネル対応はサポートの便利機能ではなく、SaaS の信頼を切らさない仕組みだとよく分かりました。それではまた次回。