abcpのカスタマーサポートの主な特徴は、売り上げ、ひいては利益がサポートの質に依存することです。 ほとんどの場合、当社のプラットフォームでオンラインストアを使用する人は、以前は屋台、店舗、自動車市場で取引されていました。 インターネット上にすでにリソースを持っている人もいますが、自分でリソースをサポートすることはできません。 特定のセグメントは、サイト全体を外部委託する準備ができている大企業によって占有されています。 時間と絶え間ない技術の進歩も独自のルールを決定します：オンラインストアを持っていなかった人は（競争に出ているため）ルールを持たざるを得ません。さらに、セルフサポートには多くの時間とお金がかかるため、コストを削減するツールです。 ほとんどの場合、発生した質問と問題はクライアントによって「その場で」形成され、迅速かつ効果的に解決する必要があります。 テクニカルサポートコールの主なトピック：サイトの価格の誤り、注文の問題、サプライヤーの価格表の更新の問題、コンテンツのサイトへの入力の問題、製品グループ（オイル、タイヤ、ホイール）のスペアパーツに関する情報の読み込みと確認など。
現時点では、システムにはプラットフォームの800以上のクライアントがあり、ポジティブなダイナミクスは毎月監視されています（下のグラフを参照）。 プラットフォームユーザーが絶えず成長していることを考えると、サポートは高速で高品質である必要があるため、配信方法を最適化することが重要です。
技術サポート方法論の形成
それはすべて非常に簡単に始まりました。 本格的なサポート部門が設立される前は、各従業員が電話または郵便でプラットフォームのユーザーを支援していました。 当時、会社で働いていた人はごくわずかだったので、すべての人が入ってくるすべての仕事に対処しなければなりませんでした。 顧客数の増加により、開発とサポートを組み合わせることは不可能になりました。 要求の登録システムの選択を決定する必要があった瞬間が来ました。 もちろん、主な選択基準は、コスト、またはむしろその不在、およびコードを自由に変更する能力でした。 開発では、Mantisはすでにバグトラッカーとして使用されていたため、クライアントからのタスクの処理に迅速に（したがって安価に）適応させることが決定されました。 サイトコントロールパネルにリクエスト送信フォームを埋め込みました。つまり、リクエストの本質を要約したり、従業員に対応したり、チケットのステータスを確認したりできるようにしました。
選択したバグトラッカーに戻りますが、Mantisの基本バージョンが、今日活発に使用されている多くのチップで補完されていることは注目に値します。 それらのほとんど（追加のボタン、顧客情報へのリンクなど）により、インターフェース間の遷移を最適化することが可能になり、それによりリクエストの処理が高速化されました。 最も有用な改善点は、サイトの管理コントロールパネルにチケットを送信するためのフォームを埋め込むことでした。
お客様には「テクニカルサポート」セクションがあり、サポートで新しいリクエスト/チケットを作成したり、既存のリクエストのやり取りを維持したり、アクティブなチケットを追跡したりできるようになりました。 リクエスト送信フォームの例を以下に示します。
新しいリクエストフォームは可能な限りシンプルです。 推奨事項として、基本的な充填ルールが追加で示されています。 また、プラットフォームのユーザーは、サポートスタッフがエラー/状況を再現して迅速な対応を行えるように、リクエストを要約する必要があります。 必要に応じて、ファイルを添付できます。 フォームはシンプルでわかりやすく、ユーザーは大量に使用し始めました。 登録後、チケットはサポートスタッフのインターフェースに表示され、リクエストを処理します。 処理中に、クライアントとの対話/通信があります。 各コメントは、プラットフォームユーザーのメールとサポート部門グループに特別に複製されます。
Mantisを使用すると、クライアントはチケットのステータスを追跡し、処理の優先順位を変更し、アーティスト、実際のリードタイムを確認できます。 特定の問題の解決が気に入った場合、「いいね」のマークを付ける機会があります。 これらすべての追加により、受信した解決済みリクエストの数を追跡できます。 部門内では、これらのデータに基づいて、従業員に関する集計情報が収集されます。これにより、作業効率と各従業員が実行した量を把握できます。 これらの概要は、マネージャーがマテリアルボーナスの割り当てについて決定するのに役立ちます。
以下の図は、サポート従業員の作業インターフェースを示しています。
提示されたインターフェースの各要素を使用すると、不必要な移動やクリックなしで、チケットの優先度の増加、クライアントまたは従業員の隠されたコメントによるパブリックコメント、チケットを追跡する従業員のリストなどを確認できます。
人と仕事をするとき、人的要因が重要な役割を果たします。 友好的で理解しているクライアントもいれば、友好的でなく常に不満なクライアントもいます。 このサポートから逃れることはできません。 ユーザーが増えれば増えるほど、サポートサービス全体の仕事について何らかの主観的な評価を行う試みが増えました。 サポートが「うまく機能しない」、「リクエストを少し処理する」などの事実に非難され始めました...不満の度合いを減らし、仕事の質を示すために、クライアントインターフェイスにタスク統計を表示し始めました：完了および失敗の数（未解決）昨年のリクエスト。 つまり、処理された割合と量、および処理されていない割合を各ユーザーに明確に示します。 もちろん、処理されたチケットははるかに多くあります。 これは、彼らが十分な注意を払わなかった、要求を満たしていないなどと文句を言う人々の熱意をわずかに冷やします。 すべてのリクエストは保存され、どこにもアーカイブされず、削除されません。 誰もがサポートでコミュニケーションの全履歴を確認し、早期の電話を見ることができます。 プラットフォームユーザーにとって重要なイベントに対してアラートが設定されています：サービス制限のしきい値に近づいている、ストップリストに入らないようにするために残高を補充する必要があるというメッセージ、オンラインプロバイダーの検索結果の不足に関するレポート、プラットフォームの革新に関するニュース、倉庫の更新結果に関するレポートなど。
サポートの質を向上させるために、バグトラッカーの従業員は、サポートレスポンスが期待されるチケットをカウントするカウンターを参照します。 どのクライアントに回答する必要があるかを知らせる手紙がメールに送信されます。 インターフェースと、一般的にはサポートサービスを可能な限りシンプルかつ高速にするようにしました。
クライアント要求の配信順序
プラットフォームの機能は常に拡張され、新しいモジュールと設定が追加されました。 開発者から実装の詳細を見つけた特定の要求に応じて、各従業員はローカルでクライアントに応答し、要求をクローズしました。 同じ要求が別の従業員によって別の時間後に受信されたとき、同じ要求が以前に処理されたことを誰も覚えていないため、スキームが繰り返されました。 サポートは部門内のコミュニケーションの問題に直面しました。 私たちは、常に気を散らしていると常に誓った開発者との協議に、自分たちの間での会議に時間を費やしました。
リクエストの配布スキームと他の部門とのコミュニケーションを少し再構築する必要がありました。 現在使用しています。 単純化された相互作用スキームを以下に示します（他の部門の作業の詳細なし）。
クライアントからの要求は、Mantisを介した呼び出しまたは要求の形式で受け取ることができます。 通話中、アクティブなチケットがあるかどうかを常に確認します。 そこにない場合は、すべての通信を転送するために作成してください。 （残りの10人は他の従業員に転送するための呼び出しであり、5％は2〜3分以内の簡単で迅速な電話相談です）。 実際、アピールはチケットに変換されます。 それらは典型的でも非標準でもかまいません。 典型的なサポートスタッフが直接任命します。 サポートマネージャーが非標準のものを選択して、詳細、技術仕様などを見つけます。 さらに、各要求に対する各コメントは、すべての従業員へのメールで読むことができます。 したがって、誰もがどのような要求をし、同僚がどのように決定するかを認識しています。 このようなスキームにより、マネージャーは常にすべてのチケット、従業員を認識し、同僚からのリクエストで何が起こっているかを知ることができます。 これにより、重複、クエリ内の質問の交差を避け、知識レベルを文脈的に高めることができます。
もちろん、修正/開発するために開発者の介入を必要とするそのような要求/エラーがあります。 この場合、サポート担当者は問題を分析して再現し、開発部門のエラーを受信するためのアルゴリズムをクライアントに隠された追加情報に書き込みます。 次に、タスクがサポートマネージャーに返されます。 彼はもう一度状況をチェックし、プラットフォームエラーの場合、タスクを開発部門に転送します。 次に、決定の責任者が任命され、要求が処理されます。 重要な点は、開発者とのすべての問題がサポートマネージャーを通じて解決されることです。つまり、開発者は最小限の時間で注意をそらされます。 私たちの側に間違いがなかった場合、相談に費やされた時間はクライアントから引き落とされます。
その過程で、顧客数と顧客に費やされたサポートリソースの比率は計り知れないことが明らかになりました。 これが問題になっています。 バグトラッカーを介したサポートに費やされた時間は考慮されていません。 電話通信とTeamViewerを使用して、新しく到着したすべてのプラットフォームユーザー向けに機能トレーニングを個人的に実施しました。 このようなトレーニングは、1人の新しいクライアントに対して平均で約2時間かかりました。 さらに、このような個別のアプローチにより、クライアント自体は何も設定したくないという事実に至り、最も単純な問題についてチケットを呼び出して作成しました。 サポートプロセスを早急に変更する必要があります。
次の変更が導入されました。
- 2週間ごとの全員向けのウェビナーによるインタラクティブなトレーニング。
- 接続時に選択した料金に応じて、サポートの時間数が制限されています。
- 顧客向けの作業マニュアルが拡張され、合理化されました。
- プラットフォームモジュールの自動化された部分。これにより、クライアントはサポートに参加せずに自身を構成できます。
結果はすぐに来ました。 部門から大幅にリソースを節約できました。 一番最初のチャートでは、記事は年間に受け取ったおおよそのチケット数を示しています。 実装された自動化、ウェビナーへの移行、およびその他の措置の後、リクエストはすでに大幅に減少しました。 この傾向は、正確に多くのプロセスの最適化にあります。
仕事における上記の変更のそれぞれが実を結びました。 料金プランに含まれるサポート時間の制限は、送信されるチケットのフローに大きく影響しました。 クライアントは、ドキュメント、ビデオチュートリアル、Webセミナーへの参加を始めました。 「限界にぶつかり」、それを超えて、テクニカルサポートに追加料金を支払うことを望む人はいませんでした。
オンライン学習
実装後、ほとんどのリソースが解放されたため、インタラクティブな学習システムの選択について詳しく調べたいと思います。 ウェビナー市場の多くのオファーから選択しましたが、その選択はCitrixの製品「Gotowebinar」にかかっていました。
主な選択基準：
- 画像のレンダリング品質;
- 高品質のフィードバック（接続された音声とのやり取りと通信の可能性）;
- 同時に接続された多数のリスナー。
- サービスを使用するコスト。
- ウェビナーを記録する機能。
要約表には、最良の検索で考慮されたソフトウェア製品が表示されます。
| webinar.ru | Gotowebinar.com | wiziq.com | webex.com | imind.ru | |
| 画像のレンダリング品質 | いいね | すごい | 悪い | 悪い | 悪い |
| 品質フィードバック | 存在します | 存在します | ？ | ？ | ？ |
| 多数の同時接続リスナー | 一度に最大500人 | 一度に最大100人 | ？ | 最大100人の参加者 | 最大1000人の参加者 |
| サービスの使用コスト | | 月額100ドル | ？ | | |
| ウェビナー録画機能 | はい | はい | ？ | はい | ？ |
適切な製品を見つけることは非常に困難でした。 調査した各製品には、いくつかの落とし穴がありました。記録時間の制限、必要な基準を備えた価格設定ポリシーの不備、画像レンダリングのひどい品質です。
もちろん、このようなシステムを選択するときに表に示されている基準は異なる場合がありますが、私たちの選択は報われました。 クライアントとの接続に問題はありません。ビデオは高品質で記録され、ローカルに保存されます。 プレゼンターの声とウェビナーの参加者の声が記録されます。
まだ多くの改善が先にありますが、現時点では、上記のすべての手順により、顧客とやり取りするための最も安定した最適なスキームが確立され、サポートの品質を改善し、部門のリソースを均等に分散できたと安全に言えます。
PS現時点でいくつかの統計：
- 1日あたり40から90枚のチケットをクライアントから受け取ります。
- サポート部門には、4人の従業員と1人のマネージャーがいます。
- 平日には、約30件のサポートコールが受信されます。
- 1人の従業員が1か月あたり約300枚のチケットを処理できます
- プラットフォームが存在する間、約66,000のチケットが処理されました。
- 2010年通年、65のクライアントから3,620枚のチケットを受け取り、処理しました。
- 2014年-821クライアントからの17192年
- 相談-総質量の70％
- エラー-総質量の15％
- 望ましいが実現不可能な要求-15％