店舗・日付・割引を管理する小売プロモーションプランナーアプリ

なぜ多くの小売チームでプロモーション計画が破綻するのか

プロモーション計画は最初は単純に始まります：スプレッドシート、いくつかのメール、日程確認のチャットメッセージ。しかし同じプロモが三か所にコピーされ、別の人が編集し、どれが最終版かわからなくなる。

問題はスプレッドシートが悪いことではありません。プロモーションは共有作業だからです。スプレッドシートとチャットとメールは唯一の真実の情報源を提供せず、小さな変更が競合を生むときに警告もしません。

プロモが散らばると同じ問題が繰り返されます：

• 重複割引（2つのプロモが誤って重なってスタックする、または新しいプロモが古いプロモのマージンを消す）
• 日付ミス（プロモが早く始まる、遅く終わる、ブラックアウト期間にかかる）
• 対象店舗の間違い（地域限定オファーが全店舗に適用されたり、重要な店舗が抜ける）
• 店舗に届かない直前の変更（店舗マネージャーが客より後に知る）

店舗マネージャーに必要なのは複雑な計画ツールではありません。今週何が実施されているか、明日何が変わるか、自分の店舗に何が適用されるかを答える一つのカレンダービューです。

小売プロモーションプランナーの仕事はシンプルです：プロモを一箇所で計画し、公開前に競合を検出し、店舗チームが信頼できるカレンダーを公開すること。そうなればマーケティングは素早く動け、オペレーションは例外処理が減り、マネージャーは更新を追いかける時間が減ります。

プランナーが扱うべきこと（そして扱うべきでないこと）

プランナーが機能するためには、全員がそれの目的に合意している必要があります。マーケティングはオファーを定義する場所が必要です。地域マネージャーはタイミングと領域を守る必要があります。店舗マネージャーはメッセージを掘り返さずに来るものをすぐに見たい。

範囲は狭く保ってください。各プロモについてプランナーは次の4つの質問に答えられるべきです：

• 日付と時間はいつか？
• どの店舗が含まれる（除外される）か？
• 割引ルールは何か（選択カテゴリの20%オフ、BOGO、金額での割引など）？
• 実行のためにマネージャーが必要とする注記は何か（サイネージ、制限、クーポンコード、連絡先）？

これらがしっかりしていれば、人々はプランナーを信頼します。

扱うべきでないこと：すべてのレジ端末の細かいケースを扱う完全なプライシングエンジンや需要を予測する在庫計画ツールです。それらはより大きく変更が難しく、既に存在することが多い。あなたのプランナーは「POSルールIDで価格処理」とか「在庫チェック必要」のようなフィールドで参照するだけでよく、置き換えようとしないでください。

使いやすくするために、画面数は小さく抑えます：プロモ一覧、プロモフォーム、カレンダービュー、簡単な承認ビューの4つ程度が理想です。

必要なデータ：店舗、日付、割引、割り当て

クリーンな共有データがないとプランナーは機能しません。基本が欠けていると、チームはプロモの意味を議論して計画に時間を使ってしまいます。

まずは店舗から。各店舗には安定した店舗ID、地域（または地区）、タイムゾーンを持たせてください。タイムゾーンは思ったより重要です："金曜9時開始"はどこでも同じ瞬間ではありません。営業時間を追加すれば、開店前に始まるプロモや閉店後に終わるプロモを検出できます。

次にプロモの定義。分かりやすく：店舗マネージャーが認識できる名前、開始・終了日時、ステータス（下書き、レビュー中、承認済み、公開済み）、タイプ（季節、クリアランス、会員限定、価格マッチ）、チャネル（店頭、オンライン、メール、SMS）。チャネルを明確にすると「棚札はあるがウェブサイトにはない」といった混乱を防げます。

割引の詳細も構造化する必要があります。一般的な形式に対応してください（%オフ、金額オフ、買一送一など）と、任意の上限（アイテムごとやバスケットごとの最大割引）。上限が記録されていないとカスタマーサービスが端数の対応に困ります。

対象は「何が割引されるか」を示します。カテゴリ、特定のSKU、任意で顧客セグメント（例：ロイヤルティ会員）をサポートしてください。

最後に割り当て：どの店舗がどのプロモを受けるかをつなげます。簡単なサニティチェックリスト：

• すべてのプロモに開始、終了、ステータスがある
• すべてのプロモに少なくとも1つの店舗割り当てがある
• すべての割引に明確なルールと必要な上限がある
• すべての対象はカテゴリやSKUリストであり、フリーテキストではない
• すべての店舗にタイムゾーンと営業時間がある

シンプルなワークフロー：ドラフト、レビュー、承認、公開

全員が同じ手順に従うとプランナーは機能します。ワークフローはシンプルに、各ステップに明確な担当者と引き継ぎを用意してください。

