予約リマインドのLINE通知を、予約システムを乗り換えずに足す方法｜予約データを書き出して通知だけ自動化する構成と、二重送信を止めるキーの決め方

前日にリマインドを送るようになってから無断キャンセルが減った、という話は美容室でもよく聞きます。ところが実際に入れようとすると、たいてい同じところで止まります。「今使っている予約システムにリマインド機能がない」「機能のあるシステムに乗り換えるとなると、予約台帳をまるごと移すことになる」——ここで話が大きくなり、結局やらないまま終わる。

先に結論を書きます。

予約システムは今のまま一切触らず、通知だけを別の小さな仕組みとして横に足すのが正解です。 予約台帳から予約データを書き出し、それを読み取って「前日のリマインド」と「来店後のお礼」の2種類だけをLINEで送る。予約の作成・変更・キャンセルには一切書き込まない読み取り専用の片方向にします。

この形なら、既存の予約フローもスタッフの操作も何ひとつ変わりません。うまくいかなかったときも、通知側を止めるだけで元に戻ります。

この記事で扱うのは次の4点です。

1. 双方向につなごうとすると何が壊れるか（避けるべき構成）
2. 読み取り専用で作るときの部品の並び
3. 同じ人に同じ通知が二度飛ぶのを止めるキーの決め方
4. 実際にいちばん時間を食う「顧客とLINEの紐付け」

弊社graciautoは名古屋でホームページ制作とLINE公式アカウント構築を手掛けており、美容サロンのフランチャイズ本部と各店舗の運用を支援しています。この記事は、支援先の1店舗へ実際に導入して稼働させた通知ツールの設計と、その本番予約データで実測した数字をもとに書いています。店名・個人名は伏せています。

—

予約システムに「書き込む」構成にしない

まず避けるべき構成から片付けます。

LINEから予約を受けて既存の予約システムに書き込む、あるいは両方の予約枠を常に同期させる——という双方向の構成は、リマインドを送りたいだけなら割に合いません。 理由は3つあります。

1つ目は二重予約です。 予約サイト側と自社側の2か所で枠を持つと、同じ時間に2件入る事故が必ず出ます。書き出したデータを取り込む方式では、取り込んだ時点の予約しか分かりません。リアルタイムの空き枠の同期には原理的に足りないので、予約の受付そのものを分けてはいけません。

2つ目は、予約サイトの管理画面を自動操作する方式のリスクです。 画面を機械に操作させて予約を書き込む作りは、規約上の扱いが曖昧なうえ、画面の仕様変更で無言で壊れます。さらに店舗のIDとパスワードを預かることになり、事故が起きたときの責任範囲が一気に重くなります。支援先での実装でも、この方式は最初から作らない方針で設計しました。

3つ目は、戻せなくなることです。 予約台帳を移してしまうと、通知の調子が悪いからといって簡単には戻せません。読み取り専用なら、止めれば終わりです。

予約台帳は既存システムを正本のままにする。新しく作るのは通知だけ。 この線引きを最初に引いておくと、以降の設計判断がほぼ自動的に決まります。

—

部品は4つだけ

読み取り専用で組む場合、必要な部品は次の4つです。

部品	やること	判断のポイント
①書き出し	予約台帳から予約一覧を出す	1日1回・営業終了後の手動で十分
②取り込み	ファイルを読んで予約と顧客を登録	表記の揺れを正規化して未知の値は対象外へ
③紐付け	顧客とLINEの友だちを結ぶ	ここがいちばん時間を食う
④送信	対象を一覧で確認して送る	送信は人がボタンを押す2ステップ

①を自動取得にしたい気持ちは分かりますが、最初は手動アップロードで始めるほうが早く動き、壊れません。 1日1回、閉店後にファイルを出して管理画面に上げるだけです。実際に導入した店舗もこの運用で回っています。自動取得は、運用が定着してから必要性を判断すれば十分間に合います。

—

送る通知は2種類に絞る

欲張ると必ず事故ります。最初は次の2種類だけにします。

前日リマインド＝来店日が翌日・予約が有効・LINE連携済み・まだ送っていない、の4条件をすべて満たすものだけ。

来店後のお礼＝今回の取り込みで初めて「会計済み」に変わった予約だけ。

2つ目の条件の書き方が重要です。「予約の終了予定時刻を過ぎたら送る」という判定にすると、来なかったお客様にお礼が飛びます。 無断キャンセルや当日キャンセルの方に「本日はありがとうございました」と送るのは、販促以前に信用を落とします。

