STEPminiの使い方｜初心者向けに設定から配信まで解説

H2-1：STEPmini V1.01とは？まずはどんな仕組みかをやさしく理解しよう

H3-1：STEPminiは小規模事業者向けのステップメール配信ツール

STEPminiは、小規模事業者や少人数で運営しているお店・会社でも使いやすいように考えられた、ステップメール配信のためのツールです。

ステップメールとは、問い合わせ後、予約後、購入後などのタイミングに合わせて、あらかじめ用意したメールを順番に送っていく仕組みのことです。
本来こうしたフォローはとても大切ですが、日々の業務に追われていると、毎回ていねいに続けるのは簡単ではありません。

特に小規模事業者では、

• 問い合わせ対応
• 見積もりや事務作業
• 現場対応
• 既存顧客フォロー

を限られた人数で回していることが多いため、「本当は送りたいのに送れない」「一度止まるとそのままになる」といったことが起こりやすくなります。

STEPminiは、そうした状況でも、まずは1つの流れから小さく始められるように作られています。
最初から何でもできる巨大な仕組みではなく、実務に合わせて少しずつ使える形へ育てていきやすいのが特徴です。

H3-2：V1.01では「取りこぼしたstepを後から順番に送れる」のが大きな特徴

STEPmini V1.01の大きな特徴は、本来送るべきだったstepを取りこぼしても、あとから順番に救済送信できることです。

従来のV1.0では、顧客の開始日からの経過日数に対して、ちょうどその日に一致したstepだけを送る仕組みでした。
この方式だと、バッチを毎日きっちり回せなかった場合、その日のstepを取りこぼしてしまい、後から送られないという弱点がありました。

たとえば、

• 0日後に送るstep
• 1日後に送るstep
• 2日後に送るstep

があったとして、数日間バッチが止まると、本来送るべきだったstepがそのまま抜け落ちてしまうわけです。

V1.01では、この考え方が変わっています。
今日までに送るべきだった未送信stepの中から、最も古いものを1件だけ送る という形になりました。

これにより、取りこぼしがあっても、次回以降の実行で

• まず一番古い未送信step
• 次の日に次の未送信step
• さらに次の日にその次のstep

というように、順番を保ちながら追回しできるようになっています。

つまりV1.01は、単なるステップメール配信ではなく、止まっても立て直しやすい実務向けの設計になっているのが大きな価値です。

H3-3：毎日きっちり回せなくても運用しやすい設計になっている

STEPmini V1.01が小規模事業者に向いている理由は、毎日きっちり完璧に運用できなくても、比較的崩れにくい設計になっていることです。

小規模事業者の現場では、

• 手動実行の日がある
• トリガーが一時的に止まる
• 忙しくてその日の確認ができない
• 数日単位で運用が抜ける

といったことは珍しくありません。

理想だけでいえば毎日1回きれいに回すのが望ましいですが、実際にはそこまで機械的に続けるのが難しいこともあります。
V1.01は、その現実を踏まえて、取りこぼしがあっても次回以降に順番に追回しできるようになっています。

さらに、同じ顧客に対して1日1通までという制限もあるため、バッチを何度か回した日でも同日に複数通が暴発しにくいようになっています。
これも実務ではかなり大事なポイントです。

また、送信済みかどうかの判定は logs シートの SUCCESS をもとに行うため、どこまで送れたかが記録として残りやすく、再送防止にも役立ちます。

このように、STEPmini V1.01は「完璧に管理できる人向け」の仕組みというより、現場で多少の揺れがあっても回しやすいように考えられた仕組みです。
それが、小規模事業者にとって使いやすい大きな理由になっています。

H2-2：STEPmini V1.01で使う5つのシート

H3-1：settings は全体設定を入れるシート

STEPmini V1.01では、まず settings シート に全体の設定を入れます。
ここは、いわば「システム全体の共通ルール」を持つ場所です。

仕様上、settings にはたとえば次のような項目を入れます。

• from_name
• from_address
• reply_to
• signature
• global_active
• test_email

この中でも特に大事なのは、from_name / reply_to / signature / global_active です。
送信者名をどう見せるか、返信先をどこにするか、メールの最後にどんな署名を付けるか、そしてシステム全体を有効にするかどうか、といった基本動作がここで決まります。

初心者の方は、settings という名前だけだと少し抽象的に感じるかもしれません。
ですが実際には、「このSTEPmini全体をどういう形で動かすか」を決める土台のシートだと考えると分かりやすいです。

