STEPminiシート記入例つき完全ガイド｜初心者向けにやさしく解説

STEPminiを使ってみたいけれど、「シートに何を書けばいいのか分からない」「項目名を見ても役割がつかみにくい」と感じる方は多いのではないでしょうか。

特にSTEPmini V1.01は、単なる一斉配信ではなく、取りこぼしたstepを後から順番に送れる実務向けの仕組みになっているため、5つのシートがどうつながって動くのかを理解しておくことが大切です。
とはいえ、最初から全部を完璧に覚える必要はありません。
まずは各シートの役割を知り、1シナリオ分だけ記入して動かしてみるだけでも、全体の流れはかなり見えやすくなります。

この記事では、STEPmini V1.01で使う settings・scenarios・steps・customers・logs の5シートについて、何を書くのか、どこに注意すればよいのかを、初心者向けにやさしく整理して解説します。
「まずは1本だけシナリオを作って試してみたい」という方は、記入例を見ながら順番に進めてみてください。

H2-1：STEPmini V1.01の入力は5シートを順番に見れば分かる

H3-1：最初に全体像を知ると入力ミスが減りやすい

STEPmini V1.01を初めて使うとき、いきなりシートに入力し始めると、どこに何を書けばよいのか分からなくなりやすいです。
そのため、最初に 5シート全体の役割をざっくり把握しておくこと がとても大切です。

特に初心者の方は、
「steps に本文を書けば送れるのでは」
「customers にメールアドレスを入れたら動くのでは」
と部分的に考えがちですが、STEPmini V1.01は複数のシートがつながって動く仕組みです。

たとえば、

• 全体設定が入っていない
• scenario_id が合っていない
• active や enabled が無効のまま
• start_date が空欄

といったことがあると、本文が正しく書けていても送信されません。

だからこそ、最初に「このシートは何のためのものか」を知っておくと、入力ミスや設定漏れをかなり減らしやすくなります。
STEPmini V1.01は、1つのシートだけで完結する仕組みではなく、5シートを順番に見ていくと理解しやすい構造になっています。

H3-2：settings・scenarios・steps・customers・logs の役割を整理する

STEPmini V1.01で使う5シートは、それぞれ役割がはっきり分かれています。
ここを先に整理しておくと、入力の意味がかなり見えやすくなります。

まず settings は、STEPmini全体の共通設定を入れるシートです。
送信者名、返信先、署名、全体の有効・無効など、「システム全体の基本ルール」をここで持ちます。

次に scenarios は、どのシナリオを有効にするかを管理するシートです。
scenario_id ごとに active を持ち、「この流れを使うかどうか」を決めます。

steps は、シナリオの中身を作るシートです。
何日後に何を送るか、件名や本文、送信時間などをここで定義します。
つまり「流れの実体」はこのシートにあります。

customers は、配信対象の顧客情報を持つシートです。
メールアドレス、開始日、停止フラグ、どのシナリオを使うかなどをここで管理します。
誰に送るのかを決める台帳の役割です。

最後の logs は、送信結果の履歴を残すシートです。
何が送れたか、何が skip になったか、今日すでに送信済みか、といった運用の記録がここに集まります。
V1.01ではこの logs が再送防止や1日1通制限にも使われるので、とても重要です。

まとめると、

• settings = 全体設定
• scenarios = シナリオの有効管理
• steps = 送信内容の定義
• customers = 配信対象の管理
• logs = 送信履歴の管理

という役割分担です。
この全体像が頭に入っているだけで、入力時の迷いがかなり減ります。

H3-3：まずは1シナリオ分だけ作れば十分

STEPmini V1.01を初めて入力するときは、最初からたくさんのシナリオを作ろうとしないほうがうまくいきます。
まずは 1シナリオ分だけ作れば十分 です。

たとえば、

• 問い合わせ後フォローだけ
• 購入後のお礼だけ
• 予約確認だけ

というように、用途を1つに絞って作るほうが、全体のつながりを理解しやすくなります。

最初から複数シナリオを同時に作ると、

