「予約、すごく使いやすかったです。予約と同時に案内が届くのも安心感がありました」
オーナーからそのメッセージが来たとき、システムが動いていることよりも「安心感があった」という言葉に引っかかった。
ユーザーが「安心」を感じる設計になっていたとしたら、それは意図していた結果だ。予約した瞬間にLINEで確認が届く。「本当に予約できたのか」という不安を、通知が消す。技術の話ではなく、心の話だ。
最初の予約が来るまでが、一番長い
予約システムは完成しても、それだけでは使われない。
「このURLを踏んで予約してください」という導線を、お客さんが知っていることが前提だ。LINEのリッチメニュー・LPのボタン・InstagramのプロフィールURL。それぞれの場所からお客さんが流れてくるには、時間がかかる。
公開直後は静かだ。管理画面を見ても予約は入っていない。「システムは動いている。後は使ってもらうだけ」という段階が、技術的には何も難しくないのに、最も時間がかかる段階だった。
これはシステムの問題ではない。マーケティングの問題だ。
使われてから初めて出てくる要望
公開後に、オーナーから新しい要望が来た。「講座が終わった後、お礼のメッセージを自動で送りたい」というものだ。
予約確認・前日リマインドに続く、3つ目の自動通知だ。
この要望の背景には「次の予約につなげたい」という意図がある。一度来てくれたお客さんへのフォローは、次の予約に最もつながりやすい。タイミング良くLINEが届けば、「また来てみようかな」と思う人がいる。
実装のアイデアはすぐに浮かんだ。GASのタイムベーストリガーで「予約日時を過ぎた予約」を全件取得してメッセージを送る。しかし「キャンセルになった予約にもメッセージが届いてしまう」という問題がある。キャンセル管理の仕組みとセットで考える必要があった。次のフェーズに積み残した。
選択肢が増えることの罠
6サービスに増えた予約フォームを自分で開いてみると、少し重さを感じた。
「何を選べばいいか、少し迷う」という感覚だ。6つの選択肢が並んでいると、比較するコストが増える。初めてアクセスしたお客さんが「とりあえずここから始めればいい」という選択肢が見えにくい。
決定疲れと呼ばれる現象がある。選択肢が多いほど選ぶことのコストが上がり、「また今度でいいか」という離脱につながることがある。
「暮らしの作戦会議（無料相談）」をデフォルト表示にして、他のサービスは折りたたみにする案を検討している。「まず話を聞く」という最初のステップへの障壁を下げることが、全体の予約数を増やすことにつながる。
GASの手動デプロイが継続的に発生する
要望のたびにCode.gsを修正してGASエディタに貼り替えてデプロイする。この作業が地道に続く。
1件あたり5分の作業だが、予約システム以外にも入退室管理システム・AiReview・焼き菓子店と複数のGASプロジェクトが並走している。月に数件の修正が複数プロジェクトで起きると、気づくと貼り替え忘れのプロジェクトが出てくる。
claspという公式のGAS CLIを使って、コマンド一発でデプロイできる仕組みを作るのが次の課題だ。コードの管理もGitHubで行えるようになる。
使われながら育つシステム
作り終えた段階の予約システムは、最低限の予約システムだった。使われる中で要望が出て、機能が追加されて、少しずつ使いやすくなっていく。
完璧な設計を最初から作ることはできない。オーナーが使い、お客さんが使い、その体験から「ここがもう少し」という声が出る。その声を受けて変えていく。
動くものを早く出して、使われながら育てる。それがこのシステムの正しい作り方だった。
*シンプルシステム株式会社 代表 伊藤勝彦*