よくできたコールセンターの利点：注文の確認、会議のリコール、調理済みの食事の提供。 VoximplantにはACDモジュールとキューの概念があり、プラットフォームの助けを借りて、数時間で通話を配信するための簡単なソリューションを構築できます。 なぜ「単純」なのですか？ 本当に複雑なソリューションは互いに非常に異なり、「誰もがすぐに使える」モジュールを作成することは不可能です。 ただし、顧客がバックエンドでキューイングロジックを実装するというバトルテスト済みのスキームがあり、当社のクラウドは着信コールのルーティングと分析を支援します。 カッターの下には小さなステップごとの指示があります。100人のオペレーターのために「自分で」コールセンターを作成する方法と理由。 「作業計画、INFA 100％」（秒）
健康な人のタンデム：バックエンド+ Webクライアント
バックエンドには厳密な要件はありません。条件付きのデジタルオーシャンを使用できます（執筆時点では既にDOへのアクセスに問題がありましたが、悲しいことは話さないでください）。 Webクライアント（またはオペレーターのアプリケーション）はワンボタンで準備ができており、WebソケットまたはHTTPリクエストを介してバックエンドと連絡を取り合う必要があります。 どのように機能しますか？
クラウド-テレフォニーセンター
- 着信コールを受け入れるVoximplantクラウドベースのJSスクリプトを作成します。 各呼び出しは、 accessURLプロパティを持つStartedイベントを発生させます。 このフィールドには、進行中の通話のJSセッションと通信するためのURLが含まれます。
- 開始されたイベントに加えて、着信コールはCallAlertingイベントもトリガーします。 このイベントには、コールに関する情報（発信者の番号、ダイヤルする番号、およびその他の必要なもの）が含まれます。
- Cloud JSセッションは、 httpRequestAsyncを使用してバックエンドにリクエストを作成します。 リクエストでは、呼び出しとaccessURLに関する情報を転送します。 リクエストがあり、バックエンドがそれを「噛む」間、クライアントのために音楽を再生し、音声合成を使用して質問をし、アラート/広告でmp3をオンにして、発信者を退屈させないことができます。
- バックエンドはリクエストを受信し、無料のオペレーターを検索します。 クライアントでレディボタンをクリックし、現在誰とも話していない人。 オペレーターが見つかると（おそらく5分後）、バックエンドはaccessURLをリクエストし、リクエストにオペレーターの連絡先を追加します：ユーザーID（オペレーターがWebSDKまたはMobile SDKを介して接続されている場合）、SIP URIまたは携帯電話番号。
- クラウドJSセッションは、オペレーターの名前/番号を持つHttpRequestイベントを受信し、オペレーターを呼び出してクライアントに接続します。
- スクリプトは、オペレーターとのやり取りに関するすべての情報をバックエンドに送信します：会話の後に電話を切ったオペレーター、つまりオペレーターまたはクライアントに連絡することは可能/失敗でした。これらはすべて、コールセンターの作業を分析し、オペレーターの可用性を判断するのに役立ちます。 バックエンドはこのデータを受信し、それに基づいてオペレーターに絶えず「マーク」を付けます。つまり、オペレーターがどれだけ迅速に応答するか、誰が応答しないか、誰がどのくらい活動を禁止するかです。 これらのメモは常に更新されるため、バックエンドは常にオペレーターに何が起こるかを把握しています。
必要なロジックと要件を使用して、コールのキューを完全に制御しながら、数時間ですべてをゼロから実行できます。 もちろん、これは決定フレームワークであり、各ビジネスに独自のニュアンスがあることは既に述べました。 このアプローチに基づいて、興味深いソリューションを実装できます。 例：
「あなたのマネージャー」
複雑なコールセンターの優れた機能は、クライアントが最初からクライアントをリードする「彼の」マネージャーに切り替えられるときです。 これは便利です。クライアントは毎回微妙なことなどを最初から説明する必要がなく、個人マネージャーはおそらくすべてをすでに知っているため、このマネージャーはクライアントと可能な限り効率的に作業する方法を知っているでしょう。
CallAlertingイベントにはコールセンターを呼び出しているユーザーに関する情報が含まれているため、バックエンドは着信番号に指定されたマネージャーがいるかどうかを確認し、マネージャーがいる場合は連絡できます。 マネージャーの休暇/病気/解雇の場合、短い説明を統合し、別のマネージャー/オペレーターに電話をかけることができます。 着信番号がまだマネージャーに対応していない場合は、オペレーターと話し合った後、クライアントに「このマネージャーに常に電話に応答しますか？」という質問をして、答えを認識し（「はい」/「いいえ」）、値を転送します顧客の選択を「記憶」するバックエンド。
「独自のマネージャー」はユーザーの忠誠心に適しています。また、添付プロセスも自動化されている場合は、間違った専門家を手動で指定するエラーがなくなります。
より多くのオペレーターが必要
負荷のピーク時に、オペレーターは着信の流れに対応しません。この場合、顧客は電話をかけないか、回答を待つ時間が長くなります。 両方のオプションはまあまあです。 この問題は組織的に解決できます。より多くのオペレーターを雇い、新しい従業員のコストが顧客の忠誠心で報われることを望みます。 しかし、あなたは反対側からも行くことができます：コールセンターの負荷の間、技術サポートへの他の専門家への直接の電話も同様に。 コールセンターの状況的な「拡大」が判明します。
これを行うには、「予備の」従業員の電話をバックエンドに置き、応答時間のしきい値を設定します（たとえば、1分）。 1分以内にバックエンドが1人の空きオペレーターを見つけられなかった場合、コールは予備の番号の1つに行きます。 同時に使用できるスペア番号の数、コールを転送できない時間、コール数をスペア番号に制限できるかどうか、その他のチューニングをバックエンドで設定できます。 いずれにせよ、私たちのクラウドはJavaScriptコードのガイダンスの下でその仕事をします。
もう少し？
コールセンターは時間の経過とともに変化するため複雑になります。市場はコミュニケーションに対する新たな要求を生み出し、法律が変化し、競争があり、あらゆる種類の興味深いことが常に発生します。 市場には多くの異なるコールセンターがあり、それは良いことです。 テクノロジーの柔軟性は、ビジネスをより快適にし、顧客を喜ばせます。 コールセンターの仮想/実際の例について質問やコメントがある場合は、コメントに自由に記入してください。 接続を維持し、雲の中をホバリングすることを恐れないでください;）