MAの運用ルールに入れる項目一覧｜複数人でも事故らない

「担当が1人から3人になり、意図しない配信が起きるようになった」「それぞれが必要なときに設定していて、順番は決めていない」——運用する人が増えた部門で起きる変化です。誤配信は、担当者の注意力の問題ではありません。誰が何をしてよいかと、送る前の手順を決めていないことが原因です。この記事では、運用のルールに入れる項目を整理します。

担当が増えると事故が起きる

最初に、起きている変化を整理します。

運用を始めた頃は、担当が1人でした。その状態では、暗黙の手順で回ります。

担当が増えると、その暗黙の手順が共有されません。

結果として、意図しない配信や設定の重複が起きます。

よくある例は、テスト配信を本番のリストに送る事故です。

宛先の設定を変えないまま送信すると起きます。

別の例は、同じ相手に複数のメールが同時に届く事故です。

複数の担当が別々にシナリオを組んだ場合に起きます。

それぞれは正しい設定でも、重なると相手には迷惑になります。

こうした事故は、注意では防げません。

手順と権限で防ぐ形にします。

加えて、担当が変わるときの引き継ぎも問題になります。

誰が何のために作った設定かが分からなければ、消すこともできません。

使われていないシナリオが残り続けます。

以降では、ルールに入れる項目を順に整理します。

あわせて、記録と引き継ぎの形も確認します。

最初から完璧を目指す必要はありません。

ルールがないと何が起きるか

問題の整理です。

運用のルールがない状態では、いくつかの問題が重なります。誤配信、重複、放置、引き継げないことの4つです。

誤配信は、最も影響が大きい問題になります。

送ってしまったメールは、取り消せません。

相手の信用に直接影響します。

重複は、気づかれにくい問題です。

複数のシナリオが同じ相手に届く状態が続きます。

配信の解除につながる場合もあります。

放置は、費用に関わります。

使われていない設定が残ると、管理の対象が増えます。

リストが増え続けると、費用が上がる仕組みの場合もあります。

引き継げないことは、担当交代のたびに問題になります。

設定の意図が分からなければ、新しい担当は触れません。

結果として、新しく作り直すことになります。

これらはすべて、事前のルールで防げます。

ルールは長くする必要はありません。

1枚に収まる分量で、要点だけを決めます。

権限の設計

誰が何をできるかです。

役割	できること	できないこと
管理する人	権限の付与、全体の設定	特になし（変更は記録に残す）
配信する人	配信の実行、シナリオの有効化	権限の変更、リストの削除
作る人	下書きの作成、テスト配信	本番の配信、シナリオの有効化
見る人	結果の確認、レポートの閲覧	設定の変更、配信の実行
外部の委託先	下書きの作成、指定された範囲の設定	本番の配信、個人情報の書き出し

この5つの役割に分けると、事故の範囲が限定されます。本番の配信ができる人を絞ることが要点です。

作る人と配信する人を分ければ、確認の工程が自然に入ります。

1人が作って1人が送る形であれば、二重の確認になります。

小規模な運用では、この分離が難しい場合もあります。

その場合は、送信の直前に別の人が確認する手順にします。

権限を付与する際は、必要な範囲に絞ります。

管理の権限を全員に与える運用は避けます。

外部に委託する場合も、範囲を限定します。

個人情報を書き出せる権限は、慎重に扱います。

権限の一覧は、定期的に見直します。

異動や退職があった場合は、その都度外します。

この作業を忘れると、権限が残り続けます。

見直しの時期を決めておけば、漏れが減ります。

配信前の確認手順

最も重要な手順です。

配信の前に確認する項目を、手順として決めます。毎回同じ順番で確認すれば、抜けが減ります。

確認する項目は、宛先、件名、差出人、本文、リンク、時刻です。

宛先は、対象となるリストと除外の条件を見ます。

件名は、誤字と文字数を確認します。

差出人の名前とアドレスも確認します。

テストの設定が残っていると、意図しない差出人になります。

本文では、差し込みの項目が正しく置き換わるかを見ます。

名前の差し込みが空になると、不自然な文面になります。

リンクは、すべて押して確認します。

計測用の記号が付いたリンクも、実際に開いて確かめます。

時刻は、意図した日時になっているかを見ます。

時差の設定が違っていると、想定と別の時刻に届きます。

この6項目を、確認する人が声に出して読み上げる形も有効です。

目で追うだけでは、見落としが起きます。

