販売パターン別ケース集

このページは、特定商取引法に基づく表記を「表示項目の一覧」ではなく、「実際に何を売ると何が増えるのか」という順番で読むためのケース集です。

販売という言葉は一つですが、買い切りのWebツール、月額SaaS、ダウンロード商品、物品、受託、予約販売、マーケットプレイス、アプリストア販売では、同じ条件をそのまま使い回せるわけではなく、見た目上は「購入する」ボタン一つでも、その後ろに必要な表示、契約、決済、返品、提供、サポートその他はかなり変わります。

ケース1　買い切り980円のWebツール

あるWebツールへ「980円で購入」というボタンを付けるとします。

ここで最初に決める必要があるのは、980円が税込か、何を購入すると何が使えるようになるのか、いつから利用できるのか、何台まで使えるのか、アップデートは含まれるのか、不具合時の対応はどうするのか、返金条件はどうするのか、といった内容です。

単に価格を表示するだけでは、利用者は「何に対して980円を払うのか」を完全には判断できません。

ケース2　月額980円のSaaS

同じ980円でも月額になると、論点は大きく増えます。

課金周期、自動更新、解約方法、解約期限、次回請求日、無料期間、プラン変更、日割り、支払失敗、解約後の保存データその他を決める必要があります。

「980円」と「月額980円」は、数字が同じでも契約としてはかなり別物です。

ケース3　初月無料

初月無料を付ける場合、利用者が無料期間終了後にいくら支払うのか、いつから課金されるのか、自動的に有料へ移行するのか、無料期間中に解約する方法は何かを確認できるようにします。

無料という言葉が強いほど、その後の有料条件は目立たなくしてよいのではなく、むしろ分かりやすくする必要があります。

ケース4　テンプレートをダウンロード販売

テンプレート、データ、PDF、ソフトウェアその他のデジタル商品では、配送はありませんが、提供方法、再ダウンロード、対応環境、ライセンス、利用範囲、返金条件その他が重要になります。

ファイルが一度提供された後の返品をどう扱うかは、物品販売と同じ発想では処理できません。

ケース5　物品を売る

Tシャツ、グッズ、機器その他の物品を販売すると、送料、配送地域、発送時期、配送方法、受取不能、返品、交換、契約不適合その他が増えます。

在庫品なのか受注生産なのか予約商品なのかでも条件が変わります。

ケース6　受注生産

注文を受けてから作る商品では、通常の在庫商品より提供まで時間がかかります。

そのため、予定時期、遅延可能性、キャンセル条件、仕様変更、制作開始後の扱いその他をより具体的に決める必要があります。

ケース7　予約販売

まだ完成していない商品やサービスを予約受付する場合、いつ提供する予定か、予定が変わる可能性があるか、提供できなくなった場合どうするかを示します。

「予約」という一言だけで提供時期が無期限に曖昧になるわけではありません。

ケース8　受託開発

企業から「このツールを自社向けに作ってほしい」と依頼を受ける場合、Web上の共通販売条件だけでは足りないことがあります。

業務範囲、納期、検収、成果物、修正回数、知的財産、秘密保持、再委託、料金、支払時期その他を見積書、発注書、契約書等で個別に決める方が適切です。

ケース9　マーケットプレイス

第三者も商品を出品できるようにすると、誰が販売者かが重要になります。

oka-project自身が販売するのか、第三者販売者の場を提供するのかで、返金、問い合わせ、表示責任、代金の流れその他が変わります。

利用者が「誰と契約しているのか」を申込み前に理解できる必要があります。

ケース10　紹介リンク・アフィリエイト

外部サービスを紹介し、そこから申込みが発生すると報酬を受け取る場合、自分が販売者ではないことと、広告・アフィリエイトその他の商業的関係を必要に応じて明示します。

紹介ページと販売ページは役割が違います。

ケース11　アプリストアで販売

アプリストアや第三者プラットフォーム経由で販売する場合、決済や返金の一部をプラットフォーム側が管理することがあります。

その場合、oka-project側の条件とプラットフォーム側の条件が重なるため、どちらが何を処理するかを整理します。

ケース12　クーポンを出す

割引コード、初回割引、期間限定価格その他を使う場合、適用条件、期間、対象、併用可否その他を確認できるようにします。

「今だけ」「通常価格より安い」といった比較表示は、実態と一致している必要があります。

ケース13　ポイントを販売する

有償ポイント、クレジット、残高その他を導入すると、単なる値引きとは別の規制が関係する可能性があります。

有効期限、払戻し、失効、譲渡、利用範囲その他を決めるだけでなく、資金決済法その他の適用可能性も確認する必要があります。

ケース14　法人契約

法人向けに月額契約、年間契約、請求書払い、SSO、SLAその他を提供する場合、一般消費者向けの申込み画面だけでは足りないことがあります。

個別契約や見積りで、利用人数、利用範囲、サポート、請求条件、セキュリティその他を定める場合があります。

ケース15　海外へ売る

海外の利用者へ積極的に販売する場合、通貨、税、消費者保護、デジタルサービス規制、返金その他、日本国内だけでは出てこない論点が増えることがあります。

最初から世界中の販売条件を一つのページに仮定で書くのではなく、実際の対象地域が決まった時点で追加条件を具体化します。

ケース16　ボタンを置く直前が一番大事

販売機能を開発していると、決済リンクが動いた瞬間に「完成した」と感じやすくなります。

しかし本当に重要なのは、そのボタンを公開する直前に、価格、追加費用、提供時期、返品・解約、契約主体、最終確認画面その他が実態と一致しているかを確認することです。

販売ページは、コードが完成した日ではなく、条件が具体化した日に公開できる状態になります。

まとめ

特定商取引法に基づく表記は、販売開始時に必要な具体表示の土台です。

販売を始める前の方針は運用思想を説明し、このケース集は売り方ごとの差を物語として追う役割を持ちます。

将来どの売り方を選んでも、まだ決まっていない価格や条件を今のうちに架空で埋めるのではなく、必要な枠組みだけ先に用意し、実際に販売する直前に具体条件へ置き換える方針です。

一文で全部つなぐと

たった一つの「購入する」ボタンを置くとしても、それが980円の買い切りなのか月額980円なのか、初月無料なのか、デジタル商品なのか物品なのか、予約販売なのか受注生産なのか、受託なのかマーケットプレイスなのか、アプリストア経由なのか、自分が販売者なのか第三者が販売者なのか、クーポンを使えるのか、ポイントを使うのか、法人契約なのか海外販売なのかによって、価格、税、追加費用、支払時期、提供時期、返品、解約、自動更新、配送、ライセンス、契約主体、最終確認画面その他の条件が次々に変わり、技術的には同じ色と大きさのボタンであっても法律と契約の世界では後ろにぶら下がっている荷物の量がまったく違うため、決済リンクが正常に開いた瞬間を「販売機能完成」と考えるのではなく、利用者がそのボタンを押す前に必要な条件を理解でき、押した後に何が起きるかが実態と一致している状態まで作って初めて販売の入口が完成したと考える、というのがこの長いページのかなり短くない結論です。