LP営業の返信確認を送信ログと分けて管理した理由
LP営業の運用で、実送信ログ、返信チェック結果、次回フォロー対象を別ファイルで残す形に整理した。試したことは、Gmail sent searchで送信済みを確認し、local markdownに送信ログを残し、reply check queueには返信確認が必要な案件だけを入れることだった。送った案件、返事を見る案件、次に追う案件、もう触らない案件を分け、同じLPへの二重連絡や見落としを減らせるかを確認した。
この設計にした理由は、送信済み確認と返信確認では役割が違うからだ。送信ログは「過去に実行した証拠」であり、返信確認は「今から判断する入口」になる。この2つを同じメモに混ぜると、送った事実だけで対応が進んだように見え、実際には返信の確認や次アクションの判断が残ったままになる。特に少人数運用では、管理する人と作業する人が同じになりやすく、記録の置き場所が曖昧なほど判断も曖昧になる。
読者が真似できることは、複雑な営業管理ツールを導入することではない。まず、送信ログ、返信チェック、次回フォロー、停止対象の4つを分け、案件が今どの判断待ちなのかを一つの場所だけに置く。今回は1日1本の作業ログ、候補最大3件、画像最低2枚という小さい条件で回した。件数を増やす前に、少ない案件でも二重連絡と見落としを防げる形を作ることを優先した。
送信済みと返信確認を混ぜた時に起きたこと
最初は、送信日時、対象LP、宛先を探すための検索語、返信有無、次回フォロー予定を同じメモにまとめていた。見た目だけなら一枚の管理表になり、情報が集まっているように見える。送った直後に一行を追加し、後日返信があれば同じ行に追記するだけなので、最初の記入は速かった。
ただ、翌日に見返すと問題が出た。どこまでが送信済みで、どこからが返信確認済みなのかが分かりにくくなった。送信した案件が並んでいるだけで作業が進んだように見え、実際には返信チェックが終わっていない案件まで対応済みに見えてしまった。Gmail sent searchで送信済みを確認できても、それは「送った証拠」であって「返信に対応した証拠」ではない。
特に危なかったのは、温度の高い返信ほど後回しになりやすいことだった。営業で優先すべきなのは、新しく送る件数だけではなく、返ってきた反応に早く次の判断をすることだ。しかし同じメモに未送信候補、送信済み、返信あり、返信なし、フォロー予定が混ざると、返信ありの案件も過去ログの一行に見える。新規候補を探す作業のほうが分かりやすいため、本来先に見るべき返信確認が後ろへずれた。
候補最大3件という小さい上限でも、この問題は起きた。件数が少なければ手で覚えられると思いがちだが、翌日には記憶の精度が落ちる。同じLPを別メモから再度拾えば、二重連絡の可能性も出る。つまり原因は件数の多さではなく、送信した事実と、返信に対する判断を同じ場所で扱っていたことだった。
4つの置き場所に分けた設計
整理後は、送信ログ、返信チェック、次回フォロー、停止対象の4つに分けた。送信ログには、送信した事実だけを残す。返信チェックには、今日または次回の確認で見る案件だけを入れる。次回フォローには、返信はないがまだ追う価値がある案件を置く。停止対象には、重複、対象外、反応なし、再連絡しないなど、もう触らない理由を短く残す。
この分け方で重視したのは、分類名のきれいさではなく、ファイルを開いた時にやることが一つに決まることだった。送信ログを開く時は、過去に送ったかどうかだけを見る。reply check queueを開く時は、返信が来ているかどうかだけを見る。次回フォローを開く時は、いつ再確認するかを決める。停止対象を開く時は、同じLPを再び拾わないために、止めた理由だけを見る。
同じメモに全情報を置く方法は、初回の入力が楽だった。だが、その楽さは翌日以降の確認に負担として戻ってきた。毎回メモ全体を読み直し、これは新規候補なのか、返信待ちなのか、停止済みなのかを判断し直す必要があった。分ける方法は、送信後に案件を移す手間が少し増える。その代わり、確認時に読む範囲が狭くなり、作業の順番を間違えにくくなった。
画像最低2枚という条件は、公開用の記録にも反映した。少なくとも一つは、送信ログ、返信チェック、次回フォロー、停止対象を4列に分けた営業運用ボード図にする。もう一つは、実際の確認手順や検索語の扱いを説明する証跡用に使う。この記事内では要約図の挿入位置だけを残しているが、考え方としては、画像を装飾ではなく、判断の置き場所を短時間で理解するための補助にした。
実際の作業ログと確認順序
作業は、候補を最大3件までに絞るところから始めた。数を増やすと、送信前の確認が雑になり、返信確認まで追えなくなる。LPを見て、連絡する理由があるものだけを残し、今日は送らない候補は無理にメモへ押し込まない。1日1本の作業ログとして閉じるため、候補確認、送信、送信ログへの記録、返信確認キューへの移動までを一つの単位にした。
送信後は、local markdownの送信ログに、送信日、対象を識別する名前、Gmail sent searchで使う検索語、短いメモだけを書く。ここに長い判断理由や感想は入れない。送信ログは読み物ではなく、後から送った事実を照合するための索引だからだ。情報を増やしすぎると、必要な検索語や送信日が埋もれるため、「送った事実を確認できる最小情報」に絞った。
次に、返信確認が必要な案件だけをreply check queueへ移す。この時、送信ログを丸ごとコピーしないことを決めた。送信時の細かい背景まで持ち込むと、返信確認用のファイルがまた過去ログ化するからだ。返信チェックに必要なのは、対象を特定できる情報、確認に使う検索語、次に判断する期限だけでよい。ここでは、返事が来たか、次回フォローに回すか、停止するかの三つだけを見る。
確認時は、最初にreply check queueを開く順番に変えた。以前は新規候補のメモを先に開いていたため、新しく送る対象を探す作業が先に進み、返信確認が後ろへ回りやすかった。順番を変えた後は、返信確認を終えてから新規候補を見る。返信があれば次アクションへ進め、返信がなければ次回フォローか停止対象へ移す。未分類の返信なしを残さないことが、この運用の要点だった。
今回の実測として残したのは、候補最大3件でも記録が混ざれば見落としは起きるという点だった。量が少ないから安全なのではない。量が少ないうちに判断の置き場所を固定するから安全になる。作業ログは細かく増やすより、次に開くファイルが一目で分かる程度に絞ったほうが使いやすかった。
失敗の原因と対処
一番大きな失敗は、送信済み確認を終えた案件を、無意識に対応済みと見なしてしまったことだった。営業運用では、送った時点ではまだ終わっていない。むしろ返信が来た時点、または返信がないことを確認した時点から、次の判断が始まる。送信ログと返信確認を同じ場所に置くと、「送信済み」という言葉に引っ張られ、確認まで終わったように見えてしまう。
対処として、送信ログでは「完了」という言葉を使わないようにした。送信ログに残す状態は、あくまで送信済みであり、対応済みではない。案件の現在地は、reply check queueで確認した後に、次回フォローまたは停止対象へ移した時点で決まる。この言葉の分離は小さいが、作業者の誤認を減らす効果があった。
もう一つの失敗は、返信なしの案件を次回フォローに残し続け、いつ止めるかが曖昧になっていたことだった。追う案件と止める案件を同じ場所に置くと、フォロー対象が膨らみ、毎回同じ案件を見直すことになる。そこで停止対象を別に作り、追わない判断を明示した。理由は長く書かず、対象外、重複、反応なし、再連絡しない、のように短く残す。止めた理由が残っていれば、後から同じLPを見つけても、また最初から判断し直さずに済む。
原因をまとめると、問題はツール不足ではなかった。Gmail sent searchもlocal markdownもreply check queueも、それぞれは十分に使える。崩れていたのは、各ツールにどの判断を持たせるかの線引きだった。送信ログに判断を入れすぎ、返信確認に過去情報を持ち込みすぎ、停止判断を独立させていなかったため、案件の現在地がぼやけた。直したことは、道具を増やすことではなく、道具ごとの責任範囲を狭くすることだった。
少人数で真似するための型
同じ運用を少人数で真似するなら、最初に4つのファイルを作るだけでよい。送信ログには、送った証拠を置く。返信チェックには、確認待ちの案件を置く。次回フォローには、再確認する日や条件を置く。停止対象には、もう触らない理由を置く。この4つを守れば、Markdown、スプレッドシート、メモアプリのどれでも同じ考え方で使える。
最初から細かいステータスを増やさないことも重要だ。たとえば、検討中、要確認、返信待ち、再送予定、保留、停止候補のように分けすぎると、どこへ入れるべきかで迷う時間が増える。今回必要だったのは、管理項目を増やすことではなく、次に開く場所を迷わないことだった。送ったか、返信を見るか、次に追うか、止めるか。この4分類で十分に回せた。
数字も小さく固定したほうがよい。候補最大3件は、営業量を増やすための数字ではなく、返信確認まで追い切るための上限だった。1日1本の作業ログに閉じることで、当日の送信、返信確認キューへの移動、翌日の確認までを追いやすくした。件数を増やすのは、未分類の案件が残らなくなってからでよい。未分類が残っている状態で件数だけ増やすと、送信ログと返信確認を分けた意味が薄れる。
毎日の終わりには、reply check queueを空に近づける。完全にゼロにできなくても、各案件を次回フォローか停止対象へ動かし、未分類を残さないようにする。分けて管理する目的は、きれいな記録を残すことではない。翌日の自分が同じ判断をやり直さないようにすることだ。営業返信の確認、次アクション、停止判断を分けて残せば、少人数でも追客の抜け漏れを減らせる。
公開前チェック
この記事の公開前には、主題が「LP営業の返信確認を送信ログと分けて管理した理由」から外れていないかを確認する。特に、送信済み確認と返信確認を同じメモに混ぜた失敗、温度の高い返信ほど後回しになった原因、4つのファイルへ分けた対処が本文内に残っているかを見る。
短い確認項目は次の通り。冒頭3段落で、何を試したか、なぜ分けたか、読者が何を真似できるかが分かる。H2は5個以上あり、各見出しが送信ログ、返信確認、次回フォロー、停止判断の話へ戻っている。1日1本、候補最大3件、画像最低2枚という数字が残っている。reply check queueを先に開くこと、送信済みを対応済みと呼ばないこと、停止対象を別に残すことが対処として読める。
この条件を満たしていれば、少人数でも追客の抜け漏れを減らすための運用設計として公開できる。