こんにちは、ウィルダー株式会社の松崎です。
レジャー業A社様の予約システムを自社開発し、外部サイトへの離脱とアカウント作成の壁をなくす予約導線を設計・開発しました。多店舗展開を進める企業や、予約の途中離脱に課題を感じている企業の参考になる事例です。
この記事では、課題・取り組み・導入後の目標の順にご紹介します。
| 項目 | 内容 |
|---|---|
| 依頼者 | レジャー業A社様 |
| 業種 | レジャー・エンターテインメント業（個室型レクリエーション施設） |
| 地域 | 関西地方 |
| 規模感 | 複数店舗を急拡大中の成長企業 |
こんな課題をお持ちの方におすすめです。
- 予約時に外部サイトへ移動してしまい、ブランド体験が途切れている
- 予約前のアカウント作成が原因で、予約の途中離脱が多いと感じている
- 店舗数の拡大に合わせて、予約・運営の仕組みを標準化したい
導入前の課題｜外部SaaSの制約で、予約も施策も止まっていた
導入前の最大の課題は、予約前にアカウント作成が必須で、予約の途中で離脱するユーザーが出ていたことです。
A社様は外部の予約SaaSを間借りして運用しており、課題は次の3点に整理できました。
| 課題 | 具体的な状況 |
|---|---|
| ①アカウント作成の壁 | 電話予約では聞かれない項目まで入力が必要で、離脱の原因になっていた |
| ②ブランド体験の分断 | 予約ボタンを押すと外部サイトへ移動し、世界観が途切れていた |
| ③施策が打てない | データはCSV出力のみで、個別クーポンや休眠ユーザーへの再訴求、エリア別・流入経路別の効果測定ができなかった |
もともと貸し会議室向けのサービスで、A社様の業態に合っていなかったことが根本の原因です。
このまま店舗を増やすと、運用面でも事業拡大のボトルネックになりかねない状態でした。
特に、予約のたびに外部サイトへ移動する仕組みでは、A社様のサイトで築いたブランドの印象が途切れてしまいます。
また、利用が止まったお客様へ個別に案内できないため、せっかく獲得した顧客との関係を、次の来店につなげにくい状況でした。
店舗が増えるほど、こうした機会損失が大きくなることから、早い段階での見直しが必要でした。
ウィルダーに依頼した理由
依頼のきっかけは、月額の外部SaaSに頼らず、予約システムを自社資産として持ちたいという考えでした。
A社様は要件定義書やプロトタイプを自社で用意されており、複数社の比較では業態への理解と提案の具体性を重視されていました。
外部SaaSの使い勝手に合わせて運用するのではなく、自社の業態に合わせて予約の仕組みを設計できることが、大きな決め手になりました。
私たちはヒアリング段階から「アカウント作成の壁をなくすこと」を提案の軸に据え、清掃連携を踏まえた部屋割当まで踏み込んで提案しました。
取り組み内容
プロジェクトの概要を以下の表にまとめます。
| 期間 | 体制 | 担当範囲 | 使用技術 |
|---|---|---|---|
| 約3〜4ヶ月（要件定義〜リリースまで） | PM・ディレクター・デザイナー・エンジニアの4職種体制 | 要件定義／基本設計／UI・UXデザイン／フロントエンド・バックエンド開発／外部サービス連携／QA・テスト | LINE公式アカウント連携、決済サービス連携、スマートロック連携、クラウドインフラ |
今回は、既存の要件定義書やプロトタイプを活かしながら、予約導線の設計から開発、運用開始の支援までを一貫してお任せいただきました。
進め方は、次の4ステップです。
ステップ1：ヒアリング・要件定義
既存の要件定義書やプロトタイプをレビューし、予約導線の課題を整理しました。
店舗数の拡大に耐えるよう、店舗単位で管理するデータ構造も、基本設計の段階から検討しました。
あわせて、「何をリリースの対象にするか」を明確にするため、今回の開発範囲と対象外の範囲を整理し、認識のずれが出ないようにしました。
ステップ2：基本設計・UI/UXデザイン
LINE公式アカウントを入口に、ノーアカウントで予約が完了する画面構成を設計しました。
決済手段は、クレジットカードに加えてキャッシュレス決済を増やす方向で検討しました。学生など、カードを持たない層も予約しやすくするためです。
入力項目は、電話予約で聞く内容と同じ程度に絞り、予約前の心理的な負担を減らす方針としました。
ステップ3：開発（フロントエンド／バックエンド）
多店舗管理、決済連携、スマートロック連携、料金プロファイル、クーポン、運営ダッシュボードを並行して開発しました。
主な機能は次のとおりです。
- 多店舗管理：店舗ごとの空き状況と予約を管理
- LINE連携：LINE公式アカウントからチャット形式で予約
- 決済連携：事前決済に対応し、複数の決済手段を選択可能
- スマートロック連携：利用の1時間前にワンタイムの入室コードを発行
- 料金プロファイル：部屋のグループごとに複数の料金パターンを設定
- クーポン：ユーザー単位の発行や、休眠ユーザーへの再訴求
- 運営ダッシュボード：予約状況、部屋割当、清掃の状況を一覧で確認
部屋は予約時点では確定せず、利用の直前に自動で確定します。清掃チームの稼働も踏まえた割当にし、スタッフが直前まで手動で変更できる柔軟性も確保しました。
ステップ4：QA・テスト／導入支援
複数店舗での運用を想定してテストを行い、特に同じ部屋への重複割当が起きないかを重点的に検証しました。
決済やスマートロックなど、外部サービスとの連携部分も、仕様を一つひとつ確認しながら動作を検証しました。
リリース後に現場の運用が滑らかに回るよう、スタッフの方が使う画面の導入支援も行っています。
導入後の目標｜予約の離脱を減らし、施策を自社で回せる基盤へ
導入後の目標は、予約の途中離脱を減らし、クーポンなどの施策を自社で回せる状態をつくることです。
リリース後の実績は、数字が確認でき次第あらためてご紹介します。ここでは、プロジェクトで掲げた目標をまとめます。
| 項目 | 導入前 | 導入後の目標 |
|---|---|---|
| 予約導線 | 外部サイトへ離脱する予約フロー | 自社サイト内で予約が完結する |
| アカウント作成 | 予約前に必須 | アカウント作成なしで予約できる |
| クーポン・休眠掘り起こし | CSV出力のみで個別施策は不可 | 個別発行や再訴求を自社で実行できる |
| 効果測定 | エリア別・流入経路別の測定ができない | エリア・訴求内容別に効果を計測できる |
| 店舗運営 | 1店舗を前提とした運用 | 複数店舗で標準化された運用ができる |
目標1：予約の入口の離脱を減らす
最優先の目標は、アカウント作成の壁をなくし、予約の途中で離脱するユーザーを減らすことです。
電話予約と同じ感覚で予約できる導線にすることで、来店のハードルを下げ、予約数の向上を目指しています。
目標2：予約システムを自社の資産にする
外部SaaSへの月額の依存から離れ、自社の業態に合わせて育てられる予約システムを持つことも目標の一つです。
機能の追加や改善を自社の判断で進められるため、店舗の拡大に合わせてシステムを成長させられます。
将来的には、同じ仕組みを他の業態へ展開することも視野に入れた設計としています。
目標3：施策の効果を計測し、改善を回す
本格的な出店拡大の前に、エリアや訴求内容ごとの施策の効果を計測できる基盤を整えることも目標です。
クーポンの発行や休眠ユーザーへの再訴求を通じて、データにもとづいた改善を続けられる状態を目指しています。
同じような課題をお持ちの方へ
同じ課題をお持ちなら、まず予約の入口（アカウント作成の有無や外部サイトへの離脱）を見直すことから始めるのがおすすめです。
店舗数が増える前に運用を標準化しておくと、拡大後の管理コストも抑えやすくなります。
電話予約が中心だった業態では、Webに不慣れなお客様にも使いやすい、入力の少ない予約導線が重要になります。
開発規模や期間は、既存システムの有無や連携先サービス（決済・チャットツール・施設管理システムなど）の数で変わります。
費用や期間は、機能の範囲や連携サービスの数によって変わります。まずは現状の課題をお聞かせください。
よくある質問
予約システムの開発を検討中の方からよくいただく質問に、一般的な内容でお答えします。
Q. 予約システムの開発には、どれくらいの期間がかかりますか？
A. 機能の数や外部サービスとの連携数、要件の固まり具合によって変わります。要件定義書やプロトタイプがすでにある場合は、期間を短縮できることもあります。まずは要件をお伺いしたうえで、スケジュールをご提案します。
Q. 開発費用の目安を教えてください。
A. 費用は、機能の範囲や連携サービスの数によって大きく変わります。優先順位をつけて段階的に開発することで、費用を調整することも可能です。個別のお見積りは、無料相談で承ります。
Q. 既存の予約システムからのデータ移行は必要ですか？
A. 移行が必要かどうかは、保有しているデータの種類や量によって異なります。移行せずに、告知や切り替え時の案内で新システムへ誘導する方法もあるため、状況に合わせてご提案します。
Q. LINE公式アカウントや決済サービスとは連携できますか？
A. はい、連携できます。既存のLINE公式アカウントを予約の入口として活用したり、クレジットカードに加えてキャッシュレス決済を追加したりする設計が可能です。連携先の仕様によっては事前の確認が必要です。
Q. 導入後のサポートはありますか？
A. はい、導入支援のほか、保守運用についても別途ご相談いただけます。システムは作って終わりではなく、店舗数の拡大や機能追加に合わせて育てていくものと考えています。
さいごに
今回の事例のポイントは、次の3点です。
- アカウント作成の壁をなくし、ブランド内で完結する予約導線を設計
- 清掃連携を踏まえた部屋割当ロジックなど、業態理解に基づく設計
- 多店舗拡大・クーポン施策に対応できる運用基盤を構築し、導入後の目標を設定
予約の途中離脱や、店舗拡大に耐える運用基盤でお悩みの方は、お気軽にご相談ください。
