LINEで予約・申込を受ける｜標準機能の限界

予約と申込は、LINEの出口のほとんどを占めます。そしてここで最も多い失敗は、作りすぎることです。 Lステップ・エルメの回答フォームで受けられるものを、わざわざ開発する。逆に、標準では受けられないものを無理にフォームに詰め込んで、離脱と手作業を増やす。どちらも、境目を知らないまま決めた結果です。 この章は、標準機能でできること／できないことを表で確定させ、「作らなくてよい範囲」をここで切り、9章（LIFF）に進んでよいかを10項目で判定するための章です。

この章で分かること

• LINEで受けてよい申込と、受けてはいけない申込の線引き
• 標準のフォーム・予約機能でできること／できないことの一覧（ここが本章の中心）
• 外部の予約サービスに飛ばしたときに起きること、決済の扱い、10項目の点検リスト

まず、LINEで受けてよい申込かを決める

申込には、LINEで受けたほうが良いものと、受けてはいけないものがあります。

LINEで受けてよい	LINEで受けない
予約（日時と人数を決めるだけのもの）	契約書の締結が必要なもの
来店予約・見学の申込	本人確認書類の提出が必要なもの
資料請求・イベント参加	健康・診療に関する詳しい内容（配慮が必要な情報）
再注文（前回と同じものをもう一度）	支払い情報そのもの（カード番号・口座番号）
簡単な見積もり依頼・相談の予約	入力項目が20を超える申請

右側に共通するのは、申込の内容よりも、預かる責任のほうが大きいことです。これらはLINEを入口にするのは構いませんが、受ける場所は、保存場所と保存期間と削除の手順が決まっている場所にしてください。専用のフォーム、既存のシステム、または要件を決めて作ったLIFF（9章）です。

標準機能でできること／できないこと

ここがこの章の本体です。Lステップ・エルメには回答フォーム（アンケート）の機能があり、提供元によっては予約の機能もあります。 どの機能がどのプランに含まれるかは提供元の機能ページで確認してください（プランの金額と上限はここには書きません）。

できること／できないことの境目は、おおよそ共通しています。

やりたいこと	標準のフォーム・予約機能	補足
名前・電話・希望日時などを入力してもらう	○	基本の用途。ここで足りるなら作らない
回答した内容を、その友だちの情報・タグとして残す	○	誰が申し込んだかが結びつく（後述）
回答した人に自動で完了メッセージを送る	○
担当者に通知を飛ばす	○	通知先の種類は提供元の機能ページで確認
回答内容でタグを分岐させ、次の配信を変える	○	配信は変えられる
指定した日時にリマインドを送る	○	出来事に紐づく配信（2章のC）
選択肢を、質問の答えによって出し分ける	△	提供元により可否と範囲が違う。実機で確認が必要
入力内容によって、次に出す画面そのものを変える	×	画面を作る仕組みがない
空き状況・在庫・残数を、今の値で見せる	×	外部の最新情報を画面に出せない
その人の過去の履歴・書類を見せる	×	個人ごとの内容を呼び出して表示できない
開くたびに変わるもの（会員証・ポイント）を出す	×	静的な画像しか置けない
社内システムに問い合わせて、その場で答えを返す	×	外部システムと対話できない
申込内容を社内システムに自動で入れる	△	外部連携の機能があるかは提供元による。無ければ手作業か開発
決済をその場で受ける	△	決済連携機能の有無は提供元による。決済は別契約（後述）

○と×の間にある△が、最も事故が起きるところです。 「できるはず」で設計し、作る段階で「このツールではできない」と分かると、設計をやり直すことになります。△は必ず、契約前にテスト環境か提供元への確認で潰してください。

項目は7つ以内。これが最初の関門

標準のフォームで受けるなら、入力項目は7つ以内にしてください。当社の決めごとで、理由は2つです。

• スマホの画面で、スクロールせずに全体が見える範囲がおおよそここまでです。長いフォームは、途中で閉じられます
• 8つ以上必要になる申込は、たいてい途中で分岐が要る（この答えならこれを聞く、という構造がある）ものです。分岐が要るなら、標準のフォームでは無理が出ます

項目を減らす方法は3つあります。

減らし方	例
後で聞く	詳細は予約確定後の確認連絡で聞く。予約の時点では日時と人数と連絡先だけ
選ばせる	自由記述をやめて選択肢にする。入力の手間も、こちらの読み取りの手間も減る
すでに持っている情報を聞かない	友だち情報に入っている項目は、もう一度聞かない