確認が終わったら、記録に残します。

誰がいつ確認したかが分かる状態にします。

テスト配信の作法

事故が起きやすい工程です。

テスト配信は、必要な工程です。同時に、事故が起きやすい工程でもあります。

宛先を固定しておくことで、多くの事故を防げます。

テスト用のリストを作り、そこにしか送らない形にします。

本番のリストを選べる状態にしておくと、誤って選ぶ場合があります。

テスト用のリストには、社内の複数人を入れます。

1人だけでは、環境による見え方の違いが分かりません。

パソコンとスマホの両方で確認します。

複数のメールの仕組みで確認する形も有効です。

表示が崩れる場合があります。

テストの際は、件名に印を付ける方法もあります。

本番の配信と区別できる形にします。

ただし、印を消し忘れる事故もあります。

この場合は、印を付けない形のほうが安全です。

運用の状況で判断します。

シナリオを使った配信では、動作の確認も行います。

条件を満たしたときに、意図した内容が届くかを確かめます。

社内のテスト用の宛先で、実際の流れを試します。

セグメントの管理

増え続ける対象です。

配信の対象を絞る条件は、運用のうちに増えていきます。命名の規則がなければ、区別が付かなくなります。

同じような名前の条件が並び、どれを使うか分からなくなります。

規則は、作成の時期と目的を含める形が扱いやすくなります。

たとえば、年月と用途を並べる形です。

一時的に作った条件は、その旨を名前に入れます。

後から整理する際の判断材料になります。

条件の中身も記録します。

何を意図した条件かが分かれば、再利用できます。

同じ条件を毎回作り直す作業がなくなります。

定期的に使う条件は、共有の場所に置きます。

個人が作った条件が個人の管理下にあると、引き継げません。

使われていない条件は、整理の対象になります。

削除する前に、シナリオで使われていないかを確認します。

使われている条件を消すと、シナリオが止まります。

この確認を手順に入れておきます。

整理の頻度は、半年に1回程度で足ります。

整理した記録も残しておきます。

シナリオの管理

自動で動く仕組みです。

条件に応じて自動で配信する仕組みは、便利ですが管理が必要です。作った後、動き続けるためです。

停止の条件を書いておかなければ、いつまでも動きます。

たとえば、期間限定の案内を自動で送る設定です。

期間が過ぎても止めなければ、古い案内が届き続けます。

そのため、いつまで動かすかを設定の時点で決めます。

終了の日を設定できる場合は、設定します。

できない場合は、確認の予定を作ります。

シナリオの一覧も作ります。

書く項目は、名前、目的、開始日、終了の条件、担当者です。

この一覧があれば、動いているものを把握できます。

複数のシナリオが同じ相手に届く可能性も確認します。

条件が重なっていれば、同時に届きます。

この確認は、新しいシナリオを作るときに行います。

既存の一覧と照らし合わせます。

誤配信の原因として、条件の細分化が挙げられています。

条件が複雑になるほど、確認しきれなくなります。

必要以上に細かく分けない判断も、事故を防ぎます。

自動で動く配信は、一時的に止める手順も決めておきます。災害や大きな事故が起きた日に、案内が届く事故を防ぐためです。

止める操作ができる人を、複数にしておきます。

担当者しか操作できない状態では、休日に対応できません。

止める基準も、事前に言葉にしておきます。

基準がなければ、判断が担当者によって変わります。

止めた後の再開の判断も、誰が行うかを決めます。

再開を忘れると、必要な配信が止まったままになります。

配信の上限を決める

送りすぎを防ぎます。

複数のシナリオが動くと、同じ相手に多くのメールが届きます。この状態は、配信の解除につながります。

一定の期間に送る通数の上限を設ける機能が用意されている場合があります。

1日や1週間の単位で、最大の通数を決められます。

この設定があれば、重複による送りすぎを防げます。

上限の目安は、相手との関係と内容によって変わります。

既存の顧客と、まだ関係のない相手では違います。

週に1通を上限とする形が、多くの場合で無理のない水準になります。

重要な案内を優先する設定も検討します。

上限に達した場合、どのメールを優先するかを決めます。

機能がない場合は、運用で調整します。

配信の予定を一覧にして、重なりを確認します。

この一覧を、担当者間で共有します。

大きな案内を出す週は、他の配信を控える判断もあります。

配信の解除の率も、あわせて記録します。

上限を設けた後に解除が減れば、効果があったと判断できます。