• どのscenario_idがどこにつながっているか
• steps はどのシナリオの内容か
• customers にどの番号を入れるか
• logs をどう見ればよいか

が一気に複雑になります。

一方、1シナリオだけなら、

1. settings を整える
2. scenarios に1つだけ登録する
3. steps を3通〜5通ほど作る
4. customers に対象を入れる
5. logs を見ながら動作確認する

という流れで追いやすくなります。

STEPmini V1.01は、仕組みが分かれば扱いやすい設計です。
だからこそ、最初は広げすぎず、「1シナリオをちゃんと動かすこと」を優先したほうが理解も早くなります。
1本うまく動けば、その型をもとに別の用途へ広げていくのもずっと楽になります。

H2-2：settings シートの記入例と見方

H3-1：from_name・from_address・reply_to の考え方

settings シートは、STEPmini V1.01 全体の共通設定を入れる場所です。
この中でも最初に理解しておきたいのが、from_name・from_address・reply_to の考え方です。

まず from_name は、メールの送信者名として相手に見える名前です。
たとえば、

• アピステクノロジー
• TECN運営事務局
• ○○サロン予約受付
• ○○ショップお客様窓口

のように、受け取った人が「どこから来たメールか」をすぐ分かる名前にするのが基本です。
会社名だけでもよいですが、問い合わせ窓口や予約受付などの役割が分かる名前だと、より親切です。

次に from_address は、送信元メールアドレスです。
これは実際にどのメールアドレスから送るかを示す設定なので、運用上かなり大切です。
受け取る側から見て不自然なアドレスになっていないか、社名やサービス名と関係のあるアドレスかを意識したほうが安心感につながります。

そして reply_to は、相手が「返信」を押したときに返事が届く先です。
ここは見落とされやすいですがとても重要です。
from_address と同じでもよいですが、実務上は

• 返信を見たい担当窓口
• 問い合わせを受けたいアドレス
• 実際に確認できる担当メール

にしておく必要があります。

つまり、

• from_name = 相手に見える送信者名
• from_address = 実際の送信元
• reply_to = 返信先

という役割です。
この3つは似ているようで意味が違うので、最初に分けて理解しておくと設定しやすくなります。

H3-2：signature と global_active の役割

settings シートでは、signature と global_active も重要な項目です。
この2つは「見た目」と「全体の動作」に関わる設定だと考えると分かりやすいです。

まず signature は、メールの最後に入る署名です。
たとえば、

• 会社名
• 担当窓口名
• 連絡先
• 営業時間
• URL

などをまとめて入れる場所です。
毎回本文の最後に手で入れなくても、共通の署名として使えるので、メール全体の印象を整えやすくなります。

署名があると、受け取る側も「ちゃんとした案内だな」と感じやすくなります。
逆に署名がまったくないと、短いメールでは少し簡素すぎる印象になることもあります。
そのため signature は、STEPmini全体の見た目を安定させる役割があります。

一方で global_active は、もっと根本的な設定です。
これは STEPmini 全体を有効にするかどうかを決めるスイッチのようなものです。

scenarios や steps をきちんと作っていても、global_active が有効になっていなければ、全体として配信が止まった状態になります。
つまり、本文やシナリオ以前に、この値が正しく設定されているかが非常に重要です。

初心者向けにまとめると、

• signature = メール末尾の共通署名
• global_active = システム全体のON/OFF

です。
特に global_active は、「設定したのに送られない」ときに最初に確認したい項目のひとつです。

H3-3：初心者が間違えやすい設定ポイント

settings シートは項目数が少なく見えるぶん、初心者は「ここは簡単そう」と思いがちです。
ですが、実際にはここでの小さな設定ミスが、配信全体に影響することがあります。

まずありがちなのが、reply_to を普段見ていないアドレスにしてしまうことです。
これだと相手から返信が来ても気づきにくくなります。
ステップメールは自動配信でも、返信対応は人が見ることが多いので、実際に確認できるアドレスを入れることが大切です。

