顧客が一つのチャネルにとどまることはめったにありません。質問はウェブサイトのチャットで始まり、メールで続き、WhatsAppに移り、緊急になると電話で終わります。オムニチャネルコンタクトセンターソフトウェアは、この4つのやり取りを4つの無関係なチケットではなく、一つの会話として保つためのものです。
この違いは表面的なものではありません。顧客が注文番号を4回繰り返すかどうか、担当者がアカウント履歴を目の前にして回答するかどうかを左右します。
オムニチャネルコンタクトセンターソフトウェアが果たすべき役割
マルチチャネルとは、複数の場所で連絡が取れることを意味します。オムニチャネルとは、それらの場所が一つの記録を共有していることを意味します。2つ目をうたうツールの多くは、実際には1つ目しか実現できていません。
両者を分ける機能は3つあり、そのすべてが機能ページを読むだけでなく、トライアルで実際に試す価値があります。
一つ目は単一キューです。チャネルごとのタブではなく、すべてのチャネルが一つの場所に一つのルールセットの下で届きます。二つ目は本人確認です。異なるチャネルから届く連絡先が同一人物として解決されることです。三つ目は継続性です。履歴が、同僚への引き継ぎを含め、チャネルをまたいで顧客に付いて回ることです。
チャットを開き、同じ顧客にメールで返信し、その後電話をかけてみてください。通話を担当する担当者が会話を離れることなくチャットとメールを読めるなら、そのプラットフォームはオムニチャネルです。そうでなければ、うまく宣伝されたマルチチャネルにすぎません。
分散したチャネルと、聞き直しのコスト
チャネルが分断されているコストは、障害という形では現れません。繰り返し、重複作業、そして互いに矛盾する回答という形で現れます。
顧客が気づくのは繰り返しの部分です。ゼロから始まるチャネル切り替えのたびに問題を説明し直すよう求められ、そのたびに諦めるきっかけが生まれます。
チームが気づくのは重複作業の部分です。相手の返信が見えないため、2人の担当者が2つのツールで同じ質問に答えてしまい、2つ目の回答は顧客がすでに最初の回答に基づいて行動した後に届きます。
矛盾はコストが高いものです。チャットである内容を伝え、メールで別の内容を伝えた場合、解決の焦点はもはや元の問題ではなくなります。
何かを変える前に数えておく価値があるのは、複数のチャネルにまたがる会話がどれだけあるかです。その数値が問題の大きさです。
一つの共有受信箱、そこに含めるべきもの
共有受信箱はこの仕組みの中核であり、その価値は何を外に出さないかによって決まります。
RolChatは、ウェブチャット、メール、電話、SMS、WhatsApp、Telegram、Facebook Messenger、Instagram、Viber、LINE、ウェブフォームという11のチャネルを一つの場所にまとめます。重要なのはその数字よりも、それらが同じルールの下で届くという点です。
一つのキューとは、一つのルーティングモデル、一つの役割セット、履歴が存在する一つの場所、そして「対応済み」とみなす基準が一つであることを意味します。
最後の項目はチームが過小評価しがちなものです。各チャネルが独自の「クローズ」の定義を持っている場合、チーム全体で見た解決時間のレポートには何の意味もありません。
本人確認: 一つのスレッドにまとめる要
チャネルを結びつけるのは簡単です。人を結びつけることこそが難しく、共有チームインボックスツールの間で静かに差が出る部分です。
各チャネルはそれぞれ異なる識別子を提供します。メールはアドレスを、WhatsAppは電話番号を、Instagramはハンドル名を提供しますが、ウェブチャットは訪問者が何かを入力するまで多くの場合何も提供しません。
| チャネル | 提供される識別子 | 単独で照合可能か |
|---|---|---|
| メール | アドレス | 可能 |
| 電話とSMS | 電話番号 | 可能 |
| WhatsAppとViber | 電話番号 | 可能 |
| TelegramとLINE | プラットフォームのハンドル名 | 初回の紐付け後のみ |
| InstagramとMessenger | プラットフォームのハンドル名 | 初回の紐付け後のみ |
| ウェブチャット | セッション、場合によってはメールアドレス | 不可 |
「不可」とある行こそが、プロジェクトの成否を左右します。ハンドル名を既知の連絡先に統合できないプラットフォームは、一人の人物に対して2つの記録を表示してしまい、その上に構築されるあらゆるレポートが二重にカウントされます。
統合がどのように機能するか、担当者がライブ会話中にそれを行えるか、そして顧客が3つ目のチャネルで再度訪れた後も統合された履歴が統合されたままかを確認してください。
多忙な日にも機能するルーティングルール
ルーティングは、オムニチャネル体制が時間を節約するか、それとも新たに管理すべきキューを生み出すかの分かれ目です。
有効に機能するルールは地味なものです。トピック別、言語別、プラン階層別、そしてその顧客がすでに対応中の会話を持っているかどうか別です。最後のルールは最もよくある失敗、つまり元の担当者がまだ対応中であるにもかかわらず、再訪した顧客が新しい担当者にルーティングされてしまう事態を防ぎます。
スキルベースのルーティングは、スキルの数が少なく、実態に即している場合に機能します。誰も管理していない20項目のスキルリストは、四半期のうちに単なる抽選になってしまいます。
優先度についても同じ抑制が必要です。誰もが尊重する2段階の優先度は、全員が「最優先」と付ける5段階の優先度に勝ります。
スキルや対応可否でルーティングする前に、すでにその顧客を担当したことのある担当者にルーティングしてください。継続性はマッチングに勝り、設定するコストはかかりません。
チャネルの違いは重要である
すべてのチャネルを同一に扱うことは、チャネルを別々に扱うことに次いでよくある間違いです。
メッセージングチャネルには、御社のヘルプデスクではなくプラットフォーム側が定める独自の配信ルールとメッセージウィンドウがあります。4分以内なら問題ない返信が、40時間後にはブロックされることもあります。
メールは長文や書式を許容しますが、チャットはそうではありません。メールでは読みやすい同じ回答が、チャットでは誰も最後まで読まない文字の壁になります。
ソーシャルチャネルは、非公開になるまでは公開されています。コメントに公開の場で答えることと、苦情に非公開メッセージで答えることは、レビューする人も異なる別の作業です。
優れたオムニチャネルソフトウェアは、裏側の仕組みは標準化しつつ、話し方には手を加えません。そのため担当者は6つのインターフェースを学ぶことなく、そのチャネルにふさわしい書き方ができます。
同じワークスペース内の音声通話
音声は、多くの場合別のベンダーから導入されそのまま残ってしまうため、最も外に取り残されがちなチャネルです。
外に置いたままにするコストは見た目以上に大きいものです。難しい案件ほど通話に集まるため、最も多くの文脈を持つチャネルが最も少ない文脈しか持たないことになり、通話記録はチームの他のメンバーが読む記録には決して届きません。
一つのワークスペース内であれば、通話は同じ顧客記録を開き、その書き起こしは同じスレッドに残り、フォローアップのメールは最初からやり直すのではなく、そこから続きます。
通話分数はプランとは別に課金されるため、音声の利用量は座席料金に隠れた要素ではなく、目に見える項目のままです。
やり直しのないチャネル間の引き継ぎ
オムニチャネルの価値の多くは引き継ぎの瞬間に実現され、オムニチャネルへの失望の多くも同じ瞬間に生まれます。
うまくいく引き継ぎは、3つのことを引き継ぎます。顧客が何を尋ねたか、すでに何が約束されたか、そして何が確認済みかです。真ん中の項目が欠けていると、2人目の担当者は再び約束をしたり、矛盾したことを言ったりしてしまいます。
御社側が主導するチャネル切り替えにも同じ配慮が必要です。速いからという理由でチャットを通話に移すのは、通話がチャットを表示した状態で始まる場合にのみ役立ちます。
トライアルで最も有効なテスト: ライブ中の会話を別のチャネルで対応する同僚に引き継ぎ、顧客が同じ質問を2回尋ねられる回数を数えてみてください。
オムニチャネル体制の中でAIが果たす役割
AIは、チャネルがすでに統合された後の方が役立ちます。なぜなら、一つのチャネルしか見えないモデルは、一つのチャネルの視点でしか文章を書けないからです。
一つの記録を背景に持つことで、アシスタントは全履歴から下書きを作成し、40言語間で双方向に翻訳し、到着時に意図を分類するため、人間が何かを読む前にルーティングが完了します。
この順序を尊重する価値はあります。分断されたチャネルに自動化を適用すると、話の3分の1しか把握しないまま自信満々な回答を生み出してしまいます。
チャネルが本当に統合されているかを測定する
チャネルごとのダッシュボードは、体験が壊れていても緑色を示すことがあります。各チャネルは自分自身の断片しか測定していないからです。
境界をまたいで読み取れる指標は4つあります。複数のチャネルにまたがる会話の割合。それらの解決時間を単一チャネルの会話と比較したもの。1週間以内の再問い合わせ率。月ごとに作成される重複連絡先レコードの数です。
マルチチャネルと単一チャネルの解決時間の差は、この中で最も正直な数字です。体制が改善するにつれて、その差は縮まります。
重複レコードは先行指標です。この数値が上昇するとき、本人確認の照合がうまくいっていないということであり、他のすべての数値もそれに追随して悪化します。
キューを壊さない移行順序
すべてのチャネルを同じ日に移行することは、チームがロールバックに陥る典型的な原因です。
うまくいく順序はこうです。最も量が多く、最も複雑さの低いチャネル、通常はメールかウェブチャットから始めます。ルーティングルールを新たに作り直すのではなくそのままコピーして、旧ツールと並行して1週間運用します。
次にメッセンジャーを追加します。本人確認の問題を早く安く表面化させてくれるからです。音声は最後に移します。外部依存が最も多く、悪い週への耐性が最も低いためです。
履歴のインポートは最初のステップに含めるべきで、最後にすべきではありません。担当者は空の状態で始まるワークスペースを信用せず、旧タブを開いたままにしてしまい、それでは移行の意味がなくなります。
購入前に知っておくべき制限
料金は担当者ごとではなく会社ごとで、Liteの$19からで、Enterpriseは個別見積もりのため、チャネルを追加しても人数分だけ倍増することはありません。
電話とコンセントは有料アドオンであり、Liteではアドオンを利用できません。コンセントはサイトごとに$5、サイトごとに3件の同意まで利用できます。
オンプレミス導入はEnterpriseの契約形態であり、自社ハードウェア上で動作するモデルは今日利用可能なものではなく、計画段階にあります。
トライアルはすべての機能を開放し、カード登録ありで30日間実施されるため、デモアカウントではなく実際のトラフィックで本人確認の照合をテストするのに十分な長さです。
よくある質問
オムニチャネルコンタクトセンターソフトウェアは実際に何を変えるのですか？
すべてのチャネルを一つの顧客記録の背後にある一つのキューにまとめるため、履歴はチャネルではなく人に付いて回ります。目に見える結果として、顧客はチャネルを切り替えた後に同じ説明を繰り返さなくなります。
オムニチャネルはマルチチャネルとどう違うのですか？
マルチチャネルとは、複数の場所で連絡が取れることを意味します。オムニチャネルとは、それらの場所が一つの記録と一つのルーティングルールを共有していることを意味します。後者として販売されているツールの多くは、実際には前者しか実現していません。
どのチャネルを最初に統合すべきですか？
最も量が多く、最も複雑さの低いもの、通常はメールかウェブチャットから始め、次にメッセンジャー、最後に音声とします。音声は外部依存が最も多いため、最後に回すことが有利です。
異なるチャネルからの会話はどのように結びつけられるのですか？
本人確認の照合によって結びつけられます。メールと電話番号は単独で照合できますが、プラットフォームのハンドル名は通常、既知の連絡先への初回の紐付けが必要であり、ウェブチャットのセッションは訪問者が自ら名乗るまで多くの場合何も提供しません。
音声はチャットと同じプラットフォームに含めるべきですか？
通話は最も難しい案件を扱うため、音声を外に置いたままにすると、最も多くの文脈を持つチャネルが最も少ない文脈しか持たないことになります。一つのワークスペースであれば、書き起こしはチャットやメールと同じスレッドに残ります。
チャネルを統合した後に何を測定すべきですか？
複数のチャネルにまたがる会話の割合、それらの解決時間を単一チャネルの会話と比較したもの、1週間以内の再問い合わせ率、そして月ごとに作成される重複連絡先レコードの数です。
何言語に対応していますか？
インターフェースとウィジェットで40言語に対応しており、会話内で双方向の翻訳が行われます。製品用語や法律用語は翻訳されないよう用語集に保持してください。
料金は担当者ごとですか？
会社ごとの料金で、Liteの$19からで、Enterpriseは個別見積もりです。電話とコンセントはアドオンであり、Liteでは販売されていません。
