象とボアの収縮の友情、またはシスコの電話とBitrix24を統合した経験について

入札の1つに興味深い仕事がありました。顧客は住宅および商業用不動産の営業部門のコンタクトセンターにCRMを必要としていました。 特定の不動産カタログ（オブジェクトのチェス）の実装に加えて、Ciscoテレフォニー（作業開始時-CUCM 10.5）など、会社の情報インフラストラクチャの要素との統合が必要でした。 シスコ製品の経験がまったくないにもかかわらず、Bitrix24に基づく他のすべての実装について明確に理解しており、コールセンターの構築の経験はほとんどなく、かなりの冒険心がありました。 その結果、 UCCXにコンタクトセンターを組織し、後者をBitrix24に接続することを提案しました。 それから来たもの-カットの下。

相互作用のシナリオ

UCCXに関連付けられた営業部門番号への各コールは、一般にこの顧客を担当するオペレータまたはボイスメールに転送する必要があります（コールフロー図は下になります）。 コールが特定のオペレーターに到着すると、クライアントのカード（システムに既に存在する顧客向け）または販売スクリプト（新規顧客向け）がブラウザで開きます。

オペレーターは、電話番号のあるリンクをクリックするか、直接ダイヤルすることにより、CRMから顧客に電話をかけます。 不在着信または不在着信はCRMの特別なレポートに記録され、その後オペレーターによって処理されます。 マニュアルは、Bitrix24のコンタクトセンターの統計を監視します。 製品関係の一般的なスキーム：



そのため、次の相互作用シナリオを実装します。

• Bitrix24データベース内の番号の利用可能性の要求、およびこの番号の責任者。
• ブラウザーで顧客カードまたは販売スクリプトを開く。
• Bitrix24からの発信呼び出し。
• Bitrix24からコールセンターの統計を表示します。

準備する

少なくとも統合にアプローチするためには、すべての製品にローカルスタンドが必要です（ESXiに仮想マシンがありました）。 そして、BitrixVMとBitrix24が15分で好転した場合、CUCM + UCCXのインストールと構成に時間がかかり、これは長い間書くことができます。 ここでは、その過程でつまずいた落とし穴の一部のみを示します。

最初のプロセスは、サーバーのインストールと起動/再起動の長いプロセスです。 開始する10分は正常です。 あなたが最初に遭遇したとき、少しがっかりしました。 そして、許容できる結果が得られる前に、製品を15回再インストールしなければならなかったという事実を考慮すると、かなりまともな時間になりました。

2番目-CUCMの電話テンプレートはIP4のみであり、IP4 + IP6ではありません。そうでない場合、CUCMユーザーをUCCXエージェントとして取得することはできません。

顧客と一緒に起動するときに遭遇する3番目の問題は、ユーザー名の文字列の長さの制限です。 名前は27文字より長く、ユーザーをエージェントとして構成することはできません。 構成しようとすると、エラーは「リソースの読み取り中にエラーが発生しました」です。

次に、コンタクトセンターオペレーターの職場についての2つの言葉。 シスコが提供する2つのオプション（FinesseブラウザソリューションとWindows用CADデスクトップアプリケーション）のうち、オペレータ側で必要な機能をすべて実装するWebクライアントであるFinesseを選択しました。 他の点は同じですが、よりモダンな外観を持ち、Bitrix24ブラウザーに適しています。

そのため、準備段階の後、 地獄の7つの輪を経て、Bitrix24とCUCM + UCCXの2つの別々に動作するシステムがあります。 しかし、すべての楽しみはまだ来ていません。

統合

Bitrix24にはSIPコネクターが付属しているため、PBXをBitrix24に接続できますが、標準モジュールを使用するというアイデアは生まれる前から消えていました。

実際、このモジュールはVoximplantに基づく仮想クラウドPBXであり、顧客の要件に応じて、すべてのシステム要素が内部ネットワークに存在する必要があります。 さらに、レイヤーとしてのアスタリスク（およびその時点で既にBitrix24との直接統合を習得していた）は、システムの信頼性とフォールトトレランスが低下したため、お客様に適していませんでした。 UCCXマナを辛抱強く吸うだけでした。

統合自体は、UCCX / Finesse側での作業とBitrix24側での作業の2つの部分に分けることができます。

UCCXサイドアクション

