知らないと損する。 SaaSのマネタイズ手法と 請求管理のイロハ
1.5K Views
February 01, 25
スライド概要
Stripe Developer Advocate
関連スライド
各ページのテキスト
Burikaigi 知らないと損する。 SaaSのマネタイズ手法と 請求管理のイロハ 岡本 秀高 ( @hidetaka_dev )
開発 / リソースの 優先順位
その開発 / リリースは 売上・収益に どんな影響を あたえるか？
自分のブログに Stripeを導入 4
頼まれて作った Payment Links の方が売上ある 5
システム・サービス開発あるある 開発量と 売上・収益は比例しない
短期間での収益化と そのための開発リソースの確保が求められている 開発リソースの確保は経営課題 経営幹部の 61% が、 優秀な開発者の確保は成功にとっ て重要な課題だと回答 短期的な収益性の改善がより重要 73% ● ● 短期的な売り上げの向上 コスト削減と効率化
プロダクトの 開発・運用リソースは 収益性に影響を受ける
SaaSのマネタイズで 絶対にやるべきこととは？
A: 顧客に料金を請求する
立ち上げ期では、マネタイズが後回しされやすい ● 開発リソースがコア機能の実装分しかない ● 顧客が使ってくれる・課金するかわからない不安 → 請求を行わない「ベータ提供」としてローンチ マネタイズ実装を、「リリース後」に検討開始 11
マネタイズ検討を後回しすると起きる弊害 ● DB構造と料金モデルの不整合による DBテーブル追加 ● 従量課金に必須の「請求根拠の利用データ」がない ● ベータ版の無料アクセスと トライアルや無料オファーユーザーの判別 ● そもそも検討した料金モデルが PMFしていない 12
α版 / β版ではフォーム + メールで申し込みを処理
申し込み後の業務フローや連携だけまず実装する メール通知で 支払い状況などを社内共有 Webフォーム ダッシュボードで サブスクを手動作成 メールで 支払い等の案内を顧客へ Webhookで 申し込み情報処理の カスタムワークフロー 15
ローコード型の決済フォームで、申し込みを自動化 個別の商談 ダッシュボードで 手動の申し込み処理 サブスクリプション作 成 メール通知で 支払い状況などを社内共有 メールで 支払い等の案内を顧客へ Webhookで 申し込み情報処理の カスタムワークフロー 16
独自のデザインやフローを実現するための API組み込み 個別の商談 ダッシュボードで 手動の申し込み処理 サブスクリプション作 成 独自の 決済フォーム メール通知で 支払い状況などを社内共有 メールで 支払い等の案内を顧客へ Webhookで 申し込み情報処理の カスタムワークフロー 17
状態変化 ( =イベント )をトリガーにしたシステム設計 E vent D riven A rchitecture https://aws.amazon.com/jp/what-is/eda/
イベント駆動アーキテクチャにすると、 さまざまなフローからの申し込みに対応できる ダッシュボード ローコード フォーム API メール通知で 支払い状況などを社内共有 サブスクリプション 作成イベント メールで 支払い等の案内を顧客へ Webhookで 申し込み情報処理の カスタムワークフロー 19
変化に対応するため、決済・請求系は疎結合に作る ● システムは決済の「後」から設計する ○ DB更新・社内通知・CRM連携etc… ○ Q: 申し込み後、やるべきタスクはどれだけある？ ● 決済・申し込みUIは、作り替え前提にする ○ 最優先は市場に出して、ちゃんと売ること ○ EDAによって、UIの変更をより簡単に 20
もう1つの 見落としポイント
獲得した売上は 全て会社の口座に入ったか？
売れても現金がないと、事業は続かない ● 経営が黒字でも倒産することはある（黒字倒産） ○ 倒産企業の 45%近くが黒字倒産 ● 売り上げを増やすだけでなく、 「お金を確実に回収すること」も事業貢献 ● 入金が遅い / 未払いや回収不能の売上はいくらある？ * https://mfkessai.co.jp/startup-article/prevent-black-ink-bankruptcy 23
実際にあった請求まわりのアレコレ - 1 ● 年間支払いのプランをリリース ● チャージバック・不審請求が発生する ● 調べると、現在進行形で使っているユーザー ● チャージバックの対応手数料やサポートの手間が ... → 顧客が契約を忘れないための通知や案内は十分？ 24
カード明細の表記は ブランドと一致していま すか？ 長期サイクル支払いは 事前にリマインドを いれていますか？
実際にあった請求まわりのアレコレ - 2 ● サービスをリリースした ● 契約数・ MAUに対して実売上が少ない ● 決済エラーで未払いになっているユーザーが 最長半年以上そのままになっていた → 請求期日や決済成否の監視と通知は十分か？ 26
通知機能や Webhook連携で 決済でも Observability
請求管理や回収フローも、実は EDA 未払い 期日超過 チャージバック 社内通知 イベント 顧客への連絡やリマインド カスタムワークフロー 28
請求管理や回収フローも、実は EDA 未払い イベントがあるなら 監視ができる 期日超過 イベント チャージバック 社内通知 顧客への連絡やリマインド カスタムワークフロー 29
プロダクトの収益性も、重要な監視対象
可視化・監視・ Ops化 ● ダッシュボードや SQLによる現状の可視化 ○ 売上・収益モデルの現状を把握する ● APIやWebhookで連携と検知が容易に ○ 決済や請求管理、売上情報などの変化を監視する ● 「見える化」したものは、 Opsにできる ○ 収益にまつわる Ops = Revenue Operation ( RevOps ) 31
短期での収益化や成長を目指すために ● プロダクトの MVPをリリースする ● まずは手動で顧客と売上を 10件獲得する ● 申し込みフローを自動化し、成長を目指す ● 売上回収やアップセル・クロスセルへの挑戦 ● RevOpsによる取り組みのアジャイル化 32
システム開発から商品開発へ ● 「売上は全てを癒す 」 by ダイエー 中内氏 ● 今の売上や収益性を把握していますか？ ● システムは売るための施策に耐えれますか？ ● 現在位置とゴールを観測可能（Observable）にして BizとTech両サイドからサービスを成功に導こう！ 33