まずドラフト。トレードマーケティングやマーチャンダイジングがプロモを作成し、日付を設定し、割引を選び、店舗を割り当てます。ドラフトは簡単に変更できるべきです。大半の編集はここで行われます。

次にレビュー。地域マネージャーがプロモが現実的か確認します：適切な店舗が含まれているか、日付が営業カレンダーに合っているか、明らかな競合がないか。この段階でサイネージの注記や不明瞭な制限を見つけるのが最善です。

問題なければ承認し、最後に動かしてはいけない部分をロックします。実務的なルールとして、日付、店舗リスト、割引レベルのような主要フィールドをロックしてください。ロックされたフィールドを変更する必要がある場合は、新しいリビジョンを作って再レビューさせるべきで、店舗がすでに見たものをこっそり編集してはいけません。

最後に公開。店舗マネージャーがスプレッドシートやメールを探す必要がないように、店舗ごとの一つのカレンダービューでプロモ名、日付、割引が平易な言葉で表示されるべきです。

管理を保ちつつ遅くしないワークフローの例：

• 下書き（プランナーが編集可能）
• レビュー（地域チェック必須）
• 承認（日時、店舗、割引レベルをロック）
• 公開（店舗カレンダーに表示）
• 変更（新リビジョン＋影響を受ける店舗への通知）

店舗に届く前に重複を検証するルール

多くのプロモのミスはクリエイティブな問題ではなく、単純な競合が誰にも同じようにチェックされなかったことによるものです。プロモを保存または提出するときに自動でチェックを走らせるべきです。

ほとんどのサプライズを防ぐ重複チェック

説明しやすいルールから始め、厳しくしていきます。

• 店舗と日付の競合： 同じ店舗で同じ日付をカバーするプロモが2つある場合、割引ルールが完全に一致しない限り（同じタイプ、同じ深さ、同じ条件）フラグを立てます。
• 商品競合： 同じSKU（またはカテゴリ）が同時に2つのプロモに含まれる場合は、明確な優先度（例：「BOGOが10%オフに優先する」）を要求するか、ブロックします。
• 予算とガードレール： 「最大30%オフ」「店舗あたり週3件まで」「月に一度の深掘り割引は1回まで」などの上限を設定します。警告よりもハードストップが効きます。
• ブラックアウト日： 棚卸、主要祝日、システムアップグレード予定、配送の空白日など、サポートできない日はブロックします。
• タイムゾーンと開始／終了時間： 開始と終了時間は本社時間ではなく各店舗のローカルタイムで検証します。

競合は煩わしいものにせず、実行可能にする

ルールが失敗したときは、何が競合しているのかと次にできることを具体的に示してください：日付を変える、店舗を削除する、SKUを除外する、優先度を設定する、など。

例："店舗014は '冬のクリアランス'（20%オフ）が1月12〜14日に予定されています。あなたの新しいプロモは1月13〜14日で重なっています。"

店舗マネージャーが実際に使うカレンダービューの公開

プロモ計画は店舗マネージャーが素早く見て信頼し、行動に移せるときにだけ役に立ちます。カレンダーはソース・オブ・トゥルースのように感じられるべきで、解読するレポートではありません。

月間ビューと週次ビューの2つでほとんどのニーズをカバーできます。月間ビューは「これから何が来るか」を答え、週次ビューは「今日は何を準備すべきか」を答えます。色分けは有用ですが一貫性を保ってください。ステータス別かプロモタイプ別かのいずれかの方式を決めて統一します。

フィルタは特に複数店舗を担当するマネージャーにとって重要です。デフォルトはシンプルに：

• 店舗（閲覧者の店舗をデフォルトに）
• 地域または地区
• プロモタイプ
• チャネル（店頭、オンライン、両方）
• ステータス（下書き、承認済み、公開済み）

プロモをクリックしたら店舗で使う詳細を表示します：短い割引サマリ（何を、どれだけ、いつ）、含まれる店舗、設置に影響するメモ（サイネージ、制限、除外）。特別な条件があれば上部に置きます。

運用負荷を下げるために二つのフォーマットを用意すると便利です：バックオフィスの掲示用と朝礼用の印刷ビュー、そして忙しい週のためのデイリーアジェンダ（今日始まる・終わるもの）。

レポートは過度に作り込まないでください。日付範囲、店舗、プロモ名、割引、ステータスのリスト形式での基本的なエクスポートで十分なことが多いです。

承認と権限を複雑にしない方法

誰でも編集できる状態が混乱の始まりです。解決は十個の役割ではなく、三つの明確な役割、シンプルな編集ルール、見える承認記録です。

実用的な構成例：