次に多いのが、from_name が相手にとって分かりにくいことです。
社内用の略称や意味の伝わりにくい名前だと、受け取った側が少し不安に感じることがあります。
できるだけ「誰からのメールか」が分かりやすい名前にしたほうが安心です。

さらに重要なのが、global_active の設定ミスです。
ここが無効のままだと、ほかを正しく作っていても全体が止まります。
初心者のうちは、「steps がおかしいのかな」と本文側を疑いがちですが、実は settings 側の global_active が原因ということもあります。

また、signature も長すぎたり情報が古かったりすると、全メールに影響します。
署名は共通で使われるので、不要に長くしすぎず、必要な情報だけを整理して入れるほうが読みやすくなります。

つまり settings シートでは、

• 相手に分かる送信者名か
• 返信先を本当に確認できるか
• global_active が正しく有効か
• 署名が自然で見やすいか

を確認するのが大切です。
ここが整っているだけで、その後の運用がかなり安定しやすくなります。

H2-3：scenarios シートの記入例と見方

H3-1：scenario_id の決め方

scenarios シートで最初に大事なのが、scenario_id をどう決めるかです。
scenario_id は、STEPmini V1.01 の中で「この顧客にはこのシナリオを使う」と結びつけるための番号です。

この値は、scenarios シートだけで使うのではなく、

• scenarios
• steps
• customers

の3つで共通して使います。
そのため、ここがずれていると、シナリオを作っていても顧客に正しくひもづかなくなります。

たとえば、分かりやすくするなら、

• SC001
• SC002
• INQUIRY01
• PURCHASE01

のように、あとから見ても意味が分かる形にしておくと運用しやすくなります。

大切なのは、複雑でかっこいい番号にすることではなく、自分で見て分かることです。
特に初心者のうちは、問い合わせ後用なのか、購入後用なのかが見て分かる程度の名前にしておくと混乱しにくくなります。

また、scenario_id は customers シートや steps シートにそのまま使うので、途中で表記ゆれが出ないように注意が必要です。
たとえば「SC001」と「sc001」は別物として扱われる前提で考えて、最初に表記ルールを決めておくと安心です。

H3-2：active の意味と有効シナリオの考え方

scenarios シートでは、scenario_id とあわせて active の考え方を理解しておくことが大切です。
active は、そのシナリオを有効にするかどうかを決める項目です。

STEPmini V1.01 では、scenarios 側で active = TRUE になっているものだけが有効シナリオとして扱われます。
つまり、steps に内容が入っていても、customers に scenario_id が入っていても、scenarios 側で active が有効になっていなければ、そのシナリオは動きません。

初心者がよく混乱しやすいのは、「steps を作ったのに送られない」というときです。
この場合、本文や送信タイミングを疑う前に、scenarios の active を確認したほうが早いことがあります。

active は、シナリオ全体の ON / OFF だと思うと分かりやすいです。

• TRUE なら使う
• FALSE なら使わない

このくらいシンプルに考えて大丈夫です。

運用上も、この active は便利です。
たとえば、いまは使わないシナリオを残しておきたい場合でも、active を FALSE にしておけば、内容を消さずに止めておくことができます。
そのため、scenarios シートは単なる一覧表ではなく、「どの流れを今動かすか」を決める管理シートとして見ておくと理解しやすいです。

H3-3：1シナリオ運用から始めると分かりやすい

scenarios シートを使い始めるときは、最初から複数シナリオを並べるより、1シナリオ運用から始めるほうが圧倒的に分かりやすいです。

たとえば、最初は

• 問い合わせ後フォロー用に SC001 を1つ作る

だけで十分です。
そのうえで active を TRUE にして、steps と customers にも同じ scenario_id を入れれば、1本の流れとして動作確認がしやすくなります。

最初から

• 問い合わせ後
• 予約後
• 購入後
• 資料請求後

と複数シナリオを一気に作ると、どの顧客がどのシナリオなのか、どのstepsがどれに対応するのかが分かりにくくなります。
その結果、「送られない理由」を追いにくくなってしまいます。

一方、1シナリオだけなら、

• scenario_id はこれ
• active はこれ
• steps はこの流れ
• customers はこの対象