たとえば、本文やシナリオをきれいに作っても、global_active が正しく設定されていなかったり、reply_to が意図しない状態だったりすると、運用全体に影響が出ます。
そのため settings は、見た目以上に大切なシートです。

H3-2：scenarios・steps はシナリオと送信内容を決めるシート

STEPmini V1.01の中心になるのが、scenarios シート と steps シート です。
この2つが、実際に「どんな流れで何を送るか」を決めています。

まず scenarios シートは、シナリオ単位の有効・無効を管理するシートです。
仕様では、たとえば

• A列：scenario_id
• C列：active

のような形を想定しています。
ここで active が TRUE になっているものだけが有効シナリオとして扱われます。

次に steps シートは、そのシナリオの中で、何日後に何を送るかを定義するシートです。
仕様上は、

• scenario_id
• step_no
• date_from_start
• enabled
• subject
• body
• send_time

などを持ちます。

つまり、scenarios が「この流れを使うかどうか」を決め、steps が「その流れの中身」を決める役割です。
たとえば、scenario_id が同じstepを並べれば、1つのシナリオとして順番に送っていく構成になります。

この2つをセットで見ると分かりやすいです。
scenarios は「流れの箱」、steps は「その箱の中に入る各メール」です。
どちらかだけでは動かず、両方がそろってはじめてステップメールの流れが作れます。

H3-3：customers・logs は配信対象と送信履歴を管理するシート

STEPmini V1.01で実際の運用を支えるのが、customers シート と logs シート です。
この2つは、「誰に送るか」と「何が送られたか」を管理する重要なシートです。

まず customers シートは、顧客ごとの開始日・停止フラグ・シナリオ番号を持つシートです。
仕様では、たとえば次のような列を持ちます。

• customer_id
• name
• company
• email
• start_date
• tag
• stop_flag
• memo
• scenario_id

この中で特に重要なのは、

• email
• start_date
• stop_flag
• scenario_id

です。
メールアドレスが正しいか、開始日が入っているか、停止フラグが立っていないか、どのシナリオを使うか。これらが、送信対象かどうかを判断する大事な条件になります。

一方、logs シートは、送信結果の履歴を残すシートです。
仕様では、

• 送信日時
• customer_id
• email
• scenario_id
• step_no
• result
• error_message
• 備考

などを持ちます。

そしてV1.01では、この logs がとても重要です。
なぜなら、result が SUCCESS のものをもとに、再送防止や未送信stepの判定をしているからです。

つまり customers は「配信対象の台帳」、logs は「配信の記録帳」です。
この2つがあることで、STEPmini V1.01は

• 誰に送るべきか
• どこまで送ったか
• 今日もう送ったか
• 何が未送信か

を判断できるようになっています。

特にV1.01では、取りこぼしたstepを後から順番に送る設計なので、logs の存在が非常に重要です。
このシートがあるからこそ、送信漏れ救済と再送防止の両方が成り立っています。

H2-3：STEPmini V1.01はどうやって送信対象を決めるのか

H3-1：start_date から経過日数 elapsed を計算する

STEPmini V1.01では、まず customers シートに入っている start_date をもとに、顧客ごとの経過日数 elapsed を計算します。
ここが送信判定の出発点です。

考え方はシンプルで、start_date を「このシナリオの開始日」として見て、そこから今日まで何日たったかを数えます。
たとえば仕様上では、

• start_date = 2026/4/29 → elapsed = 0
• start_date = 2026/4/28 → elapsed = 1
• start_date = 2026/4/27 → elapsed = 2

という扱いです。

つまり、開始日当日は 0日後、翌日は 1日後、さらにその次の日は 2日後、という形です。
この elapsed があることで、「今その顧客はシナリオ開始から何日目にいるのか」が分かるようになります。

ステップメールは「何日後に何を送るか」で組み立てるので、この経過日数が分からないと送信対象を決められません。
そのため、start_date は単なる日付ではなく、各顧客の配信タイミングを決める基準日としてとても重要です。

初心者向けに言い換えると、elapsed は「このお客様に対して、いま何通目あたりを送る段階なのかを見るための数字」です。
STEPmini V1.01は、まずこの数字を出してから、送るべきstepを探していきます。

H3-2：今日までに送るべき未送信stepを探す

