Lステップのリマインド配信で予約変更・キャンセル時に確認したい送信条件

予約日を変更したのに、古い日時の案内が残っていないか気になる。
電話でキャンセルを受けたあと、LINEの通知まで確認できているか自信がない。
予約前のリマインドを用意していても、予定が変わったときには、別の確認が必要です。

最初に確かめたいのは、通知の文章よりも、どの予約機能と配信方式を使い、変更や取消がどの状態まで進んでいるかです。
同じLINEのトーク画面に届く案内でも、設定の場所や動き出す条件は同じとは限りません。
この記事では、Lステップの公式マニュアルで確認できる仕様と、店舗側で確認したい運用上のポイントを分けて説明します。
直前予約や複数予約の例は、実際の配信結果ではなく、確認漏れを見つけるための仮定です。
あなたのお店で、どこまで確認できていて、何を担当者へ引き継ぐ必要があるかを整理していきましょう。

予約を変更したら、まず通知方式と確定状態を確認する

予約変更と通知の関係を考えるには、使っている機能を見分けることが出発点です。
まず、自動で切り替わると確認できる範囲を押さえます。

カレンダー予約の自動切替は、紐づく専用リマインダの話

カレンダー予約で日時変更が成立すると、その予約に紐づく専用リマインダは、変更後の日程に自動で切り替わります。
ここでいう専用リマインダは、カレンダー予約の機能内で設定する、予約前の通知のことです。
公式FAQが説明しているのは、この組み合わせでの動作です。

一方、同じお客様へ別に設定した一般リマインダまで、同じように変更されると判断することはできません。
外部の予約サービスから連携させた通知も、この説明の対象ではありません。
まず予約の設定と、気になっている通知の設定を照合し、両者がどのような関係なのかを確かめましょう。

また、お客様から変更希望が届いたことと、予約日時の変更が成立したことは別です。
承認を必要とする運用なら、申請を受け取っただけの段階を、変更済みとして扱わないようにします。
自動切替の仕様を確認しても、取消後の別方式の通知まで止まると推測しないことが大切です。

一般リマインダ・予約時の通知・シナリオを混同しない

一般リマインダは、ゴールと呼ばれる基準日時から逆算して配信を組み立てる機能です。
シナリオ配信は開始を起点にするため、同じ時刻に届く設定でも、時刻を決める考え方が異なります。
一般リマインダは、配信内容を作成しただけでは開始しません。

予約に関係する通知では、カレンダー予約の専用リマインダ、イベント予約の専用リマインダ、別途開始する一般リマインダを分けて確認します。
さらに、受付や変更などをきっかけに処理を動かすアクションも、予約日時を基準に送る事前通知とは別の確認対象です。
カレンダー予約の専用設定には、予約日に対する時刻指定と、予約時刻までの残り時間での指定があります。

カレンダー予約は、変更・取消の申請と確定を分けて点検する

変更やキャンセルを受け付けたあと、何をもって完了とするかを揃えましょう。
申請の受付、予約の確定状態、通知の内容を順に確認します。

リクエストを受けた状態と、承認した状態は別

カレンダー予約で変更やキャンセルをリクエスト制にしている場合、管理者が承認するまでは確定していません。
リクエストは、管理者の判断を待つ申請と考えると分かりやすくなります。
受付担当が希望を把握していても、それだけで予約データが確定したことにはなりません。

Lステップには、申請時、承認時、否認時それぞれのアクション設定があります。
通常の予約変更時・キャンセル時のアクションとは区別されており、友だちによる変更やキャンセルをリクエスト制にした場合、それぞれに対応する通常のアクションは発動しません。
どの状態で使う通知なのかを、文面と一緒に確認しましょう。

たとえば、申請を受け付けただけの通知に、手続きが完了したような文章が入っていないかを点検します。
なお、承認待ちの間に専用リマインダが具体的にいつ送られるかは、今回確認した資料だけでは確定できません。
申請中なら旧日時の通知が止まる、と決めつけず、別途確認が必要な項目として残します。

変更後の予約データと、案内に表示する日時を照合する

変更が成立したら、予約詳細と操作履歴を使い、対象の予約、現在の日時、状態を確認します。
続いて、案内文のどこに日時が表示されるかを見比べましょう。
送信予定が新しい日程へ切り替わることと、文章のすべてが新しい内容になることは、同じ確認ではありません。