この記録が、上限の見直しの材料になります。

除外の管理

送らない相手の扱いです。

配信の対象から外す相手を、明確に管理します。解除した相手に送ることは、避けなければなりません。

解除の処理が自動で反映されるかを確認します。

手動でリストを取り込む運用では、解除が反映されない場合があります。

取り込みの前に、除外の条件を確認します。

解除以外にも、送らない相手があります。

競合の会社、取引を終えた相手、担当が変わった連絡先です。

これらを除外のリストとして管理します。

除外の判断の基準も決めておきます。

担当者ごとに判断が違うと、扱いが揃いません。

届かなかったアドレスの扱いも決めます。

繰り返し届かない場合は、除外の対象にします。

届かないアドレスに送り続けると、到達に影響する場合があります。

この処理を自動で行う設定があるかを確認します。

ない場合は、定期的に確認する手順にします。

除外のリストは、共有の場所に置きます。

個人が管理すると、担当交代で失われます。

更新の記録も残しておきます。

通知と監視の設定

異常に気づく仕組みです。

配信の失敗や、シナリオの停止に気づく仕組みを用意します。気づかなければ、止まったまま日数が経ちます。

エラーの通知を設定しておくことが推奨されています。

配信が失敗した場合や、条件が意図せず動作しない場合に通知が届きます。

通知の宛先は、複数人にします。

1人だけに届く設定では、不在時に気づきません。

通知が多すぎる設定も避けます。

重要な通知が埋もれます。

必要な通知に絞る判断も必要です。

あわせて、定期的に結果を確認する予定を作ります。

通知が来なくても、意図した通数が出ているかを見ます。

配信の数が急に減っていれば、条件に問題があります。

開封や到達の数字も、あわせて確認します。

急な変化は、設定の変更が原因の場合があります。

確認の頻度は、配信の頻度に合わせます。

週に1回配信するなら、週に1回確認します。

この確認を担当の業務として組み込みます。

リストの取り込み

入口の管理です。

外部から取り込むリストの扱いも、ルールに含めます。取り込みの前に、確認する項目を決めます。

同意を得た相手かどうかが、最初の確認になります。

名刺の交換や資料の申込を経た相手であれば、経路が明確です。

経路が不明なリストは、取り込まない判断をします。

取得の経路と時期を、項目として記録します。

後から確認が必要になった場合の材料になります。

重複の確認も行います。

同じ相手が複数の記録として入ると、複数のメールが届きます。

会社名と氏名、アドレスで照合します。

表記の揺れがあると、重複が検出されません。

取り込みの前に、表記を整える作業が必要になります。

項目の対応も確認します。

会社名の欄に部署名が入ると、差し込みが崩れます。

少数の件数で試してから、全体を取り込む形が安全です。

取り込んだ記録も残します。

いつ、どこから、何件を取り込んだかを書きます。

別の仕組みと連携している場合は、同期の方向も決めます。どちらの情報を正とするかを決めておきます。

両方から更新できる状態では、内容が食い違います。

顧客の情報は営業の仕組みを正とし、行動の記録は配信の仕組みを正とする形が一例です。

同期の頻度と、失敗したときの通知も確認します。

同期が止まったままだと、古い情報で配信することになります。

項目の対応表も作っておきます。

どの項目がどこに入るかが分からなければ、確認もできません。

記録と引き継ぎ

続けられる形にします。

運用の記録は、引き継ぎのために残します。設定の意図が分からなければ、新しい担当は触れません。

記録する対象は、シナリオ、セグメント、権限、配信の予定です。

それぞれに、目的と担当者を書きます。

作成の日付も入れます。

古い設定を整理する際の判断に使えます。

記録の場所は、社内で共有される場所にします。

ツールの中だけでは、意図が伝わりません。

更新の担当も決めます。

設定を変えた人が書く形が自然になります。

引き継ぎの際は、この記録を渡します。

あわせて、動いているシナリオを一緒に確認します。

止めるものと続けるものを、その場で判断します。

権限の付け替えも、引き継ぎの作業に含めます。

前任者の権限を外す作業を忘れないようにします。

この一連の作業を、手順として書いておきます。

引き継ぎのたびに考える必要がなくなります。

ルールに入れる項目

文書にする内容です。

