ステップ配信のシナリオ設計テンプレート｜7通で予約に落とす骨組みをそのまま使う
ステップ配信のシナリオ設計テンプレート｜7通で予約に落とす骨組みをそのまま使う
ステップ配信のシナリオ設計で手が止まる原因は、たいてい「白紙から考えようとすること」です。何通にするか、何を書くか、いつ送るか。全部を同時に決めようとすると進みません。
先に骨組みを渡します。友だち追加から予約（来店予約・相談予約）までを7通で運ぶテンプレートです。
| 通 | タイミング | 役割 | 最後に置くもの |
|—|—|—|—|
| 1通目 | 追加直後 | あいさつ＋特典を渡す＋今後の予告 | 特典の受け取り |
| 2通目 | 翌日 | 読者の悩みを代弁する | 軽い問いかけ |
| 3通目 | 3日目 | 解決の考え方（正しい選び方） | 関連情報への誘導 |
| 4通目 | 5日目 | 実例・ビフォーアフター | 予約導線を初めて見せる |
| 5通目 | 7日目 | よくある不安への先回り回答 | 予約導線 |
| 6通目 | 9日目 | オファー本体（予約案内＋理由のある特典） | 予約ボタン |
| 7通目 | 10日目 | 最終案内（期限の再提示） | 予約ボタン |
この骨組みは、graciautoが本番で運用しているシナリオの設計原則──ゴールからの逆算・タグ駆動・止め方の設計──を、予約獲得型の7通に展開したものです。各通に何を書くかはこのあと順に説明しますが、先にひとつだけ強調しておきます。
**7通の文面よりも大事なのは、「予約した人にこの配信を止める」裏側の設計です。** ここを作らずに文面だけ真似ると、予約済みのお客様にセールスが届き続けます。後半で、本番構築で実際に使っている止め方をそのまま書きます。
7通テンプレートの設計思想：最後の1通から逆算する
このテンプレートは1通目から順に考えて作ったものではありません。順番は逆です。
まず6通目（オファー）を固定します。「予約してください」という案内が響くためには、その手前に何が必要か。不安が残っていれば予約されないので、5通目に先回り回答を置く。実例を見ていなければオファーが刺さらないので、4通目に実例を置く。そもそも「自分の悩みはこれだ」と自覚していなければ実例も他人事なので、2〜3通目で悩みの言語化と解決の考え方を置く。1通目は、この後の6通を読んでもらうための信頼の頭金です。
つまり各通は「読者を1段ずつ予約に近づける階段」であり、どの1通を抜いても6通目の反応に跳ね返ります。逆に言えば、読者がすでに登っている段は飛ばして構いません。この判断基準は後述します。
各通の中身：文面の骨組みまで分解する
1通目（追加直後）：信頼の頭金を払う
友だち追加の直後は、メッセージが読まれやすいゴールデンタイムです。ここで売り込むのはもったいない。あいさつ、追加特典（クーポン・診断・資料など）の即渡し、そして「これから何が届くか」の予告。この3点で終えます。予告を入れるのは、2通目以降が「知らない店からの営業」ではなく「約束した続き」として読まれるようにするためです。
2通目（翌日）：悩みを代弁する
商品の話はまだしません。読者が抱えている悩みを、読者本人より正確な言葉にして返します。美容室なら「カラーの色が2週間で抜ける」「白髪が気になり始めたけれど、何から手をつければいいか分からない」。自分ごと化した読者だけが、3通目以降を読み続けてくれます。
3通目（3日目）：解決の考え方を教える
ここも売り込みではなく教育です。「その悩みは、こういう基準で解決策を選ぶと失敗しにくい」という判断基準を渡します。判断基準を先に受け取った読者は、4通目の実例を「基準を満たしている証拠」として読んでくれます。
4通目（5日目）：実例で証明する
お客様の変化を、可能なら数字や写真で見せます。ここで初めて予約導線を文末に置きますが、主役はあくまで実例です。「押し売りされた」と感じさせずに、予約という選択肢の存在だけを知らせます。
5通目（7日目）：不安に先回りする
予約に至らない理由は「欲しくない」ではなく「不安が残っている」であることが多いものです。料金・所要時間・勧誘の有無・初めてでも大丈夫か。接客の現場で実際に聞かれる質問を3〜4個選び、Q&A形式で潰します。
6通目（9日目）：オファーを出す
逆算の起点だった1通です。予約案内と、期限や枠数に理由のある特典を提示します。「今月の新規枠は◯名まで」「初回限定の◯◯」など、嘘のない範囲で「今動く理由」を作ります。この通だけは1つのメッセージに1つの行動（予約ボタン）だけを置き、他のリンクを混ぜません。
7通目（10日目）：静かに締める
6通目を見逃した人・迷っていた人への最終案内です。新しい説得材料は足しません。期限の再提示と予約ボタンだけ。ここで煽りすぎると、6通かけて積んだ信頼を最後の1通で崩します。
裏側の設計：予約した人に、この配信を止める
ここからがテンプレートの本体です。文面は正直、業種ごとにいくらでも書き換えられます。事故が起きるのは配信の裏側です。
開始条件と「予約完了」をタグで持つ
開始条件は「友だち追加」でも動きますが、実務ではタグ駆動をおすすめします。graciautoが教育系クライアントの本番環境で組んだ予約系シナリオは、フォームのボタン→タグ付与→タグを開始条件にシナリオ起動、という完全タグ駆動です。タグで組む理由は、後から「止める・戻す」を対称に作れるからです。予約が入ったら「予約済みタグ」を付ける。この1本のタグが、以降すべての制御の起点になります。
タグを付けただけでは、走行中の配信は止まらない
多くの配信ツールでは、シナリオの開始条件と走行中の配信は別物として扱われます。つまり、4通目の時点で予約してくれた人に予約済みタグを付けても、**すでに走り出したシナリオの5〜7通目は予定通り届き続けます。** 予約したお客様に「まだ予約していない前提のオファー」が届く。受け取る側の体験としては最悪で、配信が店への信頼を削っていくことになります。
予防策は二重にかけます。本番のウェビナー予約シナリオで実際に使い、キャンセル操作の後に配信予定の対象者数が「0人」になることまで管理画面で確認した構成です。
1. **停止処理**：予約完了のアクションに「走行中シナリオの個別停止」を含める（能動的に止める）
2. **絞り込み条件**：5〜7通目のそれぞれに「予約済みタグを持つ人を除外する」条件を付ける（受動的に弾く）
停止処理には設定漏れや操作ミスがありえます。絞り込みは配信の直前にタグの有無を見るので、仮に停止が漏れていても配信対象から外れます。オファー系の通ほど、この二重ガードを省かないでください。
予約後は「リマインドシナリオ」に乗せ換える
予約に落として終わりではありません。予約した人は、教育用の7通からリマインド用の別シナリオに乗せ換えます。本番で運用している型では、リマインドは2通だけです。開始前のリマインド（あわせてキャンセル導線を置く）と、直前の最終案内。キャンセルされたらタグを解除し、走行中のリマインドを止め、翌日に再予約案内を送る。予約⇄キャンセルが何度でも対称に回る設計です。
この「教育シナリオ→予約→リマインドシナリオ」という2階建てが、予約獲得型の全体像です。7通テンプレートは1階部分にあたります。2階のリマインドシナリオの実物は、[本番稼働中のシナリオを1通目から分解した記事](/blog/line-scenario-jitsubutsu-202607/)で公開しています。/
そのまま使う前の調整：削る判断と間隔の判断
7通は上限の目安。削るのは「通」ではなく「役割」で
7通という数字の根拠は、「教育・販売型の逆算で必要になる役割を全部並べるとこのくらいになる」というものです。裏を返せば、不要な役割があれば通数は減らすべきです。
- 単価が低く、悩みが自覚済みの商材（期間限定クーポンの利用促進など）→ 2〜3通目の教育パートを丸ごと削って4通構成に
- 紹介・指名で来る客層が中心 → 実例（4通目）を薄くし、不安への先回り（5通目）を厚く
- 予約直前の人だけが登録する導線（予約ページからの友だち追加など）→ 教育パートは不要。リマインド型の2通で足ります
一番危険なのは「せっかく作ったから全員に7通」です。読者がすでに登っている階段を送りつけると、埋め草として読み飛ばされ、ブロックという形で返ってきます。
間隔は「日数の正解」を探さない
冒頭の表では追加直後〜10日目としましたが、この日付そのものに魔法はありません。間隔は相手の行動から逆算して決めるものです。この論点は[シナリオ配信は何通・何日おきが正解かを扱った記事](/blog/line-scenario-haishin-kankaku-202607/)で詳しく書いたので、そちらに譲ります。/
想定される失敗と、設計段階での予防
テンプレートを運用に載せる前に、起こりうる事故を設計で潰しておきます。いずれも「起きてから直す」より「起きない構造にする」ほうがはるかに安上がりです。
- **予約済みの人にオファーが届き続ける**：前述の停止処理＋絞り込みの二重ガードで予防します。「タグを外せば（付ければ）止まるはず」という思い込みのまま公開すると起こりえます
- **条件分岐が意図と違う値で評価される**：条件は、そのアクションが実行される瞬間の値で評価されます。友だち50万人規模のサロングループで回数券管理の仕組みを構築した際も、「値を減らす処理」と「値を見る条件」の順番が1つ違うだけで挙動が変わることを実機で確認しています。分岐を入れるときは、どの位置で・何の値を見るのかを、管理画面を開く前に書き出してください
- **テストなしで本番公開してしまう**：対象0人の状態で組み上げる→自分の端末をテスト友だちにして通しで動かす→予約とキャンセルの両方を実際に踏む、の3段階を通ってから公開します。「予約したら5〜7通目が来ないこと」の確認までがテストです
FAQ
Q. 7通も書くネタがありません。減らしていいですか？
減らして構いません。ただし削るのは「通」ではなく「役割」で判断してください。読者がすでに自覚している悩みの言語化パートや、すでに知られている情報の教育パートは削れます。逆に、オファー（6通目相当）と不安への先回り（5通目相当）は、予約獲得型ならほぼ削れません。
Q. LINE公式アカウントの標準機能だけでこのテンプレートは動きますか？
7通を順番に送るだけなら、標準のステップ配信機能で動きます。ただし「予約済みの人への停止・除外」「タグを起点にした開始」といった裏側の制御は、Lステップやエルメなどの拡張ツールが必要になる場面が多いです。文面より先に必要な制御を書き出し、それからツールを判断してください。
Q. 配信を始めた後、何を見て改善すればいいですか？
各通の配信後にブロックが増えていないか、シナリオの離脱がどの通に集中しているかを先に見ます。壊れている1通を特定してから文面を直す順番です。全通をまとめて書き直すと、何が効いたのか分からなくなります。
まとめ：文面のテンプレートと「止める設計」はセットで使う
最後に骨組みを整理します。
1. 6通目（オファー）から逆算して、各通に役割を割り当てる
2. 7通は上限の目安。読者が登り済みの階段は役割ごと削る
3. 開始条件と予約完了はタグで持つ
4. 走行中の配信はタグだけでは止まらない。停止処理＋絞り込みの二重ガードをかける
5. 予約後はリマインドシナリオに乗せ換え、キャンセルまで対称に設計する
6. テスト友だちで「予約したら止まること」まで通してから公開する
文面のテンプレートは今日から使えます。ただし、成果に一番差がつくのは裏側の設計です。graciautoでは、LINE公式アカウントのステップ配信を、本記事のような本番運用の設計基準で構築しています。シナリオ設計で判断に迷う点があれば、お気軽にご相談ください。