カレンダー予約内の該当するアクションやリマインダのテキストには、予約情報を差し込めます。
変更アクションでは、変更前と変更後の情報を選ぶことができます。
そのため、どちらの日時を伝える箇所なのかを区別して読むことが重要です。
手入力した日時、画像内の日付、別の案内文まで自動で修正されるとは考えないようにします。

説明用の仮定として、午前の予約を午後へ変更したケースを考えてみてください。
現在の予約日時に加え、文章中の集合時刻や場所、変更の連絡窓口も確認対象にすると、日時以外の食い違いにも目を向けられます。
これは運用上の点検提案であり、任意のテンプレートへ同じ予約情報を挿入できるという意味ではありません。

取消の記録だけで、別設定の通知まで止まったと判断しない

キャンセルを確認するときは、まず取消対象の予約と、関連する友だち、操作履歴を照合します。
名前が一致しているだけでなく、今回取り消したい予約の記録なのかを確かめることが先です。
取消と削除は別の操作なので、記録を消すことを取消手続きの代わりにしないようにしましょう。

管理者がカレンダー予約を取り消す際には、アクションを実行するかどうかの選択があります。
ただし、その選択だけで、専用リマインダや別途開始した一般リマインダの停止範囲まで説明できるわけではありません。
一般リマインダの開始・キャンセルと、遅延したテキストなどの送信直前の条件判定も、別のアクション設定です。
予約通知すべてに共通する一つの停止設定としてまとめないことが大切です。

運用上の目標は、取り消した予約の不要な案内を残さず、まだ有効な別予約の案内を維持することです。
この目標と、実際に確認できた動作は分けて記録します。
全通知が自動停止するとも、必ず残るとも断定せず、予約と通知の対応を確認しましょう。

イベント予約は、変更先の枠と承認状態を確認する

イベント予約では、カレンダー予約の説明をそのまま当てはめないことが重要です。
変更先の予約枠、承認状態、設定されたアクションを見分けます。

変更先の予約枠と、承認時のアクションを分ける

イベント予約の予約枠は、イベントで受け付ける日時などの単位です。
変更時に実行するアクションは、変更先の予約枠を基準にします。
移動前の枠だけを見ていると、変更後に関係する設定を確認したことにはならないため、どの枠へ移ったのかを先に整理しましょう。

また、承認制のイベント予約では、予約成功時や変更時のアクションと、承認時のアクションは異なります。
変更操作ができたことを、そのまま承認完了と読み替えないことが大切です。
専用リマインダは予約枠で設定し、承認制の場合は承認された人が発動対象になります。

点検では、変更先の枠、現在の承認状態、その状態に対応するアクションを一組として確認します。
そのうえで、事前通知の設定を別に見ていくと、確認の目的を混同せずに整理できます。
ここで確認した仕様から、変更前に関係したあらゆる通知が自動で整理されるとまでは判断できません。
気になる通知が別設定にある場合は、その設定を確認する必要があります。

枠とプランの重複設定、取消後の再予約を点検する

イベント予約では、予約枠とプランの両方にアクションを設定すると、両方が動きます。
ここでいうプランはイベント予約内の区分であり、Lステップの契約料金プランとは別の意味です。
同じ確認内容を両方へ設定している場合は、重複点検の対象として記録しておきましょう。

ただし、両方のアクションが動くことから、どの運用でも必ず同じメッセージが二通届くと一般化することはできません。
何の処理を設定しているかを確認し、異なる配信が一通にまとまる、決まった順序で届くといった未確認の動作も前提にしないようにします。

イベント予約には、友だちごとの予約回数を設定する機能もあります。
一回に制限していても、キャンセル後は再予約が可能になります。
その場合、以前の取消記録と、現在の有効な予約を別々に整理することをおすすめします。
再予約できるという仕様だけで、以前の通知と今回の通知の関係まで確認できたわけではありません。
再予約時の案内は、対象枠や状態と合わせて点検する項目として残しましょう。

リマインダの追加時期と、直前予約を分けて確認する

予約を受けてから通知を追加した場合と、通知予定の直前に予約が入った場合は、別の問題です。
設定を有効にした時刻と、予定していた配信時刻を分けて考えます。

予約後の有効化には、機能ごとの対象条件がある

カレンダー予約では、リマインダを有効にする前に入った予約には、その時点ではリマインダが発動しません。
一方で、有効化したあとにその予約が更新されると、発動するという例外が公式マニュアルに示されています。
既存予約には絶対に発動しない、という説明では、この条件が抜けてしまいます。

