Googleカレンダーと連携する予約システム 同期方向と二重予約の確認

店の予約と自分の予定を同じカレンダーで見たい。そんなときは、まず予定を表示したいのか、予定がある時間の予約受付も止めたいのかを決めましょう。この二つで、必要な連携が変わります。

たとえば、予約は見えているのに、カレンダーへ入れた外出予定が受付枠に反映されないことがあります。料金表の「連携あり」だけでは、どちらの動きを含むか分かりません。この記事では、プラン条件と予定の反映範囲をそろえて比較し、最後に試用時の点検表を用意しました。

カレンダーで見る予約と、受け付けない時間を分ける

予約システムからGoogleへ予定を送る連携は、予約を一覧するためのものです。Googleから予約システムへ予定を読み込む連携なら、会議や外出の時間を受付から外せるかが確認点になります。

STORES 予約は、予約をGoogleへ送る一方向の連携と、Googleの予定を予約不可時間として取り込む相互連携を別々に案内しています。公式の機能説明

図は判断のために作ったものです。実際の管理画面ではありません。

「双方向」という言葉も、Googleで予約時刻を動かせば顧客への連絡まで済む、という意味に広げないようにします。表示・空き枠・顧客への通知は、それぞれの仕様を読む必要があります。

5サービスの連携条件を照合する

下の表は料金の安さを並べたものではなく、必要な方向の連携を契約に含められるかを見る表です。反映に何秒かかるか、停止時に通知されるかは今回確定できていません。

根拠：STORESの機能ページ、RESERVAの料金表・連携の説明、SELECTTYPE公式ブログ、Squareの比較表、Airリザーブの比較表。

STORESはパッケージ契約と予約単品の契約があるため、上表のプラン名をそのまま別の契約へ当てはめないでください。相互連携を使うなら、その契約に含む予約プランとの対応を確認します。

RESERVAについても、機能ページの対象プラン一覧だけで「全プランで双方向」と判断しません。料金表には施設タイプ・エンタープライズ以上という条件があり、二つの記載を残したうえで、契約に適用する条件を確かめる必要があります。

開始時点の予約、休業日、取消を見落とさない

連携後の新しい予約が表示されても、以前から入っていた予約まで揃うとは限りません。STORESとSELECTTYPEは、連携する前に受け付けた予約をGoogleへ反映しないと案内しています。STORESの手順と注意事項／SELECTTYPEの連携条件

開始前には、翌週の予約を見比べる欄を用意しましょう。過去分を補う場合も、同じ予約を重複登録しないよう、どの画面を受付の基準にするか決めてから進めます。

終日予定には別の扱いがある

STORESの相互連携では、Googleの「終日」予定は予約不可時間に反映されません。ヘルプは、終日分を設定したい場合に0:00〜23:59という時間指定を案内しています。選んでいないカレンダーの予定も対象外です。公式の反映条件

休業日を終日で登録している店は、この条件を試用項目へ加えます。「Googleに休日が見える」ことと「予約ページで休日が選べない」ことを、二つの画面で確かめるためです。

取消後も予定が残る場合

STORESでは、キャンセル済み予約がGoogleから自動削除されない仕様です。非表示にしたい場合はGoogle側で手動削除する、と案内されています。取消後の公式FAQ

予定が残っているという表示上の事実から、予約システムの空き枠も閉じたままだとは判断できません。予約の状態、公開ページの残枠、スタッフの予定表示を別々に見ます。

変更する画面を店内で決めておく

担当者が複数いるなら、「電話予約を入れる人」「日時変更を受けた人」「Googleの予定を見る人」が違うこともあります。設定の前に、受付から取消までの作業場所をそろえておくと、試用で確認すべき動きが具体的になります。

以下は店内ルールを作るための記入例で、製品に共通する操作仕様ではありません。

予定名に顧客名や連絡先が表示される範囲も確認します。必要な人に必要な情報だけを渡せるかは、共有カレンダーを増やす前に見たい項目です。

連携を始める日を、予約が混在する期間として考える

新しい連携を有効にする日は、これまでの予約と連携後の予約が混在します。カレンダーに見えないから空いている、と判断する前に、予約システム側に残っている予約を照合します。公式が連携前の予約を反映しないと案内するサービスでは、この作業を省けません。

例えば月曜日に連携を始め、火曜日には以前受けた予約がある仮の店を考えます。火曜日の予定がGoogleに見えなくても、その予約が取り消されたわけではありません。予約側の一覧を基準に、どこまで表示を補うかを決めます。補った予定が別の連携から再び取り込まれる条件も、確認できるまで自動処理とみなしません。

同期が止まったときも同じ考え方を使います。再接続で停止中の予定が全部補われるかは製品仕様です。接続できたという表示と、予約内容がそろったことを別に点検します。

カレンダー名と予定の見せ方を決める

「仕事用のGoogleアカウント」とだけ記録すると、その中のどのカレンダーが対象か分からなくなることがあります。対象のカレンダー名、用途、共有する人を一覧にします。私用を空き枠判定に使いたい場合でも、スタッフ全員へ詳細を見せる必要があるかは別に考えます。

顧客名を予定名へ載せる連携なら、共有相手に何が見えるかも確認します。予定の表示権限と予約管理画面の権限が同じとは限りません。外部の協力者へ日程だけ渡す際は、連絡先や相談内容まで広げない設定が可能かを調べます。

Google側で動かしただけで、予約変更と案内が済むか

カレンダーで時刻を移せても、予約サービスの確定日時や顧客メールが変わるとは、この機能表からは判断できません。変更受付は店が決めた画面で行い、予約状態・公開枠・予定表示・通知の四つを追います。

逆に、予約側で取り消した後にGoogleへ予定が残る場合は、表示を消す担当を決めます。予定を残したままでも枠が戻るのか、別の取り込みによって閉じるのかは、使う組合せで照合する項目です。仕組みの名前より、店で実際に行う変更の順を記録しておくと、連携の範囲を見分けやすくなります。

試用で使う、同期方向と変更の点検表

次の表は未実施のテスト計画です。公開していないテスト枠と自分で管理するデータを使い、開始時刻・反映時刻・結果を記録する想定です。

反映が速かった一回だけで、常時の同期速度が保証されるわけではありません。公式に保証時間がない場合は、測定した条件と日時を残し、余裕が必要な運用かを考えます。

単純な面談受付なら、Google自身の予約スケジュールも確認先になります。Googleカレンダー内で予約ページを作る機能であり、外部の予約システムとの同期とは別です。Googleの公式作成ガイド

予定を読むだけで足りる店は一方向の連携を候補に残し、私用予定や設備の利用時間で受付を止めたい店は取り込み条件を比較します。最後は必要な操作を点検表へ書き、対象プランと組み合わせて判断しましょう。