クラウドコンタクトセンターをスモールスタートするべき理由と仕様例

こんにちは。レバレジーズ株式会社の西口です。

前回はクラウドコンタクトセンターの優位性について記載しました。そして、Twilioを用いたコンタクトセンターを作るにあたり、まずはスモールスタートをするべきでまとめてあります。
 
詳しくは以前の記事を参照してください。

 

現在、Twilioを用いたコンタクトセンターではかなり大規模になっている弊社でも、最初は10人ほどのチームにスモールスタート版を試してもらうところからはじめました。実際に現場に導入したときは、電話機ならあって当然の機能が漏れていたり、使い方の説明が難しく、受け入れまでに時間がかかったりと大変でした。改修を行っていき、一般的な電話の機能をもたせ、急に途切れたり、音質に問題が起きたりせず、電話機を使わないメリットを理解してもらえ、信頼を勝ち得た過去があります。そのため、コンタクトセンターのリプレースまでスムーズに進められた経緯があります。
 
この記事では、クラウドコンタクトセンター導入の肝となるスモールスタートする具体的な理由と、仕様の提案をします。
 

スモールスタートするべき理由

小さく早く失敗をするためです。

Twilioや、Twilioが通話するために使用するWebRTCは安定した技術ですが、ユーザが使うPCや物理的なネットワーク、通話相手の状態や通信キャリアなど、複数の要素に影響を受けます。普通のWebサイトの開発や利用より、確認に時間を掛けたいところです。時間をかけつつ、すばやく失敗し、改善していきましょう。

 

クラウドコンタクトセンターの要件を満たせるかどうかを確認する

まずは要件を明文化しましょう。

洗い出した要件を元に、TwilioのどのAPIをどのタイミングで呼び出すかを調査します。何ができてできないかをイメージしやすくなりますし、作業着手前に不明点も分かるので、早めに解決策を探す時間ができます。

不明点はKDDIウェブコミュニケーションズが開催しているTwilio相談会で相談したり、Teratailに質問したりできます。Teratailでは、Twilioタグが付いている質問はTwilio関係者が回答してくれやすいです。

 

Twilio相談会
https://twilio.kddi-web.com/consultation/

Teratail
https://teratail.com/tags/Twilio

 

技術的難易度を確認する

要件の洗い出し後は、実際にプログラミングしてみましょう。

Web開発経験があれば、手を動かすことはできますが、リアルタイムで動き続けるTwilioならではの癖やデバッグのコツを掴む必要があります。また、選定したフレームワークとTwilioの相性の確認することもおすすめです。

 

PCやネットワークなど、物理デバイスが使用に耐えうるかを確認しやすい

最後に、クラウドコンタクトセンターを使うにあたり、必要な機器やネットワークが使用に耐えうるか確認しましょう。

ネットワークの確認にはテスト用のサイトが提供されています。まずはここにアクセスし、問題がないかを確認しましょう。

WebRTCの利用可否テストサイト
https://test.webrtc.org/

Twilioの利用可否テストサイト
https://networktest.twilio.com/

TwilioやWebRTCは物理デバイスの影響を受けます。
推奨スペックは下記ドキュメントに記載あります。

推奨スペックはこちら

推奨スペックを満たしていても、PCで動かしている他のソフトウェアやネットワークの使用状況によって、
通話が不安定になったり、音質が悪くなる可能性もあります。
早い段階でこのような問題を見つけ、解決しておきたいですね。

未だに運用していてよく発生するのですが、有線LANに接続していても、Windowsだと無線Wifiで通信することがあり、通話が不安定になると言われることがあります。
このような運用上の問題は実際にやってみないとわからないので、スモールスタートで知見を貯めていきましょう。

 

スモールスタートの仕様例

スモールスタートする理由がわかったところで、実際に開発するにあたっての具体的な仕様例をあげます。

CRM連携せず、通常の電話機と同等の仕様に留める

CRM連携は考えることが非常に多く、スモールスタートには向きません。そこで、通常の電話機と同等の仕様を持たせるようにしましょう。通常の電話機は下記仕様を持ちます。

  • 架電
  • 受電
  • 保留
  • 保留解除
  • DTMFトーン

DTMFトーンは宅配便の再配達などで、電話番号や再配達希望日を入力する際にダイアルボタンを押すときの機能のことです。

仕様としてはあまり多くありませんが、この中では保留の実装が最難関です。保留と保留解除の実装はTwilioを語る上では外せない、難易度の高い機能になります。

保留をどう実装するのかは次の記事でコード例を出しますので、お楽しみに。

 

受電の仕様は一番単純にする

受電の仕様決めが一番難しいです。

一般的なビジネスフォンはACDという機能があります。
この機能は受電対応ができる状態かつ、問い合わせに対応できるスキルを持ったオペレーターに優先的に電話を回すというものです。TwilioではTaskRouterという機能で実装が出来ますが、いきなり実装し始めるのは難しいでしょう。

そのため、受電を担当させる人を何名か決めてしまいます。こうすれば、仕様も実装もとてもかんたんです。

 

スモールスタート版は少ない人数で密に連絡が取りやすいチームを選別する

スモールスタート版は、一般的なビジネスフォンより機能が少ないです。そのため、使ってみたけど、普通のビジネスフォンが良いと評価される可能性があります。

なぜTwilioを採用し、将来的にはどう会社に貢献するかのビジョンを対面で話せるくらいの人数にしておいたほうが、協力を得やすいです。また、仕様としてはかんたんでも、初めてTwilioを触る人がバグがなく作るのは難しいでしょう。そのため、何か問題が起きたときの代替手段を用意しつつ、問題発生時のフィードバックを受けやすい体制を組んでおくことをおすすめします。

 

スモールスタート版導入時の評価点

下記点を重点的に見てください。
これらがクリアできれば、CRM連携なども含めた、クラウドコンタクトセンターへの提案がしやすくなります。

  • 音質や通話が途切れることが発生しないか
  • 使用しているPCやネットワークのスペックが使用に耐えうるか
  • ネットワークに負荷がかかり、他の業務に支障をきたすことがないか

まとめ

今回の記事では、最小限の仕様を提示しました。
次回はこの仕様に沿って、具体的なコードに触れて行きます。お楽しみに。

この記事をシェア


すべての記事へ

Blog

クラウドコンタクトセンターをスモールスタートするべき理由と仕様例

Blog

コンタクトセンターにおける、オンプレミスとクラウドの比較と優位性について

Blog

LINE to Callを使ってCXを向上させよう

Blog

TwilioとLINEが連携 – 1つのAPIから複数のチャネルへのアクセスが可能に