有効化とは、その予約機能でリマインダを使える設定にすることです。
点検するときは、予約を受けた時刻、有効化した時刻、その後に予約が更新されたかを分けて記録しましょう。
どの操作が更新に含まれるかを、資料で確認できていないまま一覧にしたり、通知を出す目的だけで実際の予約を変更したりすることは避けます。

イベント予約では、予約後にリマインダ設定を追加しても、すでに予約済みの友だちには発動しません。
カレンダー予約の更新後の例外を、イベント予約にも当てはめることはできません。
同じリマインダという名前でも、対象機能と設定時期を一緒に確認する必要があります。
設定を追加したという作業記録だけで、既存予約の全員への案内が準備できたと判断しないようにしましょう。

過ぎた予定時刻と、これから必要な案内を切り分ける

説明用の仮定として、当日の午前十時に、同日午後六時の予約を受けた場面を考えます。
事前通知の予定が前日の午後七時と当日の午後五時に置かれていたとしたら、受付時点ですでに過ぎた予定と、これから到来する予定が混在します。
この時刻は考え方を示す例であり、おすすめの配信頻度を示すものではありません。

確認項目は、受付直後の確認通知、過ぎた事前通知の予定、これからの事前通知の予定という三つに分けます。
過去の予定分が追って送られるのか、送られないのか、まとめて処理されるのかは、今回確認した資料の範囲では確定していません。
同じ時刻に複数の配信が重なった場合の順序も、推測で埋めないようにします。

同じ友だちの複数予約は、一件ずつ通知との対応を確かめる

一人のお客様に複数の予約がある場合は、誰の通知かだけでは判断できません。
どの予約に関係する通知なのかを、一件ずつ整理していきます。

友だちが同じでも、予約とリマインダは同じとは限らない

Lステップでは、一人の友だちに複数のリマインダを設定できます。
このため、友だちが同じという理由だけで、確認した通知がすべて同じ予約に対応していると考えないことが大切です。
予約日時、枠やコース、現在の状態、通知方式を見比べる材料として揃えましょう。

カレンダー予約内のアクションやリマインダには、その動作の対象となる予約枠・コースを条件にできる項目があります。
これは、過去にその枠を予約した人を探すこととは分けて扱います。
過去の利用履歴に当てはまることと、今回変更したい予約に関係することは、同じ意味ではありません。

ただし、枠やコースは、予約一件を必ず区別できる識別番号という意味ではありません。
日時や内容が似た予約もあり、照合項目だけで対象を確定できない場合は、担当者への確認が必要です。
また、複数のリマインダを設定できることから、同じ設定を異なるゴール日時で重ねて開始した場合の動作まで保証することはできません。
分からない対応関係を残したまま、一括した停止操作へ進まないようにしましょう。

予約Aを取消し、予約Bの案内は残すケースで考える

ここでは、同じ友だちに二つの予約があるという仮定で、取り消す側を予約A、継続する側を予約Bと呼びます。
AとBは説明のためのラベルであり、Lステップの画面に表示される予約IDではありません。
実際のお客様の情報を使った事例でもありません。

点検用のメモでは、予約Aと予約Bを別の行に分けます。
それぞれについて、予約を見分ける材料、現在の状態、関連する通知、期待する扱い、確認結果、確認者を記録すると、確認する対象を揃えられます。
予約Aには取消の記録と不要になる案内、予約Bには有効な予約と必要な案内を対応させる考え方です。

電話・店頭受付とGoogleカレンダーの編集を切り分ける

LINE以外で受けた連絡も、どの予約記録へ反映したかが大切です。
管理者が入力した予約と、外部カレンダーに表示された予定の確認点を分けます。

管理者予約では、名前入力と友だち選択は別

電話や店頭で受け付けた予約を管理者が入力するとき、名前を入力しただけでは、LINE上の友だちは選択されません。
名前の記入と、通知先になる友だちとの紐づけは別の確認です。
同じ名前が見えるからといって、送信先まで正しく設定されたと判断しないようにしましょう。

管理者によるカレンダー予約時のアクションを確認する場合は、友だちが選択されているか、アクション実行をどう選択したか、基本予約アクションの設定はどうなっているかを分けて見ます。
アクションを実行しないという選択から、専用リマインダも必ず停止すると結論づけることはできません。

受付担当と予約の入力担当が違う場合は、予約詳細や履歴で確認した対象と状態を引き継ぎ、誰が配信設定を確認するのかも決めておきます。
氏名だけの口頭連絡ではなく、今回の予約を照合できる材料を残すという運用提案です。
導入時の受付方法の整理については、関連するLINE予約システム導入のコラムでも扱っています。
本記事では、その後の変更・取消と通知の確認に絞って見ていきます。

