VelobikeがUseDeskを実装し、サポートを6倍に加速した方法

第1章自転車に30分乗った後、驚くべきことが起こった

この刺激的な物語は5月に始まりました。 私は市の興行所で自転車に乗り、1905年の地下鉄からアルバツカヤまで車で行き、駐車して仕事に行きました。 そして3時間後、私は銀行からSMSを受け取り、1000ルーブルを償却しました。まるで30分ではなく3時間乗っているかのようです。 どうやら、駐車時にエラーが発生し、駅には自転車が見えませんでした。 Velobikeを支持して、彼らは私に、レンタルの終了についてのテキストメッセージを待たなければならないと説明し、彼らはお金を返すことを拒否しました。 私は気分を害し、残酷な（当時私には思えた）復venを思いついた。



この事例については、Usedeskカスタマーサービスブログに書きました。 この記事では、サポートの間違いを整理しました。正式な回答、官僚的なアプローチ、柔軟性のない決定、賃貸条件の不十分な報告に呪いをかけました。 彼女はFacebookで記事を共有し、@ Velobikeについて言及し、待ち始めました。



私のチームと私は冗談を言った。シティバイクのレンタルでのサービスが不十分な内部告発者のスキャンダラスな栄光と、地獄が冗談を言っていないものに負けてしまう-バイクは反応するだろう。 しかし、真剣に共鳴に頼っていませんでした。



記事の公開の翌日、Velobikeは予期せずSMSにリマインダーを追加しました。これは、レンタルの終了についてSMSを待つ必要があることを示しています。



2日後、iPhoneが鳴りました。



-こんにちは、カテリーナ、私の名前はグレブです。私はVelobikeのゼネラルディレクターです。



恐怖の欲望、彼らは実現する傾向があります。

第2章。Velobikeチームと会って、すべてが内部からどのように機能するかを調べる

千人がすでに地図に戻ってきたことを嬉しく思います。 しかし、ターンは急でした。

モスクワ市内レンタルVelobikeのCEO、Gleb Narozhnyh：



この投稿はUsedeskの企業ブログで公開され、著者の感情に加えて、クライアントサービスに関するかなり明確な推奨事項が含まれていました。 私たちの側では、その瞬間、クライアントの呼び出しを処理するシステムの難しい選択に直面しました。そして当然、Usedeskのプロファイルを研究した後、私たちは彼らにビジネス提案をしました-UsedeskとVelobikeの機能を試してみてください。 カテリーナを獲得しました。

1週間後、私たちは既にBerezhkovskaya Embankmentのオフィスに座ってコーヒーを飲み、サポートプロセスを改善する方法を考えていました。

自転車サポートはどのように機能しますか？

コールセンターは、大都市のサイクリストからのレンタル料金、デビットカード、さらにはどちらの側に自転車を駐車するかについての電話での質問にオンラインで回答します。 電話での会話を好まないお客様は、info @ velobike.ruまたはソーシャルネットワークに書き込みます。



状況が物議を醸す場合、私と同様に-コールセンターはアプリケーションをオペレーター部門に送信します-彼らは普通郵便で手紙を書きます。 オペレーターは旅行の詳細を確認し、事実を比較し、財務部に同意し、評決を出します-お金を返すか拒否します。 顧客が孤児の壊れた自転車を見つけた場合、オペレーターはこれをディスパッチャに報告し、ディスパッチャはドライバーを自転車の修理に送ります。



部門は、メール、スカイプ、さらには紙で互いに通信しました。 その結果、一部のアプリケーションが失われ、手作業が多く、統計情報がほとんどありませんでした。 顧客に迅速に対応し、日常業務に費やす時間を短縮するために、作業を合理化する必要がありました。 すぐに見つかった問題と解決策の詳細をご覧ください。

第3章。Yuzdeskの紹介を開始します

最初に、作業プロセスの大まかな図を描きました-手紙の到着方法、オペレーターがステータスを設定し、リクエストにカテゴリーを割り当てる方法、苦情のリダイレクト先、顧客への対応方法。





詳細については、画像をクリックしてください。



次のステップは、この理論上のスキームをYuzdeskに転送することでした。 これを行うために、2つのVelobikeメールボックスをYuzdeskに接続して、手紙がプログラムに届くようにしました。 毎回手動で記述しないように、よくある質問に回答するためのテンプレートを作成しました。 カテゴリタグが追加されたリクエストのトピックに関する今後の統計情報：

アカウントがブロックされ、無料レンタル、感謝、払い戻し、トリプルカード、相談、自転車の発見、支払いの失敗、自転車の故障、アイテムの故障、自転車の盗難、その他25個のタグ。

オペレーターを訓練するために残っています。 ステータスを変更し、同僚に質問を再割り当てするために押すボタン、押すボタンを示しました。 最初は、彼らは「これはどんな新しいプログラムで、異常で、不快なものだ」と抵抗しました。 しかし、1時間後、あるオペレーターは別のオペレーターに、「はい、この新しいシステムは、メール、スカイプ、Excelの1つです。」と言いました。 そして、それが私が聞いたYuzdeskの最高の定義でした。