まず、キューを設定します-すべてはマニュアルに従っています。 次に、CUCMからアプリケーションを起動する呼び出しを転送するときに、特別な番号であるトリガー（トリガー）を作成します。これは、スクリプトと環境（変数、言語など）を含む一種のコンテナーです。 次に、スクリプト（スクリプト）を作成します。これは、コールセンターを通過するときにコール処理のロジックを実装する特別な言語のプログラムです。 作成するには、UCCXに付属のUCCX Script Editorを使用します。 このツールを使用すると、スクリプトを作成してデバッグできます。 Cisco Unified UCCX管理者ツール->プラグイン Webインターフェイスからダウンロードできます。 Windowsにのみインストールします。 以下はスクリプト自体です。


UCCXのさまざまなバージョンを使用する場合、1つの機能に気付きました。バージョン10.5で作成されたスクリプトは、バージョン11.0では必ずしも機能しません。 統合作業の過程で、UCCX 10.5から11.0に切り替えたため、11番目のバージョンのエディターでスクリプトを再作成する必要がありました。

統合が開始されるのはスクリプトです。 クライアント番号を受け取った後、 URLドキュメントの 作成とXMLドキュメントの 作成を使用して、クライアント番号をCRMに送信し、責任番号（または不在に関する情報）を取得します。その後、特定のオペレーターまたはキューに呼び出しを転送します。

Finesseのオペレーターに電話がかかってくると、次のタブで目的のリード/連絡先が開き、 エンタープライズコール情報の設定を使用して、Finesseハンドラーで使用できる変数に発信者の番号を保存します。 呼び出しフローのロジックを説明するフローチャート：

Finesseでのワークフローの作成

電話がオペレーターに届いた後、彼はFinesseに来ます。 クライアントがすでにCRMに登録されている場合、次のタブで彼に関する情報のページが開きます。 そうでない場合は、販売スクリプトが開きます。 Finesseでは、これはワークフローメカニズムによって実装されます 。 イベントを選択します-呼び出しが到着し、そのアクションを定義します。 サポートされているアクションタイプには、[新しいタブで開く]があります 。 パス（CRM、つまりBitrix24）とパラメーター（クライアントIDまたは販売スクリプト）を設定します。 Finesseから直接テストするメカニズムがあります。変数の値を設定するだけです。 すべてのアクションは、Finesse Administartorを介して行われます。 以下のスクリーンショット。





UCCX / Finesse側の作業はここで終了します。 Bitrix24に移動します。

Bitrix24側のアクション

Bitrix24では、いくつかのスクリプトを作成する必要があります。

1. Bitrix24 CRMの発信者（クライアント）番号の可用性の要求を処理するスクリプト。 APIを使用して、クライアント番号を使用してリード/コンタクトをリクエストします。 データベースに電話がある場合、責任者の内部番号を転送し、そうでない場合は、発信者の電話でリードを作成して保存し、未処理のリード用に特別に作成された責任あるアカウントとして指定します。 コールが処理される場合、エージェントは販売スクリプトを記入する際に責任者に任命され、そうでない場合、リードは未処理のコールに関するレポートに含まれ、そこから最初の空いているオペレーターがピックアップします。

2. Bitrix24からの発信呼び出しを開始するスクリプト。 リード/連絡先カード内の番号とリード/連絡先リストのページをクリックすると、Finesseを介したコールが開始されます。 統合メカニズムは、REST API Finesseに基づいています。 Dialogオブジェクトが使用されます-新規ダイアログの作成（電話をかける） 。 例はFinesseマニュアルにあります。

3.統計。
UCCXから直接統計を取得します。 CCDRレコードは、UCCXサーバーのInformixデータベースに格納されます（ただし、CUIC（Cisco Unifiled Intelegence Center）を個別にインストールする場合は、個別のソリューションがあります）。 3番目のスクリプトは、Informixに接続して統計データを取得するために使用されます。 主なことは、リクエストを正しく作成することです。結果の日時は、Bitrix24サーバーのタイムゾーンに移動する必要があります。 基本構造は少し複雑ですが、Infomixのマニュアルではすべてのテーブルとフィールドが詳細に説明されています。 CRMのレポートは次のようになります。

まとめ

真のエンジニアは技術的な問題を解決します。彼にとっては時間と動機の問題にすぎません。 私たちにとって、このタスクは、その機能と奇妙さを備えた完全に未知の製品に没頭する4か月に変わりました。 簡単なことではありませんでした。眠れぬ夜にもかかわらず、一見すると明らかなように、コントロールポイントの結果は、顧客へのプレゼンテーションの15分前に達成されました。 そして、私たちはこれを行いました：システム（ここで説明したテレフォニーとの統合に加えて、他の3つの外部システムとの統合と特定の機能を実装するための約400時間を含む）が稼働し、Bitrix24のメジャーアップデート（バージョン15.5から16.5）を無事に生き残りました。