一つにまとめて課題と連結し、修正されたら関連するレビューへ返信の候補を一度に上げます。
App Store・レビューのモニタリング
新しいレビュー、評価の急な落ち込み、バグへの言及、返信の依頼。散らばるレビューをVelros AIが拾い集め、返す言葉の下書きまで用意します。
- レビューの返信率
- 評価の急落の検知時間
複数のストアから新規レビュー、評価の急落、バグへの言及、返信の依頼に関する情報を集め、重複を取り除いて優先順位を付けます。
オンラインの一人創業者は、App Store・Google Playのレビューをまとめて後から確認し、評価が下がってから原因を探します。レビュー・ソーシャルの言及・クラッシュレポート・サポートの問い合わせが別々に溜まり、バグを指摘したレビューが課題とつながらないまま放置されます。公開された評価の低下は、新規の流入まで静かに削ります。
こうした兆しが、こう処理されます。
実際に入ってくる仕事を集め、それぞれの段階で何を基準に判断するのかまで続けて残します。
-
レビュー・言及の統合収集
ストアのレビュー・ソーシャルの言及・サポートの問い合わせを一つのキューに集めます。
判断 同じ症状・バージョンへの言及をまとめる候補と見る。散らばった信号を一つに減らすため。 -
評価・感情の分類
新規のレビューを評価と内容(バグ・不満・称賛・返信の要望)で分けます。
判断 評価の急落とバグへの言及を優先順位の軸にする。急落とバグが常に上位。 -
返信の下書き・バグの連結
返信の下書きと、バグに言及したレビューを課題トラッカーに連結するメモを作ります。
判断 同じ症状のレビューをまとめて課題と連結し、修正後に返信の候補を上げる。 -
急落アラートの準備
評価が急に下がれば、原因の候補とともにアラートを上げます。
判断 急落の信号は原因の推定とともにすぐ人へ。公開の指標なので、遅れがそのまま損失。 -
レビューの追跡カード
レビュー・評価・状態・次のアクションを載せたカードを作り、未解決として追跡します。
判断 終結の条件(返信の掲載・バグ修正との連結)を付けて、キューから消えないようにする。
確かでなければ、公開では答えません。
現場で実際に引っかかる例外を、あらかじめ決めておきます。ルールが通らない場面を無理に処理せず、根拠とともに人へ渡します。
すぐに反論せず、事実確認のリストとして上げて、人が対応の方法を決められるようにします。
公開の返信で約束せず、別のケースに分けて人の承認で処理します。
公開の返信と補償は、人が確定します。
お金・契約・個人情報・ブランドがかかる実行は下書きまでにとどめ、送信と確定は人の承認を経てから動きます。
-
公開の返信の掲載
誰もが見る対外的な発言なので、元に戻す前に人が確認します。
-
対外的な謝罪・補償の約束
費用と先例が生まれる判断なので、人の役目です。
-
大量の案内・告知
一度出ると回収できないため、文面と対象は人が見ます。
-
悪意のある・虚偽のレビューへの対応
関係と評判が絡む判断なので、人が確定します。
-
バグの深刻度・緊急リリースの判断
リソースの配分が絡むため、人が決めます。
何で確かめるか
どれだけ早く気づいて答えたかで見ます。
返信が必要なレビューのうち実際に答えた割合を、導入の前後で実測します。
評価が下がり始めてから気づくまでにかかった時間を、導入の前後で測ります。
バグを指摘したレビューが課題へ連結された割合を、導入の前後で測定します。
レビューやサポートの問い合わせに含まれるユーザー情報を扱うことがあるため、必要な範囲でのみ保管し、公開の返信に個人情報が現れないように整理します。
人が自分で抱えていた仕事が減ります。
散らばった確認と繰り返しの返信を先に整理して上げれば、スタッフは確認と例外の処理に集中でき、人は大事な判断だけを見ます。
運用診断確認が人のところに積み上がります。
レビューをまとめて後から確認し、評価が落ちてから原因を探します。
処理の準備ができた状態で上がってきます。
新規レビューと急落の兆しが一つのキューに集まって返信まで用意され、公開の掲載は人が確認します。
この業務を任せる前に、よく聞かれること
App Store・レビューのモニタリングについて、実際に最初に確認されることを集めました。
公開の返信をVelrosがすぐに書きますか。
返信の下書きまでを準備し、実際の公開の掲載は人が確認してから実行します。
バグに言及したレビューはどう処理されますか。
同じ症状のレビューをまとめて課題トラッカーのバグと連結し、修正後に返信の候補を上げます。
悪意のあるレビューにはどう対応しますか。
すぐに反論せず、事実を整理して上げ、対応の方法は人が確定します。