Otkritie Bankの新しいアプリケーションでは、カスタマーサポート用のチャットを構築しました。これは、大規模な更新のフレームワークで最大かつ最も複雑なストーリーの1つになりました。 機能と情報保護に関して銀行の要件を満たすチャットを作成することは、決して簡単な作業ではありませんでした。

なぜ銀行チャット

幸いなことに、銀行に関する多くの問題は、たとえばコールセンターに電話したり、手紙を書いたりすることで、リモートで解決できます。 しかし、遠隔性の絶頂は、サポートサービスオペレーターとのチャットです：オンライン通信では、クライアントは迅速に、内密に（誰も会話を盗聴しません）、時には楽しいことさえあります（チャットオペレーターは冗談を言っています！）財務を管理します。 過去数年にわたって、モバイルメッセンジャーは身近なコミュニケーション手段になり、チャットは現代の銀行サービスにとって絶対に必要なものです。



Alexey Kruglov、Otkritie Bank、上級副社長兼デジタル製品ディレクター

「最新のサービスのチャットは、クライアントとのコミュニケーションに対するアプローチの変革です。 人々はメッセンジャーに移動し、そこに住んでいます。 そして、この世界から抜け出すこと、コールセンターに電話すること、またはメールを書くことを彼らに強制するたびに、私たちは彼らを緊張させます。 チャットの開発に今投資して、長期的な効果を得ることを望んでいます-顧客からのコミュニケーションの他のチャネルのコストをそれほど下げない、原則として銀行からの顧客の流出を減らし、サービスに感銘を受けた新しい顧客の流入をできるだけ便利にするように努めます」



そしてもちろん、チャットはフィードバックを収集するための貴重なチャンネルでもあります。



Anastasia Grafskaya、プロジェクトマネージャー、「Discovery Digital」

「基本的に、彼らは2つの機会にチャットで書きます。サービスのリクエスト（金融および情報の問題）、または何らかの苦情のいずれかです。 私たちの場合、チャットはアプリケーションの最近の再設計に関するフィードバックを収集する上で非常に重要な役割を果たしました。 人々は好きなものや嫌いなものについて書き、この機能やその機能がいつ追加されるかを尋ねます。 チャットは、まったく新しいアプリケーション機能です。 彼は私たちを逆さまにして、手の上を歩く方法を学びました。 アプリケーション自体にチャットを導入することに加えて、チャットを銀行のインフラストラクチャに展開するには多くの時間と労力がかかりました。 多くの瞬間をセキュリティサービスと長い間調整する必要があり、クレーム部門の同僚も途方もない仕事をしました。彼らは新しい従業員を雇って訓練し、生きた言語で顧客と通信する方法を教えなければなりませんでした。

事前パイロット

Otkritieのモバイルアプリケーションでチャットが必要であるという考えは、約1年前に銀行で生まれました。 その後、開発の開始とデザインコンセプトの出現のずっと前に、チーム「Discovery Digital」は、一種の「パイロット」という実験を実施することを決定しました。 この通信チャネルの機能を伝える必要がありました。オペレーターは、チャーター、規則、規制からの抜粋ではなく、将来的にチャットで顧客と通信する専門家に、生きた言語で応答する生きた人です。



ディスカバリーデジタル、プロジェクトマネージャー、キリル・クラショフ

「SIMカードを購入し、Telegramアカウントを登録し、デジタルチームとサポートサービス用のグループチャットを作成しました。 空き時間があるとき、「Discovery Digital」のチーム全員とこの共有チャットにリクエストを送信しました。 オペレーターが回答すると、メールまたは電話で回答を一緒に郵送またはソートしました（OtkrytieサポートサービスはSaratovに基づいています）。 最初は非常に詳細な解析文字があり、その後はほんの小さなコメントがありました。 次に、顧客とのチャットの標準を設定します。」



その後、個人的な会議、トレーニング、特別なガイドが登場し、サポートサービスオペレーターへの推奨事項を収集しました-こんにちはと連絡する方法、使用する単語と使用しない単語、絵文字が適切かどうか-クライアントの年齢などの要因に応じて。

通常のメッセンジャーとは異なり

ユーザーの観点からすると、銀行のモバイルアプリケーションでのチャットは通常のメッセンジャーと変わりません。 同じ方法でテキスト、リンク、写真、場所を送信できます。 何らかの理由でチャットが利用できない場合でも、ユーザーは通常のチャネルの1つ（郵便または電話）を介して銀行に連絡する機会があります。







チャットはアプリケーションの許可されたゾーンでのみ使用できます。これにより、サポートスペシャリストはクライアントをすぐに特定し、アピールに取り組むために必要なすべての情報を取得できます（コミュニケーションスタイルを選択できます）。 したがって、ユーザーは追加の識別手順を行う必要がなくなります。



オペレータにとって、チャットは、チケット、ルーティングツール、通話の分析と統計情報など、使い慣れたHelpDeskシステムのように見えます。







現在、サポートスペシャリストは2つの役割を担っています。