これで、すべての文字が1つのフィードに分類されます。 私はプログラムを開きました-何件の手紙、何のトピック、誰が責任者であるか、すぐに応答する必要があるのを見ました。





Yuzdeskのお問い合わせリスト

第4章そこから何かを導入する必要があった理由が明らかになる

コーヒーを飲みながらの会話から最初の問い合わせまで、システムで3週間が経過しました。 応答速度を大幅に低下させる問題に遭遇しました。 返信なしの@ .ruからの手紙の60％がコールセンターの従業員から届いた

標準形式で。





コールセンターからの手紙



クライアントに回答するためには、最初にクライアントIDでバイクデータベースで彼の電子メールアドレスを見つける必要がありました。 次に、Yuzdeskにメールを追加し、その回答の後にのみ追加します。 長くて不快な悪夢。 次の2つのステップで、1レターあたり2分余分に従業員を節約しました。



電子メールを持つクライアントは、VelobikeデータベースからYuzdeskデータベースに転送されました。 レター内のIDによってデータベース内のクライアントを検索し、目的のクライアントをカード内のアドレスに置き換えるルールを作成しました。



「ああ、今では100倍速くなった！」



ペダルが回転し、作業が速くなりました）



古い作業プロセスと比較して、私たちが何とか修正することができました。



問題1.クライアントが何度もコールセンターに電話をかけたりコールしたりすると、複数の従業員が同じ問題を同時に取り上げました。 事件がありました。 レンタルの料金に同意しなかった永続的なクライアントは、コールセンターに電話し、信仰のために2回サポートに書き込みました。 顧客は幸運でした-オペレーターの1人が彼の好意で決定し、お金を返しました。 しかし、彼らはさらに2人のクライアントを助けることができる時間を費やしました。



どのようになった。 クライアントからの同じアプリケーションが結合されます。 これにより、相互作用の全履歴が保持されます。



サポート担当者はすべての詳細を考慮し、評決に達する前にシステムでクライアントの証言を確認します。 クライアントが、レンタル料金について何も知らなかったという主張を書くことが起こります。 しかし実際には、彼はコールセンターに電話をかけ、駅に駐車せずにケーブルでフェンスに自転車を縛った場合、いくらのお金が引き落とされるかを警告されました。 簡単に確認できます。 クライアントが言ったこと、異なるオペレーターが彼に答えた-すべてが彼の目の前にあり、パズルの一部が失われていない。 したがって、悪徳サイクリストは水をきれいにするために連れて行かれます。 しかし、責任と誠実さは常に前進します。



問題2.リクエストの22％が支払いと返品に関連しています。 係争中の料金の返還に関する最終決定は、ヘッドによって行われます。 以前は、オペレーターが承認申請を提出しました...紙の上で。 各申請書が印刷され、リーフレットが保管され、テーブルに束ねられて置かれました。 何かが失われ、顧客は長い間お金を待つことができず、当然inしました。



1日に最大120の印刷されたアプリケーションに達すると、オフィスの投票箱には紙がいっぱいになりました。





返品依頼



どのようになった。 サイクリングは木を節約し、プリンターのインクを節約します。 古紙なし。 調整は、内部コメントの助けを借りてYuzdeskで行われます。 質問は単にSergeyに割り当てられ、彼は反応が必要なアプリケーションのリスト全体を見ます。 すべてのソリューションは、1つのリクエストでステップします。





Yuzdeskでの返品の申請



問題4.統計のために、各文字の情報は、通常のExcelファイルである「コールログ」に手動で入力されました：日付、時刻、コールの件名、クライアント、責任者、ステータスおよび決定の期間。





Excelの連絡履歴



このルーチンは時間がかかりました。 シフト後にファイルに記入することはよくあることです。 以前はこの余分な営業日に費やされていました。



肉体労働がある場合-エラーがあります：数字が追加されなかった場合、時刻が誤って示されました-すべて、統計はすでに嘘をついています。 したがって、それは役に立たない。



どのようになった。 不要なジェスチャーは最小限に抑えられます。何もする必要はありません。システムはすべてのステータスとそれ自体の責任を記憶しています。 従業員は、スキーヤーを支援し、サイクリングの問題を解決することに集中しています。 同時に、マネージャーはアピールの理由、意思決定の速度に関する統計を見て、1つのシステムでプロセスを制御します。

第5章Velobikeは、プロアクティブなサポートのためにYuzdeskを使用する方法を決定します

Q＆Aプロセスを郵送で確立した後、Velobikeサポートチームはさらに前進しました。 次に並んだのは、顧客とVelobikeがお金を失ったことによる痛い問題でした。



自転車が完全に駐車されていないとき



追加料金の最も一般的な理由は、駐車時の城の誤りです。 乗車後に疲れたサイクリストが自転車を城に完全に挿入せず、レンタルは開いたままです。 そして数時間後、クライアントはすでに銀行からSMSを受け取ります。これは450ルーブルで償却されます。



多くの苦情、涙、そしてお金の損失がありました。 したがって、自転車をサポートするために、プロセスは近代化されました。 これで、駐車中にエラーが発生した場合、SMSがクライアントに送信され、オペレーターが電話をかけます。「駐車できないことがわかりました。 助けましょう！」 通常、クライアントは駐車場から遠く離れる時間がないため、戻って自転車が正しく配置されていることを確認するように求められます。