Google側の変更・削除だけでは、Lステップの予約本体は直らない

LステップからGoogleカレンダーへ反映された予約は、Googleカレンダー側で変更・削除しても、Lステップの予約自体は変更・削除されません。
Google上で予定を直したことだけをもって、Lステップ側の予約や案内も修正済みと判断しないようにしましょう。

この説明は、Lステップから反映された予約をGoogle側で編集した場合の、特定の方向についての仕様です。
連携機能の全体を、完全な一方向連携や双方向連携と分類する説明ではありません。
他社の予約サービスにも同じ仕様が当てはまるという意味でもないため、利用中の組み合わせを確かめる必要があります。

電話で日時変更を受けたときは、今回の予約内容の基準にする記録、つまり正本をどこで管理するかを決めておきます。
さらに、その記録を更新する担当と、利用者向けの通知文を照合する担当を明らかにしましょう。
カレンダーに新しい予定が見えていることと、予約データ・通知の条件・案内文が揃ったことは別です。
どこを確認したかを具体的に残すと、次の担当者も未確認の箇所を引き継げます。

設定を変える前に、予約・送信条件・案内文を一緒に照合する

ここまでの確認点を、実際の点検に使える形へまとめます。
試験を計画した段階と、実際に結果を確かめた段階は、分けて記録しましょう。

七つの場面で、期待結果と確認結果を分けて記録する

以下は、担当者が確認計画を作るためのチェックリストです。
本記事の制作で実施した試験ではなく、すべて未実施の検証案として示しています。
実際に確認する際は、権限のある担当者と、実顧客に影響を与えない検証条件を先に決めてください。

• 日時変更が成立した場面：対象予約と専用リマインダ、案内文中の新旧日時を照合します。
• 申請・承認・否認の場面：予約の状態と、その状態に対応する通知の意味を確認します。
• 複数予約のうち一件を取り消す場面：不要になる通知と、残したい別予約の通知を分けます。
• 直前に受け付けた場面：受付時刻、過ぎた通知予定、これからの予定を並べます。
• 有効化前に受けた予約の場面：対象機能、有効化時刻、予約更新の有無を記録します。
• 管理者予約やGoogle側編集の場面：友だちとの紐づけと、予約本体への反映を確認します。
• イベントの枠変更・再予約の場面：変更先の枠、承認状態、関連アクションを照合します。

各項目に期待結果と確認結果の欄を設け、確認担当も残しましょう。
未確認の挙動を予想で埋めず、追加確認が必要な点として扱うことが、この点検の基本です。

プレビュー確認と実配信の確認を分け、担当者を決める

一般リマインダでは、手動で開始する前に配信予定日時をプレビューできます。
また、友だち詳細のタイムラインでは、設定中のリマインダを確認できます。
ただし、これを予約専用リマインダも含めた全通知の待機一覧とみなすことはできません。
対象の機能について、何が表示されているのかを確認する必要があります。

プレビューは予定の表示であり、実際に受信したこととは別です。
画面上で予定時刻が合っていても、変更・取消との連動や、実配信まで確認できたことにはなりません。
日常の設定点検で分かることと、別途、安全な条件で観測が必要なことを分けておきましょう。

そのうえで、受付、予約の更新、承認、配信確認という役割を整理します。
小さなお店で一人が兼務する場合も、確認項目を分けて記録すれば、どこまで対応したかを見直せます。
確認できない項目があるときは、対象の機能名と状態、調べた資料、残る疑問を添えて担当者へ引き継ぎましょう。
プレビューだけを根拠に、本番の送信結果まで保証しないことが大切です。

自分で切り分けにくい部分は、現在の運用を整理して相談する

最初から配信を作り直す必要があると決めつけず、まずは利用中の機能名と、困っている予約パターンを書き出してみてください。
日時変更なのか、取消なのか、直前受付なのかによって、見比べる条件は変わります。
確認できたことと、まだ分からないことを分けるだけでも、次に調べる対象が明確になります。

それでも整理しきれない場合は、studio-THのIT集客に関する無料相談をご活用ください。
どの予約機能を使い、どの場面の案内に困っているのかを整理しておくと、相談したい点を伝えやすくなります。
相談のために、実際のお客様の予約情報や、ログイン情報をここで用意する必要はありません。

大切なのは、予約の記録だけ、通知の設定だけ、文章だけを別々に見て終わらせないことです。
三つを同じ予約に対応させ、未確認の箇所を残さず把握するところから、現在の運用を点検していきましょう。