• オペレーターは、ユーザーと直接やり取りし、問題を解決してチケットをクローズするオペレーターです。
• 管理者は、基本的に作業の速度と品質を監視するオペレーターの作業のコントローラーです。

新しい顧客の呼び出しごとに、システムにチケットが作成され、無料のオペレーターの1つに自動的に割り当てられます。 オペレーターはブラウザーで通知を受け取り、ユーザーに応答します。 問題が解決すると、オペレーターはユーザーに別れを告げ、チケットをクローズします。







ユリア・ベロノゴヴァ、Otkritie Bank、請求管理責任者

「合計で、1か月の間に、銀行はすべてのチャネル（電話、メール、ソーシャルネットワーク、チャット）を介して17から18,000のコールを受け取ります。 約200のコールがソーシャルネットワーク経由で着信します。 チャットは7月6日に機能を開始し、初日には1,000を超える質問が寄せられました。 午後から始めましたが、そのような反応は期待していませんでした。 初日の夜、すべてのオペレーターは熱心に顧客をサポートしていました。 現在、6人のオペレーターがおり、毎日約150枚のチケットを処理しています。 チケットは単一のリクエストではなく、ダイアログであり、1〜20〜30の顧客の質問を含めることができます。 クライアントがもう質問がないと言ったときに、クローズされたチケットが考慮されます。



チャットを介して最初の通話に応答するには、オペレーターに1分間与えられます。 この間、クライアントは自分が一人ではないことを明確にする必要があり、銀行はすでに問題の本質を掘り下げて情報を収集し始めています。 問題を解決する時間は、その本質によって異なります。 これが標準的な情報要求である場合-たとえば、カードでの利息の計算方法、または最低支払額が必要な場合、応答速度は原則として3分を超えません。 金銭的な償還に関しては、20分から1日かかることがあります。



管理者は、すべてのダイアログと統計を表示およびダウンロードできるマネージャーの役​​割と、オペレーターに転送されたチケットに応答するオペレーターの役割の両方を実行できます。 また、管理者は新しいオペレーターを作成し、既存のオペレーターへのアクセスを一時停止できます。







サーバーで収集される統計は次のとおりです。

• 処理済みチケットおよびオープンチケットの数
• 最初の応答時間
• 呼処理時間

これにより、個々のオペレーターとチーム全体のパフォーマンスを評価できます。 管理者は、時間と曜日ごとに通話を配信するスケジュールにより、部門の作業をより適切に計画できます。

既製のソリューションVSカスタム開発

インスタントメッセージングソリューションの市場は現在急成長しており、適切なコンポーネントを見つけてそれを製品に統合することは難しくないと思われます。 しかし、チャットに基づいてカスタマーサポートチャネルを構築する必要がある場合、次のような多くのニュアンスを考慮する必要があります。



セキュリティ上の理由から、ソリューションは銀行の内部ITインフラストラクチャに展開する必要があります。 チャットは、銀行のシステムと統合して、顧客に関する情報を取得し、顧客の操作履歴を表示し、サポートサービス全体の有効性を測定するためにチケットを一般回線に含めることができる必要があります。 メトリックとレポートは、HelpDesk部門の企業標準に準拠する必要があります。



私たちは市場に出回っているオープンソース製品を分析しましたが、さまざまな理由で、それらのどれも私たちの元には来ませんでした。 セキュリティ基準を満たしていないか、実装言語が気に入らなかったか、既存のソリューションは通常のインスタントメッセンジャーの機能（クライアントとクライアント間の対応）に重点を置いているため、コードを大幅に改善する必要がありました。 この分析は1年前に行われたものであり、この間に一部のソリューションの機能が変更される可能性があることに注意してください。 その結果、彼らは自分でチャットを書くことにしました。



XMPPやWAMPなどのメッセージを送信するための既存のプロトコルに縛られることはありませんでした。それらのかさばり、冗長性、高度な複雑さのためです。 ほとんどのサードパーティソリューションは、あらゆる場合に不必要な詳細で過負荷になっています。これをすべてサポートし、さらに追加のパラメーターが渡された理由をセキュリティサービスに説明する必要があります。 必要なすべての言語のライブラリの品質も問題でした。 そのため、独自のJSON仕様でWebSocketを介してチャットを実装しました。

チャットの実装と展開

チャットは3つのブロックで構成されます。

• すべてのロジックが機能し、メッセージがルーティングされるサーバー。
• クライアント部分は、モバイルアプリケーション（iOSおよびAndroid）およびサイトに埋め込まれたSDKです。
• サポートオペレーターと管理者のワークステーション-顧客との通信を行い、メッセージ統計を表示およびダウンロードするためのWebパネル。

Vladimir Vyalov、バックエンド開発者、Redmadrobot

