複数サイトの料金改定を同じ日に反映する

複数店舗・サイトの料金改定で旧料金を残さないため、料金項目、適用先、旧新値、反映先、例外、公開確認を一つの台帳へ整理。当日の更新順と確認方法を解説します。

本部が新しい料金を決め、店舗サイトを更新した翌朝、予約サイトには旧料金が残っている。別の店舗ページでは適用開始日だけ変わり、金額は以前のまま。複数サイトの料金改定は、原稿を一度書き換える作業ではなく、どの料金がどの店舗・サービスにいつから適用され、どの画面に表示されるかをそろえる更新です。「同日反映」を実現するには、変更の正本と反映先、例外、確認する担当を、先に一枚の台帳へまとめます。

この記事は、店舗やサービスごとに複数サイトを運営する本部の担当者、料金を決める部門、Web更新担当者に向けています。料金項目、適用店舗、旧値・新値、反映先、切替時刻、公開後確認を台帳にし、改定当日の手順を具体化します。実際の料金、税の扱い、契約の適用、法的な表示可否をこの記事や制作会社が決めるものではありません。表の値は架空の記入例であり、金額を入れていません。

みやあじよの複数サイト・多店舗の情報管理では、共通情報と店舗ごとの条件を分け、入力欄や更新・確認の手順を整えます。この記事では対象サイトが分かっている状態から、一回の料金改定を各ページやシステムへ反映し、切替後に一致を確認する場面に絞ります。料金が載る画面と更新元を対応づければ、共通化する項目や、個別に直すページを制作担当と相談できます。

新料金は、対象店舗と適用日時を確定してから載せる

「新料金表はこちら」というPDFだけを正本にすると、店舗ごとの例外や旧予約への扱いが漏れることがあります。まず料金を決める部門が、対象となるサービス・商品、料金単位、税の表示、適用する店舗・地域・プラン、開始日時を確定します。新しい値だけでなく旧料金の値も残し、どの画面がどちらを表示していたかを照合できるようにします。決定していない条件は空欄で承認待ちにし、Web担当が推測で補いません。

料金の適用開始には少なくとも二つの意味があります。新規申込へ新料金を適用する時点と、サイト上で新料金を見せ始める時点です。二つが同時でない場合、旧料金で受けた予約や既存契約の扱いを説明する必要があります。「○日から改定」とだけ書くと、前日までに申し込んだ人まで新料金と思われることがあります。適用条件は業務・契約の担当者が確認し、承認された説明を画面に載せます。

店舗ごとに営業時間やサービス内容が違えば、同じ料金項目名でも適用範囲が異なるかもしれません。全店舗へ一括で新値を配る前に、対象、対象外、保留を分けます。季節プラン、会員料金、法人契約、キャンペーン料金、オプション料金が別の管理元にあるなら、その値を主料金へ勝手に統合しません。料金表で示す単位と、予約・決済画面で計算する単位も一致させます。

Google Merchant Centerの公式ヘルプは、商品フィードの価格と着地ページの価格が一致することを求め、更新時刻のずれを価格不一致の理由として挙げています。これはGoogleの商品掲載を使うECの要件であり、すべてのサービス料金へ直接適用される規則ではありません。ただ、外部へ価格を送る仕組みがある事業者では、サイト本文だけ変えても表示が揃わないという具体例です。自社が実際に利用する外部媒体を反映先へ含めます。

料金が載るページ・予約画面・PDFを洗い出す

料金改定の台帳で正本、対象と例外、反映先、公開確認を結ぶ図 — 料金の正本から適用先、反映先、公開確認へつなぐ編集図。実際の値と担当は事業者の承認資料で確認します。

サイトの一覧だけでは、どの料金がどこへ載るかを追えません。台帳は「一行に一つの料金項目と適用条件」を基本にし、店舗が違えば行を分けます。共通価格でも例外店舗があるなら、共通行の注記だけで済ませず、例外行を独立させます。旧値と新値の欄は、金額だけでなく単位と税の表記まで照合します。画面の文言、予約サービスの設定、PDFの表が同じ意味になっているかを見ます。

表は左右にスクロールして確認できます。

台帳の列	記入する内容	確認する人
料金項目・単位	サービス名、対象プラン、時間・人数などの単位	料金決定部門
適用店舗・条件	対象店舗、対象外、既存予約や会員の扱い	店舗責任者・業務担当
旧値・新値	金額、税込・税別などの表記、承認版の所在	料金決定部門
反映先	店舗サイト、共通サイト、予約・決済、PDF、外部媒体	Web・システム担当
切替・確認	予定時刻、実際の公開時刻、画面URL、確認者	公開担当・受入担当

この表は台帳の設計例で、特定事業者の金額や規約を示しません。一行の反映先が多い場合は、別表でURLや画面名を列挙してもかまいません。ただし「Web一式」とだけ書いて完了にせず、訪問者が金額を見るページと申込確定前の画面を特定します。画像化された料金表、過去の告知記事、ダウンロードPDF、構造化データは、本文検索だけでは見つからないことがあります。

台帳には、原稿の承認者と公開の操作担当を別に記録します。Web担当が新値を受け取っても、それが最終版か分からなければ公開できません。料金部門は承認版の識別子と決定日を付け、更新担当はその版を各サイトへ割り当てます。公開後は、別の人が閲覧者として金額と適用条件を確認します。自分が入力した画面だけを見るのでは、参照先のPDFやキャッシュに残った旧値を見落とします。

