とあるB向けの無料Webサービスを有料サービスへリニューアルしました。

その際にプロダクトマネージャーとして考えたことを振り返ってみます。

有料化の背景

- 収益化できていなかったのを打破するため
- 無料提供してきた既存サービスを通してバリューを見定めることができたため

の2つが大きな理由です。

もともとこのサービスは無料で使える基本サービス + さらに便利なプレミアムプランも有料で選択可という建て付けでした。

無料でサービス提供していたのは、はじめてのローンチで認知拡大を優先したかったからです。

意図した通り、無料登録数は順調に伸び、認知拡大という点では成果が出せたと思うのですが、さぁ今度は収益化するぞという段階ですぐにできるわけもなく困った、、、という状況でした。

「無料で使えます！」という売り文句も収益化という面では足を引っ張り、有料であるプレミアムプランへのフックを強化したくても、明らかに導線が目に付くというのはUXとしてどうなんだろう？というモヤモヤがつきまといました。

そこで、有料サービスに無料トライアルを設けるという建て付けに変更し、違和感のない有料申込のUXを目指しました。

もう一点は、このwebサービスの延長で一部クライアントに向けて展開していたコンサルに近いプロジェクトが好評で、その知見がある程度溜まったということ、また本質的にクライアントが求めているのがなんなのかというのが定まってきたということが大きいです。

既存の機能をブラッシュアップしつつ、コンサルでの知見を活かしてサービスリニューアルを行うことでバリューのあるサービスが展開できそうだという確信が持てたので、有料化へと踏み切りました。

プライシング

プライシングについては結構議論を重ねました。。
取り得るべきアプローチは多岐に渡るのですが、意識したのは

- クライアントにとってのROIが見込めるか
- 経営指標に対してそのプライシングをするとどのくらいの期間で達成が見込めるか
- そのプライシングの目的が明確であるか、ターゲットが絞れているか

の3つです。
それらを議論を通して言語化していき、納得のいくプライシングにまで磨き上げた感じです。

こちらの記事は参考になりました。

無料トライアルの設計

無料トライアルを設けるにあたって意識したのは、いつから始まるか、いつで終わるかという定義をはっきりさせることです。
1ヶ月無料！といっても、いくつかパターンは考えられます。例えば月途中から登録を開始したとき、その月が無料なのか、その月と翌月が無料なのか、30日間無料なのか、などです。
仮にその月を無料としたとき、では月末に登録したクライアントには不公平にならないかとか、その対策として月終わり10日間に登録した場合、翌月も無料とするとか、そうすると、その間に登録したクライアントは少しお得になるので、月終わり10日間を狙って登録するクライアントが増えるのではないかとか、その期間を待ってサービスを認知したその日に登録してもらえないのではないか。。。とかです。

結果30日間無料となりました。

既存のクライアントへどう伝えるか？

すでにサービスを利用されているクライアントに無料から有料になるという点をどう納得してもらうかをデザインする必要がありました。

意識したのは

- サービスのリニューアル内容をなるべく事前に知ってもらうこと
- スケジュールの共有をこまめに行うこと
- いつから料金が発生するかを丁寧に伝えること
- 有料になるが、その分機能がパワーアップすると伝えること

です。

これについては、誠実に伝えてあとは天命を待つという感じです。💦
有料化への過程で解約が発生するのはしかたないという前提に立って臨んでいました（結果的に思っていたほど解約は発生しませんでした）。

開発時に注意したこと

料金体系が変更されるので、旧バージョンでの請求料金、新バージョンでの請求料金をどう扱うかというのは悩みました。

ベストプラクティスかどうか自信はありませんが

- DBは別にした
- 請求料金確認画面は一画面とした
- 選択された日付(月)で旧データか新データを条件分岐
- UIは新料金が見やすくなるように寄せた

という感じです。
旧料金の詳細は請求書で確認できるので若干簡素化し、新料金が見やすいUIに統合しました。

また、リニューアルには直接関係ありませんが、請求情報のデータの持ち方も少し変更しました。

請求情報はもともと計算式(いつ、どのプランを購入したか|解約したか)としてのデータを保存していましたが、経験上これが結構扱いづらいという意識があったので、それとは別に計算結果(ログとしてのその月の請求データ)を残すようにしました。

扱いづらい理由としては、キャンペーンや条件付きでの契約など、特殊なケースというのが頻繁に発生するのですが、それを吸収したシステムづくりが後手後手に回るという悲しい現実です😇

計算結果のデータを持つことで最悪そのデータをイジるというパワープレイでその場しのぎができます(ダメです)。

ただ、こんなことスケールしたら破綻するのは目に見えているので、例外的なケースが発生したら、都度都度ルールを決め、システムへ落とし込む努力が必要です。

特にB向けのサービスの場合、営業の方と密に連携して契約を取るにあたってのルールを徹底することが後々のためにも大事です。自戒を込めて。

まとめ

サービスの価格向上はどうしてもマイナスイメージがついてしまうので、単に価格向上するのではなく、それ以上にパワフルにアップグレードされるということをブランディングすべきだなと改めて思いました。
そしてそれ以上に、機能として価格以上のベネフィットを提供することをサービス提供者として意識すべきなのかなと思いました。

リソースが限られた中で走りながらなんとかリニューアルにこぎつけたというのが実情なので、全然うまくできたとは思っていませんが、それでも達成感は感じられました。

最後まで読んでいただきありがとうございました！