記事

着信側のコールセンターと発信側のコールセンターの大きな違いは、コールの発生方法の違いです。コンタクトセンターのインフラストラクチャの背後にあるテクノロジーについて説明します。

Twilio、ソリューションディレクター、Devang Sachdev

「Acme Incorporatedへようこそ。どのようなご用件ですか？」このように、これまでに何度も経験してきたやり取りが始まります。昔ながらのコールセンターは、多くの企業にとってカスタマーサービスの中心です。顧客がサポートを必要として企業に電話すると、コールセンターに繋がります。ビジネス担当者が営業やアンケートのために潜在的顧客に電話する際にも、コールセンターから行われます。しかし、すべてのコールセンターが同じわけではありません。ビジネスの性質により運営するコールセンターのタイプが決まります。

コールセンターAPIのプロバイダーであるTwilioは広範にわたる企業と協力しており、それらの企業はコールセンターのテクノロジーを通じて顧客と繋がっています。長年にわたり、同じ質問が何度も問いかけられてきました。これらの質問の1つは、「着信側コールセンターと発信側コールセンターの違いは何か」ということでした。この2つには顕著な違いがあり、ビジネス用にコールセンターを設置するには、その違いを理解することが重要です。

この記事では、着信側コールセンターと発信側コールセンターの違いについて検討します。一部の企業では着信側コールセンターと発信側コールセンターの両方を提供しています。その場合でもこの2つの違いを理解すると、企業に最適なテクノロジーを判断する際に何に注意すべきかが分かり有益です。

その名前が示すように、着信側コールセンターはコールを受けます。着信側コールセンターの最も基本的な特徴は、オペレーターが積極的に電話をするのではなく、電話が入ってくるのを待つことです。通常着信側の通話者はカスタマーサービスを必要としています。これは、技術サポート、製品アシスタンス、注文についてのヘルプなどです。このため、着信側コールセンターのオペレーターは、顧客の問題やリクエストを迅速に効果的に解決する必要があります。

着信側コールセンターは何よりもまずカスタマーサービスに焦点を置き、技術サポート、請求上の質問、その他のカスタマーサービス上の問題に関するナレッジベースとして機能します。これらのコールセンターにとっては、迅速なコールの解決とオペレーターの生産性が、成功のメトリックスとなります。

大半のコールセンターは、通話者をまずインタラクティブ音声応答（IVR）システムに送ってから、オペレーターに繋げます。JDPowerの調査によると、顧客は、オペレーターとやり取りではなく、IVRシステムでのコールセンターとのやり取りに30%の時間を費やしています。IVRプロセスをできるだけ迅速、効率的にするため、多くの着信側コールセンターはTaskRouterのようなインテリジェントルーティングを使用しています。これは、タスクをルーティングし、監視し、空いている最適なオペレーターにエスカレートします。

2016年に、モバイル検索によるビジネス電話の着信は700億件にのぼりました。この数字は2019年までに1620億件までに増加すると推定されています。Googleによると、モバイル検索の61%が通話に至っています。Ruby Receptionistsは、オレゴン州ポートランドを拠点とするライブの仮想受け付けサービスです。北米全体で6,000企業の電話を受け付けています。

Ruby Receptionistsは、通話の品質が落ちることを恐れ、できるだけ長い間レガシーの電話システムを維持しようとしました。Twilio APIに切り替えた際、同社はTwilio SIP TrunkingとProgrammable Voiceを使用して着信側コールセンターを構築しました。Twilioは、迅速なセットアップ、地域の電話番号への簡単なアクセス、堅牢な管理コンソール、通話品質を確保するMPLS、地理的冗長性、より多くの機能提供を可能にする開発プラットフォームを提供しただけでなく、大幅な費用削減も実現しました。

Twilioに切り替えてから通話品質が低下することはなく、Ruby Receptionistsでは電話が不本意に切れてしまうことが以前よりも減りました。システムはAPIに基づいているため、Ruby Receptionistsのオペレーターは全員が同じ大きな一室で電話を待つ必要がありません。実際、オペレーターの大半はリモートで勤務しています。クラウド型コンタクトセンターソフトウェアにより、新しいオペレーターを電話システムに接続する際にインストールの必要がありません。ただシステムに接続するだけです。

デジタル化が進み続ける世界において、有意義な人間関係を提供することに専念するRuby Receptionistsは、各電話連絡で素晴らしいインタラクションを提供するために尽力しています。Ruby Receptionistsは、着信側コールセンターの優れた一例です。

発信側コールセンターは、着信側コールセンターの全く反対です。発信側コールセンターのオペレーターは電話を受けるのではなくかけます。大半の発信側コールセンターは営業に焦点を当てています。オペレーターには電話する連絡先リストがあり、通常顧客関係管理（CRM）ソフトウェアを使用してやり取りを追跡、管理します。

発信側コールセンターのオペレーターの焦点は、質問に回答してサポートを提供するために待機している着信側コールセンターのオペレーターのものとは全く異なります。発信側コールセンターのオペレーターには営業やその他の達成すべき目的があり、それらの目的を満たすために積極的に潜在的顧客に連絡をとります。

All Web Leads（AWL）は、テキサス州オースティンを本拠地とする会社です。同社は、有料調査、オーガニックリード、クリック報酬型広告を使用してインターネットを調査し、家屋、保険、自動車保険を探している顧客を探します。AWLがそれらのリードを見つけると、それらのリードを、AWLの顧客である保険業者に紹介します。従来AWLは、それらのリードをただ顧客に渡していました。データを顧客に提供していましたが、そのデータをどのように取り扱うかは顧客次第でした。

