RightTouchエンジニア３チームそれぞれの特徴と課題をチームリーダーに聞いてみた！【2023年11月ver.】

<html><head></head><body><h1 id="はじめに">はじめに</h1>
<p>先日、RightTouchの新プロダクト「<a href="https://rightconnect.karte.io/" target="_blank" rel="noreferrer">RightConnect by KARTE</a>」のβ版がリリースされました。</p>
<p>このプロダクトは問い合わせ体験における、Webサイトと電話の分断をなくし、顧客とオペレーターの両方の満足度を高めることを目指しています。</p>
<p>従来の電話問い合わせは下図の様なフローで表現できます。</p>
<p><img src="https://ik.imagekit.io/righttouch/2bdca1f3-e594-49f4-930a-94fe9638bf14/connect_1.png" alt="connect_1.png"></p>
<p>図にもある通り、このフローにはいくつか課題があります。</p>
<ol>
<li>
<p>顧客の要件把握問題</p>
<p>電話問い合わせの際、IVR（Interactive Voice Response）を用いて顧客の要件を事前に把握することが多いです。しかし、選択肢の限定性により、実際の顧客のニーズとの間にギャップが生じることがあります。その結果、オペレーターへの通電後も追加の情報収集が必要となり、通話時間の延長や顧客の不満につながることがあります。</p>
</li>
<li>
<p>オペレーターのミスマッチ課題</p>
<p>顧客の問い合わせ内容とオペレーターの専門性のミスマッチは、サービスの質に影響を与える重要な課題です。この問題は、Webサービスの日々の変化と、CTI（Computer Telephony Integration）システムを手動で更新する必要があることに起因します。最新のサービス情報に基づいてCTIが設定されていない場合、顧客と繋がるオペレーターが適切な対応ができないことがあります。このミスマッチを減らすには、CTIシステムの定期的な更新と、オペレーターのスキルに合わせた問い合わせの割り当てが必要です。</p>
</li>
<li>
<p>Webサイトと電話の間での顧客情報・顧客体験分断の課題</p>
<p>顧客対応における大きな課題の一つは、Webサイト上での顧客の行動データと電話システムとの間で情報が共有されないことによる分断です。顧客がサイト上で行ったページ閲覧履歴、ウィジェット操作、ポップアップの利用、Webフォームへの入力などの行動データは、貴重な情報源です。これらのデータはCRMなどのシステムを通じて一部オペレーターに共有されますが、多くの場合、電話という異なるインタフェースに切り替わる際に失われてしまいます。</p>
</li>
</ol>
<p>これらの課題は、顧客の満足度やコールセンターの業績指標に直接影響を与える重要な要素です。</p>
<p>この記事ではRightConnectでどのように上記の課題を解決するのかと一部システムの裏側で行われている工夫を紹介します。</p>
<h1 id="RightConnectの概要">RightConnectの概要</h1>
<p>まずはじめに、RightConnectは４つの要素で構成されています。</p>
<ul>
<li>ウィジェットによるリーズンの絞り込みと問い合わせ導線ごとのチャネル切り替え</li>
<li>問い合わせ前のアンケートによる共通項目の聴取</li>
<li>問い合わせ番号ベースのオペレーターへの情報還元</li>
<li>オペレーター向け画面による応対の効率化</li>
</ul>
<p>これらの要素を使って実際に応対を始めるまでのデモがこちらです。</p>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.25%;"><iframe src="https://www.youtube.com/embed/DYdeEgKluoA?rel=0" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen="" scrolling="no" allow="accelerometer; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share;"></iframe></div>
<h2 id="全体の流れ">全体の流れ</h2>
<p>顧客とオペレーターそれぞれの視点でどのような操作を行うかをまとめると、下記のような感じになります。</p>
<h3 id="顧客視点">顧客視点</h3>
<ol>
<li>Webサイト上のウィジェットから問い合わせ番号を発行</li>
<li>ウィジェットに表示された電話番号に架電し、発行した問い合わせ番号を入力</li>
<li>CTIを通じて適切なオペレーターへのルーティングがされたうえで通電</li>
</ol>
<h3 id="オペレーター視点">オペレーター視点</h3>
<ol>
<li>受電履歴ページを開いておく</li>
<li>CTIからルーティングされた問い合わせ電話を受電</li>
<li>問い合わせに紐づくユーザーのダッシュボードが自動で開かれる</li>
<li>ダッシュボードを見ながら応対を行う</li>
</ol>
<p>さらにシステム含めて流れを図にすると下記のようになります。</p>
<p><img src="https://ik.imagekit.io/righttouch/278f9509-773f-4881-ba37-90976ad63460/connect_2.png" alt="connect_2.png"></p>
<p>ウィジェットから問い合わせ番号を発行することで架電時のIVRのステップを大幅に削減しつつ、ウィジェット内の窓口ごとにルーティングを行うことによってオペレーターとのミスマッチを減らすことができます。また、問い合わせ直前に事前アンケートを行うことで通電後に共通で聞いている内容などもWeb上で回答し、オペレーターに共有された状態で会話を開始することができます。</p>
<h2 id="ダッシュボード">ダッシュボード</h2>
<p>次にRightConnectにおいて肝となるダッシュボードを紹介します。</p>
<p>ダッシュボードは下図のような画面であり、大きく4つの機能を持ちます。</p>
<p><img src="https://ik.imagekit.io/righttouch/52095f9b-4459-49da-a43f-72fb52d6a965/connect_3.png" alt="connect_3.png"></p>
<h3 id="①問い合わせ基本情報">①問い合わせ基本情報</h3>
<p>ユーザーの一時ID、オンライン・オフライン、ウィジェット上での行動データや事前アンケート項目への回答、問い合わせリーズンなど問い合わせユーザーのこれまでと現状を把握するための情報が表示されます。</p>
<h3 id="②ユーザーセグメント">②ユーザーセグメント</h3>
<p>KARTEのセグメント機能を利用しています。エンドユーザーの属性（ログイン・未ログイン、契約済み、など）から応対に必要なものを選択して表示することができます。</p>
<h3 id="③KARTE イベント">③KARTE イベント</h3>
<p>BigQueryに溜まっているWeb上での行動データ（KARTEイベント）から今回のセッションやそのユーザーに紐づくものを集計し、表示します。応対に必要なイベント、カラムに絞って表示することができます。</p>
<h3 id="④Liveストリーミング">④Liveストリーミング</h3>
<p>KARTEのLiveストリーミング機能を利用しています。リアルタイムにお客さんの画面を見ることができるため、特にWeb上での操作が必要になるお問い合わせなどでスムーズな応対が可能になります。また、マウスポインタ共有機能(α機能)を用いて、オペレーターが実際に問い合わせユーザーの画面上にポインタを表示しながらの応対をすることもできます。</p>
<p>オペレーターはダッシュボードを使うことで、Web上でのこれまでの顧客の様々なデータと現時点のステータスを把握しながらの応対をすることが可能になります。（課題③）</p>
<h1 id="技術的制約と工夫">技術的制約と工夫</h1>
<p>このプロダクトの特徴的な要件として、上述の通りダッシュボードをオペレーターが電話応対しながらリアルタイムで利用することがあげられます。</p>
<p>そのため、<strong>オペレーターが受電してから素早くダッシュボードが表示され、見たい情報を変更しながら確認できる即時性が重要</strong>になります。</p>
<p>しかし、技術的に以下の課題がありました。</p>
<ul>
<li>問い合わせユーザーの行動データが BigQuery に大量に保存されており、取得に時間がかかる</li>
</ul>
<p>クエリの速度とデータ量の問題により、 BigQuery へのクエリを最適化しても何秒もかかる状態でした。</p>
<p>シンプルに大きく以下の2つで対策をとりました。</p>
<ul>
<li>事前キャッシュ</li>
<li>情報の表示優先度を決めてキャッシュ</li>
</ul>
<h2 id="事前キャッシュ">事前キャッシュ</h2>
<p>取得にどうしても時間がかかるのであれば、事前にキャッシュすれば、解決します。</p>
<p>大事なのは、どのタイミングでキャッシュ処理を実行するかになります。</p>
<p>そこで、ユーザー問い合わせの流れの <code>お問い合わせ番号発行 ~ オペレーター通電</code> までのラグがあることを利用しました。</p>
<p>ユーザーのお問い合わせ番号発行のタイミングで、ダッシュボードに必要な情報キャッシュするジョブを PubSub に Publish して、ジョブを実行して BigQuery から取得して Redis にキャッシュしています。</p>
<p>これにより、ダッシュボードに必要なデータをすべてキャッシュから取得できるようになり、表示速度を劇的に改善できました。</p>
<h2 id="情報の表示優先度を決めてキャッシュ">情報の表示優先度を決めてキャッシュ</h2>
<p><code>お問い合わせ番号発行 ~ オペレーター通電</code> までのラグを利用して事前にキャッシュしていましたが、そのラグが短い場合、キャッシュが間に合わないケースがありました。</p>
<p>キャッシュが間に合わないと、表示に何秒もかかってしまうため、オペレーターがプロダクトを有効活用することができません。</p>
<p>そこで、カスタマーサポートのオペレーターの対応の流れに合わせて、ダッシュボードで何のデータを先に表示すべきかそれぞれの情報の優先度を決めてキャッシュの仕組みを変更しました。</p>
<p>カスタマーサポートのオペレーターの対応の流れを簡略化すると以下のようなものになります。カッコ内は上記システムの流れ、ダッシュボード内の該当機能。</p>
<p>(受電)</p>
<ol>
<li><code>問い合わせ内容確認</code> (①問い合わせ基本情報)</li>
<li>詳細要件確認 (②ユーザーセグメント, ③KARTE イベント)</li>
<li>対応 (④Liveストリーミング)</li>
</ol>
<p>(終電)</p>
<p>このオペレーターが最初に行う、 <code>問い合わせ内容確認</code>に着目し、 ユーザー行動の<code>問い合わせ内容確認</code> に必要なデータを抽出し、BigQueryを介さずにそのままキャッシュできる機構を用意しました。</p>
<p>これにより、ラグが極端に短い場合でも、 <code>問い合わせ内容確認</code> に必要なキャッシュを間に合わせることができました。対応時にダッシュボードの他のデータがキャッシュが間に合っていなくても、オペレーターが <code>問い合わせ内容確認</code> をしている間に、すべてのデータも表示されます。</p>
<h1 id="おわりに">おわりに</h1>
<p>この記事では電話問い合わせにおける課題とそれを解決するプロダクト「RightConnect by KARTE」の概要、技術的な制約について紹介しました。</p>
<p>RightConnect by KARTEはまだβリリースであり、今後も顧客と企業双方に価値を提供できるようにどんどん進化していきます。</p>
<p>カスタマーサポートという領域は長い歴史を持ち、多くの課題を抱えています。実際の現場に入り込みながら技術で課題を解いていく、そんなプロダクト開発に興味がある方はぜひこちらの募集概要もご覧ください。気軽にお話しできればと思います！</p>
<p>${RECRUIT_LINK}</p>
<p>また、Wantedlyでもエントリーを受け付けています。応募を悩まれている方は、まずはブックマークを登録ください。<br>
${WANTEDLY_LINK}</p>
</body></html>

RightConnect by KARTEの裏側