と全体を追いやすくなります。

STEPmini V1.01 は、仕組みが分かれば扱いやすいツールです。
だからこそ、最初は広げず、1シナリオだけで

「scenario_id がどうつながるか」
「active がどう効くか」

を体感したほうが理解が早いです。
1本うまく動けば、その後に別シナリオを増やすのはかなり楽になります。

H2-4：steps シートの記入例と見方

H3-1：step_no・date_from_start・enabled の意味

steps シートは、STEPmini V1.01 の中でも「実際に何をいつ送るか」を決める中心のシートです。
ここで特に大事なのが、step_no・date_from_start・enabled の3つです。

まず step_no は、そのシナリオの中で何通目のメールかを表す番号です。
たとえば、

• step_no = 1
• step_no = 2
• step_no = 3

のように入れていくと、「この流れの1通目・2通目・3通目」が分かりやすくなります。
特にV1.01では、同じ日付の候補がある場合に step_no の小さいものが優先される考え方もあるため、順番の整理に意味があります。

次に date_from_start は、開始日から何日後に送るかを表します。
たとえば、

• 0 = 開始日当日
• 1 = 開始日の翌日
• 2 = 2日後

という考え方です。

この値は、customers シートの start_date から計算される elapsed と照らし合わせて使われます。
つまり date_from_start は、「このメールを出すタイミング」を決める数字です。

そして enabled は、そのstepを有効にするかどうかの設定です。
内容を書いていても、enabled が TRUE でなければ送信候補には入りません。
逆に、今は使わないstepを残しておきたい場合は FALSE にしておけば、削除せず止めておけます。

初心者向けにまとめると、

• step_no = 何通目か
• date_from_start = 何日後に送るか
• enabled = そのstepを使うかどうか

です。
この3つが揃うことで、STEPmini は「どのメールをどの順番でいつ送るか」を判断しやすくなります。

H3-2：subject・body・send_time をどう考えるか

steps シートでは、送信タイミングだけでなく、何を送るか も決めます。
その中心になるのが subject・body・send_time です。

まず subject は件名です。
件名はメールの第一印象になるので、長すぎず、内容が分かりやすいものにするのが基本です。
たとえば、

• お問い合わせありがとうございます
• ご予約ありがとうございます｜日時のご確認
• ご購入ありがとうございます｜ご利用前にご確認ください

のように、「何のメールか」がひと目で分かる件名のほうが使いやすいです。

次に body は本文です。
ここには各stepで送りたい内容を入れますが、最初から長文にしすぎないことが大切です。
ステップメールは分けて送れる仕組みなので、1通1通は短くても問題ありません。
むしろ、

• 1通目はお礼と安心感
• 2通目は補足説明
• 3通目は事例や不安解消

のように役割を分けたほうが読みやすくなります。

そして send_time は、そのstepをどの時間帯に送るかの設定です。
初心者のうちは、まず大きく悩みすぎず、「見やすそうな時間」でそろえて始めるくらいで十分です。
大切なのは、時間を細かく最適化することより、まず流れをきちんと動かせることです。

つまり、

• subject = 開かれる入口
• body = 実際に伝える中身
• send_time = 送る時間帯

という役割です。
この3つを「読み手にとって分かりやすいか」という視点で整えると、steps シートはかなり作りやすくなります。

H3-3：3通〜5通の基本パターンで作ると始めやすい

steps シートを初めて作るときは、最初から長いシナリオを作ろうとしないほうがうまくいきます。
まずは 3通〜5通の基本パターン で作るのが始めやすいです。

たとえば問い合わせ後フォローなら、

• 1通目：お礼
• 2通目：補足説明
• 3通目：事例紹介
• 4通目：よくある質問
• 5通目：次の案内

という形で十分です。

予約後・来店後なら、

• 1通目：予約確認
• 2通目：来店前案内
• 3通目：来店後のお礼

でも役立ちますし、購入後なら、

• 1通目：購入のお礼
• 2通目：使い方の補足
• 3通目：次回につながる案内

くらいから始められます。

