勝手に招待せず、確認が必要と表示して人が順番を決められるようにします。
複数のチャネルから登録の申し込み、招待の順番、ベータのフィードバック、オンボーディングの質問に関する情報を集め、重複を取り除いて優先順位を付けます。
ウェイトリスト・ベータの運用
登録の申し込み、招待の順番、ベータの声、使い始めの質問。ローンチ前後のやり取りをVelros AIがまとめて受け、返信の下書きまで進めます。
オンラインの一人創業者は、順番待ちの申し込みが申込フォームに溜まるだけで、招待は順番もなく思い出した順に送ります。申し込み・招待・ベータのフィードバック・オンボーディングの質問がフォーム・メール・Discord・Slackに散らばり、誰をいつ招待して、どんなフィードバックが来たのかが残りません。管理されない順番待ちの名簿は、期待だけを膨らませて参加につながりません。
こうした兆しが、こう処理されます。
実際に入ってくる仕事を集め、それぞれの段階で何を基準に判断するのかまで続けて残します。
-
申し込み・順番の収集
フォーム・メールの申し込みを一つのキューに集め、重複を除いて順番を付けます。
判断 メール・申し込みの識別子で同じ人をまとめる。一人が何度申し込んでも順番は一つに。 -
招待対象の分類
順番・条件(招待コード・優先グループ)で招待の候補を分けます。
判断 順番と招待の条件で分ける。記憶ではなく基準で招待するため。 -
招待・案内の下書き
招待の案内・順番の案内・オンボーディングの質問への回答の下書きを作ります。
判断 順番と条件に合う案内だけを下書きにする。送信と権限の付与は人へ渡す。 -
ベータのフィードバックの整理
チャネルごとのフィードバックを集め、機能・バグで分類して整理します。
判断 チャネルが違っても同じフィードバックはまとめて機能・バグに。機能要望・バグの分類の流れへつなぐ。 -
参加の追跡カード
申込者・順番・招待の状態・次のアクションを載せたカードを作り、未解決として追跡します。
判断 終結の条件(招待の受諾・明示的な辞退)を付けて、名簿に放置されないようにする。
順番が不確かなら、招待を見送ります。
現場で実際に引っかかる例外を、あらかじめ決めておきます。ルールが通らない場面を無理に処理せず、根拠とともに人へ渡します。
同一の申込者をまとめて重複の招待を防ぎ、追加の招待は人の承認で処理します。
勝手に答えず、本人確認が必要と表示して人に上げます。
招待とアクセス権限は、人が確定します。
お金・契約・個人情報・ブランドがかかる実行は下書きまでにとどめ、送信と確定は人の承認を経てから動きます。
-
招待の送信
アクセスが開く実行なので、対象と時点を人が確認します。
-
アクセス権限の付与
元に戻しにくいアクセスの判断なので、人が確定します。
-
大量の招待・案内
一度出ると回収できないため、文面と対象は人が見ます。
-
ベータの条件・範囲の変更
参加者全員に影響するため、人が承認します。
-
優先・特別な招待
関係の文脈はコードではなく人が分かります。
何で確かめるか
招待が参加につながったかで見ます。
招待を受けた申込者のうち実際の参加につながった割合を、導入の前後で実測します。
招待した参加者のうちフィードバックを残した割合を、導入の前後で測定します。
初期の質問の受付から回答までにかかった時間を、導入の前後で測ります。
申し込みと招待の過程でメールのような個人情報を扱うため、取得の目的を知らせて同意の範囲でのみ利用し、アクセス権限の付与は人の確認のあとに処理します。
人が自分で抱えていた仕事が減ります。
散らばった確認と繰り返しの返信を先に整理して上げれば、スタッフは確認と例外の処理に集中でき、人は大事な判断だけを見ます。
運用診断確認が人のところに積み上がります。
登録の申し込みがフォームに溜まるだけで、招待は順番もなく思い出すままに送ります。
処理の準備ができた状態で上がってきます。
申し込みと順番が一つのキューに集まって招待の案内まで用意され、送信は人が確認します。
この業務を任せる前に、よく聞かれること
ウェイトリスト・ベータの運用について、実際に最初に確認されることを集めました。
招待を自動で送りますか。
順番と招待の案内の下書きまでを準備し、実際の招待の送信と権限の付与は人が確認してから実行します。
ベータのフィードバックはどこに集まりますか。
チャネルごとのフィードバックを一つのキューに集めて機能・バグで分類し、機能要望・バグの分類の流れへつながります。
順番はどう決まりますか。
申し込みの時点と招待の条件で順番の候補を付け、実際の招待の順番は人が確定します。