V1.01の大きな特徴は、今日ちょうど送るstepだけを見るのではなく、今日までに送るべきだった未送信stepを探すことです。

V1.0では、step の日数と elapsed が完全一致したものだけを送っていました。
このやり方だと、その日にバッチが動かなければ、そのstepは取りこぼしになってしまいます。
一度逃したstepは、あとから送られませんでした。

V1.01では、この考え方が変わっています。
送信対象になるのは、次の条件を満たすstepです。

• step.days が elapsed 以下
• まだ logs に SUCCESS がない
• 顧客の scenario_id と一致している
• step が enabled = TRUE になっている

つまり、本来今日までに送るべきだったのに、まだ成功送信されていないstep が対象になります。

たとえば、0日後・1日後・2日後のstepがある顧客で、今日の elapsed が 3 なら、0・1・2日後のstepは本来すでに送っておくべき対象です。
その中でまだ SUCCESS がないものがあれば、それが V1.01 の送信候補になります。

これが、V1.01 が「取りこぼし救済型」といえる理由です。
今日ぴったりのstepしか見ないのではなく、今日までに送るべき未送信stepを見るので、数日バッチが止まっても後から追回しできるようになっています。

H3-3：最も古い未送信stepを1件だけ送る仕組みになっている

V1.01では、送るべき未送信stepが複数見つかったとしても、1回の実行で一気に全部送るわけではありません。
ここも大事なポイントです。

仕様では、1顧客につき1回の実行で送るstepは 1件だけ と決まっています。
そのうえで、候補が複数ある場合は、

• date_from_start が最も小さいもの
• 同日なら step_no が小さいもの

を優先します。

つまり、いちばん古く、本来最初に送るべきだった未送信stepから順番に、1件ずつ送る仕組みです。

この設計のよいところは、流れが崩れにくいことです。
たとえば3日間バッチが止まっていて未送信stepが3件たまっていても、V1.01は同日に3通まとめて送るのではなく、

• 今日：一番古い未送信step
• 次回：その次の未送信step
• さらに次回：その次のstep

という形で順番に追回しします。

さらに、V1.01には同一顧客への1日1通制限もあります。
logs を見て、その日にすでに SUCCESS がある email には追加送信しないようになっているため、同日に複数回バッチを回しても暴発しにくい設計です。

初心者向けにまとめると、V1.01は
送るべき未送信stepを見つける → その中で一番古いものを1件だけ送る → 同日に何通も送らない
という順番で安全に動いています。

この仕組みがあるからこそ、毎日完璧に回せなくても、後から順番に立て直しやすい実務向けの運用がしやすくなっています。

H2-4：STEPmini V1.01の配信が安全な理由

H3-1：未送信stepだけを対象にするので取りこぼしを救済しやすい

STEPmini V1.01の安全性を支えている大きなポイントのひとつが、未送信stepだけを対象にしていることです。

V1.0では、その日の経過日数と完全一致したstepだけを送る仕組みでした。
このやり方は一見分かりやすいのですが、バッチが止まった日や手動実行を忘れた日があると、その日のstepがそのまま取りこぼしになってしまう弱点がありました。

V1.01では、この考え方が変わっています。
送信対象になるのは、「今日までに送るべきだったのに、まだSUCCESSになっていないstep」です。
つまり、1日や2日運用が止まっても、次回実行時に本来送るべき未送信stepを拾ってくれる設計になっています。

この仕組みのよいところは、単に漏れを防ぐだけではなく、過去の取りこぼしを順番に立て直しやすいことです。
毎日完璧に回すのが理想でも、実務ではどうしても止まる日があります。
V1.01はその現実を前提にして、送るべき未送信stepを見つけてくれるので、小規模事業者でも扱いやすくなっています。

つまり、未送信stepだけを対象にする設計は、「一度止まったら終わり」にしないための安全装置になっています。

H3-2：同一顧客に1日1通だけなので暴発しにくい

V1.01が安全なのは、同一顧客に対して1日1通しか送らない仕組みになっていることも大きいです。

取りこぼし救済があると聞くと、「止まっていた分が一気に何通も送られるのでは」と不安に感じる方もいるかもしれません。
ですが、V1.01では、未送信stepが複数あっても、1回の実行で送るのは最も古いstepを1件だけです。

さらに、その日にすでにSUCCESSになっているメールアドレスには追加送信しないように設計されています。
つまり、同日に何度バッチを回したとしても、同一顧客に同日複数通が飛びにくいようになっています。

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