最初から10通以上を作ろうとすると、内容が重くなったり、途中で役割が曖昧になったりしやすいです。
そのため、まずは短い流れで「ちゃんと動く形」を作るほうが現実的です。

STEPmini V1.01は、あとから改善や追加がしやすい仕組みです。
だからこそ、最初の steps シートでは「立派な長編シナリオ」よりも、「3通〜5通で使える流れ」を意識したほうが成功しやすくなります。

H2-5：customers シートの記入例と見方

H3-1：customer_id・email・start_date・scenario_id が特に重要

customers シートは、STEPmini V1.01 の中で「誰に、どのシナリオを、いつから送るか」を決める大切なシートです。
この中でも特に重要なのが、customer_id・email・start_date・scenario_id の4つです。

まず customer_id は、顧客を識別するための番号です。
logs にも残るため、「誰に対して何が送られたか」を後から確認するときの軸になります。
必ずしも複雑な番号にする必要はなく、自分で管理しやすい一意の番号になっていれば十分です。

次に email は、実際の送信先です。
ここが空欄だったり、メール形式として不自然だったりすると、その顧客は送信対象から外れます。
STEPmini V1.01 は安全側に判定するので、email が怪しい場合は無理に送らず skip になりやすいと考えておくとよいです。

そして start_date は非常に重要です。
この日付を基準に elapsed が計算され、「いま何日目のstepを判定するか」が決まります。
start_date がなければ経過日数が計算できないため、送信判定そのものができません。

最後の scenario_id は、その顧客にどのシナリオを使うかを決める番号です。
これが scenarios と steps 側の scenario_id と一致していないと、どんな流れを送るべきか判断できません。

つまり、

• customer_id = 誰かを識別する番号
• email = 送信先
• start_date = いつから始めるか
• scenario_id = どの流れを使うか

という役割です。
customers シートでは、この4つが揃って初めて「送信対象として動ける状態」になります。

H3-2：stop_flag や memo の使い方

customers シートでは、stop_flag や memo も地味ですが大切な項目です。
特に実務で運用していくと、この2つがあることでかなり扱いやすくなります。

まず stop_flag は、その顧客への配信を止めるための項目です。
仕様上では、stop_flag が TRUE の顧客は送信対象から外れます。
つまり、customers シートにデータを残したままでも、「この人には今は送らない」という状態を作れるわけです。

これは実務ではかなり便利です。
たとえば、

• もう配信不要になった
• 一時停止したい
• 手動で別対応に切り替えたい
• テスト用データなので止めておきたい

といった場面で、わざわざ行を消さずに止められます。

次に memo は、送信判定そのものには直接使われませんが、運用上の補足情報を書いておける場所として役立ちます。
たとえば、

• この顧客はテスト用
• 特定の対応履歴あり
• 一時停止理由
• 管理上のメモ

などを書いておけば、後から見返したときに判断しやすくなります。

初心者のうちは、memo はなくても動くと思いがちですが、実際に顧客が増えてくると「何のデータだったか」が分かりにくくなることがあります。
そのため、最低限の補足を書いておける欄として考えておくと便利です。

H3-3：customers シートでつまずきやすい注意点

customers シートは一見シンプルですが、初心者がつまずきやすいポイントも多いです。
特に多いのは、値は入っているのに送られないというケースです。

まずありがちなのが、start_date の未入力や形式のズレです。
V1.01 では start_date から elapsed を計算するので、ここが空欄だとその時点で送信判定が止まります。
また、見た目は日付っぽく見えても、意図通りに扱えない形になっていると混乱しやすくなります。

次に多いのが、scenario_id の不一致です。
customers 側で入れた scenario_id が scenarios や steps と合っていなければ、その顧客にどのシナリオを適用するか分からず、送信対象になりません。
文字の違い、表記ゆれ、大文字小文字のズレなども含めて、最初はかなり注意したほうがよいです。

さらに、stop_flag が TRUE のまま になっているケースもあります。
テスト中や過去の調整で止めたつもりが、そのまま残っていると送信されません。
本文やstepを見直す前に、customers 側の停止条件を確認したほうが早いことがあります。

