モバイルメールクライアントのユーザーがサポートに目を向けると、ほとんどの場合、ほとんど直接開発者と直接通信していると考えます。 もちろん、これはそうではありません。 すぐにEにドットを付けます：サポートサービスからのチケットがユーザーからの形式で開発者に届くと、開発者はサポートになります。 したがって、チケットはいくつかの「フィルター」を通過します：最初に3つのサポートライン、次に調査のために送信され（これが製品の問題であるかどうか、および分析するのに十分なデータがあるかどうかが決定されます）、テスターに送られて再生されます開発者向けのJiraでの最終タスク。 ところで、少数のチケットだけが試験に合格します。そのうち、プロジェクトに応じて、タスクの形で開発者に送られるチケットは2〜5倍少なくなります。
開発者に連絡する前に、どのようなデータを収集し、ユーザーの呼び出しとレビューはどのような経路をたどりますか？
モバイルアプリケーションには独自の使用方法と更新機能があります。 ユーザーの信頼を失わないために、バグレポートを自分で送信するのを待つことはできません。 ユーザーはこれを好まない-多くは、アプリケーションのバグに直面して、ただそれを誓って閉じるか、ソーシャルネットワークで文句を言うか、市場にレビューを残す。 したがって、サポートアプリケーションフォームまたはアプリケーションに組み込まれている開発者だけでなく、フィードバックを収集します。 また、App StoreとGoogle Playのレビュー、ソーシャルネットワーク上のメッセージとコメントを自動的に監視し、 フォームを介してHelp Mail.Ruに送信されたデータも収集します。
モバイルアプリケーションからの呼び出しには、ログ、クラッシュダンプ、その他の情報が伴うため、開発者は引き続きサポートとして行動することがあります。 サポートは常にこの情報を使用してユーザー側の問題を解決できるとは限りません。
チケットのパス
そのため、アプリケーションのフィードバックフォームのユーザーが[レポートの送信]ボタンをクリックしました。 この時点で、アプリケーションは、診断に有用で必要なデバイス情報のリストを既にコンパイルしています。 これには、ガジェットモデル、オペレーティングシステムのバージョン、デバイス言語、ハードウェア、およびその他の情報が含まれます。 たとえば、Android用のMail.Ruメールアプリケーション：
このすべてのデータは、メッセージのテキストとともに、特定のアプリケーション（Mail.RuまたはmyMail）およびオペレーティングシステム（iOSまたはAndroid）に応じて、サービスメールボックスの1つに送られます。 Help Mail.Ruを介してアクセスする場合、すべてが同じように行われます-サービスはレターを生成し、サポートボックスに送信します。
レポート送信画面には、「アプリケーションログを添付する」というチェックマークがあることに注意してください。 設定されている場合、アプリケーションは、アプリケーションを送信する前に、記録されたログを.zipアーカイブに自動的にパックし、このファイルをアプリケーションに添付します。
当社のCRMシステムは、添付のスクリーンショットやログファイルを含むすべてのデータをメールボックスから受け取り、サポートサービスへのリクエストを自動的に生成します。
また、CRMでGoogle Playからユーザーレビューを自動的に取得します。システムは、オープンなGoogle Play Developer APIを使用して 、アプリケーションバージョン、デバイスモデル、画面解像度、RAMサイズなどを含むデバイスに関する完全な情報とともにレビューを取得します。オープンAPIがないため、開発者向けのWebインターフェイスでこのアプリケーションストアからのフィードバックを処理します。
完璧に制限はありません。したがって、将来的には、プッシュするユーザーのサブスクリプションに関する情報を収集する機能をCRMアプリケーションに追加する予定です。 プッシュサーバーから直接データを取得し、チケットインターフェイスに表示します。 これにより、アプリケーションのプッシュ通知設定、サイレントモード設定、および各メールフォルダーの通知のステータスに関する情報を、作成時と現在の両方で自動的に受信できます。
CRMシステムで作成されたアプリケーションは、サポートサービスの専門家によってレビューされます。 必要に応じて、たとえば、問題を再現するためのスクリプトやスクリーンショットなど、不足している情報をユーザーに求めます。 次に、CRMシステム内のアプリケーションは、問題の主題に応じて適切なキュー（フォルダー）に移動されます。
- 認可
- 添付ファイルを添付します。
- 添付ファイルを表示します。
- アバター。
- 同期する
- 通知。
- メールを読む。
- などなど
問題が本質的に技術的なものであり、以前に遭遇したことがない場合、ユーザーから必要な詳細をすべて受け取った後、サポートサービスはJiraでタスクを作成します。 これは、CRMシステムインターフェースのワンクリックでJira APIを介して行われます：キュー（フォルダー）に基づいて、システムはリクエストをプロジェクトに入れ、問題の説明、ユーザーとの通信履歴を含むすべてのデータを自動的にCRMチケットからJiraタスクに転送します添付ファイル。 その後、システムはJiraボード上のどのタスクがコンポーネントによって自動的にソートされるかに基づいてタグを付加します。
次に、タスクはテストに入り、タスクには3つの結果と3つの対応するJiraボタンがあります。
- テスターは、問題を特定するために追加のデータを必要とします 。 彼は、ユーザーに情報を問い合わせるサポートサービスのコメントを書いています。 このコメントはJiraからCRMチケットにブロードキャストされ、サポートチームにのみ表示されます。
- テスターはタスクをfixに設定します 。 タスクを修正待ち状態にし、データは開発者に送られます。 同時に、JiraではテスターからJiraタスクへのリンクが必要です。 入力後、タスクはCRMチケットに変換され、サポートチームのみが見ることができます。
- テスターは何らかの理由でタスクを閉じます （たとえば、問題は最新の更新で既に修正されています）。
問題がアプリケーションのエラーに関連付けられていない場合、問題に関する情報と可能な解決策がサポートサービスに返され、ナレッジベースに補充されます。
利益はいくらですか？
「誰かがユーザーリクエストを収集して処理するプロセスを複雑にしているのはなぜですか？」 私たちは答えます-これに感謝します：
- 各問題は、構造化された理解可能な情報を持つ個別のタスクに変わります 。 同時に、サポートサービス、テスター、開発者が協力して問題を解決します。
- すべてを修正したバグ修正とユーザーの応答を追跡するのは簡単です。
将来の計画では：
- バグを修正した後、CRMシステムでレポートとチケットを使用してJiraタスクを自動的に閉じます。 おそらく、バグが修正されたというユーザーへの自動応答を追加します。
- バグタスクでのユーザーの苦情のカウンター：各問題の苦情の数の半自動更新。