• 手動で何度か実行してしまった
• トリガー確認で再実行した
• 運用中に原因調査のため複数回回した

といった場面でも、同一顧客への暴発リスクを下げやすくなります。

ステップメールは、順番に届くことが大切です。
一気に何通も届いてしまうと、せっかくの流れが崩れやすくなります。
その意味でも、1日1通制限は「取りこぼし救済」と「配信の穏やかさ」を両立するための大事な仕組みです。

H3-3：logs を使って再送防止するので運用が安定しやすい

STEPmini V1.01の安全性を支えるもうひとつの重要な要素が、logs シートを使って再送防止をしていることです。

V1.01では、送信結果を logs に残し、その中で result が SUCCESS になっているかどうかを判定に使っています。
これにより、「すでに送ったstepをまた送ってしまう」ことを防ぎやすくなっています。

たとえば、ある顧客に対して step_no 2 がすでにSUCCESSになっていれば、そのstepは未送信候補から外れます。
この判定があるからこそ、V1.01は「未送信stepだけを対象にする」運用が成り立っています。

また、logs には送信成功だけでなく、skip や error の情報も残るので、原因調査にも役立ちます。
たとえば、

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

といった理由が分かれば、なぜ送られなかったのかを後から追いやすくなります。

これは単なる記録ではなく、運用を安定させるための土台です。
特にV1.01では、取りこぼし救済・1日1通制限・再送防止の多くが logs に依存しているため、このシートの存在は非常に重要です。

逆にいうと、logs を消してしまうと再送判定が崩れやすくなるため、運用ルールとして保持していく必要があります。
このように、logs を使って送信履歴を管理しているからこそ、STEPmini V1.01は小規模事業者でも安定して回しやすい設計になっています。

H2-5：STEPminiを使い始める基本手順

H3-1：settings と scenarios を整える

STEPminiを使い始めるときは、最初に settings と scenarios を整えるところから始めます。
ここが土台になるので、いきなり steps や customers を入れるより先に確認しておくほうが分かりやすいです。

まず settings シートでは、システム全体の共通設定を入れます。
具体的には、送信者名、返信先、署名、全体の有効・無効など、全メールに関わる基本情報です。

仕様上、とくに重要なのは次のような項目です。

• from_name
• reply_to
• signature
• global_active

この中でも global_active は特に大切です。
ここが正しく有効になっていないと、シナリオやstepを作っても、全体として配信が止まったままになります。

次に scenarios シートでは、どのシナリオを有効にするかを決めます。
ここでは scenario_id と active が基本になります。
たとえば、1つの問い合わせ後フォローを試したいなら、そのシナリオ用の scenario_id を1つ作り、active を TRUE にしておきます。

初心者のうちは、ここで複数シナリオを一気に作らないほうがよいです。
まずは1シナリオだけ有効にして、「この流れだけを試す」という形にしておくと、全体の動きがつかみやすくなります。

H3-2：steps と customers を入れて配信準備をする

settings と scenarios が整ったら、次は steps と customers を入れて配信準備をします。
ここでようやく、誰に、どの流れで、何を送るかが具体的に決まります。

steps シートには、シナリオの中身を入れます。
つまり、「何日後に、どの件名・本文を送るか」を並べていく場所です。

仕様上は、たとえば次のような列があります。

• scenario_id
• step_no
• date_from_start
• enabled
• subject
• body
• send_time

初心者のうちは、まず 3通〜5通くらいの短い流れを作るのがちょうどよいです。
たとえば問い合わせ後なら、

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

といった形で十分始められます。

customers シートには、実際の配信対象を入れます。
ここでは特に次の項目が重要です。

• email
• start_date
• stop_flag
• scenario_id

この中でも start_date と scenario_id は送信判定の軸になります。
start_date がないと elapsed が計算できませんし、scenario_id がないと、どのstepsを使えばよいか分かりません。

つまり、steps で「送る内容」を準備し、customers で「送る相手」を準備することで、STEPminiは初めて動ける状態になります。

H3-3：バッチ実行と logs 確認で動作を見ていく

steps と customers を入れたら、次は実際にバッチを実行して、logs を確認しながら動作を見る段階に入ります。

STEPmini V1.01では、送信判定や再送防止、1日1通制限の多くが logs に依存しています。
そのため、送れたかどうかを見るだけでなく、「なぜ送られたのか」「なぜ送られなかったのか」を logs で確認することがとても重要です。