• 役割ごとの権限（本番の配信ができる人を限定する）
• 配信前の確認手順（宛先・件名・差出人・本文・リンク・時刻）
• テスト配信の宛先（テスト用のリストに固定する）
• セグメントとシナリオの命名の規則と一覧の場所
• 一定期間に送る通数の上限と、優先する配信
• 除外の基準（解除・競合・届かないアドレスの扱い）
• エラーの通知の宛先と、定期的な確認の頻度
• リストの取り込みの条件と、記録する項目

この8項目が、ルールの骨格になります。すべてを最初から決める必要はありません。

上の3項目から始めれば、大きな事故は防げます。

権限、確認手順、テストの宛先の3つです。

この3つで、誤配信の多くを防げます。

4項目目以降は、運用の規模に応じて追加します。

シナリオが1つしかない段階では、管理の負担も小さくなります。

増えてきた時点で、規則を決めます。

文書は、1枚に収める形にします。

長い文書は読まれません。

見直しの時期も決めておきます。

半年に1回程度、実際の運用と合っているかを確認します。

合っていない部分は、実態に合わせて直します。

守れないルールは、書いてあっても意味がありません。

小規模な運用での工夫

人が足りない場合です。

担当が1人か2人の運用では、役割を分けられません。その場合も、確認の工程は入れられます。

送信の直前に、別の人に見てもらう形にします。

マーケティングの担当以外でも構いません。

宛先と件名、リンクを見てもらうだけで効果があります。

時間を置いてから自分で確認する方法も有効です。

作った直後は、誤りに気づきにくくなります。

翌日に確認する形にすれば、見落としが減ります。

そのため、配信の予定は余裕を持って組みます。

当日に作って当日に送る運用では、確認の時間がありません。

確認の項目を紙や画面の一覧にしておく方法も有効です。

記憶に頼らず、目で追える形にします。

シナリオも、最初は数を絞ります。

1つか2つで運用し、慣れてから増やします。

最初から複雑な設計にすると、管理できません。

記録も、簡単な表で足ります。

完璧な文書を作ることが目的ではありません。

引き継げる状態にすることが目的になります。

やりがちな失敗

実際に起きている例です。

• テスト配信の宛先を毎回選ぶ運用にし、本番のリストに送ってしまう
• 複数の担当が別々にシナリオを作り、同じ相手に同時に届く
• 期間限定の案内を自動で送る設定を止め忘れ、古い案内が届き続ける
• 退職者の権限を外し忘れ、アカウントが残ったままになる
• 設定の意図を記録せず、担当交代のときに作り直すことになる

1行目は最も影響が大きい失敗です。テスト用のリストに固定します。

2行目は、一覧を作って重なりを確認すれば防げます。

3行目は、設定の時点で終了の条件を決めます。

4行目は、権限の見直しを定期的に行えば防げます。

5行目は、引き継ぎで問題になります。記録を残します。

どれも、運用を始める段階で決めておけば防げます。

進める5工程

順番に進めます。

• シナリオは設定の時点で終了の条件を決める（止め忘れを防ぐ）
• セグメントを削除する前に、シナリオで使われていないか確認する
• 異動や退職があった場合は、その都度権限を外す
• 経路が不明なリストは取り込まない（同意の確認を優先する）
• ルールは1枚に収め、半年に1回は実態と合っているかを見直す

この5工程と5つの注意で、複数人でも回る形になります。

1工程目から3工程目までで、大きな事故は防げます。

誤配信の多くは、権限と手順で防げます。

4工程目は、運用が続くほど価値が出ます。

5工程目は、相手との関係を守る設定になります。

すべてを一度に整える必要はありません。

事故が起きやすい部分から順に決めます。

運用しながら、実態に合わせて直していきます。

まとめ

MAツールを複数人で運用する場合、暗黙の手順が共有されないまま事故が起きます。テスト配信を本番のリストに送る、複数のシナリオが同じ相手に同時に届く、期間限定の設定を止め忘れる、といった事故です。これらは注意では防げず、権限と手順で防ぎます。

最初に決めるのは、役割ごとの権限、配信前の確認手順、テスト配信の宛先の3つです。本番の配信ができる人を限定し、宛先・件名・差出人・本文・リンク・時刻を毎回同じ順番で確認します。テスト用のリストに固定すれば、誤送信の多くを防げます。

運用が続くと、セグメントとシナリオが増えていきます。命名の規則を決め、目的と終了の条件を一覧に記録します。一定期間に送る通数の上限を設ければ、重複による送りすぎも防げます。ルールは1枚に収め、半年に1回は実態と合っているかを見直します。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。