営業パーソン向けメール一斉送信システム

営業パーソン一人あたり50〜100社を担当する会社で、新製品告知やイベント案内の機会が定期的に発生していた。マーケティング部門が会社公式のメルマガを送っていたが、一度商談した相手への連絡は、担当営業から個別に送るほうが明らかに効果が出る。にもかかわらず、営業パーソンのITリテラシーの低さから市販の一斉送信システムは使わせられず、加えて、複数の営業マンが同じイベント案内を重複して送るリスクを避けるため、ツールの使用そのものが禁じられていた。結果、営業パーソンたちは通常メールのコピペで対応するしかなく、「忙しい」「面倒だ」という理由でほとんど実行されなかった。

市販ツールを解禁すれば誤送信・重複送信のリスクが生まれる。禁じ続ければ個別案内はゼロに近いまま。どちらの選択肢も取れない状態が続いていた。「営業が連絡をしない」問題は、営業パーソンの意識や習慣の問題として扱われ、仕組みの問題として誰も解決しようとしていなかった。

問題を構造として整理した。「案内が届かない」原因は、営業パーソンの怠慢ではなく、使えるツールが存在しなかったことだ。必要なのは、ITリテラシーが極めて低くても間違えないUI・重複送信を構造的にブロックする仕組み・リスト管理の統制が保てる設計、この3点を同時に満たすシステムだった。実装はGASをコアとし、GmailAPIと連動させる構造で行った。送信前に3つのチェック確認を必須化し、同一アドレスへの二重送信を自動ブロック。宛名（会社名・役職・氏名）は自動生成されるため、担当者はリストと本文を用意するだけでいい。スプレッドシートを開かなくても操作できるWebアプリとして実装し、4ステップのUI（設定→宛先リスト→送信実行→ログ確認）で完結させた。誰がいつ何件送ったかもログに自動記録される。

システム稼働後、「これを案内しろ」という指示が出れば、1000社への個別案内が実行されるようになった。それまでほぼゼロだった営業パーソンからの連絡が、仕組みとして動き出した結果、イベント集客と商談機会は桁違いの水準に変わった。やれていなかった行動を責める必要はない。やれる構造を作るだけでよかった。案内機会の損失は、構造ごと消去された。