3つのカテゴリーは別々に販売されているが、目的は1つ、顧客に答え、しかも顧客を見失わないことだ。ヘルプデスク、ライブチャットツール、カスタマーサービスCRM。三者の重なりは大きく、たいていのチームは結局2つを併用し、重複する部分に二重の料金を払うことになる。
そこから抜け出す方法は機能比較表ではない。それぞれのカテゴリーが実際に何を中心に構築されているかを理解することだ。その中心こそがそのツールが得意とする部分であり、それ以外はすべて付加機能にすぎない。
3つのカテゴリー、1つの仕事
それぞれのカテゴリーは異なる対象を軸に構成されており、そこからすべてが導かれる。
ヘルプデスクはチケットを軸に構築されている。状態、担当者、期限、そして責任を負う人が存在する作業単位だ。ライブチャットはセッションを軸に構築されている。今まさに起きている会話であり、秒単位で計測される。CRMはアカウントを軸に構築されている。個々の依頼よりも長く残る履歴を持つ人物や企業のことだ。
そのツールがどの対象なしには機能しないかを問えば、価格ページが何と呼んでいようと、そのカテゴリーは自明になる。
ツールは自らが扱う対象をネイティブに処理し、他の2つを付属物として扱う。ライブチャットツールがチケットの扱いにぎこちなさを見せ、ヘルプデスクが薄い顧客プロフィールしか表示せず、CRMがリアルタイムの受信箱として不向きなのはそのためだ。
ヘルプデスクが担うもの
ヘルプデスクが存在するのは、依頼を1件も見失わず、すべてに担当者がつくようにするためだ。そのネイティブな概念はキュー、ステータス、割り当て、優先度、SLAタイマー、エスカレーションである。
作業が解決されるより速く到着する場合、依頼が1回のやり取りより長く残る場合、そして未解決のまま残っているものについて誰かが責任を負わなければならない場合、これが正しい中心となる。
ヘルプデスクのチケット管理ソフトウェアは、依頼の初日ではなく2日目にその価値を発揮する。扱う案件のほとんどが1回の会話で完結するなら、その仕組みの大部分は使われないまま眠ることになる。
適しているのは: 案件数が多く、依頼が1回のセッションより長く続き、解決期限について誰かが責任を負う場合。
ライブチャットとチャット会話の形
ライブチャットは今まさに起きている会話に最適化されており、その設計全体はこの期限から導かれている。
ネイティブな関心事はウィジェットの挙動、訪問者のコンテキスト、空いている担当者へのルーティング、定型返信、そして数時間ではなく数秒で測る初回応答だ。
販売前の質問や簡単なアカウントの問題に向いている。より広く言えば、速い部分的な回答が遅い完全な回答に勝るあらゆる場面に適している。
その弱点はチャットが完結できないときに現れる。背後にチケットがなければ、未完了の会話には担当者も期限も状態もなく、誰かの記憶の中にしか残らない。
適しているのは: 会話が1回のセッション内で完結し、追跡よりも速度が重要な場合。
カスタマーサービスCRMソフトウェアとアカウント記録
CRMはアカウントを保持する。この顧客は誰か、何を購入したか、何を約束されたか、前回何が起きたかということだ。
サポートにとっては、速度ではなく回答の質を変える要素になる。プラン内容、更新日、過去のクレームを見られる担当者は、現在のメッセージしか見えない担当者とは異なる対応をする。
カスタマーサービスCRMソフトウェアはまた、サポートを会社の他部門から見えるようにするものでもある。営業は更新契約の電話の前に未解決のクレームを確認でき、アカウント管理はチャーンが起きる前にそのパターンを把握できる。
CRMが受信箱ではないという点は重要だ。パイプライン向けに設計されたCRM内でリアルタイムの会話量を処理することは、結局2つのツールを抱えることになる最も一般的な原因である。
決め手となる質問を並べて比較する
| 質問 | ヘルプデスク | ライブチャット | CRM |
|---|---|---|---|
| 何を軸に構築されているか | チケット | セッション | アカウント |
| 自然な時間単位 | 数時間から数日 | 数秒から数分 | 数ヶ月から数年 |
| 「誰が担当か」に答えられるか | はい | いいえ | 部分的に |
| 「これは誰か」に答えられるか | 部分的に | いいえ | はい |
| チャネルの切り替えを乗り越えられるか | はい | めったにない | はい |
| 失敗のしかた | 初回応答が遅い | 未完了の作業を見失う | リアルタイム対応が苦手 |
最後の行から先に読んでほしい。それぞれのカテゴリーは予測可能な形で失敗し、その中で最も許容できない失敗こそが、どの中心が必要かを決める最も強い根拠になる。
二重に料金を払うことになる重複部分
これらのカテゴリーはいずれも互いの領域に向かって拡張してきた。だからこそ、デモではその境界が曖昧に見え、日々の運用では鮮明に感じられる。
ヘルプデスクはチャットウィジェットを追加した。チャットツールはチケットオブジェクトを追加した。CRMは受信箱を追加した。それぞれの追加は本物だが、いずれもその対象を軸に構築された専用ツールより浅い。
重複は請求書上ではめったに見えない。同じ顧客が二重に保存されたり、同じ会話が2つのダッシュボードで二重にカウントされたり、2つのチームが異なるシステムを見ているために数字について食い違ったりする形で現れる。
最もコストがかかるのは連絡先記録だ。顧客に関する情報源が2つあると、どちらも信頼されなくなり、あらゆるレポートがどちらのエクスポートが正しいかという議論になってしまう。
1つのカテゴリーを超えたサイン
変えるべき時期は、人数よりも症状で見分ける方が容易だ。
チャットだけでは、担当者が未完了の会話を独自のスプレッドシートで管理し始めたり、顧客が戻ってきたときに昨日何が話されたか誰も見つけられなくなったりすると機能しなくなる。
ヘルプデスクだけでは、販売前の質問がチケットとして届き、対応が遅すぎて意味をなさなかったり、プロフィールが薄すぎるために担当者が返信のたびに別のツールを開いたりすると機能しなくなる。
CRMだけでは、最初の忙しい午後に、パイプラインのレイアウトが40人への対応の邪魔になった時点で機能しなくなる。
3つすべてに共通する信頼できるサイン: 担当者がツールの外に独自のリストを持っていること。そのリストこそが不足している機能である。
ナレッジベース: 3つすべてが前提とする要素
3つのカテゴリーはすべて、ナレッジベースが存在することを暗黙のうちに前提としているが、いずれもナレッジベースそのものではない。
公開された回答がなければ、定型返信は担当者ごとにばらつき、チケットの解決策はすでに完了した作業を繰り返し、AIレイヤーには信頼できる下書き元となる材料がなくなる。
カスタマーサポート向けナレッジベースソフトウェアは二重に元を取れる。1つは顧客が自ら答えを見つける最前線で、もう1つは自動下書きの根拠となる材料になる裏方の場面で。
ツールが分断されるとレポーティングが最初に破綻する
分断はどこよりも先にレポーティングに現れる。各ツールは自分が見えるものしかカウントできないからだ。
チャットは応答時間を報告するが、メールに引き継がれたやり取りはすべて見逃す。ヘルプデスクは解決時間を報告するが、その質問がすでにチャットで回答済みだったことはわからない。CRMはアカウントについて報告するが、キューの負荷については何も知らない。
3つの緑色のダッシュボードが、実は失敗している体験を描写していることがあり得る。しかもどれも間違ってはいない。
統合されたシステムでしか現れない数字とは、あらゆる接点を通じた顧客1人あたりのコストであり、それが人員配置を決める数字である。
統合か、単一プラットフォームか
3つのツールを連携させることは正当な選択であり、統合が双方向であり、識別キーが一致し、フィールドが変わるたびに誰かが同期を管理していれば機能する。
それは静かに機能しなくなる。一方向の同期はデータの陳腐化へと劣化し、名前が変更されたフィールドは誰も気づかないままマッピングを壊し、その失敗は担当者が誤った記録を信頼するという形で表面化する。
単一プラットフォームは同期を改善するのではなく、そもそも取り除いてしまう。その選択の代償は正直なもので、専門ツールが最も強い領域においては、その専門ツールほどの深さは得られない。
RolChatは単一ワークスペース側の選択肢であり、チケット、チャット、連絡先記録、ナレッジベース、11のチャネルを1つのルーティングモデルと1つの履歴の背後にまとめている。
失う深さと、もはや維持する必要のない同期とを比較すること。専任のオペレーション担当者がいるチームは3つのツールをうまく運用できる。いない場合、同期は1ヶ月壊れたままになって初めて発覚することが多い。
成長とともに挙動が変わるコストモデル
各カテゴリーの価格設定は異なり、その差はどんな機能差よりも速く積み重なっていく。
エージェント単位のライセンスは人数に応じて増えるため、季節採用によって年に2回請求額が変わる。3つの製品から構成されるスイートは製品数によっても増えるため、2つ目、3つ目のツールは最初のツールが示していた金額より高くつく理由となる。
RolChatはエージェント単位ではなく企業単位で価格を設定しており、LiteプランのReturn: $19からで、Enterpriseは個別見積もりとなり、年払いなら10ヶ月分の支払いで済む。電話機能と同意管理はアドオンであり、Liteプランではアドオンは利用できない。
30日間の無料トライアルはカード登録の上ですべての機能を開放するため、サンプルではなく実際の案件量を通して試すのに十分な時間がある。
過剰投資せずに選ぶ
最も許容できない失敗から始めよう。作業を見失うことが問題なら、チケットが答えだ。誰かが待っている間に販売機会を失うことが問題なら、チャットが答えだ。相手が誰かわからないまま回答してしまうことが問題なら、アカウント記録が答えだ。
次に、2番目に深刻な失敗を確認しよう。それが単一カテゴリーのツールで十分か、あるいは重複がコストとしてのしかかってくるかを決めるからだ。
プランに書かれている案件量ではなく、現在の案件量に加えて1四半期分を見込んで購入すること。サポートツールは成長に合わせて拡張するのは容易だが、そこから縮小するのは高くつく。
よくある質問
ヘルプデスクとライブチャットの本当の違いは何ですか？
ヘルプデスクは担当者と期限を持つ作業単位であるチケットを軸に構築されています。ライブチャットは今まさに起きている会話であるセッションを軸に構築されています。前者は追跡し、後者は回答します。
カスタマーサービスCRMソフトウェアも必要ですか？
そのCRMが保持するアカウント記録は必要です。それが独立したCRMとして提供されるか、サポートプラットフォーム内の連絡先記録として提供されるかは、営業やアカウント管理がどれだけ同じビューを必要とするかによります。
CRMをヘルプデスクとして使うことはできますか？
案件を保持することはできますが、キューではなくパイプラインを軸に設計されています。実際の会話量をCRM内で処理しているチームは、たいてい1年以内に2つ目のツールを追加します。
2つのツールを運用することの実際のコストは何ですか？
2つ目のライセンス費用に加えて、重複した連絡先記録、2つのダッシュボードで二重にカウントされる会話、フィールドが変わるたびに誰かが管理しなければならない同期処理といったコストが発生します。
チャットのみのサポートを超えたことをどう判断すればよいですか？
最も明確なサインは、担当者がツールの外に未完了の会話の独自リストを持つことです。そのリストこそが不足しているチケットキューです。
単一プラットフォームは常に3つの統合ツールより優れていますか？
いいえ。統合が双方向であり、識別キーが一致し、誰かが同期を管理していれば、3つのツールでも機能します。単一プラットフォームはその保守作業をなくす代わりに、いくらかの深さを手放します。
ナレッジベースはどこに位置づけられますか？
3つのカテゴリーいずれの外にも位置しつつ、すべてに前提とされています。顧客に直接回答を提供し、自動下書きの根拠となる承認済みの資料を供給します。
ツールが分断されるとどのレポーティング数値が失われますか？
あらゆる接点を通じた顧客1人あたりのコストです。各ツールは自分が見えるものしかカウントできないため、3つの健全なダッシュボードが、実は失敗している体験を描写していることがあります。
