前回までのあらすじ
「半年・500万円」と言われて諦めていた予約システムを、お盆休みにClaudeと作り始めた話を書いています。
前回は決済編でした。モックが通用しなくなり本番環境に切り替わった工程で、「決済は借りてくるもの」という思い込みが崩れた回です。
今回は、Googleカレンダーとの双方向同期です。
正直に言うと、この機能こそが今回の開発で最も切実なテーマでした。そして結果は、まったく予想と違うものでした。
予約の経路が、3つある
まず、私たちの置かれている状況を説明させてください。
レンタルスペースALBEには、予約の入り口が3つあります。
- 自社の予約システム
- スペースマーケット
- インスタベース
比率でいえば、自社システムがおよそ90%、ポータルサイト経由が10%程度です。
数字だけ見れば、ポータル経由は少数派です。しかし、ダブルブッキングは許されません。 1件でも起きれば、その日にお客様が2組現れることになります。
そして台帳は、Googleカレンダー1つです。すべての予約が、ここに集まってきます。
だからこそ、Googleカレンダーとの双方向同期、しかもリアルタイムであることが、決定的に重要でした。
以前は、手で転記していました
この問題は、今回が初めてではありません。10年以上、私たちを悩ませ続けてきました。
以前使っていたシステムでは、Googleカレンダーとの連携が一方通行でした。予約システムからGoogleカレンダーへは自動で入る。しかしポータルサイト経由の予約は、予約システム側には取り込まれない。
そこで何をしていたか。手で転記していました。
ポータルサイトに予約が入るたびに、予約システム側に同じ内容を入力する。やらなければ空き枠が実態とずれて、ダブルブッキングになります。
そして手入力では、リアルタイムには追いつきません。だから当日予約の受付を止めていた時期が長く続きました。
ここを解決できるかどうか。今回の開発で、私が最も気にしていた部分です。
決済の瞬間に、カレンダーを見に行く
では、どう解決したか。
答えはシンプルでした。
決済が実行される瞬間に、一度Googleカレンダーを参照する。
確認したところ、ポータルサイトからの予約は、ほぼリアルタイムでGoogleカレンダーに表示されます。つまりGoogleカレンダーを見れば、その瞬間の正しい状況が分かる。
であれば、予約が成立する直前に、必ずそこを見に行けばいい。
前回書いたとおり、私たちは「決済が完了した瞬間に予約が成立する」というルールを決めていました。成立する瞬間が1つしかないのなら、その1点だけを守ればいいのです。
定期的に同期を繰り返すのではなく、成立の直前に一度だけ確認する。これでダブルブッキングを防ぐ仕組みができました。
埋まっていた場合は、成立させません
もし決済の瞬間にカレンダーを確認して、すでに埋まっていたらどうなるか。
「予約が成立できませんでした」というメールをお返しします。
お客様にとっては残念な結果です。ただ、後から謝るよりはずっと誠実だと考えました。
一度確定の通知を出しておきながら、後になって「やはり使えません」と連絡する。これが一番まずい。その場で成立しなかったと伝えるほうが、お客様の次の行動も早くなります。
双方向にしたのに、スタッフは書き込みません
ここからが、この回でお伝えしたいもう一つの話です。
双方向同期にしたということは、Googleカレンダー側から予約システムへも情報が流れます。技術的には、どちらからでも書き込めます。
しかし私たちは、スタッフがGoogleカレンダーに直接書き込まないというルールにしています。
管理者もスタッフも、必ずシステムの管理画面から入る。そこで予約をブロックしたり、後述する「商談中」のフラグを立てたりする。これを徹底しています。
理由は2つあります。
ひとつは、間違いを防ぐため。入口が複数あると、どこかで必ず抜けが出ます。
もうひとつは、情報が残らないからです。Googleカレンダーに直接書き込むと、予約システム側には「誰が、何のために押さえたのか」が残りません。管理画面から入れば、ブロックなのか商談中なのかという状態まで持てます。
台帳は1つ。でも、書き込む入口も1つに絞る。
できることと、やっていいことは違う。これは料金設計の回でも書いたことですが、ここでも同じ判断をしました。
こだわった「商談中」フラグ
今回こだわった機能のひとつが、この商談中フラグです。
背景から説明します。
アルベホール名古屋は、1ヶ月前まで一般予約を受けません
私たちが運営する「アルベホール名古屋」は、おかげさまで大変人気のあるスペースです。
このスペースは、一般の予約を1ヶ月前からしか受け付けない仕組みにしています。
なぜか。連続した複数日を使ってくださるお客様を優先するためです。
そして、複数日にわたる利用は、ほとんどの場合お問い合わせから始まります。いきなりネットで予約されるものではありません。
「埋まっている」と見えた瞬間に、諦められてしまう
ここがポイントです。
カレンダーの見た目が完全に埋まっている状態だと、お客様はその時点で諦めてしまいます。 問い合わせすら来ません。
しかし「商談中」というマークが表示されていればどうでしょう。問い合わせにつながる可能性が残ります。
そして実際のところ、商談中のお客様が必ず確定するとは限りません。話が流れることもある。
だからこそ、商談中の日でもクリックすれば問い合わせフォームが開くように設計しました。
分かりやすく言えば、先行して打ち合わせをしているお客様がキャンセルになった場合に、次のお客様をプールしておくということです。機会損失を減らすために作りました。
カレンダーは、在庫表ではなく営業ツールです
この機能を作りながら考えていたのは、予約カレンダーは単なる在庫表ではないということです。
◯か✕かだけを表示すれば、確かに正確です。でもそれは、お客様に「諦めてください」と伝えているのと同じことでもある。
◯でも✕でもない状態を見せる。そこから会話を始める。
ホテルの宴会場を販売していた頃の感覚が、ここで出たのだと思います。
そして、実装は拍子抜けするほど簡単でした
最後に、正直な話を書きます。
この双方向の仕組みを作るのは、ものすごく大変な作業になるのではないかと思っていました。
10年以上どうにもならなかった問題です。それが簡単に解決するとは、正直思っていませんでした。
ところが、とても簡単でした。
いや、正確に書くなら、こう言うべきかもしれません。Claudeが、簡単かつ確実な方法を示してくれたのだと思います。
やったことは、拍子抜けするほど単純でした。
- 取り込む側は、GoogleカレンダーのIDをコピーして貼り付ける
- 情報を出す側は、共有設定をする
複雑なプログラムも、面倒な設定も、ほとんど発生しませんでした。
そして前回と同じことを、ここでも思いました。
これもプラグインやパッケージがないと実現できないものだと思い込んでいた。 クレジットカード決済のときと、まったく同じです。
オリジナルで設置できるとは、思っていませんでした。
この回でわかったこと
10年悩んだ問題が、数日ではなく、数時間で解決しました。
もちろん、裏側ではClaudeが相応のことをやってくれているのだと思います。私が理解できているわけではありません。
ただ、難しいと思い込んでいた期間のほうが、解決にかかった時間よりはるかに長かったというのは事実です。
そして今、当日予約も直前予約も受けられるようになりました。手作業の転記もありません。ダブルブッキングも起きていません。
10年間、私たちが失っていたものの正体は、技術的な壁ではなく、「これは無理だ」という思い込みだったのかもしれません。
次回：#7 メールと通知の設計
次回は、地味ですが運営に直結する部分です。
予約確認メール、入金の案内、リマインド。部屋ごとに違う入室方法をどう届けるか。
「メールを送る」というだけの話が、実際にやってみると想像以上に考えることの多い工程でした。
シリーズ一覧（全12話）
- 連載まとめ・目次
- #1 きっかけ編｜「作れます」の一言から始まった
- #2 準備編｜Cloudflareが何かも分かっていなかった
- #3 予約カレンダーと顧客導線｜なぜ日付から入らせるのか
- #4 料金設計という難所｜AIは「やめたほうがいい」とは言わない
- #5 決済とStripe｜「借りてくるもの」だという思い込み
- #6 Googleカレンダー双方向同期｜台帳は1つでいい（この記事）
- #7 メールと通知の設計｜10年間、諦めていたこと
- #8 思わぬ落とし穴｜2回、巻き戻しました
- #9 ローンチ当日｜「あっ、ヤバい」
- #10 ローンチ後に起きたこと｜作った本人には見つけられない
- #11 予約システムが、画面の外に出た日（SwitchBot連携）
- #12 最終回｜私でも、優秀なプログラマーを配下に置ける
運営ルールの記事