3つ目ができるのがLINEの利点です。メールのフォームと違い、送信した人が「どの友だちか」が分かるので、2回目以降は聞かずに済みます。

「誰が申し込んだか」が結びつくことが、LINEで受ける最大の理由

外部のフォームで受けると、届くのは「山田太郎さん・090-…」という文字列だけです。それがどの友だちかは分かりません。だから、

• 申込をした人だけ、その後の配信を変えることができない
• 申込をした人に、ステップ配信の残りが届き続ける（4章の必須項目8）
• 入口別に「どの入口の友だちが申し込んだか」が数えられない（11章）

標準のフォームで受ければ、この3つが同時に解決します。ただし、設定して終わりにせず、必ずテストしてください。 自分のスマホから友だち追加し、実際に送信し、自分の友だち情報に回答が入り、タグが付いていることを管理画面で確認する。これが点検リストの4番です。

完了通知は、本人と担当者の両方に

片方だけの設計が非常に多く見られます。

届く先	入れる内容	抜けたときに起きること
本人	受け付けた内容（日時・人数）、次に何があるか、変更・キャンセルの方法	「送れたのか分からない」で、同じ申込が二重に届く
担当者	申込の内容と、誰から（友だちの表示名）	気づかれず放置される。予約の日に誰も準備していない

本人への通知に変更・キャンセルの方法を入れておくと、後のチャット対応が減ります。「キャンセルしたいのですが」という1対1のやり取りが、そのまま人件費だからです。

変更・キャンセル・リマインドの回し方

申込を受ける設計で、作る前に必ず決めるのがここです。受けるところだけ作って、変更とキャンセルを決めていないのが、標準フォームで受ける場合の典型的な抜けです。

場面	標準フォームでの現実的な回し方
変更	「変更用のフォーム」を別に用意するか、チャットで受ける。フォームの再送信で上書きはできないと考えておく
キャンセル	リッチメニューかリマインドの文中に、キャンセル用の導線を1つ置く。受けたら担当が台帳を直す
リマインド	申込のタグが付いた人に、前日・当日などのタイミングで自動配信（2章のC）

変更とキャンセルが手作業になるのが、標準フォームの実質的な上限です。件数が少ないうちは問題ありません。月に何件その作業が発生しているかを数えてください。 その件数が、9章に進むかどうかの判断材料になります。

外部の予約サービスに飛ばすとどうなるか

LINEから外部の予約サイトへリンクで飛ばす設計は、最も手早く、最も多く使われています。悪い方法ではありません。ただし、何が起きるかを知ったうえで選んでください。

起きること	なぜ
ブラウザが開く	LINEのトークから離れる。戻ってくる操作は自分でする必要がある
ログインや会員登録を求められることがある	予約サービス側の仕様。ここが最も止まりやすい
氏名・電話を打ち直す	LINE側に情報があっても渡らない
誰が予約したか分からない	予約サービスの中の「山田太郎」と、LINEの友だちが結びつかない
その後の配信を変えられない	予約済みかどうかがLINE側で分からないので、予約した人に予約の案内が届き続ける

「何割が離脱するか」は、業種でもサービスでも違うので、ここには書きません。自分で測ってください。 測り方は2つの数字を並べるだけです。

リッチメニュー（または配信）のタップ数 ÷ 予約サービス側の完了数。この2つの差が、離脱です。

タップ数はLINE側の分析画面、完了数は予約サービス側の管理画面で出ます。両方を同じ月で並べて1行にする。 これをしていないと、「外部に飛ばしているせいで減っているのか」が永久に分かりません。点検リストの8番です。

外部に飛ばしたままでよい場合

• 予約サービス側で会員として管理していて、そちらが正本になっている
• 月の予約件数が少なく、手作業の転記が負担になっていない
• 測った結果、完了数がタップ数に対して十分に出ている

測ってから判断してください。 測る前に作り直すのは、直す場所を決めないまま費用を使うことです。

決済の扱い

決済は、LINEの機能の話ではなく決済事業者との契約の話です。ここを混ぜると判断を誤ります。

方法	実際に決めること
決済しない（現地・後払い・請求書）	最も簡単。まずこれで始められないかを先に検討する
外部の決済サービスのリンクを送る	決済事業者との契約・審査が必要。手数料が発生する
ツールの決済連携機能を使う	機能の有無は提供元の機能ページで確認。結局、決済事業者との契約は別に要る
LIFFの中で決済まで通す（9章）	上と同じく決済事業者の契約が前提。加えて開発と、扱う情報の設計が必要

どの方法でも、カード番号そのものを自社のLINEやツールの中に置くことはありません。 決済事業者の画面で入力してもらい、こちらは「決済が終わったかどうか」だけを受け取る形になります。

