今日、CRMとテレフォニーの統合は不可欠です。 クライアントが自動グリーティングを長すぎる時間リッスンした場合、またはクライアントがサイトに残したアプリケーションにコールバックしなかった場合、それは失われます。
インテグレーター企業のinformUnityが 、FreePBXを実行しているBitrix24とAsteriskを統合するための大規模な製品を作成する方法と、その結果-削減されました。
背景
2016年末までに、箱入りのBitrix24とAsteriskに基づくコンタクトセンター向けのほぼ完成したソリューションがありました。 実際には、ブラウザでWebRTCを処理するために使用されるSIPML5フォークはまだデバッグされていないためです。
12月にBitrix24 REST APIでテレフォニーがサポートされたときに、複製製品の最終テストと発売をすでに計画していました。 さらに、同僚は新しいRESTメソッドを使用してAsteriskとBitrix24を統合する必要がありました。
その間、そのような統合の必要性はちょうど成熟しました。 VoxImplantを介したリンクには追加のリンクが含まれており、チューニングには「タンバリンと踊る」必要があり、「アスタリスク」から自由を奪いました。 SIPトラフィックとともに呼処理ロジックの一部が外部システムに与えられたため。
コンタクトセンターは待機することにしました。 特定の注文を実行します。 その結果に基づいて、すべての人のために統合製品を準備しています。
MVP
私の同僚は3つのアスタリスクを使用したことが判明しました。
- カスタムコンテキストを持つもの
- 最初に接続された2
これは基本的に単純なタスクを複雑にしました。
- 責任者を特定する
- オープンカード
- CRMで通話を録音する
本当に簡単だとあなたは言います。 4時間の仕事。 つまり、自分で書く場合は、必要なスクリプトだけに制限できます。 しかし、側に一歩進むとさらに4時間長くなります。 しかし、私たちは皆のためにしました。 したがって、私たちの目標は開発者にとって簡単な方法ではありません。 ユーザーにとって簡単な方法。
ソリューションの基礎は、FreePBX v.13フレームワークによって選択されました。 これは、これまでアナログで最も人気があります。 これは積極的に開発されており、ソリューションに必要なすべてが含まれています。
FreePBXのモジュールとして主要部分を設計しました。
FreePBXの第13バージョンの長所：
- 最新のインターフェース
- モジュール設定時の便利なアラート
- AJAXサポートおよび
- テーブル構造の変更を伴う簡単なモジュール更新プロセス
モジュールが機能するための最も重要なことは、統合に適切なコンテキストを決定することです。 結局のところ、各クライアントには独自の呼処理スキームがあります。
現在、主要な作業は、着信コール用のコンテキストext-did-001、ext-did-002およびmacro-dial-one、発信コール用のoutrt-、macro-dialout-trunk-に関連しています。
2か月で、アスタリスクとBitrix24が統合されました。 Bitrix24 CRMは、着信コールと発信コールのすべてを見る目を監視するようになりました。
私たちは共同作業の過程で素晴らしい経験を得ました。 さまざまなシナリオについての多くの議論は無駄ではありませんでした。 また、一部のバグレポートは日中閉じられました。 3月末までに、「ベータ」とマークされたアプリケーションディレクトリに既に送信できる製品がありました。
最初の結果
MVPを作成するとき、シンプルで透過的なロジックに焦点を当てました。 たとえば、会話の開始時間と終了時間は、外部加入者のチャネルに関連付けられています（着信チャネル、開く最初のチャネル、発信チャネル、着信番号が配置されているチャネル）。 MVPバックログには、リンググループとFollowMeのサポートが含まれていませんでした。 ただし、これらはキューに置き換えられるため、機能に影響はありませんでした。
結果はすぐに現れます。最初の数日から、1日に15〜20のインストールが行われます。 私たちにとっては、仮説検定でした。 最初のベータ版はかなり粗雑なMVPでした。 したがって、この結果は私たちに強さと自信を与えました。 そして、自信を持って、最初の行の質問の突風が来ました。
ユーザーフレンドリー
ほとんどのアスタリスクのインストールは世界から切り離されており、NATに対して静かに動作します。 しかし、統合のためにファイアウォールを構成する方法についてシステム管理者から多数の質問を受け取ったことは非常に驚くべきことでした。
「 ポート転送？」 もちろんそうでした。 転送するもの どこへ？ なんで？ 「。
問題はユーザーの資格ではありませんでした。 そして、情報の提出において。 そして、あなたは指示の修正で降りることはできません。 インターフェイスが再設計された後、同様の問題はほぼ停止しました。
システム管理者は、どのインターフェイスを使用するかを気にしていないと考えられています。 この見解は実践の試練に耐えていません。 ユーザーがシステム管理者であるか主婦であるかは関係ありません。 インターフェイスがシンプルで理解しやすいほど、アプリケーションに対する忠誠心が増します。 同時に、インターフェイスをシンプルにすることは非常に困難です。 特に定期的な変更の場合。 ベータ期間中、週に少なくとも1つのアップデートをリリースしようとしました。
モジュールインターフェイスの進化
毎週新しい機能が追加され、内部ロジックが変更されました。 この製品は非常に高速に開発されました。 1週間に収集された分析は、新しいバージョンのリリースとは無関係になりました。 時々、技術革新がインターフェースの変更よりも先だった。 次に、ユーザースクリプトを編集または完全に修正する必要がありました。 これにより、インターフェースが大幅に変更されました。
高度な開発ダイナミクスにより、インターフェース設計に制限が課せられます。 Bitrix24とAsteriskを接続するための便利なアプリケーションを作成するという野心的なタスクを設定しました。 そして私たちは管理しました-今では誰でも「友達を作る」ことができます。
あとがきの代わりに
1か月半のベータテストで、多くの仮説をテストし、多数のシナリオを実装しました。 これがサポートサービスのメリットです。
すぐにチケットとメールを拒否しました。 このような対応は、迅速な反応を意味するものではありません。 そして、1つの簡単な質問を検討することは、数日間続くことがあります。
Bitrix24のオープンラインは本当に役に立ちました。 私たちとお客様の両方が同じ製品を使用しています。 クライアントは常にチャットのリストで私たちのオープンラインを見つけ、通信の全履歴を見ることができます。 1つのエコシステムで、タスク、内部コミュニケーション、およびクライアントとのコミュニケーションを取得します。
この形式のおかげで、クライアントは平均して3分以内に通話に対する回答を受け取ります。 また、クライアントはサポートに満足しており、問題だけでなく、製品を改善するためのアイデアも喜んで共有しています。
安定版のリリースでは、品質を優先して人為的にダイナミクスを削減する必要がありました。商用ユーザーに対する責任では、以前の規模で実験することはできません。
アセンブリとテスト、およびDockerコンテナーへのモジュールのインストールと操作は、GitLab CIに基づいて自動化されました（これについては別途作成する予定です）。 週に一度アップデートをリリースしようとしていますが、すべての実験はベータ版ブランチに投稿されました。 ところで、ベータテスターを招待して共同作業を行います。
これで話は終わりですが、私たちの決定の物語はまだ始まったばかりです。
製品自体： リンク