だから判定は時刻ではなく、台帳側のステータスが会計済みに変わったことを使います。来店したかどうかを知っているのは予約システムであって、こちら側の時計ではありません。加えて「来店から48時間以内」の上限も付けておくと、過去分をさかのぼって送ってしまう経路をもう一段塞げます。

—

二重送信を止めるキーは「店舗・予約番号・種別」の3点

同じ通知が二度飛ぶのは、リマインド系でいちばん起きやすく、いちばん嫌われる事故です。取り込みをやり直した、画面を二度押した、時間をおいて再実行した——原因はいくらでもあります。

対策は運用の注意ではなく、データベース側の制約で止めます。送信記録のテーブルに、次の3点の組み合わせで重複を許さない制約を付けます。

（店舗ID、予約番号、通知の種別）

この3点の理由です。

• 予約番号：予約1件を一意に指すのは予約番号だけです。「顧客ID＋来店日」でまとめると、同じ日に2回来る、あるいは同じ日に別メニューで2件取っている場合に、片方が送れなくなります
• 種別：リマインドとお礼は同じ予約に対して1通ずつ送ります。種別を入れないと、リマインドを送った時点でお礼が送れなくなります
• 店舗ID：1店舗で始めるとしても入れておきます。予約番号は店舗をまたぐと重複しうるため、あとから2店舗目を足したときに別店舗の送信済み記録とぶつかります。最初から列だけ持たせておけば、拡張時にデータを作り直さずに済みます

制約さえ効いていれば、送信処理を二度叩いても2通目は「送信済みのためスキップ」として記録に残るだけです。実装後の検証でも、同じ送信をもう一度実行して2通目が止まることを実地で確認してから本番に上げました。「二度押さないよう気をつける」で運用してはいけません。

もう1点、初回の取り込みだけは特別扱いにします。何も入っていないデータベースに過去1か月分の予約を入れると、過去の会計済み予約が全部「お礼が未送信」に見えます。初回は取り込むが送信候補にしないモードを既定にしてください。ここは事故の規模が大きい割に対処が簡単な場所です。

ただし全部を塞ぐと、導入初日にテスト送信ができず、翌日の予約にも送れない状態になります。実際の運用では、お礼は初回取り込み分を全件塞ぎ、リマインドは明日以降の予約だけ残す、という分け方に落ち着きました。初回時点では誰もLINE連携していないので、勝手に飛ぶ危険はありません。

—

本当のボトルネックは「誰に送るか」

設計の山場はここです。予約データとLINEの友だちは、自動では絶対に一致しません。

予約台帳にあるのは氏名・カナ・電話番号。LINE側にあるのはLINEのユーザーIDと表示名です。表示名は本名とは限りません。両者を結ぶのは人の作業になります。

まず、作業量の見積もりから。支援先の実データで測ったところ、107件の予約は60人の顧客に寄りました。 内訳は1回来店27人・2回21人・3回10人・4回2人です。つまり予約100件に対して、紐付ける相手は60人程度。リピーターが多い業態ほどこの比率は下がります。導入前にこの数字を出しておくと、「やれる作業量かどうか」を感覚ではなく人数で判断できます。

照合に使うキーは、次の優先順位で見ます。

1. 顧客番号（店舗の設定次第で全件空のことがある。実測した2本のファイルはどちらも全件空でした）
2. 予約時の電話番号
3. 顧客マスター側の電話番号
4. 氏名カナの一致

電話番号を唯一のキーにすると危険です。 別々の時期に出した2本のデータで、電話番号の入り方が正反対でした。

実測データ	電話予約	予約サイト経由
298件のファイル	243件すべて空	55件すべて入っている
107件のファイル	82件中74件（90%）入っている	25件すべて入っている

電話番号が入るかどうかは、店舗の入力運用で決まります。 片方のデータだけを見て「電話予約には番号が入らない」と設計すると、別の店で前提が崩れます。

そしてもう1つ、電話番号が一致しても同一人物と決めてはいけません。 実データで、同じ電話番号に複数の氏名が付いている組み合わせが5件ありました。今回は全部が空白の有無だけの表記ゆれでしたが、家族で固定電話を共有していれば、別人が1人に統合されます。 その状態で通知を送れば、娘さんの予約情報が母親のLINEに届きます。

なので、機械が確定してよい範囲を狭く切ります。

