mise.
店舗運営ノウハウ

「予約したつもりが、できてなかった」を避けるLINE予約テスト

2026-06-29 ・ 著: Currents編集部

LINEで予約を受けられるようにすると、お店側はかなり楽になる。

お客さんは、いつものLINEで問い合わせできる。お店は、電話やDMのやりとりを減らせる。イベント名、人数、名前、電話番号を順番に聞いて、最後に予約として残せればいい。

LINE予約の説明用モック画面。実際の予約情報ではなく、人数選択と確認の流れを見せるサンプル。
LINE予約の説明用モック画面。実際の予約情報ではなく、人数選択と確認の流れを見せるサンプル。

ただ、ここで一番怖いのは「動かないこと」ではなかった。

本当に怖いのは、お客さんが予約できたと思っているのに、実際には予約台帳に入っていないことだった。

LINEの会話が進むだけでは、予約完了とは言えない

LINE予約を作るとき、最初に見たくなるのは会話の流れだ。

イベントを選べるか。人数を聞けるか。名前を聞けるか。電話番号を聞けるか。最後に「予約を受け付けました」と返せるか。

ここまで動くと、なんとなく完成したように見える。

でも、会話が進むことと、予約が本当に入ることは別である。

予約で大事なのは、最後に台帳へ書き込めているかだ。台帳というのは、たとえばスプレッドシートや予約管理用のデータである。そこに記録されてはじめて、お店側があとから確認できる。

もしLINEだけが「予約完了」と返して、裏側の台帳への書き込みに失敗していたら、お客さんは予約したつもりで来てしまう。お店側には記録がない。これはかなり困る。

だから、LINE予約のテストでは「返事が来るか」だけを見てはいけない。

LINEの会話、予約API、予約台帳、完了返信を分けて確認する。台帳に書けた後だけ予約完了にする。
LINEの会話、予約API、予約台帳、完了返信を分けて確認する。台帳に書けた後だけ予約完了にする。

テストは4つに分けたほうがいい

今回わかったのは、LINE予約の確認はひとまとめにしないほうがいい、ということだった。

少なくとも、次の4つに分けて見る。

部品テストでは、LINEの返事や画面の流れを見る。ここでは偽物の予約APIを使ってもよい。まず会話の順番が壊れていないかを確認するためだ。

でも、偽物APIで動いたからといって、本物のスプレッドシート連携まで保証されたわけではない。

本物の台帳へ書き込むところは、結合テストで見る必要がある。ここを分けておかないと、「ローカルでは動いた」が「本番でも予約できる」と誤解されやすい。

残席不足は、最後だけでなく途中でも止めたい

もうひとつ大事だったのが、残席の扱いだ。

たとえば、残り1席のイベントに2名で申し込もうとした場合。最後の確定時に「残席が足りません」と止めるだけでも、最低限の事故は防げる。

でも、お客さんの体験としては少し遅い。

人数を選ぶ時点で、残り1席なら1名までしか選べないようにしたほうが親切だ。手入力で2名と送られた場合も、その時点で「残り1席のため、2名では予約できません」と返す。

つまり、残席チェックは一度だけではなく、複数の場所で見る。

最後の確認だけに頼ると、お客さんは途中まで進んでから断られる。早めに止められるところは、早めに止めたほうがいい。

実際のテストでも、残席2名の公演に4名で進もうとしたときは、予約完了にせず、理由を返して受付中の候補を出し直す流れを確認した。

残席2名の公演に4名で進もうとしたとき、予約を完了せず、残席不足の理由と受付中の候補を返しているLINE予約テスト画面。
残席2名の公演に4名で進もうとしたとき、予約を完了せず、残席不足の理由と受付中の候補を返しているLINE予約テスト画面。

台帳に書けた後だけ「予約完了」と返す

LINE予約で一番大事なルールは、これだと思う。

台帳に書き込めた後だけ、予約完了と返す。

スプレッドシートが落ちている。権限が切れている。予約APIが失敗した。残席が足りない。こういうときに、LINEが先に「予約できました」と言ってはいけない。

失敗したら、失敗として返す。

お客さんに見せる文面はやさしくていい。「申し訳ありません、予約を確定できませんでした。お店へ直接お問い合わせください」のような言い方でいい。

でも、内部の扱いとしてははっきり分ける。

ここを曖昧にすると、「お客さんは予約したつもり、お店は受けていない」という一番避けたい状態になる。

「動いた」の意味を分けておく

AIで実装すると、画面や会話の流れはかなり早く作れる。

だからこそ、「動いた」という言葉を分けておいたほうがいい。

LINEの返事が動いた。これは会話の確認。

予約APIが動いた。これは裏側の処理の確認。

台帳に書けた。これは予約記録の確認。

満席や残席不足で止まった。これは事故防止の確認。

公開後に失敗が出ていない。これは運用の確認。

全部をまとめて「動いた」と呼ぶと、見落としが起きる。

LINE予約は、お客さんがその場で返事を信じる仕組みである。だから、見た目の会話よりも、予約として本当に成立しているかを大事にしたい。

「予約したつもりが、できてなかった」を避ける。

そのためのテストは、会話の確認だけでは足りない。残席、台帳、失敗時の返事まで見て、はじめて安心して出せる。

この記事は、作業ログと現場メモをもとにCurrentsのAI社員が下書きし、編集部が確認して公開しています。
← 事例一覧へ