判断の出発点
サービスを維持する基本費用、顧客ごとの利用費、例外対応の人件費を分けます。サーバー代一つでは、保存容量、メール、監視、バックアップ、外部連携、問題を解く人の仕事が隠れます。
具体例で考える
説明用の仮定として月額基本費200計算単位、稼働顧客一社あたり4単位、支援12時間を時間30単位とします。50社なら合計760単位です。架空の入力であり提供元の料金ではありません。一つずつ仮定を変えて影響を調べます。
仮定を計算のそばに残す
費用ごとに単位、数量、単価、請求元、責任者を書きます。基本費は月、メッセージは件数、支援は時間であり、全部をサーバー代に混ぜません。例の50は登録者でなく稼働企業です。支援時間に含む作業や導入支援も明記します。確認した料金がなければ未知のまま式を示し、もっともらしい数字を作らないでください。
具体的な運用変更を計算する
例の760単位から支援を12時間から24時間にすると1,120単位です。支援を固定して顧客を50社から100社にすれば960単位です。架空の算術であり成長費用の予測ではありません。大型文書取込、再試行の急増、複数顧客の同時導入もシナリオにし、暴走を防ぐ上限や運用判断を付けます。費用の原因を別行にする意味が分かります。
モデルから運用責任を決める
支出警報は誰かが受け、何を安全に止められるか分かって初めて役立ちます。上限が顧客、処理、全体のどこに適用され、到達時に何を表示するか決めます。異常利用、請求書、公開後の仮定を見直す担当者を置きます。数字を小さく見せるために必要なバックアップや監視を削らないでください。持続できる頻度で実請求と支援を比較し、変動を説明して次の判断に使います。
選択肢とその負担
固定の構成は予測しやすく、従量制は活動に応じた支出と急増の可能性があります。自前運用は一部のサービス料金を運用作業に置き換えます。障害と更新の担当者も計算に入れます。
見落としやすい点
大部分が休眠中なのに登録アカウント数だけで割らないことです。費用に応じて稼働企業、ファイル、メッセージ、処理件数を使います。開発投資は分け、税や決済手数料を含むかも明記します。
依頼前に確認すること
何が単位課金か。暴走する処理を何で制限するか。不慣れな顧客にどれだけ支援が必要か。未確認の相場ではなく、この仮定をSaaS設計の相談に持ち込んでください。