• 電話番号が一致しても、姓が違えば「要確認」に落として人が見る（姓を切り出せない表記は判定しない。そうしないと要確認が増えすぎて誰も見なくなります）
• カナの一致だけの相手は、スタッフが「本人確認済み」を押すまで配信対象にしない

実データで検証したところ、このガードを入れても要確認は4人のままで増えませんでした。安全側に倒しても、現場の手間はほとんど増えないということです。

紐付けの入口は、会計時にQRコードで友だち追加してもらい、その日の夜、取り込みのついでに表示名と当日の来店者を突き合わせる——という運用が現実的です。まとめて一気に60人を結ぼうとせず、来店のたびに1人ずつ増やしていきます。

なお、電話番号は平文で持たないでください。照合に必要なのは「一致するかどうか」だけなので、不可逆に変換した値と下4桁だけを保存すれば足ります。万一の漏洩時の被害が根本的に変わります。

—

予約データを読むときに壊れやすい場所

書き出したファイルは、見た目より癖があります。実測で確認したものを挙げます。

列名で取ると壊れます。 実際のファイルは59列あり、「開始時間」「終了時間」「電話番号」「性別」といった同じ列名が複数回出てきます。予約時の情報と顧客マスターの情報がそれぞれ入っているためで、列名で拾うとどちらを取ったのか分かりません。列の位置で読み、列数と並びが想定どおりかを取り込み時に検証します。

日付と時刻は文字列で扱います。 来店日が「20260913」、時刻が「0930」のような形式のとき、数値として読むと先頭のゼロが消えて「930」になります。 こうなると時・分の切り出し位置がずれるため、表示が崩れるか、そもそも時刻として解釈できなくなります。リマインドの本文に入るのは来店時刻そのものなので、ここが崩れるとお客様の来店時間に直結します。

ステータスの表記は時期で変わります。 同じ予約システムから出したファイルでも、ある時期は「済み」、別の時期は「会計済み」でした。文字列を実装に直書きすると、表記が変わった日から無言で送信が止まります。

対策は同じ形になります。ステータスの対応表を設定として外に出し、知らない値が来たら「配信対象外＋警告」に落とす。 知らない値を勝手に有効扱いすると誤送信、無視すると無言の停止です。警告として見えるようにするのが唯一の正解です。

—

安全スイッチは1か所にまとめる

最後に、運用開始の直前でつまずきやすい点を1つ。

送信を伴うツールには「実際には送らないモード（ドライラン）」を必ず付けます。このとき、設定ファイルと管理画面の2か所にスイッチを置いてはいけません。

どちらか一方が優先される実装になると、画面でオフにしても切り替わらない——という状態になります。しかも画面には理由が出ないので、触っている人には「壊れている」としか見えません。

正しい形は、実行時に見る設定は1か所だけにすることです。設定ファイルの値は「初期値」としてのみ使い、稼働後の判定は画面の設定だけを見る。そして画面には「今どちらのモードか」だけでなく「なぜそのモードか」を表示します。これが無いと、原因にたどり着けません。

あわせて、送信は一覧で対象を確認してから人がボタンを押す2ステップにしておきます。無人で自動送信にするのは、運用が数週間安定してからで遅くありません。通知は取り消せないので、最初の設計は「送りすぎない側」に倒します。

—

まとめ

• 予約台帳は既存システムのまま。通知だけを読み取り専用で横に足す。 予約の書き込みも枠の同期もしない
• 送るのは前日リマインドと来店後のお礼の2種類だけ。お礼は時刻ではなくステータスが会計済みに変わったことで判定する
• 二重送信は（店舗ID、予約番号、種別）の組み合わせをデータベース側で重複禁止にして止める。運用の注意で守らない
• 初回の取り込みは取り込むが送らないモードを既定にする
• 紐付けが本当の作業量。100件の予約でも相手は60人程度。電話番号一致でも姓が違えば人が確認、カナ一致だけでは配信対象にしない
• 列名・日付の先頭ゼロ・ステータス表記の3点は実データで必ず検証する

実際にこの構成で1店舗に導入したときは、初日の取り込みが42件、顧客40人、そこから紐付けの済んだ1人へリマインドを1通送るところから始まりました。通知は「全員に一斉に送るもの」ではなく、紐付いた人から順に増えていくものです。予約システムを乗り換えないと決めれば、その1通目は今週のうちに出せます。

LINE公式アカウントの運用設計や、店舗の予約・顧客データを使った仕組みづくりでお困りでしたら、お気軽にご相談ください。