しかし実際には、落とし穴が待ち受けていました。デザインを少し微調整したり、テンプレートの塗りつぶしを見逃したりするとどうなるかについて話しましょう。そしてそれをすべて修正する方法。
新しいユーザーに利益をもたらしたかったのですが、当然意図したとおりに動作しませんでした
Skyengの主要な販売ツールは、ファシリテーターによる無料の紹介ビデオチュートリアルです。プラットフォームでレッスンを行っているところ、生徒が電話に接続しようとしたが、マイクやカメラがキャプチャされていないことがあります。
これは、ブラウザでの通知の平凡なミスクリック（この写真のように）から完全にエキゾチックなケースまで、さまざまな理由で発生する可能性があります。たとえば、ある人がTeslaで作業しようとしたときに、サポートされていない独自のソフトウェアがあります。
問題をすばやく修正できない場合、入門レッスンは技術的に中断されます。
- 学生は否定的なままです、
- 先生の授業が中断され、
- 学校は今ここで支払いへの変換を失い（これは私たちの部門の主要な指標です）、レッスンへの教師の参加を補償し、レッスンを転送するプロセスを開始します
誰もが苦しんでいます。そのため、昨年、技術的な混乱を減らすために一連のプロジェクトを開始しました。それぞれのアイデアがテストされました。ビジネスは、機能が機能しているかどうか、および機能をサポートするためのコストが回収されるかどうかを理解したいと考えていました。
テストに投入しなければならなかった解決策の1つは、機器チェッククエストでした。元々はウィジェットでしたが、ここにメイン画面があります。
アイデアは単純です。レッスンに入る瞬間を待たずに、事前にカメラとマイクを確認するように生徒を招待します。トレーニングのリクエストを残したときです。問題が発生した場合は、テクニカルサポートにチケットを発行し、問題を解決するために数時間かかります。
ユーザーをテストとコントロールに分けたとき、テストグループの人々がウィジェットをクリックしてクエストを完了することを期待していました。何がうまくいかない可能性がありますか？
コントロールグループ（「A」）では、すべてが通常どおりに行われました。人々はアプリケーションを離れてビジネスを始めました。しかし、テスト後、グループ「A」と「B」の技術的な失敗の割合は100分の1パーセントに類似していることがわかりました。うーん、テストグループの全員がクエストを通過しましたが、それは役に立ちませんでしたか、誰も中には入りませんでしたか？私たちは知りませんでした-ロギングはありませんでした。
2つのステージが1つに統合され、それらを分離できないことが判明しました。テストを再開し、「クエストに入った」キーステージをログに記録する必要がありました。ユーザーの約10％がログインしていることがわかりました。メトリックの大幅な増加はありませんでした。クエストは忘却に陥り、機器チェック自体は最終的にグローバルな再設計中にオンボーディングに組み込まれました。そして今、私は最初に、目標到達プロセスのすべての主要な段階に関するデータがあるかどうかを確認します。
« - ?». ,
技術的な問題に加えて、学生が寝坊したり、頭から飛び出したり、何かが移されたりしたために、その非常に無料の入門レッスンに単に参加しないことがあります。
したがって、各レッスンの前に、方法論者は電話をかける準備ができている学生を見つける必要があります。このために、システムは彼にいくつかの連絡先を提供し、教師はそれらを呼び出します。これは、人がより便利で楽しいものに費やすことができる時間の12〜15％を「食い尽くし」ます。
自動化の良い機会のようです-ロボットに電話させてください。しかし、A / Bテストが必要です。結局のところ、ロボットを聞いた人の中には、電話を切ることができる人もいます。何かを失う可能性は明らかです。私たちはテストを実行し、最初はすべてが驚くほどうまくいきましたが...私たちは完璧主義に失望しました。
多くのシナリオでは、ロボットは人間のオペレーターに通話を転送する必要がありました。たとえば、学生がレッスンをキャンセルしたい場合、オペレーターはCRMに変更を加える必要がありました。そして時々、ロボットはおしゃべりな対話者に出くわしました-システムは真剣な音声認識と対話サポートのために設計されていませんでした、ここでも、人をつなぐ必要がありました。
ユーザーエクスペリエンスを可能な限りシームレスにしたかったのです。
そのため、このような通話をすぐに着信電話回線に切り替えることにしました。たとえ質問が緊急でなかったとしても。同じケースの方法論者は、「レッスンを再割り当てするために、3〜5分後にコールバックされます」と述べました。そして、オペレーターはワークロードを分散し、すべての人を助ける時間がありました。
オペレーターはロボットに同意できず、1分あたり数回の緊急呼び出しでスパイクが発生しました。回路はスケーラブルではないことが判明しました。
ピーク時には、状況は古典的なゲームに似ていました）写真については、Wikipediaとその寄稿者であるperepelin30に感謝します。
メソジストが使用したスキームに戻りました。転送要求を明確に表明した場合、ロボットは「折り返し電話します」と応答します。潜在的に緊急の問題のみが直ちにオペレーターに転送されました。これらの変更後、変更が主要なメトリックに影響を与える可能性があるため、テストを再実行する必要がありました。そして今、各実験の前に、「OK、すべてがうまくいけば、それを展開できますか？」という質問をします。
テストを開始し、すべてが順調に進んでいることを確認し、現在のタスクの束をかき集めました
Skyengには非常にクールで成長している聴衆がいます-これらは私たちと一緒に数学と英語を教える子供たちです。ただし、親がいない場合は、入門レッスンを行うことはできません。合法的にできません。したがって、子供が一人で接続すると、レッスンが中断されます。それからあなたは知っています：ネガティブ、再録音など。
両親は、レッスンの時間に同意したときに、彼らが電話をしたときに、これについて常に口頭で警告されました。しかし、電話からレッスンまで時間が経ちました。もちろん、誰もがこの合意を覚えているわけではありません。
それから解決策が来ました：SMSリマインダーを送信しましょう。入門レッスンの時間に近いほど、そのようなテキストは親に残されていました。
中断することなく入門レッスンの数が増えても、支払いへの転換が増えるわけではありません。 ROIを見積もる必要があります。これを行うために、実験を行いましょう：
- 子供の紹介のすべての申請をランダムに2つのグループに分けます。
- 最初のグループの親には何も送信しません-彼らは定期的な流れを持っています、
- 別のグループの保護者には、レッスン開始の24時間前と1〜2時間前の2つのSMSリマインダーが送信されます。
私たちはテストを開始し、初日にチェックを行い、売上高をクリーンアップしました。
数週間後、ダッシュボードを調べます。テストグループとコントロールグループの他に、他のユーザーがいます。
50を50で割りたい場合、赤いグラフは明らかに何かがうまくいかなかったことを示しています。
平凡なバグが原因であることが判明しました。イベントに問題があり、全員がトリガーでSMSを送信しているわけではありません。バグは修正されましたが、テストを再開する必要がありました。最終的には、すべてのテンプレートが入力された正しいテストデザインであっても、テストがスムーズに実行されるとは限りません。そして、あなたはそれをできるだけ頻繁に調べるべきです。
psこのテキストが、誰かがテストでミスを減らすのに役立つことを本当に望んでいます。ほとんどの場合、あなたはあなた自身の面白いケースを持っているか、すでに持っているでしょう：いつかそれらを共有しすぎるとそれはクールになるでしょう！RostovIT
コミュニティRnDTechのレポートに基づくpps投稿 -あなたが国の南部のどこかに住んでいるなら、参加してください、みんなは素晴らしい動きをしています。