結論|保証文を書く前に、「何が起きたら誰がどう対応するか」を決める
Makuake公開前には、商品の魅力や配送予定だけでなく、不具合が起きたときの対応も決めておく必要があります。
ここで「1年保証」「初期不良は交換」と文章だけ先に作ると、公開後に問い合わせが来たとき、誰が何を確認し、どの条件で交換・修理・返金へ進むのかをその場で決めることになります。
不具合が起きたときに、実際に履行できる対応手順を短く表示したものです。
Makuake公式では、リターンの管理やプロジェクトに関することは各実行者が行い、不具合・破損時の返品・修理・交換は、まず実行者へ直接問い合わせる運用としています。
さらに、実行者への問い合わせは公開後にメッセージで届き、Makuake公式は遅くとも3営業日以内の返信を求めています。
そのため公開前に、問い合わせ窓口 → 状況確認 → 対応判断 → 修理・交換・返金等の実行 → 完了連絡までを一つの運用として決めます。
Makuake公式:
届いたリターンに不具合 / 破損がある
サポーターからメッセージが届きました。どうすればいいですか?
1|最初に「何を不具合として扱うか」を分ける
「不具合があれば交換」とだけ決めても、実際の問い合わせでは症状が異なります。
| 問い合わせ内容 | 公開前に決めること |
|---|---|
| 到着時の破損 | 写真・外箱・注文情報など、確認に必要なもの |
| 初期動作不良 | どの手順で症状を確認し、交換・修理を判断するか |
| 注文内容との相違 | 誤配送・不足品をどう確認し、再発送するか |
| 使用中の故障 | 保証対象期間・対象症状・修理可否 |
| 仕様への不満 | 商品不良と、説明済み仕様への不満をどう分けるか |
同じ「使えない」という問い合わせでも、配送破損、初期不良、使用方法、仕様理解の違いでは対応が変わります。
公開前に症状を分類しておけば、問い合わせを受けてから判断基準を作り直さずに済みます。
2|保証期間より先に、「何を保証するか」を決める
保証を考えるとき、「半年」「1年」のように期間から決めたくなります。
しかし期間だけ決まっても、保証対象が曖昧なら運用できません。
- 対象:自然故障、部品破損、初期不良など、何を保証するか。
- 除外:誤使用、消耗、外観傷など、対象外とするもの。
- 対応:修理、部品交換、本体交換、返金など、何が可能か。
- 確認資料:注文情報、写真、動画、シリアル等、何が必要か。
- 履行可能期間:部品・交換在庫・メーカー対応がいつまで続くか。
「競合が1年だから」ではなく、実際に修理・交換を履行できる期間と、商品カテゴリで必要な条件を確認してから表示します。
3|返品・交換条件は、「全部不可」で簡単に処理しない
返品・交換条件は、問い合わせを減らすために厳しくすればよいわけではありません。
Makuake公式の現行ガイドでは、「いかなる場合も返品・交換は一切受け付けない」といった一律不可の表現について、初期不良や注文と違う商品が届いた場合まで責任を免除する内容は、法律上認められない可能性が高いと説明しています。
また、不具合が理由なのに返送料をサポーター負担とするなど、不当な負担を課す条件にも注意を促しています。
どの状態なら、誰がどの負担で、どの対応へ進むかを双方が判断できる条件です。
法的な解釈に迷う場合は、Makuake公式も弁護士などの法律専門家への相談を案内しています。
Makuake公式:
返品交換の条件設定に関する留意点
4|問い合わせ窓口は、「誰が読むか」まで決める
Makuakeでは、プロジェクト公開後に実行者への問い合わせフォームが設けられ、サポーターや応援購入を検討しているユーザーからメッセージが届きます。
窓口があるだけでは、対応体制があるとは言えません。
| 公開前に決めること | 具体化する内容 |
|---|---|
| 一次受付担当 | 誰がMakuakeのメッセージを毎営業日確認するか |
| 商品判断担当 | 症状が仕様か不具合かを誰が判断するか |
| メーカー連携 | 海外メーカー等へ誰が確認し、何日以内に返答を得るか |
| 交換・返金承認 | 誰が最終判断し、誰が実行するか |
| 返信期限 | 3営業日以内というMakuake上の返信目安に間に合う体制か |
特に輸入商品では、実行者、海外メーカー、物流会社、修理会社など複数の関係者が入ることがあります。
サポーターへ「メーカーへ直接問い合わせてください」と丸投げするのではなく、実行者側で一次受付してどこへつなぐかを決めておくと、連絡先探索をサポーターへ押し戻さずに済みます。
5|交換・修理を約束するなら、「交換できる現物」まで確保方法を決める
ページに「不具合時は交換します」と書いても、交換在庫がなければ実行できません。
公開前に、最低でも次を確認します。
- 交換用在庫:初回発注の中から何個を確保するか。
- 部品:故障しやすい部品だけ交換できるか。
- 再製造:在庫がなくなった場合、何日で再調達できるか。
- 修理先:国内で修理できるか、海外返送が必要か。
- 送料:どのケースで誰が負担するか。
この確認は、保証条件だけでなくMOQや初回発注数にもつながります。
MOQと余剰在庫の考え方は、MakuakeのMOQはどう設計する?最低発注数と応援購入数がずれたときの在庫判断で整理しています。
なお、Makuake終了後に一般販売を予定している場合は、この対応フローをMakuakeだけの臨時運用にせず、その後も使える形にしておくと、保証・問い合わせ体制を作り直す作業を減らせます。
公開前は、この5項目を一枚にまとめる
| 確認項目 | 決めること |
|---|---|
| 1. 不具合分類 | 何を不具合・破損・仕様差として扱うか |
| 2. 保証条件 | 対象、除外、期間、必要資料 |
| 3. 対応方法 | 修理、交換、返金等の選択条件 |
| 4. 問い合わせ担当 | 一次受付、判断、承認を誰が担当するか |
| 5. 履行手段 | 交換在庫、部品、修理先、送料条件 |
何か起きたときに、サポーターが窓口を探さず、実行者側も判断を作り直さずに対応できる状態を公開前に作ります。