前回までのあらすじ
「半年・500万円」と言われて諦めていた予約システムを、お盆休みにClaudeと作り始めた話を書いています。
前回は、すべての出発点となった予約カレンダーの話でした。なぜ「カレンダーから入る」にこだわったのか、◯△✕の基準をどう決めたのか。
今回は、レンタルスペースの予約システムで最も厄介な部分に入ります。料金設計です。
そして今回は、これまでとは少し毛色の違う話になります。作れるのに、あえて作らなかったという話だからです。
料金そのものは、すでに決まっていました
前提として書いておくと、レンタルスペースALBEの料金は、今回のシステム開発以前から決まっていました。
決め方には、私なりの手順があります。競合となる施設の価格を横に並べて、各スペースの平米単価にまで分解する。その平均値より少し低い水準を基準にして、自社スペースの面積と掛け合わせて金額を出す——というものです。
これは前職のホテル時代、客室販売で使っていた考え方をそのまま持ち込んだものです。
この料金設定そのものの話は、それだけで1本の記事になるので、また改めて書こうと思います。
今回の開発でやったのは、すでにある料金を、どうシステムに載せるかという作業でした。
最初は「何でも組めるようにしよう」と考えました
レンタルスペースALBEの料金は、基本的に平日料金と土日祝料金で差をつけています。
ただ、開発を始めるにあたって、私はこう考えました。
これから競合が増えるかもしれない。外部環境も変わる。であれば、昼間の料金、夜の料金といった時間帯のバリエーションも組めるようにしておいたほうがいいのではないか。
縦軸に平日・土日祝、横軸に昼・夜。そういうマトリックスが組めれば、どんな状況にも対応できます。
実際にClaudeにも相談しました。答えは明快で、そのマトリックスは組めるという見解でした。
技術的には、何の問題もなかったのです。
しかし、限界がありました
ところが、進めていくうちに限界を感じました。
ここははっきり書いておきたいのですが、限界があったのはシステムではありません。コントロールする側の人間のほうです。
理由は2つあります。
1. 自分たちが管理しきれなくなる
料金のパターンが増えれば増えるほど、設定する側の負担が上がります。
平日の昼、平日の夜、土日祝の昼、土日祝の夜。ここに季節料金やキャンペーンが加われば、組み合わせは一気に増えます。複数のスペースを運営していれば、それが部屋数だけ存在することになる。
作れることと、運用し続けられることは別の話です。
2. お客様が、料金を理解できなくなる
こちらのほうが深刻だと考えました。
料金体系を複雑にしすぎると、お客様が料金に対する理解に追いつかなくなります。
そして厄介なのは、それが表面化するタイミングです。予約の最終局面、まさに申し込もうとしている場面で、「なぜこの金額になるのか」が分からなくなる。
算定根拠が難しすぎると、納得できずに離脱してしまうのではないか。
これは私たちが別の場面でも痛感していることです。人は、金額が腑に落ちていない状態では決断できません。
だから、横軸をやめました
そこで判断しました。
昼間と夜という横軸の区分はやめて、平日と土日祝という縦軸だけでシステムを組む。
作れるけれど、作らない。技術的に可能だと分かったうえで、使わない選択をしました。
そしてここが、自社でシステムを持つことの本当の意味だと思っています。
これはASPではありません。 後日、本当に時間帯別の料金が必要になる場面が来たら、そのときにまたClaudeに相談すればいい。
ASPだと、こうはいきません。機能が用意されていれば使いたくなりますし、逆に用意されていなければ諦めるしかない。必要になってから足す、という選択肢がそもそも存在しないのです。
自社開発の一番の利点は、何でも作れることではありませんでした。作らない判断を、自分で下せることでした。
時間貸しと1日貸しの併売が、画期的でした
一方で、今回の開発で実現できて本当に良かったと思っている機能があります。
同じ部屋で、時間貸しと1日貸しを併売できるようになったことです。
これまでは、手作業でした
Booklyや他のASPを使っていたときは、この2つをプランで切り分けるしか方法がありませんでした。
つまり、どういうことが起きるか。
1日料金で販売したい日には、手作業でその日の時間販売を停止して、1日料金のプランを配置する。 これを毎回やる必要がありました。
土日祝は1日料金で売りたい、と思えば、毎週その作業が発生します。祝日が絡めばさらに増えます。地味ですが、確実に時間を奪われる作業でした。
今は、チェックボックス一つです
新しいシステムでは、「土日祝は1日料金で販売する」というチェックボックスを入れるだけで、一発で整うようにしました。
毎週繰り返していた作業が、設定一回で消えました。
これは「機能が増えた」という話ではありません。運用の手数がなくなったという話です。このシリーズを通して繰り返し出てくる構造ですが、私にとってはこちらのほうが価値があります。
こだわったのは、ゴールデンウィークやお盆の「谷間」
そして、料金まわりで最もこだわったのがここです。
ゴールデンウィークやお盆の、谷間の期間の料金。
レンタルスペースを運営している方なら、すぐに分かっていただけると思います。
ゴールデンウィークの谷間は、カレンダー上は平日です。でも実態は違います。世の中は休みモードですし、需要も休日と同じように動きます。お盆も年末年始も同じです。
できればゴールデンウィークは、谷間も含めて土日祝料金で販売したい。その年によって並びは変わりますが、谷間が短い年であれば、なおさらハイレートで売りたい。
ところが、曜日で判定する仕組みでは、これができません。
解決策は、シンプルでした
そこで搭載したのが、任意に指定した日を「土日祝扱い」にできる機能です。
新しい料金区分を作ったわけではありません。区分は平日と土日祝の2つのまま。ただ、「この日は土日祝として扱う」という指定ができるようにしただけです。
これでゴールデンウィークの谷間も、お盆も、年末年始も、すべて処理できます。
年によって日並びが変わる問題も、その年の日付を指定するだけで済みます。複雑なルールを組み立てる必要がありません。
そして何より、料金体系そのものは複雑になっていません。 設定する側も、お客様も、理解の負荷が上がらない。
前半で「横軸を増やさない」と決めた判断と、きちんと一貫した解き方になりました。
もうひとつ載せたのが、シーズン料金です
料金まわりで、もう一つ搭載した機能があります。シーズン料金です。
特定の期間について、%または具体的な金額で、料金の基礎を引き上げられるというものです。
これもホテルの手法です
考え方の出どころは、やはり前職のホテル時代です。
客室販売の世界では当たり前の話ですが、稼働が高ければ高単価で売り、稼働が低ければ安く売る。 レベニューマネジメントと呼ばれる考え方です。
レンタルスペースでも同じことが言えます。需要が集中する時期に、平常時と同じ単価で売り続ける理由はありません。
実際に、今まさに使っています
分かりやすい例が、今年の名古屋です。
アジア競技大会が開催され、需要が活況になっています。
こうした特殊需要が見込める期間は、ピンポイントで料金を調整できることに大きな意味があります。1年に何度もあることではありませんが、あるときに動かせるかどうかで結果が変わります。
なお私たちは、この期間の予約をブロックする選択はしませんでした。オープンにしたうえで、高単価で販売する方針を取っています。
そのかわりに調整したのが、予約を開放するタイミングです。早い段階から安い価格で販売してしまうのではなく、販売のリリースを3ヶ月前に設定しました。
早く開ければ、需要が本格化する前に埋まります。売れたように見えて、実際には一番高く売れたはずの枠を失っている。これもホテルの客室販売では当たり前に行われている判断です。
%と金額の両方で指定できるようにしたのは、使い分けが必要だからです。全体を一律に引き上げたいときは%、単価の異なる部屋に同じ額を上乗せしたいときは金額。実際に価格を動かしてみると、この二択が必要になります。
ただし、判断するのは人間です
ここで書いておきたいことがあります。
シーズン料金という道具は、システムが持っています。しかし、いつ販売を開けるか、どれだけ上げるかを決めているのは人間です。
システムは「3ヶ月前にリリースしましょう」とは言ってくれません。その判断は、需要の動きを読んで自分で下すしかない。
道具があることと、使いこなせることは別の話です。
増やさなかったのは「区分」、増やしたのは「期間」
ここまで書いてきて、矛盾していると思われたかもしれません。
昼夜の区分は作らなかったのに、谷間の指定やシーズン料金は載せている。結局、複雑にしているではないか、と。
ただ、この2つは性質が違います。
作らなかったのは、料金の「区分」です。 平日の昼、平日の夜、土日祝の昼——というように、料金表そのものの枠を増やすこと。これをやると、設定する側もお客様も、理解しなければならない体系が複雑になります。
載せたのは、期間の「指定」です。 この日は土日祝として扱う。この期間は基礎料金を上げる。料金表の構造は平日と土日祝の2つのまま変わりません。いつ、どれだけ動かすかを操作しているだけです。
お客様から見れば、料金は「平日料金か土日祝料金か」のどちらかでしかない。理解の負荷は上がっていません。
方向は、最初から揃っていました。
この回でやったのは、引き算でした
料金設計の回を振り返ると、やったことは足し算ではなく引き算でした。
組めると言われたマトリックスを組まなかった。料金区分を増やさなかった。その代わり、既存の区分に日を割り当てる仕組みと、期間で単価を動かす仕組みだけを足しました。
やりたいことは実現しつつ、体系そのものは増やさない。結果的に、そういう形に落ち着きました。
AIと一緒に作っていると、「できます」と言われることがたくさんあります。 技術的には、たいていのことが可能です。
だからこそ、何を作らないかを決めるのは、こちら側の仕事でした。
その判断ができたのは、10年以上お客様の予約を見てきたからです。どこでお客様が迷うか、どこで手が止まるか、何が分からないと離脱するか。運営してきた人間にしか、この線は引けません。
AIは、やめたほうがいいとは言ってくれません。聞けば「できます」と答えてくれます。どこでやめるかは、自分で決めるしかないのです。
次回：#5 決済とStripe
次回は、お金が動く部分に入ります。
クレジットカード、PayPal、銀行振込、コンビニ払い、請求書払い。5つの決済手段をどう組み込んだか。そして、決済が絡むと何が難しくなるのか。
正直に言うと、ここが一番緊張した工程でした。
シリーズ一覧（全12話）
- 連載まとめ・目次
- #1 きっかけ編｜「作れます」の一言から始まった
- #2 準備編｜Cloudflareが何かも分かっていなかった
- #3 予約カレンダーと顧客導線｜なぜ日付から入らせるのか
- #4 料金設計という難所｜AIは「やめたほうがいい」とは言わない（この記事）
- #5 決済とStripe｜「借りてくるもの」だという思い込み
- #6 Googleカレンダー双方向同期｜台帳は1つでいい
- #7 メールと通知の設計｜10年間、諦めていたこと
- #8 思わぬ落とし穴｜2回、巻き戻しました
- #9 ローンチ当日｜「あっ、ヤバい」
- #10 ローンチ後に起きたこと｜作った本人には見つけられない
- #11 予約システムが、画面の外に出た日（SwitchBot連携）
- #12 最終回｜私でも、優秀なプログラマーを配下に置ける
運営ルールの記事