前回までのあらすじ
「半年・500万円」と言われて諦めていた予約システムを、お盆休みにClaudeと作り始めた話を書いています。
前回は、10年悩み続けたGoogleカレンダーの双方向同期が、拍子抜けするほど簡単に解決した回でした。
今回はメールと通知です。
地味な話に聞こえるかもしれません。実際、開発の中でも派手さのない工程です。
ただ、私にとっては10年間ずっと諦めてきたことを実現した回でもありました。
メールは、50種類以上あります
まず結論から書きます。
今回作った予約システムには、50種類以上のメールテンプレートが実装されています。
送る相手も分かれています。
- お客様向け：予約確認、入金完了、入金待ちのご案内、キャンセル、返金、日程変更、利用前のリマインド、利用後のお礼、回数券の購入、ポイントや回数券の有効期限のお知らせ、ログイン関連、内見のご案内 など
- 管理者・スタッフ向け：新規予約の通知、未入金のアラート、変更依頼の受付、決済で対応が必要な案件のアラート、週次レポート など
「メールを送る」と一言で言ってしまえばそれまでですが、実際にやってみると、場面ごとに書くべきことがまったく違います。
これは、10年間の課題でした
なぜここまで作り込んだのか。
理由は単純です。ASPやBooklyでは、ここまで細やかな対応ができなかったからです。
既存のサービスでも、メールの文面自体は変更できることが多いです。ただ、送る場面そのものを増やすことはできません。
予約確認は送れる。キャンセル通知も送れる。でもそれ以外の場面は、用意されていなければ諦めるしかない。
私たちはこの10年、何度も同じことを言ってきました。
「この場面でメールが飛ぶといいよね」
言いながら、毎回諦めてきました。
今回、オリジナルで作れたことで、その諦めてきたものを全部実現しました。
ヒントは、自分の買い物体験にありました
では、なぜそこまでメールにこだわるのか。
きっかけは、自分自身がショッピングサイトを使ったときの経験です。
丁寧なサイトは、こんなメールを都度送ってきます。
- 「現在、出荷の準備をしています」
- 「本日発送しました。◯月◯日ごろ到着の予定です」
- 「お荷物の中身に不備はありませんでしたでしょうか」
これを受け取ると、とても良い印象を持ちます。
冷静に考えれば、こうしたメールは事務連絡として必須ではありません。追跡番号を1通送れば、用は足ります。
それでも都度届くと、ちゃんと見てもらえているという安心感があります。
私はここからヒントを得ました。
そして大事なのは、これはWEB屋としての知識から出た発想ではないということです。一人の利用者として、受け取って嬉しかったものを覚えていた。 それだけです。
レンタルスペースにも、同じ「空白の時間」があります
この構造は、レンタルスペースでもまったく同じです。
お客様が予約してから、実際に利用する日までには時間があります。1ヶ月先の予約なら、1ヶ月の空白が生まれます。
その間、お客様は自分の予約がどうなっているのか分かりません。
しかも私たちは前入金でお願いしています。つまりお客様は、お金を払ったのに何も返ってこない期間を過ごすことになります。
ここに接点があるかないかで、安心感はまったく違います。
メールの通知が丁寧になることで顧客接点が増え、それが安心につながる。 そして「レンタルスペースALBEは細やかな対応をしてくれる」というブランドの認識にもつながっていく。
そう考えて、送る場面を洗い出していきました。
文面は、Claudeと人間の分担でした
メールの文面をどう作ったかについても書いておきます。
基礎的な部分はClaudeに任せました。 構成、盛り込む項目、全体の骨格。ここは早かったです。
ただし、細かい部分は自分たちで何度もテストを繰り返して整えました。
特に手を入れたのが、日本語特有の言い回しです。
たとえば、入金の催促
分かりやすい例を挙げます。
「お振込みがまだです」
これでは、お客様を責めているように読めます。
「お振込みが確認できておりません。お手数ですがご確認をお願いいたします」
言っている内容は同じです。ただ、後者はこちらの確認が取れていないという言い方になっています。
受け取ったお客様の気持ちは、まったく違うはずです。
督促のメールは、関係を壊しかねない場面です。ここで強い言葉を使えば、その後の予約はもう来ません。言い方ひとつで、その先が変わります。
こういった調整は、AIに任せきりにはできませんでした。10年お客様とやり取りしてきた感覚で、一通ずつ確認していきました。
第5話で、テストの役割分担について書きました。Claudeが動作を見て、私が体験を見る。 メールの文面も、まったく同じ構造です。
事故から生まれたメールもあります
50種類以上のメールの中には、過去に実際に起きたトラブルから生まれたものもあります。
たとえば、枠を開放した後に入金があった場合のメールです。
私たちは、未入金の予約について督促をしています。それでも入金がなければ、最終的にキャンセルして枠を開放します。
ところが、催促のメールを見てくれないお客様が、一定数いらっしゃいます。
そして厄介なのは、キャンセルした後になって振り込んでしまわれるケースです。こうなると、お金は入ってきたのに、枠はもうないという状態になります。
これは過去にも何度か起きていました。今後も想定できることです。
だから今回、対策用のメールとして実装しました。
起きてから作ったのではなく、起きたことがあるから作った。 10年運営してきたからこそ、この場面が必要だと分かっていました。
それでも解決できなかったこと
最後に、メールでは解決できなかった課題についても書いておきます。
解錠パスワードの問題です。
私たちのスペースは、部屋ごとに入室方法が異なります。これまでは、解錠番号を定期的に更新して、お客様に通知していました。Booklyのメール機能で文面を変えられたので、2週間に1回程度パスワードを変更しては、案内を送っていました。
ただ、本当の課題はそこではありませんでした。
当日、解錠パスワードの入れ方が分からない、という物理的なトラブルが時々起きるのです。
そのたびに電話で説明することになります。
特に、年齢層が高いお客様に、パスワード入力ができない方が多いという傾向がありました。
使っている機器の操作性自体は、決して悪くありません。おそらく原因は、機械に対する認識や、抵抗感のようなものではないかと推測しています。
だとすれば、パスワードを送る仕組みをどれだけ磨いても、この問題は解決しません。通知の精度を上げても、入力していただけないのであれば同じことだからです。
メールでできることには、限界がありました。
だから、問題そのものを消しにいきます
現在、私たちはSwitchBotとの連携に取り組んでいます。
予約情報と連動して、予約時間の5分前に自動で解錠する仕組みです。
これが動けば、どうなるか。
パスワードを送る必要がなくなります。そして、入力していただく必要もなくなります。
課題を解決するのではなく、課題そのものを消してしまう。お客様のストレス軽減にもなります。
この話は、後の回であらためて書きます。
この回でわかったこと
メールの設計を振り返ると、必要だったのは技術ではありませんでした。
「この場面で連絡が来たら嬉しい」と思える感覚です。
それは10年の運営から来たものもあれば、自分がネットで買い物をしたときの記憶から来たものもあります。
AIは、指示すればメールを書いてくれます。でも「この場面でもメールを送ろう」とは言ってくれません。
どの場面で、誰に、何を伝えるか。そして、どういう言い方で伝えるか。
そこは全部、こちら側の仕事でした。
次回：#8 思わぬ落とし穴
次回は、うまくいかなかった話です。
順調に進んでいるように見えた開発の中で、何を見落としていたのか。そして公開の直前と直後に、何が起きたのか。
正直、あまり書きたくない内容も含まれます。
シリーズ一覧（全12話）
- 連載まとめ・目次
- #1 きっかけ編｜「作れます」の一言から始まった
- #2 準備編｜Cloudflareが何かも分かっていなかった
- #3 予約カレンダーと顧客導線｜なぜ日付から入らせるのか
- #4 料金設計という難所｜AIは「やめたほうがいい」とは言わない
- #5 決済とStripe｜「借りてくるもの」だという思い込み
- #6 Googleカレンダー双方向同期｜台帳は1つでいい
- #7 メールと通知の設計｜10年間、諦めていたこと（この記事）
- #8 思わぬ落とし穴｜2回、巻き戻しました
- #9 ローンチ当日｜「あっ、ヤバい」
- #10 ローンチ後に起きたこと｜作った本人には見つけられない
- #11 予約システムが、画面の外に出た日（SwitchBot連携）
- #12 最終回｜私でも、優秀なプログラマーを配下に置ける
運営ルールの記事