「独自の非同期チャットサーバーを作成する必要があるため、このプロジェクトは他とは一線を画しています。 最初は、フレームワークを選択する必要がありました。主な選択は、nodejs、asyncio、Tornadoの間でした。 AsyncioはPython 3.4以降でのみ使用できますが、他のプロジェクトの生産では最新の言語を既に使用しているため、それを選択しました。 PostgreSQL、Redis、RabbitMQとの非同期相互作用を実装し、Webソケットを介してメッセージを送信し、非同期コードをテストでカバーする必要がありました。 その結果、asyncioでの経験は成功し、次のプロジェクトで再び選択します。」



最初の1か月半の間、システムのすべてのコンポーネントは並行して開発され、相互接続されませんでした。 マネージャーは、統合の開始を見越して神経質に廊下を歩いていました:)最後に、この瞬間が来ました、そして、いくつかのファイリングの後、チャットは働き始めました！ 最初は、お互いに書き込みが可能で、QA部門を接続することができました。 ただし、そのバージョンではシステムを安定して呼び出すことはほとんど不可能でした。メッセージが失われ、接続が切断され、サーバーがクラッシュしました。 システムを安定させ、問題の原因を見つけるにはしばらく時間がかかりました。 ブラウザーとサーバー間で接続の状態を確認するためにping / pongを実行する必要がありました。数回繰り返した後、RabbitMQ /チャットサーバーバンドルのバグを修正し、モバイルデバイスでのメッセージの重複に対処する方法を学びました。 しかし、何百人もの人々が同時にオペレーターにメッセージを書き始めたときにのみ自分自身を感じるようになり、テスト環境でそのようなアクティビティを完全にエミュレートすることは難しいため、初期段階ではまだいくつかのバグを見逃していました。



銀行には多くのセキュリティ要件があり、バックエンドの組織に関する独自の見解があるため、チャットを拡大することは容易ではありませんでした。



アーサーサハロフ（ mc_murphy ）、CTO、Redmadrobot

「もちろん、すべてのテクノロジースタックが銀行で使用されているわけではありません。 通常、Pythonで記述し、Postgresデータベースを取得し、RabbitMQキューを接続し、Redisにキャッシュを保持し、LinuxでDockerコンテナーを上げます。銀行にとって、この環境全体はデフォルトでは信頼できないと見なされます。 MS SQLはどこにでもあり、アプリケーションは.NetまたはJavaで記述されており、多くがWindows Serverに展開されているという事実に慣れました。 このスタックでは、必要なすべての手順が実行され、アナライザーがセットアップされ、銀行の専門家が独自にサポートおよび展開できます。

その結果、セキュリティサービスとの妥協点を発見し、標準コンポーネントの一部を置き換えました。ほとんどのソリューション（たとえば、PythonとPostgresを残しました）では、現在の銀行スタックに収まらず、ITインフラストラクチャを更新する将来の計画に収まりました。 このプロジェクトは、とりわけ、安全保障理事会、建築家、保守のトレーニング場となり、そこで必要な手順を提起したことが判明しました。 献身的なチームと「Discovery Digital」の支援のおかげで、できるだけ早くこれを行うことができました。」

仕組み

最近、クライアントがチャット経由で書き込みました。 彼はジョージアにいて、セキュリティの目的で設定された現金引き出し限度を超えたため、ATMで資金を受け取ることができませんでした。 「理解する」と彼は言います。「ここにあと5日ありますが、お金を引き出すことができず、帰りのチケットを買うものがなく、資金さえ使い果たしてしまいます。」 制限を増やすことは技術的に不可能であったため、オペレーターは賢くなければなりませんでした。







銀行の誰もがチャットは簡単で人間的であるべきだと理解していますが、パンクが発生します:)顧客の1人がチャットで質問し、フレンドリーな回答ではなく銀行の条件からの抜粋を受け取りました。 クライアントは驚き、通信のスクリーンショットを撮り、Twitterに送信しました。 並行して、彼は質問をしました：「どうすればあなたの銀行の口座を閉鎖できますか？」 これに応えて、彼らは彼にこれを行う方法に関する完全な詳細な指示を送った。 それは壮大な失敗でした。







もちろん、Ctrl C + Ctrl Vにかなり怒っているクライアントの問題は解決されました。 そして銀行にとって、このケースはあなたの過ちから学ぶ方法の参照ケースになりました。

結果と計画

将来の計画の一部：

• Androidおよびプレログインゾーン（制限モード）でチャットを開始します。
• ボットを使用した回答の自動化。
• 管理者の分析ダッシュボード。特定のオペレーターと部門全体の両方の負荷、およびコールの処理速度をリアルタイムで監視できます。
• 顧客側のさまざまなバックエンドとの統合。 まず第一に-銀行のCRMで。
• 第2レベルのサポートの追加：サポートスペシャリストとチケットルーティングスクリプトの新しい役割（チケットは複雑さを評価した後に配布され、さらに速く飛ぶようになります）。
• IPテレフォニー接続：通話のルーティングは電話の通話に似ています。

その間、銀行は新しい通信チャネルを試し続けており、時には金融問題だけでなく理解する必要がある場合もあります ...







...そしてパターンを引き裂きます:)





お楽しみに！