顧客からの手紙と同様に、駐車エラーメッセージはYuzdeskのオペレーターに届きます。これは、顧客がサポート番号をダイヤルする前に応答するのに役立ちます。





駐車エラー通知



レンタルが6時間遅れたとき



もう1つの費用のかかる問題は、6時間を超えるレンタルです。 クライアントが隣の都市に乗ることを決め、時間と彼の強さを計算しなかったことが起こります。 たぶん、彼は仕事に遅れて、駅で空き枠を見つけられなかったのでしょう。 または、初心者が自転車を駐車場に戻す方法を理解していませんでした。 いずれにせよ、レンタルが半日続く場合、それは「何かが起こった」ことを意味します。 おそらく良くない。 その結果、クライアントは誤って1,500ルーブルとVelobike-はるかに高価な自転車を失う可能性があります。



以前は、サポートは長期レンタルに関するシグナルを受信しませんでした。 オペレーターは、24時間以上駐車場に戻らなかった自転車を手動で監視しました。 しかし、一日おきに失われた自転車を見つけることはほとんど不可能でした。



そのため、Velobikeはシステムを完成させ、アラートを実装しました。 これで、レンタルが6時間以上続く場合-SMSで顧客に通知され、オペレーターはYuzdeskで通知されます。 オペレーターは簡単に顧客を見つけ、彼に連絡して、何が起こったかを見つけます。 クライアントが自転車をどこかに置いてきた場合、最寄りの駐車場に戻るように求められます。 サポートのアドバイスに従い、レンタルバイクを責任を持って扱ってください。それはあなた自身のものです-有益です。 クライアントが実際にどれだけ移動したかを考えると、自転車は家賃の再計算の必要性を満たすでしょう。 これは私が理解していることです-それは柔軟で良心志向です。



2016年の自転車シーズンの開始以来、4台の自転車が見つからないたびに駐車エラーが発生しました。



時間通りに戻らなかった自転車のアラートの導入後、2.5倍になりました。 クライアントが別の駅に駐車することを拒否したため、アラートで作業して3か月間、失われた自転車は1つだけでした。 残りの自転車が見つかり、「帰宅」しました。

第6章要約する場所

歌詞から数字に移ります。 2016年のサイクリングシーズンで成功したもの。

	2015年7月〜9月	2016年7月〜9月
2倍のコールを処理する（クライアントが異なる通信チャネルを介して複数回コンタクトした場合）	17％	2％
最初のアピール中にクライアントに関する情報を検索します（ログイン名またはクライアント名、アピールの有無の確認、履歴の表示）	7分	3分
回答の技術的な準備の時間（標準的な回答とルールを使用）	4分	1分→ 4 倍 高速
状況の調査を考慮したクライアントへの応答時間	12時間12分	2時間22分→ 6 倍 高速

オペレーターは顧客に連絡し、問題を解決する期限について警告するようになりました。その結果、顧客は自分が問題を処理していることを認識し、再度電話することはほとんどありません。 オペレーターには電話がかからず、顧客により迅速に対応します。

セルゲイ・ツィガンコフ、副 顧客管理Velobikeの責任者：



SRMシステムで働いていた人として、私はすべての長所と短所を理解しました。 それらの実装について十分に重要な議論は、すべての動きが記録され、各従業員が個人的に責任があるということです。 オペレーター1、2ではなく、個人的には、たとえば、Alexander Gromov、Sergey Tsygankov。 会社の経営陣がすべての視界とアクセスにあるという事実により、Usedeskの使用はオペレーターを規律します。 システムは、アプリケーションがその人に当たったとき、彼がこれをやったと答えたとき、彼が正解したかどうかを反映します。 いつでも戻って、Yuzdeskで何が起こっているのか、どのようなアピールが機能しているのかを確認できます。 このツールを使用すると、クライアントとのやり取りのすべてのチャネルで作業の品質を向上させることができます。

次は？

次の自転車シーズンに向けて、VeloBikeは3番目のリングの自転車レンタルゾーンを拡大し続け、モバイルアプリケーションの新しい便利な機能で一般顧客をサポートする予定です。 また、Yuzdeskは、モバイルアプリケーションとVelobikeの顧客およびレンタルのデータベースと統合して、紛争のケースをさらに迅速に「調査」する予定です。 私たちは協力して、マスコビットが楽しく快適な方法で街を移動するのを支援します。



有益でやりがいのある経験でした。 Velobikeのメンバーは目立たず、部分的でクールなプロフェッショナルであることが判明したため、すべてがうまくいきました。 そして、私にとって、この話は顧客サービスについてでさえありません。 それは、人々が一緒に有用なことをする方法についてです。



個人的にはGlebにチャンスを与えてくれたことに感謝します。 ファリッドとセルゲイ-忍耐と優しさのために。 Velobike全体-都市をより健康で、よりモバイルで、より幸せにするために。 UseDeskをこれに参加させてくれてありがとう。



4月にまた会いましょう:)