そして当然ですが、email の誤り も重要です。
メールアドレスが不自然だと、仕様上 skip の対象になります。
送信されない理由が steps や scenarios にあると思っていたら、実は customers 側の email が原因ということもあります。

初心者向けにまとめると、customers シートでは特に

• email
• start_date
• stop_flag
• scenario_id

を優先して確認するのがコツです。
この4点を見直すだけでも、「なぜ送られないのか」がかなり見えやすくなります。

H2-6：logs シートは何を見るためのものか

H3-1：SUCCESS が再送防止に使われる

logs シートは、単なる送信履歴の保存場所ではありません。
STEPmini V1.01 では、再送防止の判定に使う重要なシートです。

特に大事なのが、result 列の SUCCESS です。
V1.01 では、「そのstepがすでに成功送信されたかどうか」を logs の SUCCESS を見て判断します。

つまり、ある顧客に対して step_no 2 がすでに SUCCESS になっていれば、そのstepは「送信済み」とみなされ、次回以降は未送信候補から外れます。
この判定があるからこそ、V1.01 は

• 今日までに送るべき未送信stepを探す
• すでに送ったものは除外する
• 取りこぼしだけを順番に追回しする

という動きができます。

また、同一顧客への 1日1通制限 にも logs が使われます。
その日にすでに SUCCESS がある email は追加送信しないようにするので、同日に複数回バッチを回しても暴発しにくくなっています。

初心者向けに言うと、logs の SUCCESS は
「もう送ったから次は送らない」
を判断するための印です。
この印があるから、STEPmini V1.01 は安全に動きやすくなっています。

H3-2：skip ログを見ると原因調査がしやすい

logs シートの価値は、SUCCESS だけではありません。
skip ログを見ると、なぜ送られなかったのかを追いやすい のも大きな特徴です。

V1.01 では、送信しなかった場合にも理由が分かるようにログが残りやすくなっています。
たとえば仕様上、次のような skip 理由があります。

• skip: email不正
• skip: startDateなし
• skip: stopFlag=true
• skip: scenarioIdなし
• skip: scenarioが非アクティブ
• skip: stepsなし
• skip: 送るべき未送信stepなし
• skip: 本日すでに送信済み

こうした記録が残ることで、「送れなかった」という事実だけで終わらず、どこを直せばよいか が見えやすくなります。

初心者のうちは、送られないとすぐ本文や件名を疑いがちです。
ですが実際には、

• customers 側の start_date が空
• scenarios 側の active が FALSE
• steps 側の enabled が FALSE
• その日はすでに送信済み

といった理由のほうが多いこともあります。

そのため、STEPmini V1.01 では「動かない」と感じたら、まず logs を見る習慣をつけるとかなり分かりやすくなります。
logs は、結果を見るだけでなく、原因を調べるための窓口でもあります。

H3-3：logs を消すと運用が崩れやすいので注意する

STEPmini V1.01 を使ううえで、とても大切なのが logs を消さないこと です。
これは運用ルールとしてかなり重要です。

V1.01 は、logs の SUCCESS を見て

• そのstepが送信済みか
• 今日すでに送ったか

を判断しています。
そのため、logs を途中で消してしまうと、再送防止の土台が崩れてしまいます。

たとえば logs を消すと、

• 送ったはずのstepが未送信とみなされる
• 同じstepを再送する可能性が出る
• 1日1通制限の判定が崩れる

といった問題が起きやすくなります。

また、原因調査の履歴も消えてしまうので、「なぜ動かないのか」を追いにくくなります。
特にV1.01は、取りこぼし救済・順番維持・再送防止の多くを logs に支えられているため、このシートは単なる記録ではなく 運用の一部 と考えたほうがよいです。

もちろん、データが増えていくこと自体は自然です。
ですが、それは正常運用の結果でもあります。
軽くしたいからといって安易に消すのではなく、「残しておくことに意味があるシート」と理解しておくことが大切です。

H2-7：初心者向け｜まず1シナリオを作るときの記入の流れ

H3-1：settings を入れる

