クーポン ユースケース集
具体的なシナリオを通じて、クーポンの配信・利用・管理の流れを示します。
ユースケース1: カフェの新規会員獲得
シナリオ
個人経営のカフェが新規顧客を獲得するため、入会特典クーポンを用意する。
設定
- クーポン名: 初回来店ドリンク1杯無料
- 種別: 無料クーポン
- 配信タイミング: 即時配信（会員証取得時）
- 有効期限: 会員証取得から14日間
- 利用回数: 1回
- 利用条件: なし
- 対象範囲: 当該ショップのみ
流れ
- 来店客が店頭のQRコードをスキャンして会員証を取得
- 会員証取得と同時に「初回来店ドリンク1杯無料」クーポンが配信される
- ユーザーがクーポン一覧で確認し、カウンターで提示
- 店舗スタッフがバーコードをスキャンしてクーポンを使用済みに変更
- ユーザーに無料ドリンクを提供
考慮点
- 14日間の有効期限で再来店を促す
- アカウント量産による不正防止のため、1端末につき1アカウントの制限を検討
ユースケース2: 商店街の買い回り促進
シナリオ
商店街テナントが、加盟店の回遊を促進するためにクロスクーポンを発行する。
設定
- クーポンA: A店で1,000円以上購入するとB店の100円引きクーポンを配信
- クーポンB: B店で500円以上購入するとC店の10%オフクーポンを配信
- クーポンC: C店で利用すると抽選クーポンを配信
流れ
flowchart TD
A["A店で1,000円以上購入"] --> B["B店の100円引きクーポン配信"]
B --> C["B店で500円以上購入"]
C --> D["C店の10%オフクーポン配信"]
D --> E["C店で利用"]
E --> F["商店街全体の抽選クーポン配信"]- ユーザーがA店で買い物をし、クーポンAの条件（1,000円以上）を満たす
- A店でのクーポン利用をトリガーに、B店の100円引きクーポンBが即時配信される
- ユーザーがB店に足を運び、クーポンBを利用（500円以上の購入）
- B店での利用をトリガーに、C店の10%オフクーポンCが配信される
- C店で利用すると、商店街全体の抽選クーポンが配信される
考慮点
- 各クーポンの有効期限をイベント期間に合わせる
- 買い回りの順序を強制するか、任意にするかは運用方針で決める
- 各店舗の利用実績を集計し、商店街全体での効果測定を行う
ユースケース3: 美容室の休眠顧客掘り起こし
シナリオ
美容室が180日以上来店のない顧客を呼び戻すためのクーポンを定時配信する。
設定
- クーポン名: お久しぶりですね！20%オフ
- 種別: 割引クーポン（率割引）
- 配信タイミング: 定時配信（毎日0時）
- 配信条件: 最終来店から180日以上経過した会員
- 有効期限: 配信から30日間
- 利用回数: 1回
- 最低購入金額: なし
流れ
- 毎日0時のバッチ処理で、最終来店から180日以上経過した会員を抽出
- 該当者でまだこのクーポンが配信されていないユーザーにクーポンを配信
- プッシュ通知「お久しぶりですね！次回のご来店で20%オフクーポンをプレゼント」
- ユーザーが予約・来店し、会計時にクーポンを提示
- 店舗スタッフがスキャンしてクーポン利用を確認、20%割引を適用
考慮点
- 配信済みユーザーへの多重配信を防止
- 休眠期間の閾値（180日）は業種によって調整
- 利用率を計測し、閾値や割引率の最適値を見つける
ユースケース4: 天候連動クーポン
シナリオ
チェーン店が雨の日限定で全会員向けクーポンを提供し、悪天候時の来店を促進する。
設定
- クーポン名: 雨の日限定10%オフ
- 種別: 割引クーポン（率割引）
- 配信タイミング: 利用時配信（Just-in-Time）
- 表示条件: 全会員（天候条件は運用で公開/非公開を手動切替）
- 利用回数: 1回/日
- 対象範囲: テナント配下全ショップ
- 利用種別: 見せるだけ
流れ
- 雨の日に管理者がクーポンを「公開」に設定
- ユーザーがクーポン一覧を表示すると、条件に合致するためクーポンが画面に表示される
- ユーザーが店舗でクーポン画面を提示し、スタッフが確認
考慮点
- 全会員が対象のため利用時配信（Just-in-Time）が適している
- 天候判断を自動化する場合は気象APIとの連携を検討
- 「見せるだけ」方式のため利用回数の正確な集計はできないが、来客数の増減で効果測定が可能
- 天候により配信するため、クーポン配信開始を当日決める必要がある
ユースケース5: 抽選クーポンによるイベント集客
シナリオ
ショッピングモールが年末イベントで抽選クーポンを実施する。
設定
- クーポン名: 年末大抽選会
- 種別: 抽選クーポン
- 配信タイミング: 初回配信（イベント開始日に全会員配信）
- 有効期限: イベント期間中（3日間）
- 利用回数: 1回
- 当選商品: 1等 5,000円引きクーポン / 2等 1,000円引きクーポン / 3等 100ポイント / 参加賞 50ポイント
流れ
- イベント開始日にモールテナントの全会員にクーポンを配信
- ユーザーがアプリでクーポンを確認し、イベント会場で「利用する」
- 利用時に抽選が実行され、結果が即座に表示される
- 当選した特典（クーポンまたはポイント）がユーザーに自動付与される
考慮点
- 当選確率と景品総額の事前設計が必要
- 消化率も考慮した上で当選率は決定する
- 抽選結果を記録し、景品の消化状況をリアルタイムで把握
- 抽選期間最後までに景品が当選するように当選率を随時調整することも考慮する
- 景品数に上限がある場合、上限到達後の挙動を定義
ユースケース6: 電子チケット（クーポン機能の応用）
クーポンの「配信 → 提示 → 使用済みに変更」という流れは、電子チケットの「発券 → 入場 → もぎり」と同じ構造です。 インセンティブの種類が「割引」から「入場権」に変わるだけで、システム上の仕組みはそのまま応用できます。
シナリオ
商業施設が施設内イベントの入場管理に、クーポン基盤を電子チケットとして活用する。
設定
- チケット名: 夏休みワークショップ参加券
- 種別: 無料クーポン（特典＝イベント参加権）
- 配信タイミング: 即時配信（予約完了時）
- 有効期限: イベント当日のみ
- 利用回数: 1回
- 利用条件: なし
- 対象範囲: 当該イベント会場のみ
流れ
- ユーザーがアプリからイベントを予約
- 予約完了と同時に「参加券」がクーポンとして配信される
- イベント当日、ユーザーが受付でクーポン画面のバーコードを提示
- スタッフがスキャンしてクーポンを使用済みに変更（＝もぎり）
- ユーザーが入場
クーポンとの対応関係
flowchart LR
subgraph クーポン
A1[配信] --> A2[提示] --> A3[利用] --> A4[使用済み]
end
subgraph 電子チケット
B1[発券] --> B2[提示] --> B3[もぎり] --> B4[入場済み]
end| クーポンの概念 | 電子チケットでの読み替え |
|---|---|
| 配信 | 発券 |
| クーポン提示 | チケット提示 |
| 利用（スキャン） | もぎり（入場確認） |
| 使用済み | 入場済み |
| 有効期限 | 開催日時 |
| 利用条件 | 参加資格 |
考慮点
- クーポン基盤をそのまま利用できるため、チケット専用システムの追加開発が不要
- 定員管理が必要な場合は、配信上限数＝定員として制御できる
- 有料チケットの場合は決済連携が別途必要になる
ユースケース7: 回数券（クーポン機能の応用）
紙の綴りチケットと同じ仕組みを、クーポンの「利用回数」設定で実現できます。 1枚のクーポン＝1冊の回数券として扱い、利用のたびに残回数を減らしていく形です。
シナリオ
個人経営のカフェが、コーヒー10杯分の金額で11回利用できる回数券を電子化する。
設定
- クーポン名: コーヒー回数券（11回）
- 種別: 無料クーポン（特典＝コーヒー1杯引換）
- 配信タイミング: 即時配信（店頭で購入時）
- 有効期限: 購入から90日間
- 利用回数: 11回
- 利用条件: なし
- 対象範囲: 当該ショップのみ
流れ
- ユーザーが店頭でコーヒー回数券（10杯分の金額）を購入
- スタッフが管理画面から回数券クーポンを発行し、ユーザーに配信
- 来店時にユーザーがクーポン画面のバーコードを提示
- スタッフがスキャンし、残回数が1減る（11→10→...→0）
- 残回数が0になるとクーポンが使用済みになる
クーポンとの対応関係
| クーポンの概念 | 回数券での読み替え |
|---|---|
| 配信 | 購入・発券 |
| 利用回数 | 残り枚数 |
| 利用（スキャン） | 1枚もぎり |
| 使用済み | 全枚数消化済み |
| 有効期限 | 回数券の有効期限 |
考慮点
- 有料販売のため、決済完了と配信のタイミングを一致させる運用が必要
- 残回数をユーザーが確認できるUI（例：「残り 5/11 回」）があると利便性が高い
- 有効期限切れ時の未使用分の扱い（返金不可等）を事前に利用規約で定めておく
- 紙の回数券と異なり、第三者への譲渡を防止できる点がメリット