CASE STUDY ・ 小売業 ・ WholeBridge（仮称）
- PHP 8.1
- Socket.IO
- AWS
- Redis
※ 機密保持のため、企業名・プロジェクト名・システム画面は仮名およびモックに置き換えています。
卸売・流通を牽引する、国内有数の「マルシェ流通株式会社」様。
マルシェ流通株式会社様は、食品・雑貨・コスメなど多分野の商材を扱うメーカーと、全国の小売店をつなぐ卸売・流通事業者です。これまで電話・FAX・展示会を軸に行われてきた卸商談を、オンラインで完結できる新しい取引基盤を求めていました。
メーカーは商品を掲載し、小売店は横断的に商品を探して商談を依頼する─双方向のマッチングと、その後の見積・受発注までを1つのプラットフォームで支えるのがWholeBridgeの役割です。
プラットフォームに求められた、4つの構造要件。
- 商談プロセスをオンライン化しなければ、機会損失が続く
電話・FAX・展示会に依存すれば、商談履歴が属人化・散在し、対応漏れと遅延が常態化する。
- 商品マスタを統合しなければ、探索性が上がらない
メーカーごとに台帳がExcel分散すれば、小売店は横断的に商品を探せず取引機会を逃す。
- 見積条件を構造化しなければ、取引が追えなくなる
金額・税・数量のやり取りを記録しなければ、条件交渉の履歴が残らず、後の受発注で齟齬が生じる。
- 即時のやり取りを設計しなければ、商談が遅延する
メール往復に頼れば、商談スピードが落ち、競合に先を越され成約率が下がる。
卸取引を、4つの領域で「止まらない基盤」へ。
マルシェ流通株式会社様と共に、商談・商品マスタ・見積・コミュニケーションの4領域をゼロから内製で構築しました。EC-Cubeを土台にした堅牢なデータモデルの上に、卸取引に特化した商談ドメインを設計しています。
- 領域 01商談プロセス課題
電話・FAX・展示会に依存し、商談履歴が属人化する状況を解消する必要
解決策オンライン商談ルームで一元化依頼〜承認〜交渉〜成約をステータス管理
- 領域 02商品マスタ課題
メーカーごとに台帳がExcel分散し、検索性が低い状態を統合する必要
解決策JANコードで一元管理メーカー横断の商品マスタを構造化
- 領域 03見積・受発注課題
条件交渉の金額・税・数量の履歴が残らない状態を記録可能にする必要
解決策見積を構造化し記録・追跡総額/税/正味とPDF帳票を自動生成
- 領域 04コミュニケーション課題
メール往復で商談スピードが遅く、機会損失が生じる状態を改善する必要
解決策リアルタイムチャットで即時化Socket.IO + Redisで在室・即時同期
マルシェ流通株式会社様の「卸取引のデジタル化」が、加速する。
- 商談を止めない基盤。依頼から成約までをオンラインで完結し、機会損失を最小化する。
- 横断的に商品を探せる設計。JANコードの商品マスタで、メーカーを越えた探索を最大化する。
- 取引を追跡できる構造。見積の金額・税・数量を構造化し、受発注まで一貫して追える。
- 事業判断に集中できる可視化。取引KPIをダッシュボードで把握し、運営の意思決定を高速化する。
- Stakeholder小売店バイヤー仕入れ担当一般的に
展示会や電話で商品を探し、時間がかかりやすい
マルシェ流通では商品マスタを横断検索し、その場で商談依頼
事業インパクト仕入れリードタイム短縮 - Stakeholderメーカー（卸元）商品供給側一般的に
引合が電話/FAXで散在し、対応漏れが起きやすい
マルシェ流通では届いた商談を一覧管理し、即見積回答
事業インパクト商談対応スピード・成約率向上 - Stakeholder営業/取引担当取引管理一般的に
見積条件が口頭・紙で、記録が曖昧になりやすい
マルシェ流通では見積（金額/税/数量）を構造化して記録
事業インパクト取引の透明性・追跡性向上 - Stakeholder運営事業者プラットフォーム運営一般的に
取引全体の状況が見えにくい
マルシェ流通ではKPI・商談ステータスをダッシュボードで可視化
事業インパクト意思決定の高速化
