知らないと損する。 SaaSのマネタイズ手法と 請求管理のイロハ
>100 Views
January 21, 25
スライド概要
JP_Stripes東京 2025/01の登壇資料です。
Stripe Developer Advocate
関連スライド
各ページのテキスト
JP_Stripes 東京 知らないと損する。 SaaSのマネタイズ手法と 請求管理のイロハ 岡本 秀高 ( @hidetaka_dev )
岡本 秀高 Stripe Developer Advocate こんな話できます ● ● ● Stripe入門 Stripe製品・実装Deep Dive / ワークショップ 個人的にStripeを使っている経験談 ○ 請求管理 ○ SaaSへの組み込み ○ ノーコードでチケット販売 こんな相談やお話し募集中 Stripeが好きすぎて中の人になった人 ● ● ● ● JP_Stripes京都の元運営 JP_Stripes Connect 2019の実行委員長 Stripe Apps一人アドベントカレンダー完走 [ 継続中 ] QiitaでStripe記事を累計200本以上更新 ● ● ● ● Stripe導入相談 「Stripe導入したよー」のお知らせ 決済やサブスク請求で悩んでいる人の紹介 JP_Stripes(都市名)やりましょう！ https://hidetaka.dev/ja-JP https://wp-kyoto.net https://x.com/hidetaka_dev
開発 / リソースの 優先順位
その開発 / リリースは 売上・収益に どんな影響を あたえるか？
自分のブログに Stripeを導入 5
頼まれて作った Payment Links の方が売上ある 6
システム・サービス開発あるある 開発量と 売上・収益は比例しない
短期間での収益化と そのための開発リソースの確保が求められている 開発リソースの確保は経営課題 経営幹部の 61% が、 優秀な開発者の確保は成功にとっ て重要な課題だと回答 短期的な収益性の改善がより重要 73% ● ● 短期的な売り上げの向上 コスト削減と効率化
プロダクトの 開発・運用リソースは 収益性に影響を受ける
SaaSのマネタイズで 絶対にやるべきこととは？
A: 顧客に料金を請求する
立ち上げ期では、マネタイズが後回しされやすい ● 開発リソースがコア機能の実装分しかない ● 顧客が使ってくれる・課金するかわからない不安 → 請求を行わない「ベータ提供」としてローンチ マネタイズ実装を、「リリース後」に検討開始 12
マネタイズ検討を後回しすると起きる弊害 ● DB構造と料金モデルの不整合による DBテーブル追加 ● 従量課金に必須の「請求根拠の利用データ」がない ● ベータ版の無料アクセスと トライアルや無料オファーユーザーの判別 ● そもそも検討した料金モデルが PMFしていない 13
α版 / β版ではフォーム + メールで申し込みを処理
申し込み後の業務フローや連携だけまず実装する メール通知で 支払い状況などを社内共有 Webフォーム ダッシュボードで サブスクを手動作成 Stripeからのメールで 支払い等の案内を顧客へ Webhookで 申し込み情報処理の カスタムワークフロー 16
申し込みベースと商談ベース両方にノーコードで対応 個別の商談 ダッシュボードで 手動の申し込み処理 サブスクリプション作 成 メール通知で 支払い状況などを社内共有 Stripeからのメールで 支払い等の案内を顧客へ Webhookで 申し込み情報処理の カスタムワークフロー 17
申し込みフローをよりシンプルにするためのアプリ連携 個別の商談 ダッシュボードで 手動の申し込み処理 サブスクリプション作 成 Stripe API メール通知で 支払い状況などを社内共有 Stripeからのメールで 支払い等の案内を顧客へ Webhookで 申し込み情報処理の カスタムワークフロー 18
イベント駆動アーキテクチャにすると、 さまざまなフローからの申し込みに対応できる 個別の商談 ダッシュボードで 手動の申し込み処理 サブスクリプション作 成 Stripe API メール通知で 支払い状況などを社内共有 Stripeからのメールで 支払い等の案内を顧客へ Webhookで 申し込み情報処理の カスタムワークフロー 19
Q: 決済フローを「全て自作」すべきか？ ● 「システム連携があるので、ノーコードはNG」 → 連携が必要な「つなぎ目」はどこ にある？ ● 連携したいのは決済の「前」か「後」か ○ ユーザー体験？それとも業務システムの都合？ 20
もう1つの 見落としポイント
申し込み後、 その請求は完了したか？
実際にあった請求まわりのアレコレ - 1 ● 年間支払いのプランをリリース ● チャージバック・不審請求が発生する ● 調べると、現在進行形で使っているユーザー ● チャージバックの対応手数料やサポートの手間が ... → 顧客が契約を忘れないための通知や案内は十分？ 23
カード明細の表記は ブランドと一致していま すか？ 長期サイクル支払いは 事前にリマインドを いれていますか？
実際にあった請求まわりのアレコレ - 2 ● サービスをリリースした ● 契約数・ MAUに対して実売上が少ない ● 決済エラーで未払いになっているユーザーが 最長半年以上そのままになっていた → 請求期日や決済成否の監視と通知は十分か？ 25
通知機能や Webhook連携で 決済でも Observability
プロダクトの収益性も、重要な監視対象
決済・請求も Ops化が加速する -> Go RevOps ● APIやWebhookで連携と検知が容易に ● 決済や請求管理、売上情報なども監視が可能 ● 作らない実装と、 Ops化の発展により 開発サイドからもプロダクトや企業が持つ ビジネス的な課題の可視化や解決を目指せる 28
一般的に 考えられている Stripeの機能 決済の仕組み 実装
一般的に 考えられている Stripeの機能 ビジネスサイドで 「継続的」に 実現したいコト LTV向上 決済の仕組み 実装 顧客の離反・ チャーン対策 コストの削減
一般的に 考えられている Stripeの機能 Stripeによって 継続的に実現できる ワークフロー ビジネスサイドで 「継続的」に 実現したいコト LTV向上 プロセス改善 ・自動化 決済の仕組み 実装 顧客の離反・ チャーン対策 RevOps コラボレー ション促進 データ ドリブンでの 意思決定 コストの削減
システム開発から商品開発へ ● 「売上は全てを癒す」 by ダイエー 中内氏 ● 今の売上や収益性を把握していますか？ ● システムは売るための施策に耐えれますか？ ● 現在位置とゴールを観測可能（Observable）にして BizとTech両サイドからサービスを成功に導こう！ 32
DEV UPDATE 2024 [Preview] アカウント作成時などに、ユーザーへクレジットを付与
DEV UPDATE 2024 [New] プランごとのアクセス権管理も、 Stripe上で完結 Entitlements ( エンタイトルメント ) 商品ごとに機能リストを登録する サブスクリプションを作成すると、 自動的にcustomerに機能が割り当てられる プランごとのアクセス権管理が 1つのAPIコールで実現 customer_idをAPIに渡すと、 利用できる機能リストが取得できる。 リストにキーがあるかを見て、 表示非表示の制御が可能 https://sizu.me/terms?tab=privacy
DEV UPDATE 2024 [Preview] 使いすぎ防止の利用量アラート機能 / API
気づきや疑問を Xで共有しよう！