そして、LINEで決済まで通す必要があるかは、商材で決まります。 予約時に前金が要る商売（キャンセルが痛い業種）では効きますが、そうでなければ決済は後工程に置いたほうが、離脱も、扱う責任も減ります。

受けた内容を、誰がどこに写すか

申込を受けた後の転記は、静かに一番時間を食います。しかも増えても請求が来ないので気づきません（7章のチャットと同じ構造です）。

決めることは3つです。

1. 正本はどこか（LINE側の友だち情報か、顧客管理か、予約システムか。同じ情報を両方で編集しない）
2. 誰が写すか、または自動で入るか
3. 手作業が残るなら、月に何件・何分かを数える

3つ目を数えていないと、自動化すべきかの判断ができません。「面倒だから自動化したい」では見積もりも取れませんが、「月60件・1件3分・合計3時間」なら判断できます。 連携の設計そのものは10章で扱います。

個人情報の保存場所と保存期間

申込を受けるということは、個人情報を預かるということです。作る前に、次の3つを書いてください。

決めること	書き方の例
何を持つか	氏名・電話番号・希望日時。住所は持たない
どこに置くか	顧客管理（kintone）が正本。LINE側には友だちの識別と予約済みのタグだけ
いつまで置くか	来店から1年。過ぎたものは毎年3月に削除

LINE側に個人情報を多く持たせないでください。 ツールを乗り換えるとき（12章）に移せるとは限らず、削除の手順も自社でコントロールしにくくなります。識別子と、氏名・連絡先は分けて持つのが基本の形です（10章）。

「作らなくてよい範囲」をここで確定させる

この章の目的は、9章に進む人を減らすことです。次の条件をすべて満たすなら、作らないでください。

• 入力項目が7つ以内で、出し分けが要らない
• 空き状況・在庫・履歴を見せる必要がない
• 申込の件数が少なく、変更・キャンセル・転記の手作業が負担になっていない
• 外部サイトに飛ばしているなら、完了数を測ったうえで問題が出ていない

この4つが揃っているのに開発するのは、費用の使いどころとして間違っています。 標準のフォームで受け、浮いた予算は配信の設計（4章・6章）と入口（2章）に回したほうが、出口の件数は伸びます。

逆に、次のどれかに当たるなら、標準機能の上限です。次の章に進んでください。

当たったもの	何が足りないか
項目が8つ以上／分岐が要る	画面を出し分ける仕組みが無い
空き状況・在庫・残数を見せたい	今の値を画面に出せない
その人の履歴・書類を見せたい	個人ごとの内容を呼び出せない
会員証・ポイントを出したい	静的な画像しか置けない
社内システムの情報をその場で確認させたい	外部システムと対話できない

よくある誤解を3つだけ

「予約はLINEで完結させたほうが必ず良い」 ——完結させる価値があるのは、離脱が実際に起きているときだけです。すでに外部の予約サービスが回っていて、完了数も出ていて、会員管理もそちらが正本なら、無理にLINEに寄せる理由はありません。測ってから決めてください。 測っていない状態で「LINEで完結」を目指すのは、根拠のない作り替えです。

「フォームの項目を増やしておけば、後で使える」 ——使いません。増えるのは離脱と、読まれない自由記述です。聞いてよいのは、その申込を成立させるために今すぐ必要な項目だけです。残りは、予約が確定した後の確認連絡で聞けます。そのときのほうが相手も答えます。

「標準のフォームは簡易版で、本当はLIFFのほうが良い」 ——違います。役割が別です。標準のフォームは入力を受けて、その人の情報として残すためのもので、この用途では速く、安く、直すのも簡単です。LIFFが必要になるのは、入力ではなく「見せる」「つなぐ」が入ったときです。用途が違うので、上下ではありません。

この章の出口

この章を終えたとき、手元に残っているべきものは次の3つです。

1. 受ける申込の名前と、入力項目の一覧（7つ以内か、超えているか）
2. 点検リスト10項目のうち、必須の2・6・9が○（全体で8つ以上）
3. 「作らない」か「9章に進む」かの結論が1行（進むなら、5つの兆候のどれに当たったかを番号で書いてある）

3つ目が、次の章の入口そのものです。当たった兆候が1つも書けないなら、この章で止めてください。 標準機能で足ります。

次の章は、この教科書で最も金額の大きい判断を扱います。勧める章ではなく、作らなくてよい理由を先に潰す章として読んでください。

次の章へ：9章 LINEのLIFF開発｜標準機能では届かない部分