専門商社の顧客管理・営業支援（CRM／SFA）＋メール・LINE配信

相談のきっかけ

顧客・案件・見積の情報と、メールやLINEでの接点がそれぞれ別の場所にあり、1人の顧客に対して「いつ何を売って、いつ何を送ったか」が繋がっていなかった。担当者名や商品名が文字で入力されていたため集計もできなかった。

この案件の中身

運用状況

実運用中。営業8名が日常業務で使用（2026年9月時点）

対象業務

営業部門の顧客管理・案件管理・見積作成・売上集計と、既存顧客および見込み客へのメール／LINE配信。設計・開発・サーバー構築・運用保守まで当社が担当

導入前の手間

顧客・案件・見積は既存の仕組みで管理していたものの、担当営業や商品が「名前の文字列」で入力されていたため、担当者別・商品別の集計ができなかった。営業のステータスと「この人にメールを送っていいか」が同じ項目に同居しており、配信対象を安全に絞り込めない。金額が浮動小数で保存されていて合計に誤差が出る。参照先が消えても関連データが残る作りで、明細だけが孤立していた。そしてメールやLINEの配信の仕組みがそもそも無く、顧客リストはあるのに接点を作れていなかった。

実装した範囲

• —顧客（企業）・店舗・連絡先（個人）の階層と、案件のパイプライン、見積、商品マスタ、数量別の卸価格、活動記録、訪問記録、タスク、売上ダッシュボード
• —見積を画面で作成してA4で印刷できる帳票出力。受注が決まると顧客の導入商品に反映され、月額サービスの定期案件は毎月まとめて確定できる
• —メール配信のシナリオエンジン。受注や問い合わせをきっかけに、条件分岐を含む複数通の配信が自動で進む。開封・クリック・配信停止を外部ツールに頼らず自前で計測
• —配信対象を条件で絞るセグメント機能と一斉配信。実顧客へ送る前に必ずテスト送信を通す安全段つき
• —LINE公式アカウントとの連携。友だちと顧客台帳を紐づけ、LINEの画面から商品を選んで発注できる導線と、LINEでの一斉配信
• —自社サイトでの閲覧行動の計測と、匿名の訪問者を顧客に紐づける名寄せ、行動にもとづくリードスコアリング
• —ホームページの問い合わせフォームから顧客台帳への自動連携
• —旧システムからの移行。何度実行しても結果が同じETLで、担当者名を担当者ID、商品名を商品IDに変換し、混在していたステータスを営業状態と配信可否に分離

確認できている成果

• —営業8名が日常業務で使用中（本番稼働）
• —顧客369社を旧システムから移行し、案件・見積・売上・配信履歴を1つの顧客画面に集約
• —見積の作成からA4印刷までを画面上で完結
• —メール配信のシナリオが自動で回り、開封・クリック・配信停止を自前で計測できる状態に
• —LINEの友だちと顧客台帳が紐づき、LINEから直接発注できる導線まで到達

開発期間・体制

前身の仕組みから作り直し、約1週間で主要機能を移植して本番稼働。以降も機能追加を継続。設計・実装・サーバー構築・運用まで代表1名で対応

費用目安

この規模を今の料金体系で作る場合は個別見積（初期費用0円・月額制）。顧客管理だけ、配信だけといった1領域なら月額2万〜6万円（税別）

対応できない条件

• —会計・請求の本格的な機能は範囲外。会計ソフト側に任せる前提で、連携が必要な場合は別途相談
• —配信は特定電子商取引法にもとづくオプトアウト方式で運用するため、取得経路が説明できない連絡先は配信対象に入れられない。導入時にリストの仕分けが必要になる
• —メールの到達率はSPF・DKIM・DMARCの設定に依存する。ドメイン側の設定ができない場合は配信の効果が出ない
• —サーバー1台構成のため、数時間の停止は許容する前提。毎晩のバックアップと5分ごとの死活監視で「データは失わない」ことを担保している

使った技術

Django 5.2、PostgreSQL 17、Procrastinate（非同期ジョブ）、HTMX / Alpine.js / Tailwind、Docker Compose / Caddy、SendGrid、LINE Messaging API / LIFF