承認版の変更が切替直前に起きた場合は、変更前の依頼と変更後の依頼を同時に進めないことが重要です。変更箇所、理由、承認時刻、取り消す版を台帳へ記録し、未着手・作業中・公開済みの反映先を分けます。既に更新したサイトだけ差し戻す必要があるかも判断できます。「最新版を使ってください」という口頭連絡だけでは、複数の担当者が異なるファイルを開くおそれがあります。差し替えを受けた人が、確認したことを記入する欄を用意します。

サイトと外部サービスの反映時刻を確かめる

同日反映は「全画面が一瞬で同時に変わる」とは限りません。別々のCMS、予約システム、外部媒体には公開操作や反映までの時間差があります。担当者は、更新可能な順番、予約を受け付ける画面の優先順位、公開確認の期限を決めます。新料金のページを先に見せて予約画面が旧料金のままになると、利用者がどちらを信じるか迷います。申込・決済に直結する反映先を先に把握します。

WordPressの公式文書には、記事やページの公開予定日時を設定できる機能が示されています。ただし既存の料金ページの一部更新、複数サイト、予約システム、外部PDFまですべて同時に切り替える機能だとは言えません。使用中のCMSで何を予約公開できるかを実環境で確認します。更新を予約設定した場合も、その日時に実際に画面へ反映されたかを確認する人が必要です。

公開前には、新料金を本番で見える状態にせずに原稿と設定を準備します。プレビュー、検証環境、非公開の下書きなど使える方法はサイトごとに違います。新旧値を取り違えないよう、ファイル名や更新依頼に料金項目と版を入れます。コピーしたPDFをメール添付からさらにコピーする運用では、最終版が複数できやすくなります。正本の置き場所と「この版を公開する」という承認記録を一つにします。

切替時刻は、日付だけでなく時刻と時間帯を明記します。複数拠点があるなら、どの地域の時刻を基準にするかを決めます。受付終了後に切り替えるのか、午前の開始時刻に切り替えるのかで確認方法も変わります。外部媒体の反映時刻が読めない場合は、完全な同時表示を約束せず、更新順と許容できない不一致を関係者で決めます。遅延した時の連絡先と一時案内も事前に作ります。

料金表以外の表示と、旧料金が適用される条件も確認する

料金ページのほかに、トップページの目立つ案内、店舗ごとのメニュー、FAQ、予約確認メール、申込フォーム、紙やPDFの資料、外部予約媒体を確認します。料金を直接書いていないページでも「月額○円から」「初回無料」などの文言が残るかもしれません。料金項目名でサイト内検索し、画像内の文字やファイル名にも目を向けます。検索結果の古い説明文はサイトを変えても即時に置き換わるとは限らないため、現在サイトに表示されている内容と区別して記録します。

ECの商品を扱う場合、Google Search Centralの販売者向け構造化データには、現在の有効な価格を示す項目があります。Google Merchant Centerの商品フィードを使う場合は、商品データと着地ページ、購入時の価格が一致するか確認します。こうした項目を実装していないサービスサイトに不要な作業を増やす必要はありません。台帳では「使用中」「使用なし」「確認待ち」を分け、実際にある反映先だけを更新対象にします。

旧料金で作成済みの予約、回数券、契約期間中の顧客、既に送った見積は、新規申込と同じ扱いとは限りません。適用条件は事業者の規約と業務判断で決めます。Webには、必要な対象区分と確認窓口を載せ、個別の契約状態を公開ページで断定しないようにします。例外を台帳に残しておけば、店舗が電話で旧料金を案内している一方で、サイトには新料金だけが載っているような食い違いも探しやすくなります。

更新後は別の担当者が、申込画面まで開いて確かめる

切替当日は、更新担当が各反映先へ承認版を反映し、確認担当が閲覧者として公開画面を開きます。確認は管理画面の「更新済み」表示だけで終えません。店舗サイト、共通ページ、料金表PDF、予約画面、確認メールまで、台帳のURLと画面名に沿って進みます。ページ上の金額だけでなく、料金単位、適用開始、店舗名、旧予約の扱いが一致するか見ます。違いがあれば、その画面だけの問題か正本の修正が必要かを分けます。

デスクトップとスマートフォンでは、料金表の並びや注記の見える位置が変わります。1440、768、390ピクセル程度で、金額と単位、注意書きが離れないか、表を横へ送った時に店舗名が分からなくならないかを確かめます。折りたたみ内やタブ内の旧料金も開いて確認します。読み上げやキーボード操作を使う人にも、改定前後の区別と適用日が伝わるよう、色だけで「新料金」を表さない設計にします。

確認結果には、単なるチェック印だけでなく、確認したURL、表示された値と適用文、時刻、確認者を残します。店舗によって旧料金が残ったら、どの画面を見た時点の記録か分からないと原因を追えません。閲覧者の画面でキャッシュを更新した場合も、その操作前に旧値が見えていた事実を消さずに残します。予約システムが別の事業者の管理なら、問い合わせ番号や反映完了の通知も台帳の反映先へ添えます。

一つのサイトで反映が遅れた場合は、現場で案内する料金を統一します。料金部門が承認した一時案内を、必要なページと店舗の電話対応へ共有します。Web担当だけで旧料金を消したり、未承認の新値を表示したりせず、台帳の状態を「未反映」「確認待ち」「反映済み」に分けて記録します。外部媒体の修正待ちなら、提出時刻と再確認時刻も残します。あとで誰がいつ何を見たか追えることが重要です。

公開後しばらくは、料金の問い合わせがあった際に、相手が見たページ・媒体の表示もあわせて記録します。問い合わせ件数が減ったという成果は測るまで書きません。次の改定では、残っていた旧料金や更新が遅れた反映先を台帳へ追加します。同日反映の成否は「更新ボタンを押したか」ではなく、適用条件と申込時の金額が複数の接点で矛盾していないかで判断します。