STEPmini V1.01を初めて動かすときは、まず settings シート から整えるのが基本です。
ここは全体設定なので、先に入れておくと後の確認がしやすくなります。

特に最初に確認したいのは、

• from_name
• from_address
• reply_to
• signature
• global_active

です。

この中でも大事なのは、reply_to が実際に確認できるアドレスになっているか、そして global_active が有効になっているか です。
本文やシナリオをきれいに作っても、全体設定が止まっていれば送信は動きません。

初心者のうちは、settings を難しく考えすぎなくて大丈夫です。
まずは「誰の名前で送るか」「返信はどこで受けるか」「全体をONにするか」を整えるだけでも十分です。
この土台ができると、次のシナリオ作成に進みやすくなります。

H3-2：scenarios・steps・customers を順に作る

settings を整えたら、次は scenarios → steps → customers の順で作っていくと分かりやすいです。

まず scenarios では、1つだけ scenario_id を作ります。
たとえば問い合わせ後フォローを試すなら、SC001 のような分かりやすい番号を1つ決めて、active を TRUE にします。

次に steps では、その scenario_id にひもづくメールの流れを作ります。
初心者のうちは、3通〜5通くらいで十分です。
たとえば、

• step1：0日後にお礼
• step2：1日後に補足説明
• step3：2日後に次の案内

のように、短い流れを作るだけでも動きが確認しやすくなります。

そのあと customers で、実際の配信対象を入れます。
ここでは特に、

• email
• start_date
• scenario_id

が重要です。
scenario_id は scenarios・steps と同じ値にしておく必要があります。

この順番にすると、

1. 全体設定を入れる
2. シナリオを作る
3. 中身のstepを作る
4. そのシナリオを使う顧客を入れる

という流れになるので、全体のつながりを理解しやすくなります。

H3-3：実行して logs で確認する

ここまで入力したら、次は実際に実行して logs シートで確認する 段階です。
初心者のうちは、送れたかどうかだけでなく、「なぜそうなったか」を logs で見ることが大切です。

実行後には、たとえば

• SUCCESS になっているか
• skip になっていないか
• どの step_no が対象になったか
• error_message は出ていないか

を確認します。

もし送られていなければ、logs に出ている skip 理由を見ると原因を追いやすくなります。
たとえば、

• email不正
• startDateなし
• scenarioが非アクティブ
• 本日すでに送信済み

などが分かれば、本文ではなく設定側を見直せばよいと分かります。

最初は1シナリオ・少人数の customers だけで動かしてみると、logs の見方も理解しやすいです。
STEPmini V1.01は、作って終わりではなく、実行して logs を見ながら仕組みを理解することで使いやすくなっていきます。

H2-8：まとめ｜STEPminiは記入例を見ながら1シナリオずつ作るとうまくいく

STEPmini V1.01 は、シートの数だけ見ると少し難しそうに感じるかもしれません。
ですが実際には、5シートの役割を順番に理解しながら、1シナリオずつ作っていく とかなり分かりやすくなります。

特に大切なのは、

• settings で全体設定を整える
• scenarios で使うシナリオを決める
• steps で何をいつ送るかを書く
• customers で誰に送るかを決める
• logs で結果を確認する

という流れを、ひとつずつ追うことです。

最初から複数シナリオを一気に作ろうとすると、scenario_id のつながりや active・enabled の設定、start_date の扱いなどが複雑になりやすくなります。
そのため、初心者のうちは、まず1シナリオだけを作って動かしてみるほうが、全体の仕組みを理解しやすくなります。

また、STEPmini V1.01 は、取りこぼし救済や1日1通制限、logs を使った再送防止など、実務向けの考え方が入っているのも大きな特徴です。
だからこそ、単に入力項目を埋めるだけでなく、「なぜこのシートが必要なのか」を理解しながら進めることが大切です。

STEPminiは、完璧に一気に作るものではありません。
記入例を見ながら、まず1シナリオを作り、実行し、logs を見て調整する。
この進め方が、いちばん失敗しにくく、結果として早く慣れやすい方法です。