| クライアント | 販促支援業のクライアント様 |
|---|---|
| 初期費用 | 500,000円 |
| 開発期間 | 4ヶ月 |
| 商流 | 直受け |
取引先ブランドの販売促進プログラムを代行運用しているクライアント様より、営業担当からの申請・複数段階の承認・実施後の報告までを一つのシステムでまとめて管理したい、というご相談をいただきました。
今回は、機材貸し出しを伴う販促プログラムの「申請〜承認〜実績報告」を一気通貫で管理するWebシステムの開発事例をご紹介します。
開発前の課題
関係者もステップも多く、情報が分散していた
販促プログラムの運用には、営業担当・マネージャー・倉庫管理者・事務局といった複数の関係者が関わります。運用の中では、次のような確認や作業が発生します。
- 申請内容の確認
- リージョンごとの実施上限の管理
- 出荷後の内容修正
- 実施後の写真や実績数の報告
関わる人数とステップが多いほど、情報が分散し状況把握が難しくなりがちです。
リアルタイムに状況を把握できる仕組みが求められていた
ご相談の時点でご要望としてあがっていたのは、次の3点です。
| 論点 | ご要望 |
|---|---|
| 承認状況の把握 | 誰の申請が今どの承認段階にあるのかを、関係者全員がリアルタイムに把握したい |
| 実施上限の管理 | リージョンごとの実施件数が上限を超えていないかを、関係者全員がリアルタイムに把握したい |
| 予算の可視化 | 実施後の予算執行状況を、プログラムごと・年度ごとにシステム上で可視化したい |
予算執行状況については、個別に集計するのではなく、システム上で自動的に見える状態にしたいというご要望でした。
ご提案・開発アプローチ
申請フローを3段階の承認ステップとして設計
まず申請フローを、次の流れで進む3段階の承認ステップとして設計しました。
- 申請（営業担当）
- 一次承認（マネージャー）
- 二次承認（事務局）
- 倉庫確認・出荷
各ステータスはシステム上で一元管理できるようにしています。あわせて、プログラム・リージョンごとに申請数を自動集計し、設定した上限を超えそうな場合はアラートを表示する仕組みを実装しました。
出荷後の修正と実績報告をシステムに集約
出荷後は倉庫側で内容修正ができるようにし、イベント実施後は写真つきの完了報告と実績本数の報告をシステムに集約しました。
営業担当には実績報告を促すメールを自動送信し、未報告の場合は指定期間後にリマインドを送る仕組みも組み込んでいます。報告の催促を人の手でやらなくて済む状態にしました。
年度ごとに本番環境を切り分ける構成
機能追加のたびに申請データが新旧仕様で混在してしまうリスクを避けるため、年度ごとに本番環境を切り分ける構成を採用しています。
2023年のリリース以降、2024年・2025年と機能追加のたびに新しい環境へ移行し、過去データはそのまま残す形で運用しています。
実装した主な機能
申請から実績報告までをカバーする機能一覧
- 販促プログラムの新規申請・一次承認・二次承認の3段階ワークフロー
- プログラム別・リージョン別の申請数自動集計と上限超過アラート
- 出荷後の申請内容修正、写真アップロードによる完了報告
- 実績報告の自動依頼メールおよび未報告時のリマインド送信
- 実施金額の個別登録・一括アップロード、年度別の予算集計ダッシュボード
- 役割別の権限管理(営業・ブランド担当者・倉庫管理者・事務局)
- クライアント側システムからの日次データを自動取得し在庫情報を更新する自動連携処理
- 「申請」「一次承認済み」「二次承認済み」「完了報告済み」「実施報告済み」「キャンセル」「不承認」による申請ステータスの多段階管理
申請の状態は7つのステータスで多段階に管理しており、キャンセルや不承認も含めて一覧で追える設計です。
役割ごとに操作できる範囲を分ける
権限まわりは、役割ごとに操作できる範囲を分けて設計しています。
| 役割 | 主な操作 |
|---|---|
| 営業担当 | プログラムの新規申請 |
| 承認者(マネージャー) | 申請の一次承認 |
| 倉庫管理者 | 申請の二次承認、各種マスタの閲覧 |
| 事務局 | 申請の二次承認、各種マスタの登録・編集・削除 |
| ブランド担当者 | 各種マスタの閲覧・ダウンロード |
運用を支えるシステム基盤
画面上の機能だけでなく、裏側の仕組みにもいくつか工夫を入れています。
既存の基幹システムとデータ連携し、二重管理を避ける
まず、クライアントが運用する既存の基幹システムとデータ連携し、ユーザー情報や担当者情報を都度参照できるようにしました。
新規にマスタを持たせるのではなく既存データを参照する設計にすることで、情報の二重管理を避けています。
在庫データの更新をGASで自動化
クライアント側のシステムから、毎日深夜0時ごろに在庫情報のCSVファイルがメールで届く運用になっています。そこで専用アカウントでそのメールを受信し、毎朝5時ごろに内容を取得してシステムへ自動反映する仕組みをGoogle Apps Script(GAS)で構築しました。
これにより、担当者が毎朝ファイルを取り込む作業は発生しません。
現場の運用ルールに合わせた集計ロジック
リージョンごとの集計には、現場ならではの仕様も反映しています。たとえば、複数リージョンにまたがって表示される特殊なケースは集計の対象から外すといった調整を行い、実際の運用ルールに合わせて集計ロジックを細かくチューニングしました。
こうした一つひとつの仕様調整の積み重ねが、現場での使いやすさにつながっています。
導入効果
手作業だった確認・集計がシステム上で完結
承認フローと実績報告がシステム上で完結するようになったことで、進捗確認のための問い合わせや、Excelやメールでの個別集計といった手作業が大幅に減りました。
リージョンごとの上限管理や年度別の予算集計も自動化され、これまで手作業で行っていた確認作業がシステム上で完結するようになっています。
関係者それぞれが必要な範囲だけを操作できる
役割ごとに操作範囲を分けたことで、ブランド担当者は必要なマスタ情報だけを閲覧・ダウンロードでき、事務局は申請の承認を画面上で完結できます。
関係者それぞれが自分の業務に必要な範囲だけを迷わず操作できる状態になったことも、地道ながら運用の負荷軽減につながっています。
リリース後も継続的に機能を拡張
本システムは、ご発注から現在まで段階的に機能を広げながら運用されています。
| 時期 | できごと |
|---|---|
| 2022年 | ご発注 |
| 2023年 | リリース |
| 2024年 | ログイン機能とリージョンの追加 |
| 2025年 | 実施金額管理機能とデータ同期処理の追加 |
運用の中で見えてきた課題を都度システムに反映できる関係性を築けていることも、この事例の特長の一つです。
まとめ
複数の関係者が関わる承認フローや実績管理は、関わる人数が増えるほど情報が分散し、確認作業に手間がかかりやすい領域です。
今回の事例では、申請から承認、実績報告までを一つのシステムに集約し、集計や通知の自動化を組み合わせることで、運用負荷を抑えながら状況を可視化する仕組みを構築しました。
申請・承認フローの管理や、複数拠点にまたがる実績集計の仕組みづくりでお悩みの際は、ぜひお気軽にご相談ください。