• マーケティング編集者： プロモ作成、日付調整、割引タイプ／値の選択、内部メモの追加が可能。公開はできない。
• 地域承認者： 承認、却下、修正要求が可能。店舗割り当てや日付を必要に応じて調整できる。
• 店舗閲覧者： 公開カレンダーとプロモ詳細を参照のみ。店舗メモの追加は可だが、割引や日付の変更は不可。

承認後にフィールドをロックして編集を予測可能にします。例えばマーケティングは実行メモは更新できるが、日付、店舗、割引値の変更は再承認が必要にする、という具合です。これでサイネージやスタッフ、在庫計画を壊す静かな変更を防げます。

承認は軽量なトレイルを残してください：誰がいつ承認したか、何が変わったか。読みやすい承認ログがあれば事後検証で十分です。

通知は静かでターゲットを絞ってください。店舗に影響があるときだけアラートする：新しいプロモが割り当てられた、日付が変わった、プロモが中止になった、など。内部メモが書き換えられただけで店舗に通知しないでください。

各プロモの古いバージョンは保存しておいてください（直近5件程度でよい）。店舗から「消えた割引は何だった？」と問い合わせが来たときに、そのプロモがいつ実施されていたか、誰が変更したか、なぜかを答えられます。

ステップ・バイ・ステップ：週次のプロモサイクル設定と運用

週次のリズムを作るとプロモが明確になります。変更の締切時間を一つ決めてください（例：水曜正午）。そこから変更は止まり、カレンダーが確定します。

一度だけのセットアップ

すべての店舗を地域とタイムゾーンにマッピングします。再利用できるプロモテンプレートをいくつか作ります（例：「週末10%オフ」「クリアランス2つで1つ」）。プロモを店舗単位、地域単位、店舗グループ単位のどれで割り当てるか決めます。クリック数が少ないほどミスは減ります。

この基礎ができれば、計画は毎回ゼロから作るのではなくスケジュールに記入するような感覚になります。

週次運用

翌週のプロモをドラフトして正確な開始・終了時刻を設定します。特に問題になりやすい境界（金曜夜、月末、祝日）を明確にしてください。公開前に重複チェックを走らせ、競合は日付調整、対象商品の絞り込み、またはどのプロモを優先するかの判断で解決します。承認に出して公開します。

特別な対応が必要なら短いマネージャーノートを追加します（例：「エンドキャップのみ」「ロイヤルティクーポンと重ねないで」）。

例：12店舗で「週末ホーム用品20%オフ」を予定しているが、同時に月初のロイヤルティ割引（10%）が毎月第1週末に適用されるケースがある。

プランナーでドラフトし、12店舗を割り当て、対象を「ホーム用品（クリアランス除外）」に設定して検証を実行すると、3店舗が既存のローカルな会員向けブースト（例：会員15%）と重なり、許容される最大割引を超えてしまうとフラグが立ちます。

解決の方法は主に3つ：

• その3店舗だけ翌週に日付をずらす。
• 日付は維持して対象商品を狭める（例：マージンの厳しい小型家電を除外）。
• 日付と対象を維持しつつ、その期間はロイヤルティの上乗せを無効にする（スタック禁止ルールを設定）。

競合が解消されたら公開します。マネージャーに見せるのは複雑なルールブックではなく、毎日のクリーンなビューです：日ごとにプロモ名、割引、短い注記が表示されます。

実行に役立つ軽いフォローアップ：サイネージや人員のためのメモ欄（例：「金曜17時までにエンドキャップ設置」「土曜12時〜16時はレジを1名追加」）。

次のステップ：プロセスをチームで運用できるアプリに移す

もしスプレッドシートでプロモが回っているなら、半分はうまくいっています。次は繰り返し作業を小さなアプリにして、全員が同じビュー、同じルール、同じバージョンの真実を見られるようにすることです。

小さく始めて、有用なものを素早く出してください。ひとつの地域、ひとつのプロモタイプ（例：週末の%オフ）、店舗マネージャーが10秒で確認できるカレンダービューを最初に作り、他は後回しにします。

よくある構築順序：

• 基本をモデリングする：店舗、プロモ、期間、割引ルール、店舗割り当て
• 公開前の競合を防ぐ重複チェックを追加する
• 軽い承認ステップと公開ステータスを追加する
• プロモ公開や変更時に1回だけ通知を送る
• 店舗マネージャー向けの読み取り専用カレンダービューを出す

データモデルは柔軟にしておきましょう。プロモは時間とともに変わるので、プロモタイプや条件を想定してハードコーディングしないでください。

完全な内部ツールとして別システムをつなぎ合わせずに作りたい場合、AppMaster（appmaster.io）は選択肢の一つです：同じ画面、データ、承認ルールから本番対応のバックエンド、ウェブアプリ、ネイティブモバイルアプリを生成できます。