しかしAWLはさらにサービスの質を向上できることに気付き、発信側コールセンターを設立しました。そこでは元々エンタープライズソリューションを使用していましたが、最終的にはTwilio ClientとProgrammable Voice Platformに切り替えました。発信側コールセンターを通じ、潜在的顧客がオンラインフォームに記入するとすぐにAWLのオペレーターは電話をかけ、リードを特定します。AWLのオペレーターはリードを特定し、顧客が購入しようとしていることを確認します。顧客の購入準備ができるとAWLは直ちにそれらの顧客を保険業者に紹介するため、高品質のリードをオンデマンドで提供できます。

発信側コールセンターを追加することにより、AWLの顧客満足度が大幅に向上しました。また、同社はTwilio APIを使用してコールセンターを構築したため、400人を超えるAWLのすべてのオペレーターはリモートで勤務しています。このため、同社は費用を抑えながら急激な成長を遂げることができました。

着信側のコールセンターと発信側のコールセンターの大きな違いは、コールの発生方法の違いです。多くのコールセンターでは着信と発信の両方のコールを処理しますが、大多数のコールが着信の場合には、そのコールセンターは着信側コールセンターと見なされます。同様に、大多数のコールが発信の場合には、そのコールセンターは発信側コールセンターと見なされます。

貴社組織でコールセンターインフラストラクチャを計画する際には、顧客とどのようなタイプのインタラクションを行うのかを理解することが重要です。たとえば、大半のコールが受信の場合には、TaskRouterのようなインテリジェントなコールルーティングが、運営の効率化にとって最も重要です。さらに、オペレーターがCRMを使用して一時間に複数回電話をかける場合には、プレディクティブダイヤラーのようなテクノロジーの導入を検討することをお勧めします。

多くの企業では、着信側コールセンターか発信側コールセンターのいずれかを運営していますが、その両方が必要となることが頻繁にあります。たとえば、英国最大のオンライン自動車ローンブローカーであるCarFinance247は、毎週数千人の人々がローンの承認を受け、車をオンラインで探せるように支援しています。オンラインでの車の購入は複雑なトランザクションのため、他の購入と比較してより詳細なカスタマーサービスが必要とされます。

CarFinance247は、見込客からの電話を処理し、オンラインで連絡先情報を入力した関心を持つ購入者に電話をします。つまり、同社のオペレーターは、電話の発信と受信の両方を行います。しかし、オペレーターは電話のみでつながっているわけではありません。CarFinance247は、顧客が、友達や家族と連絡するように、好きなときに好きなチャネル（SMSやチャットなど）で連絡できることを非常に重視していることに気付きました。このため同社は、Twilio Voice、SMS、Chatを使用してコールセンターを構築し、ユーザーが電話、テキスト、アプリ内チャットで連絡できるようにしました。

このシステムはTaskRouterを使用して顧客を最適なオペレーターに接続します。一方オペレーターはTwilio Syncを使用し、顧客がWebサイトでどのような車を検索しているかなど、顧客の行動をリアルタイムで確認できます。

従来コールセンターは電話のみで顧客とやり取りしてきましたが、CarFinance247の例から分かるように、現在のコールセンターは顧客が好むチャネルで顧客と繋がるマルチチャネルコンタクトセンターへと進化しています。現代的なマルチチャネル着信側コンタクトセンターでは、アプリ内チャットやビデオ、SMSやFacebook Messengerでカスタマーサポートが行われます。イベントプロモーションのような発信コミュニケーションはプッシュ通知として送信され、アンケートはメッセージングアプリで展開されます。また、メールで受信した販売に関する問い合わせは、電話で連絡できるように、オペレーターに直接送信されます。コンタクトセンターは常に、すべてのチャネルのすべてのコミュニケーションを処理します。

複雑だと感じますか？マルチチャネルの着信側と発信側のコンタクトセンター向けに設計されたコミュニケーションAPIを使用することにより、顧客とコミュニケーションをとるための希望に合うシステムを構築することは驚くほど簡単になります。

TwilioのプログラマブルAPIなどのコミュニケーション構築ブロックを使用してコンタクトセンターを構築すると、必要なチャネルや機能を選択でき、コールセンターが複数チャネルへと拡大する際にそれに応じてブロックを追加できます。着信側コールセンターとしてスタートし、後に発信コールのために拡大することもできます。SMS、アプリ内チャット、ビデオなど、電話を超えたほかのチャネルを後で追加できます。

APIにより、希望通りのカスタマーサービスを構築する柔軟性と、希望する頻度でコミュニケーションを繰り返せる自由が得られます。

さらに、市場の新しいオプションであるプログラマブルコンタクトセンタープラットフォームもあります。Twilio API上に構築されたFlexは、すぐに展開でき、また、スタックのあらゆるレイヤーでプログラム可能なるコンタクトセンターでです。コンタクトセンターの購入者は、もう以前のようにレガシーのオンプレミスソリューションで高費用と時間のかかる開発サイクルを必要とする構築と、すぐに使用できる機能が限定されているSaaSソリューションの購入の2つの間で選択する必要がありません。Twilio Flexを使用することにより、企業はすぐに使用できるコンタクトセンターを購入することも、それぞれのビジネス目標を満たす完全なカスタマーサービスを今すぐ、または将来に構築することもできます。