logs には、たとえば次のような情報が残ります。

• 送信日時
• customer_id
• email
• scenario_id
• step_no
• result
• error_message
• 備考

さらに V1.01 では、skip 理由も確認しやすくなっています。
たとえば、

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

といった理由が分かれば、どこを直せばよいか見つけやすくなります。

初心者のうちは、「送れた／送れない」だけを見るのではなく、logs を見ながら動きの意味を理解することが大切です。
そうすると、STEPmini V1.01 の仕組みが一気に分かりやすくなります。

最初は1シナリオ・少人数の customers だけで試し、logs を見ながら流れを確認する。
この進め方が、STEPminiを安心して使い始めるためのいちばん現実的なやり方です。

H2-6：初心者がSTEPminiを使うときの注意点

H3-1：scenario_id と active・enabled の設定ミスに注意する

STEPminiを使い始めるとき、初心者がつまずきやすいのが scenario_id と active / enabled の設定ミスです。
仕組みそのものはシンプルでも、この部分が少しずれるだけで「なぜか送られない」という状態になりやすくなります。

まず scenario_id は、customers・scenarios・steps をつなぐ共通の番号です。
たとえば customers 側で scenario_id が「SC001」になっていても、scenarios や steps 側で別の値になっていれば、その顧客にどのシナリオを適用すべきか判断できません。

また、scenarios では active = TRUE のものだけが有効シナリオとして扱われ、steps では enabled = TRUE のものだけが送信候補になります。
つまり、

• scenario_id が一致している
• scenarios 側で active が有効
• steps 側で enabled が有効

この3つがそろって初めて、対象stepとして見てもらえる形になります。

初心者のうちは、「文章は入れたのに送られない」と感じたら、まず本文より先にこのあたりの設定を見直すほうが早いです。
STEPmini V1.01は安全側に倒れる設計なので、設定が少しでも合わないと無理に送らず、skip になることが多いからです。

H3-2：logs を消さずに保持することが大切

STEPmini V1.01を使ううえで、特に大切なのが logs を消さずに保持することです。
これは単なる履歴保存ではなく、V1.01 の安定運用そのものに関わる重要なポイントです。

V1.01では、logs の中にある SUCCESS を見て、

• そのstepがすでに送信済みか
• 今日すでにその顧客へ送っているか

を判定しています。
つまり、logs は「過去に何が起きたかの記録」であると同時に、「次に何を送るべきかを判断する材料」でもあります。

もし logs を途中で消してしまうと、再送防止の前提が崩れやすくなります。
その結果、

• 送ったはずのstepが未送信とみなされる
• 同じstepをもう一度送ってしまう可能性がある
• 1日1通制限の判定が崩れる

といった問題につながりかねません。

もちろん、logs が増えていくこと自体は自然なことです。
むしろ V1.01 では、それが正常運用の一部です。
初心者のうちは特に、「logs は消して軽くするもの」ではなく、運用を安定させるために残しておくものと理解しておくことが大切です。

H3-3：最初は1つのシナリオだけで試すと分かりやすい

STEPminiを初めて使うときは、最初から複数シナリオを同時に回そうとしないほうが分かりやすいです。
まずは 1つのシナリオだけで試す ことをおすすめします。

たとえば、

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

というように、用途をひとつに絞って動かしてみる形です。

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

• どのscenario_idがどこにつながっているか
• どのstepがどの顧客向けか
• どこでskipされているのか

が見えにくくなります。
その結果、設定の確認もログの読み方も複雑になりやすいです。

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

• settings が正しいか
• scenarios が有効か
• steps が正しいか
• customers の start_date と scenario_id が合っているか
• logs にどう出るか

を順番に追いやすくなります。

STEPmini V1.01は、仕組みが分かれば扱いやすいツールです。
だからこそ最初の段階では、「たくさん作る」ことより「1つを正しく動かして仕組みを理解する」ことを優先したほうが、結果的に早く慣れやすくなります。

H2-7：STEPmini V1.01はどんな人に向いている？

H3-1：問い合わせ後フォローを整えたい小規模事業者

STEPmini V1.01が特に向いているのは、問い合わせ後フォローをきちんと整えたい小規模事業者です。

たとえば、ホームページから問い合わせは来るものの、

