予約や通販を受けているホームページをリニューアルするとき、公開日までに新しい画面を完成させるだけでは準備が足りません。制作中にも予約が入り、注文や在庫が変わり、お客様は以前の案内から受付へ進んでいます。
営業を続けながら切り替えるには、新しくする案内ページと、使い続ける受付・決済の仕組みを分け、確認方法と問題時の戻し方を先に決めることが大切です。停止を避けられるかは現在のつくりと変更内容によって異なります。ここでは、依頼前に整理しておきたい情報を説明します。
お客様の入口から、受付の保存先までたどる
まず、今の予約や購入を一件たどります。ホームページのボタンを押すと、別サービスの画面が開くのか、同じサイト内で入力するのか。送信後はどこに予約や注文が記録され、担当者が何を見て対応しているかを確かめます。
例えば、体験教室の紹介ページから外部の予約サービスへ進み、物販は別の通販サイトで受けている会社を考えます。この場合、紹介ページの文章やデザインを変えても、予約と通販の受付先を継続できる可能性があります。ただし、リンク先、埋め込み表示、利用契約や接続条件まで確認して判断します。
反対に、紹介ページと購入処理が同じ仕組みで動いている場合は、見た目の変更がカートや決済画面にも影響することがあります。「ボタンの先は変えないから大丈夫」と決めつけず、制作会社に現在の構成を調べてもらいます。
依頼時には、公開中のURL、利用している予約・通販サービス名、普段確認する管理画面、契約の管理者が分かると調査を進めやすくなります。仕組みを説明する資料がなくても、実際の操作を一緒に見るところから始められます。パスワードを資料へ書き込むのではなく、必要な権限の渡し方は別に相談します。
切り替えるものと、営業中も使うものを並べる
新しい画面をつくり始める前に、今回変更する対象を具体的にします。紹介文や写真、ページの並びを変える仕事と、予約枠や注文を管理する仕事を一括りにしないようにします。
先ほどの会社なら、新しい紹介ページの予約ボタンから従来の体験プランへ進めるか、通販ボタンから営業中の店へ進めるかを確認します。受付先を残す場合も、新しい紹介文と受付側のプラン名、価格、開催条件が一致している必要があります。
案内ページと販売処理を分ける仕組みの例として、ShopifyのBuy Buttonには、外部サイトへ購入機能を設置し、注文をShopifyの管理画面で確認する方法があります。これは一つの構成例であり、どのサイトでも同じ方法で受付を残せるという意味ではありません。現在使っている方式を調べてから、残す範囲を選びます。
新しいページで使うボタンの接続先だけでなく、チラシのQRコード、お客様へ送ったメール、お気に入り登録から来る入口も確認します。以前の紹介ページのURLを変えるなら、そこから正しい案内や受付へ進める方法を用意します。予約の確認・変更用URLまで、まとめて新しいトップページへ転送しないようにします。
制作中に増えた予約や注文を、古い控えで上書きしない
確認用のサイトをつくった日から公開日までの間にも、本番の受付には新しい記録が増えます。そのため、確認用サイトを丸ごと公開先へ置けばよいとは限りません。古い状態へ置き換えると、その間の注文や更新内容が見えなくなる可能性があります。
WooCommerceの開発者向け資料でも、制作したコードを本番へ反映することと、データベースの内容を扱うことを分けて計画する考え方が示されています。依頼する会社側が移行作業を行う必要はありませんが、「公開中に増える情報はどこにあり、どう保持するか」は確認しておきたい点です。
予約や注文を外部サービスに残すなら、その記録を今回の切替で移さないことを明確にします。同じサイト内で受付を管理しているなら、注文、在庫、会員情報など、営業中に変わる情報をどう扱うかを制作会社と決めます。商品説明の変更も続ける場合は、誰がどちらの画面を更新し、公開版へいつ取り込むかをそろえます。
調べた結果、受付処理そのものの変更で短い停止が必要になることもあります。その場合は「止めずにできるはず」と進めず、変更を段階に分けるか、受付の少ない時間帯に切り替えるかを検討します。停止が必要な範囲、事前の案内、再開の確認まで含めて予定を決めます。
切替前は、ボタンの表示から受付側の記録まで試す
新しい画面に予約ボタンが見えていても、別のプランへ進んだり、受付が終わった商品につながったりすることがあります。スマートフォンで紹介ページから進み、希望するプランや商品、日付、数量が正しく選べるかを確かめます。
その先も、送信や購入の完了、確認メール、担当者が見る記録まで確認します。決済後に戻るページが古いURLのまま残っていないか、既存の予約を確認・変更する入口が使えるかも、今回の変更が関わる範囲で試します。
テストは、利用サービスの検証方法に沿って行います。本番へ不用意な予約を入れて枠を消費したり、実際の請求や出荷が発生したりしないよう、担当者と方法を決めます。確認用の画面から本番の受付につながる場合も、見た目がテスト用だから処理もテストになるとは限りません。
公開直前には、新しい案内と稼働中の受付をもう一度照合します。制作中に価格やプランが変わっていれば、新しいサイトの原稿にも反映します。公開後も同じ入口から動作を確かめ、担当者が普段の方法で予約や注文を確認できる状態まで見届けます。
戻す対象と判断する人を、公開前に決める
問題が起きた場合に「元へ戻す」と言っても、新しい紹介ページを以前の表示へ戻すことと、注文を含むサイト全体を過去の状態へ戻すことは違います。公開後に入った予約や注文を保持しながら、どの部分を戻せるかを決めます。
例えば、新しい紹介ページのボタンに問題があれば、以前の案内へ戻すのか、確認済みの受付先へのリンクに切り替えるのかを用意できます。決済や予約処理に問題がある場合は、重複して処理しないための確認も必要です。担当者の連絡先、切替を進める判断、戻した後に確認する操作を事前に共有します。
依頼前に完璧な切替手順を作る必要はありません。「受付を続けたい」「現在の予約と注文を残したい」という条件を伝え、今の入口と管理方法を示せれば、調査すべき範囲が見えてきます。
Bämのホームページのリニューアル・部分改修の相談では、現在の内容と機能を確認し、残す範囲と変更する仕事を整理します。新しい画面だけでなく、公開中の更新を取り込む時点や、切替前後の確認、問題時に戻す対象も含めて相談できます。
