前回までのあらすじ
「半年・500万円」と言われて諦めていた予約システムを、お盆休みにClaudeと作り始めた話を書いています。
前回は、CloudflareもGitHubも何のことか分からないところから、それぞれの役割を教わり、コストの見通しを立てた準備編でした。
今回からは、いよいよ実装の話に入ります。最初に手をつけたのは、予約カレンダーです。
モックアップが、驚くほどイメージに近かった
第1話で書いたとおり、私が最初に作ってもらったのは予約カレンダーでした。
そして正直に言うと、モックの時点でイメージにかなり近くて驚きました。
もちろん、この時点では細かい部分は入っていません。後で書く◯△✕の表示も、まだ実装されていませんでした。
それでも、頭の中にあったものが、ほぼそのまま画面に出てきた。「これでいい」ではなく「これだ」と思えたのが大きかったと思います。
ここで時間を使わずに済んだことが、2週間という期間に効いています。
カレンダーから入ると、「戻る」が減る
なぜそこまでカレンダーにこだわったのか。
以前から思っていたことがあります。
レンタルスペースの予約は、カレンダーから選べるようにしたほうが、お客様の「戻る」行為が少なくなる。
言葉で説明するより、実際の場面で考えたほうが早いと思います。
防音室の場合
私たちは防音のピアノ練習室も運営しています。ここはリピートのお客様が中心です。
プランから入る導線だと、こうなります。
まずプランを選ぶ。次に進む。オプションを選ぶ。さらに進む。そして日程を決めるカレンダーが開いて——空いていない。
がっかりされると思います。しかもここまでの操作が、全部無駄になります。
一方、最初にカレンダーが出ていればどうでしょう。
空いているかどうかが、その場で分かります。「今週は埋まっているな、では翌週はどうかな」「明日なら時間が作れるから、明日にしよう」——検討がその場で完結します。
イベントの場合
イベント利用も同じです。
たとえばポップアップストアの企画が持ち上がったとします。この人にとって最初に必要なのは、料金でもプランでもありません。
場所が確保できないと、何も始まらないのです。
日程が押さえられて初めて、企画が動き出す。告知もできるし、人も呼べる。
そう考えると、カレンダーは単なる予約画面ではなく、お客様の企画を前に進めるための道具です。
Booklyでは、これができませんでした
第1話でも書きましたが、それまで使っていたWordPressのプラグイン「Bookly」は、プランを選んでから日時を選ぶという設計でした。
機能面では優秀なプラグインです。ただ、カレンダーが後から表示される構造そのものは変えられません。
海外ではその流れが自然なのだと思います。しかし日本のお客様は、まずカレンダーを見たい。
3年ほど使ってきて、ここだけはどうにもなりませんでした。
だから自分で作ると決めたとき、迷わず最初にカレンダーを作ったのです。
◯△✕の基準を、どう決めたか
カレンダーには、日ごとの空き状況を◯△✕で表示しています。
では、どのくらい予約が入ったら△になるのか。どこから✕なのか。
これもClaudeと相談しながら決めました。
考え方自体は、意外とすんなり決まりました。レンタルスペースの在庫は「時間枠」だからです。
- 在庫の時間が 50%を切ったら △
- 在庫が ゼロになったら ✕
これだけです。非常にシンプルな基準にしました。
難しいのは、部屋ごとに営業時間が違うこと
ここでレンタルスペース特有の事情が出てきます。
部屋によって営業時間が異なるのです。 ということは、そもそもの在庫時間も部屋ごとに違う。
10時間営業の部屋と、24時間使える部屋を、同じ物差しで測ることはできません。
だからこそ、絶対値ではなく割合にしました。 「残り3時間なら△」ではなく「残り50%なら△」とすれば、どの部屋でも同じ基準が使えます。
複数のスペースを管理するうえでは、判断基準をある程度共通にしておいたほうがいい。そう考えました。
50%に、確たる根拠はありません
正直に書いておきます。
この50%という数字に、確定的な根拠はありません。 まずはこれでやってみよう、という感覚で決めました。
ただ、決められた理由があります。
Claudeに相談したときに、後から変更するとしても共通の概念なので簡単に変えられると教えてもらったからです。
これは自分で作ることの大きな利点だと思います。
ASPを使っていれば、こうした基準はサービス側が持っています。気に入らなくても変えられません。自分たちのシステムなら、運用してみて違和感があれば調整できる。
だから、最初の判断に時間をかける必要がない。
「完璧に決めてから作る」のではなく「まず決めて、動かしながら直す」。この進め方ができたことも、2週間でローンチできた理由のひとつだったと思います。
そして、空き状況ページを作りました
カレンダーとは別に、日付から全スペースの空き状況を探せるページも作りました。
これを作った動機は、実は理想的な話ではありません。
電話の問い合わせに対応するためです。
一番多い問い合わせは、いつも同じでした
レンタルスペースを運営していて、最も多い問い合わせの電話はこれです。
「◯月◯日の◯時、◯◯スペースは空いてますか？」
毎日のように、この電話が鳴ります。
サイトを見れば分かることではあります。ただ、空き状況を調べる前に知りたい、というせっかちなお客様は実際に多いのです。Booklyの構造ではカレンダーが後から表示されるため、確認するまでに何手もかかりました。それなら電話したほうが早い、と思われるのも無理はありません。
電話が、なくなりました
カレンダーと空き状況ページができてから、どうなったか。
この種の問い合わせが、パタッとなくなりました。
正直、ここまでとは思いませんでした。
レンタルスペースの運営では、お客様のために始めたことが、かえって自分たちの作業を増やしてしまう場面がよくあります。親切心で始めた案内や対応に、後から足を取られるのです。
今回は、その逆が起きました。お客様が自分で調べられるようにしたら、こちらの手数も同時に減った。
設計が正しければ、お客様と事業者の利便性は両立するのだと思います。
この回でやったことは、順番を変えただけ
振り返ってみると、第3話で書いたことに高度な技術はほとんど出てきません。
カレンダーを最初に出す。空き状況を割合で判定する。日付から全スペースを探せるようにする。
やったことは、順番を変えたことと、基準を決めたことだけです。
それでも、お客様の無駄足が減り、電話が鳴らなくなりました。
そしてこの判断ができたのは、技術力ではなく、10年以上お客様の予約を見てきたからです。どこで迷うか、何を最初に知りたいか。それを知っていたから、迷わず順番を決められました。
AIは、指示すれば作ってくれます。でも「カレンダーを最初に置こう」とは言ってくれません。 そこは運営してきた人間の仕事でした。
次回：#4 料金設計という難所
次回は、レンタルスペースの予約システムで最も厄介な部分に入ります。
時間帯によって変わる単価。平日と土日祝の違い。時間貸しと1日貸しの併売。季節料金。オプション。
ここが、既存のASPが「最後の一歩」で届かなくなる場所でもあります。
シリーズ一覧（全12話）
- 連載まとめ・目次
- #1 きっかけ編｜「作れます」の一言から始まった
- #2 準備編｜Cloudflareが何かも分かっていなかった
- #3 予約カレンダーと顧客導線｜なぜ日付から入らせるのか（この記事）
- #4 料金設計という難所｜AIは「やめたほうがいい」とは言わない
- #5 決済とStripe｜「借りてくるもの」だという思い込み
- #6 Googleカレンダー双方向同期｜台帳は1つでいい
- #7 メールと通知の設計｜10年間、諦めていたこと
- #8 思わぬ落とし穴｜2回、巻き戻しました
- #9 ローンチ当日｜「あっ、ヤバい」
- #10 ローンチ後に起きたこと｜作った本人には見つけられない
- #11 予約システムが、画面の外に出た日（SwitchBot連携）
- #12 最終回｜私でも、優秀なプログラマーを配下に置ける
運営ルールの記事