• お礼メールだけで終わってしまう
• その後の案内が続かない
• 忙しい時は返信だけで精一杯になる
• 見込み客との接点が自然に途切れてしまう

といった悩みを持っている場合、STEPminiはかなり相性がよいです。

特に小規模事業者では、営業担当・事務担当・現場担当が明確に分かれていないことも多く、問い合わせ後フォローを毎回手作業で丁寧に続けるのは簡単ではありません。
そのため、「本当はやりたいけれど回らない」部分を仕組み化できるだけでも大きな意味があります。

STEPmini V1.01は、まず1つのシナリオから小さく始めやすく、さらに運用が止まっても後から順番に追回ししやすい設計なので、問い合わせ後フォローを整えたい事業者にはかなり現実的です。
特に「見込み客を放置したくない」「お礼だけで終わらせたくない」と感じている方には向いています。

H3-2：手動運用やトリガー停止に不安がある人

STEPmini V1.01は、手動運用やトリガー停止に不安がある人にも向いています。

理想だけでいえば、ステップメールは毎日きっちり自動で動いてほしいものです。
ですが実際には、

• 手動で実行する日がある
• トリガーが止まることがある
• 数日間バッチを確認できない
• 忙しくてその日の運用が抜ける

といったことは十分起こりえます。

V1.0のような完全一致型だと、こうした止まり方をしたときに、その日のstepを取りこぼして終わってしまうのが弱点でした。
一方、V1.01では「今日までに送るべき未送信step」を見て、最も古いものから順番に追回しできるようになっています。

つまり、毎日一度も止まらずに完璧運用できる人向けではなく、多少運用が揺れても立て直しやすい仕組みになっているのがポイントです。
さらに同一顧客への1日1通制限もあるので、再実行時の暴発リスクも抑えやすくなっています。

そのため、「自動化したいけれど、実際には手動運用も混ざりそう」「止まったときに壊れるのが怖い」と感じる方には、かなり向いている仕様です。

H3-3：まずは無料でステップメールを試したい人

STEPmini V1.01は、まずは無料でステップメールを試してみたい人にも向いています。

ステップメールに興味があっても、最初から高機能なツールを導入するのは不安に感じる方は多いと思います。
特に小規模事業者では、

• 自分の業務に本当に合うか分からない
• 続けられるか分からない
• まずは小さく試したい
• いきなりお金をかけるのは不安

と感じるのは自然です。

STEPmini V1.01は、そうした段階の人にとってちょうどよい立ち位置です。
最初から多機能な仕組みを使いこなす前提ではなく、まず1つのシナリオ、1つの用途で試しながら、ステップメールの運用感をつかめるからです。

しかも、V1.01では取りこぼし救済や1日1通制限、logsによる再送防止など、実務向けの安心設計が入っています。
そのため、「無料だから不安定」というより、無料で試しやすいのに、実務で止まりにくい考え方が入っているのが強みです。

「まずは問い合わせ後フォローだけやってみたい」
「まずは1本だけ流れを作って試したい」
そんな方にとって、STEPmini V1.01はかなり始めやすい選択肢です。

H2-8：まとめ｜STEPminiは「止まっても追回ししやすい」実務向けの仕組み

STEPmini V1.01は、ただステップメールを送るための仕組みではありません。
毎日完璧に回せなくても、取りこぼしたstepを後から順番に追回ししやすい、実務向けの考え方を持った仕組みです。

従来の完全一致型では、バッチが止まった日や手動実行漏れがあると、その日のstepはそのまま抜け落ちてしまう弱さがありました。
V1.01では、今日までに送るべき未送信stepを見つけて、最も古いものから1件ずつ送る形に変わったことで、運用が止まっても立て直しやすくなっています。

さらに、

• 同一顧客への1日1通制限
• logs を使った再送防止
• skip 理由を見ながら原因確認できる設計

があるため、小規模事業者でも比較的安心して扱いやすいのが大きな強みです。

特に、問い合わせ後フォローを整えたい人、手動運用やトリガー停止に不安がある人、まずは無料で試したい人にとっては、かなり現実的な仕組みだといえます。
最初から複雑な運用を目指す必要はなく、まずは1シナリオから小さく試しながら、使い方を理解していけば十分です。

STEPmini V1.01は、「止まったら終わり」ではなく、「止まっても順番に追回ししやすい」ことに価値があります。
その意味で、机上の理想論ではなく、日々の運用に合わせて考えられた実務向けのステップメール配信ツールといえます。