BASEの予約販売のやり方｜発送予定・注文変更・長期予約を確認

BASEで予約販売を始めるときは、商品を受け付ける期間と、発送する予定期間を分けて設定します。受注後の予定変更も一律ではありません。通常予約は商品設定を直しても既存注文の情報が変わらず、長期予約には注文ごとの前倒し操作があります。

この記事では、布バッグ一商品を使い、通常予約の注文Aと長期予約の注文Bを別の条件として追います。入力前の準備から、購入者への連絡、追加利用料、カード承認、発送期限までをつなげ、どの記録を直すか判断できる形にします。

対象は実物の商品をBASEで販売するショップ運営者です。2026年10月12日（日本時間）に公式資料を確認しました。商品・注文番号・日付・金額・文章例は説明用の架空例で、実際の注文や操作の記録ではありません。個別の売上や決済成立は保証されません。

BASEの予約販売は発送予定と販売期間を分けて準備する

予約販売Appと販売期間設定Appの役割を分ける

「予約販売 App」で設定する中心は、商品をいつ発送する予定かという情報です。「10月中に注文を受け付け、11月に発送する」という売り方なら、10月の受付期間と11月の発送期間は別の条件です。予約の発送日を入力しただけで、希望する受付締切も設定できたとは考えないようにします。

注文を受け付ける開始・終了日時を制限したい場合は、「販売期間設定 App」の役割を確認します。発送予定が来たときに通常商品へ切り替わる仕組みと、販売を終了する操作は異なります。限定期間で売るつもりなら、受付を止める方法まで決めてから商品を案内してください。

たとえば布バッグP-01を「10月11日から注文を受け、11月1〜5日に発送する」とします。この文には受付開始と発送期間の二つがあります。さらに「10月20日で受付終了」とするなら、終了日時も別に管理します。購入者に説明する一文を先に作り、それぞれをどの機能で実現するか対応させると、設定漏れを探せます。

公式の導入手順は、予約販売Appをインストールし、予約設定を登録して対象商品と発送予定を指定する流れです。商品登録画面から設定する方法も紹介されています。複数商品をまとめて設定する場合と、一商品の情報を編集する場合を使い分け、対象外の商品まで同じ日程に含めないことが大切です。根拠はBASEの予約販売設定ガイドとBASE Uの予約販売の解説で確認できます。

通常予約と長期予約を日付の条件で分ける

通常予約の発送開始予定日と発送完了予定日は、設定日から八週間以内の範囲で指定します。発送完了予定日は任意ですが、設定する場合は開始予定日の翌日以降です。「11月1日に発送開始、11月5日までに発送」という幅と、「11月1日に到着」という約束は違います。配送日数まで自動で含まれる設定ではありません。

発送開始予定日が五十七日以上先になる長期予約では、日付を一日単位で選ぶ通常予約と扱いが変わります。指定できる最も先の時期は、設定する月の十一か月後の下旬です。上旬は1〜10日、中旬は11〜20日、下旬は21日〜月末という区分で選び、長期予約には発送完了予定日を設定できません。

長期予約で「2027年1月上旬」を選んでも、元日中の発送をすべての購入者へ約束したことにはなりません。購入者向けの表示は上旬という期間であり、ショップが発送処理を始められる状態には、時期に加えてカード承認の条件があります。完成見込みだけで長期予約を選ぶのではなく、この決済待ちも発送手順に含めます。

以下では、同じP-01を通常予約として売る場合をA、長期予約として売る別の設定例をBとします。一つの注文が同時に両方の種類になる例ではありません。商品名が同じでも、注文を受けたときの設定によって、その後に使える操作や利用料の扱いが異なることを比べます。

同じ商品の準備表へ受付と発送を記入する

表は横にスクロールできます。

この準備表には、制作終了の見込みと検品・梱包に使う日を別にメモしておきます。材料が届く日をそのまま発送開始日にすると、検品で不具合が見つかったときに余裕がありません。購入者へ出す発送期間は、材料の入荷予想だけでなく、自分が発送できる状態になる見通しから決めます。

商品写真、種類、在庫数などの基本登録がまだ終わっていない場合は、先にBASEの商品登録方法で土台を整えると進めやすくなります。ここでは予約特有の日付と受注後の操作を扱います。一般の商品情報を作り直すより、既存の商品へ予約条件を正しく追加することに集中してください。

予約に向かない条件を受付前に見つける

予約販売Appは、デジタルコンテンツ販売、定期便、抽選販売、テイクアウトの各Appで作成した商品には利用できないと案内されています。また、予約販売の商品には配送日設定Appを使えず、配送希望日を指定できません。Appを入れているだけで、すべての商品へ同じ組合せを適用できるわけではありません。

用途の決まった贈り物など、到着日が重要な商品では、発送予定だけで相手の希望を満たせるかを考えます。配送希望日の指定を受けられないのに、「希望日を備考へ書けば必ず届く」と案内しないでください。対応できない条件が分かったら、受注後に調整する前提にせず、購入前の説明を直す必要があります。

予約設定を登録して商品ページとカートを確認する

対象商品と開始・完了予定を選んで保存する

通常予約Aを設定するときは、予約販売Appで予約設定の登録へ進み、P-01を選択します。発送開始予定日を2026年11月1日、発送完了予定日を11月5日として、選んだ商品と日付を照合してから保存します。複数商品を選択した場合は、同じ生産予定に含めてよいかを各品番で確認してください。

完了予定日を入力せず開始日だけにする場合は、購入者に見せる情報が変わります。「開始日だけで十分か」「発送に幅があるので完了日も必要か」を、実際の作業計画で判断します。入力欄が任意だから省くという決め方ではなく、購入者が発送時期を理解できる情報が残るかを見てください。

長期予約Bなら、同じ流れでも発送予定は「2027年1月上旬」の区分を選びます。通常予約のように1月5日を完了日として補う操作ではありません。説明文に独自の細かい日を加える場合も、公式表示より狭い範囲を守れるかを確認し、確定していない予定を確約へ変えないようにします。

保存後に見るのは、操作完了の表示だけではありません。対象商品、予約の区分、発送時期の三つを読み直します。別の商品を複製して登録した場合は、とくに古い品番や旧日程が残っていないか確認してください。誤りがあれば、まだ注文がない段階で訂正するほうが、購入者ごとの説明を増やさずに済みます。

商品一覧と詳細では見える情報が違う

予約商品の表示を確認するときは、商品一覧と詳細ページを分けて見ます。公式は、販売期間設定AppのComing Soonと予約販売を併用した場合、一覧ではComing Soonが表示され、予約商品という表示は出ないと案内しています。一方、詳細にはComing Soonと予約商品、発送予定期間が表示されます。

そのため、一覧で予約の表示が見えないという理由だけで、直ちに設定失敗と判断する必要はありません。Coming Soonの併用有無と詳細の表示を合わせて確認します。逆に詳細に予約期間が出ていても、販売期間が意図した日時になっているかは別に点検し、受付開始前なのに注文できる状態になっていないかを見ます。

長期予約の発送時期は、商品詳細や購入者へのメールで上旬・中旬・下旬の表記となり、具体的な日付は表示されないという案内です。自分の管理メモに「1月1日以降」と書いていることと、購入者が「1月上旬」と見ていることを対応させます。問い合わせへ返す説明も、購入時に見た表記とつながる言葉にしてください。

表示確認だけのつもりで、注文や決済を確定する必要はありません。公開状態やプレビューで確認できる範囲を先に使い、費用や在庫変動を伴う購入操作と分けます。実際の画面名や配置が公式資料と異なる場合は、対象Appと最新の公式案内を照合してから進めると、別機能を操作する誤りを減らせます。

同じカートへ入れられる組合せを確認する

予約販売Appを利用した商品は、同じAppを利用したほかの商品と同時購入できるとされています。一方、Appを利用していない通常商品と、予約商品を同時に購入することはできません。ショップに通常販売のポーチもある場合、「バッグとポーチを一つの注文でどうぞ」と案内する前に、その組合せを確かめる必要があります。

長期予約には、同じ発送時期の商品だけを同時購入できるという追加条件があります。1月上旬のバッグと1月上旬の別商品、1月上旬のバッグと1月中旬の別商品は、同じ扱いにできません。この「同じ時期」という制限を、通常予約の商品すべてにも同じ条件で適用されると広げないでください。

確認表には、P-01単品、通常販売の商品との組合せ、同時期の長期予約との組合せ、別時期の長期予約との組合せを分けて記入します。購入者から「カートに入らない」と連絡が来た場合も、商品名だけでなく、予約Appの利用有無と発送時期が分かれば、設定不良か仕様上の組合せかを絞れます。根拠は予約商品とほかの商品の同時購入に関する公式案内です。

一緒に購入できない商品を別々に注文する場合、送料などの負担も購入者の判断に関わります。同時購入できることと、一個口で送ること、送料が一回分になることを同じ意味で使わないようにします。配送方法の設計はBASEの送料設定も参照し、カートの条件とは別に照合してください。

支払方法の対応を予約の種類ごとに絞る

通常予約に対応する方法は、公式設定ガイドではコンビニ・Pay-easy、銀行振込、クレジットカード、Pay IDあと払い、キャリア決済です。BASE全体の支払方法一覧に載っている方法が、すべて予約販売でも使えるとは限りません。商品ページの説明へ一般一覧をそのまま貼り付けないようにします。

長期予約はクレジットカード決済のみで、購入者のPay IDログインが必要です。ショップ側も、BASEかんたん決済でカード決済を利用できる状態である必要があります。カード利用が制限されている状態では承認や決済ができず、注文のキャンセルにつながる可能性があります。商品を作れることと決済を受けられることは、両方確認しておきます。

受注後に発送予定が変わったら商品設定と注文ごとの対応を分ける

通常予約Aは個別連絡、長期予約Bは注文操作を確認する

ここで最初に分けるのは、通常予約Aの「商品設定の変更と購入者への個別連絡」と、長期予約Bの「注文詳細から行う前倒し操作」です。通常予約の商品日付を直したら既存注文も更新できる、という手順ではありません。同じ発送予定の変更でも、触る対象が違います。

通常予約Aは、2026年10月12日に、11月1〜5日発送という条件でカード注文を受けたとします。10月20日に材料の遅れが分かり、新たに受け付ける商品の発送予定を、11月10日開始・11月14日完了へ変更したとします。この変更だけでは、すでに購入したAの注文情報は変わりません。Aの記録には、元の11月1〜5日が残る前提で対応します。

公式は、通常予約の発送予定日を変更しても既存の購入者の注文情報は変更されないため、個別に連絡するよう案内しています。商品ページを直したことを知らせるだけでなく、Aの元の約束、今分かっている見込み、相手に確認したい点を示します。遅れの説明を新しい商品ページへ任せず、対象の注文へ結び付けて残してください。

連絡例は「ご注文Aの発送予定は11月1〜5日でしたが、材料入荷の遅れにより11月10日以降の発送を見込んでいます。変更理由と現在の見通しをご案内します。ご利用予定に支障がある場合は、この注文についてご相談ください」といった形です。原因も新日程も実際に確認できた内容へ置き換え、まだ不明な到着日や返金方法まで約束しないようにします。

通知した内容と購入者の回答を同じ行へ残す

Aの管理行では、注文時の発送予定を消さず、その隣へ変更後の見込みと連絡日を追記します。「11月10日へ変更済み」という一欄だけでは、商品を直したのか、相手へ伝えたのか、注文情報まで変わったのかが分かりません。購入者の回答も別に記録すれば、未返信の注文だけを見つけられます。

同じ商品を複数人が注文していても、用途や返答は同じではありません。一人が了承したことを全員へ適用しないでください。連絡先、注文番号、変更の理由は必要な範囲にとどめ、ほかの購入者の情報をまとめて送らないようにします。返信待ちの間に新しい遅れが分かった場合は、更新した見込みを同じ注文の記録へ追加します。

通常予約では、発送開始予定日より前でも、その予定日を変更せず発送できると公式に案内されています。ただし、支払状況など発送に必要な確認を省いてよい意味ではありません。早く届くことで受け取りに支障が出る商品や長期不在の連絡がある注文では、発送可能かという機能の条件と、購入者との調整を分けて判断します。

名入れや仕様変更も含む注文では、日付だけを確認して制作を進めると、最終仕様を取り違えることがあります。そうした個別条件の確定はハンドメイドのオーダーメイド対応が参考になります。予約日程の変更票には、必要なら最終仕様の記録への参照だけを置き、同じ説明を何度も転記しない方法が使えます。

長期予約Bの前倒しは一注文ずつ操作する

長期予約Bは、2026年10月11日に2027年1月上旬発送として受けた別の注文です。制作が早く進み、10月20日に11月1日へ前倒しする例を考えます。公式の注文変更機能でできるのは前倒しであり、発送開始予定日を後ろへ遅らせることはできません。遅延をこの入力欄で処理できると考えないようにします。

前倒しで選べるのは、変更する日から八日後以降、元の発送開始予定日の前日までの範囲です。10月20日の八日後は10月28日なので、この例の11月1日は範囲内です。「明日には完成するから10月21日へ変更する」という選び方にはできません。完成日ではなく、変更操作の日を起点として範囲を確かめます。

手順は、対象の注文詳細から発送開始予定日の変更へ進み、新しい日を選んで変更する流れです。一注文ずつ行う必要があります。変更後はショップと購入者の両方へメールが送られ、注文詳細の予定日も更新されます。複数のB型注文がある場合、商品設定を一度直したことを、全件の注文変更が済んだ証拠にしないでください。

操作したあとは、Bの元の「1月上旬」、新しい「11月1日」、変更日「10月20日」を残し、通知と注文詳細の結果を照合します。自動キャンセル日も変更されるため、前の期限をそのまま発送管理表へ残さないことが必要です。新しい日から機械的に六十日を足すのではなく、カード承認に基づく期限を注文ごとに確認します。

二つの注文を混ぜずに変更の結果を照合する

表は横にスクロールできます。

この比較表は、遅れたAと早めるBを同じ方法で片付けないためのものです。Aで購入者が返信したら回答欄を更新し、Bで注文操作が終わったら表示と通知の確認欄を更新します。対応済みの意味をそれぞれ決めておけば、商品ページを変更しただけで全件終了とする誤りを避けられます。

通常予約・長期予約それぞれの変更条件は、発送開始・完了予定日の変更に関する公式ヘルプが根拠です。とくに長期予約で後ろ倒しが必要なときは、この前倒し機能で代用できません。状況を整理して購入者へ連絡し、該当注文の決済状態に合う公式の対応を確認してください。

長期予約の決済・利用料・発送可能日を照合する

時間が過ぎても自動で通常予約にはならない

長期予約Bを受けたあと、日が進んで発送開始予定日まで五十六日以内になっても、長期予約が自動的に通常予約へ切り替わるわけではありません。公式は、通常予約にしたい場合、発送開始予定日が来る前に、その予定日を手動で変更する必要があると説明しています。

ここには三つの状態があります。長期予約のまま日数だけが減った状態、商品設定を手動で変えて通常予約として新たな注文を受ける状態、発送開始予定日を過ぎて通常商品になる状態です。二つ目の「通常予約」と三つ目の「通常商品」を同じ言葉でメモすると、予約表示や受付の判断を誤りやすくなります。

Bを11月1日へ前倒しした後に、新しい注文Cを受ける場合も、BとCの条件を分けて確かめます。商品側を手動変更し、発送開始まで五十六日以内の通常予約としてCを受けたなら、Cは長期予約の追加利用料の対象にならないという案内です。Bの注文だけを前倒ししたことから、商品側も変わったとは判断しません。

商品を手動で変更した日時と、Cが注文された日時を残すと、適用関係を追えます。販売ページの現在の表示だけで過去のBを通常予約扱いに書き換えないでください。費用の分類は、その注文を受けたときの設定を基に照合する必要があります。

追加一パーセントの対象額と適用時点を確かめる

長期予約では、2024年5月15日15時以降に入った対象注文に、注文金額の一パーセントの長期予約販売利用料が発生すると案内されています。計算対象は送料などを含む注文金額で、小数点以下の端数は四捨五入です。商品の価格だけに一パーセントを掛ければ済むと考えないようにします。

Bの商品代金を4,000円、送料を500円、ほかの加算・割引なしとすると、注文金額は4,500円です。一パーセントは45円になります。この45円は長期予約による追加利用料の例であり、BASE利用時のすべての費用でも、その注文の利益でもありません。材料・配送などの費用も別に管理します。

既存のBを前倒しして発送まで五十六日以内にしても、注文時に長期予約だったBには利用料がかかります。これに対し、商品側の設定を通常予約へ変えた後に入ったCは、該当条件なら長期予約の利用料がかからない扱いです。「同じ日に発送するから同じ費用」という分け方ではなく、注文時の種類を残して判定します。

長期予約の商品代金は、商品を発送するタイミングで決済されるとされています。追加利用料を売上の見通しに織り込むことと、実際に明細へ計上されたことは別に記録します。注文受付時の予定額だけを確定費用として帳簿へ写すのではなく、発送後の明細と突き合わせてください。

カード承認と注文の状態を見てから発送する

長期予約では、購入者のPay IDに登録された「通常使うカード」で与信審査、つまりカード承認が行われます。発送可能になる日の五〜一日前に承認が行われ、承認されたうえで対象の発送開始時期になると、注文が「対応開始前」から「未対応」へ変わる仕組みです。

上旬なら1日、中旬なら11日、下旬なら21日が、発送を始められる時期の基準です。ただし、カレンダーがその日になったことだけで発送してよいとは限りません。長期予約は、注文が「未対応」になっていることを確認します。作品が早く完成したときも、通常予約の前倒し発送の説明をそのまま当てはめないでください。

Bを11月1日へ前倒しした例では、制作予定の欄を11月1日に変えるだけでなく、承認の確認欄を追加します。承認前なら「確認待ち」、承認結果が反映されたら実際の日付と注文状態を記録します。予定表の色を変えただけで、実際の決済準備まで整ったことにしない運用が必要です。

デビットカードやプリペイドカードでは、長期予約の注文時に一時的な引き落としが発生する場合があると公式に案内されています。この動きを見た購入者から問い合わせがあっても、ショップ側で最終的な決済や返金時期を推測して断定しないようにします。一時的な引き落としの取消と、注文そのもののキャンセルを混同しない説明が必要です。

承認エラーと発送期限は別の欄で追う

承認に失敗すると、購入者へメールで通知されます。購入者はPay IDへログインし、通常使うカードの情報を確認・更新する流れです。エラーメールの送信から五日以内に有効なカードへ更新できない場合、注文はキャンセルされるとされています。ショップがカード番号を聞き取って代わりに登録する方法ではありません。

承認処理は一日一回のため、購入者がカード情報を変更した直後に注文が更新されるとは限りません。購入者の「変更しました」という返信と、注文の承認結果を別に確認します。一方、承認が済んだ後のカード変更は当該承認へ反映されず、発送時にそのカードを利用できないと決済エラーになる場合があります。

カードを継続利用できない場合、公式は注文をキャンセルして再注文する対応を案内しています。実際に必要かは、承認前か承認後か、カード会社側で解決できるかを確認して判断します。二重注文や二重発送を避けるため、元注文の状態を確かめずに新注文だけを促さないようにしてください。

長期予約の自動キャンセル期限は、カード承認日から六十日後です。注文日から六十日と数える通常のカード注文とは起点が違います。たとえば承認日を仮に10月27日と置くなら、六十日後の暦日は12月26日ですが、実際の管理には注文詳細に表示される期限を使います。発送開始予定日の11月1日から数え直す例ではありません。

仕組みの根拠は長期予約の商品に関する公式注意事項と予約商品の発送可能時期の公式案内です。Bの記録には、注文時の種類、追加利用料45円という試算、実際の承認日、未対応への変更、注文詳細の取消期限を並べます。これらは異なる確認項目なので、一つの「決済済み」欄へまとめないほうが追いやすくなります。

発送前は支払方法ごとの自動キャンセル期限を見る

未入金の期限と未発送の期限を分ける

通常予約Aでは、発送予定期間の中に発送することに加え、支払方法ごとの自動キャンセル期限にも間に合う必要があります。予定を遅らせたとき、商品ページの新しい日程だけを見ていると、注文が先にキャンセルされることがあります。予約であることを理由に、支払期限や発送期限が無期限になるわけではありません。

最初に、代金が未払いなのか、支払いや承認は済んでいるが未発送なのかを分けます。コンビニ払いの未入金期限とカード注文の未発送期限を同じ「注文から何日」の欄へ入れると、何をすれば期限の条件が変わるか分かりません。注文番号ごとに、支払方法と現在の状態も一緒に記録してください。

コンビニ・Pay-easyは、注文から五日後までに支払いがない場合に自動キャンセルされるという案内です。入金済みなら、この未入金による自動キャンセルの説明は当てはまりません。ただし、入金後も発送期限があるため、「払ってあればいつ発送してもよい」とは考えないようにします。

銀行振込は、未入金なら注文から五営業日後が基準です。さらにBASE口座への入金確認と自動キャンセル処理のタイミングに関する案内があるため、単にカレンダーで五日足す方法ではありません。休日を含む注文はとくに、暦日と営業日を混ぜず、購入者に示された支払案内を確認してください。

入金済みの銀行振込・コンビニ決済には、注文日から六十日後という発送期限があります。期限を過ぎると自動的に「対応済」となり、売上が計上されますが、実際に商品が発送されたことを意味しません。この処理では商品発送の通知メールは送信されず、その後もBASEのシステムから発送通知を送れないため、実際の発送状況を確認して購入者へ直接連絡します。詳しくは未発送なのに対応済となった場合の公式案内を確認してください。

予約で使える支払方法だけを期限表に並べる

表は横にスクロールできます。

銀行振込について、公式は支払期限の翌営業日午前中までにBASE口座へ入金が確認された注文はキャンセルされず、未入金注文の自動キャンセル処理は翌営業日午後に行われると説明しています。この処理の説明を、購入者へ延長を約束する根拠にはしないでください。購入者には所定の期限内の支払いを案内します。

カードの六十日という行は、通常のカード注文の条件です。公式には販売パートナーApp利用時の別期限もありますが、今回の予約販売の例へ混ぜません。また、一般の自動キャンセル一覧に載るAmazon Pay、PayPal、PayPayなどの期限を、予約販売Appで利用できる方法として追加していません。

期限を一覧に転記するときは、単位だけでなく起点もそのまま残します。キャリア決済の「注文日の翌日から」と、カード注文の「注文から」を同じ書式に丸めると、境界を取り違える原因になります。公式の自動キャンセルになるまでの期間を開き、利用している決済の項目で確認してください。

通常予約Aと長期予約Bの期限を別々に記入する

通常予約Aは10月12日のカード注文なので、注文日から六十日後の暦日は12月11日です。変更後の発送見込みが11月10日なら、単純な暦の比較ではその日より前ですが、これだけで発送完了を保証できるわけではありません。実際の注文詳細、支払状態、制作進捗を確認して発送を管理します。

一方、Bは10月11日に長期予約で受けた注文であり、10月11日から六十日を足した日を取消期限として使いません。前章の仮の承認日10月27日を使う場合は12月26日が比較用の日付です。AとBを同じ発送便へまとめる計画でも、それぞれの決済期限を一つへ統合しないでください。

日付計算は、見落としを見つけるための補助です。注文詳細に違う期限が出た場合、表の計算を優先して画面を無視せず、長期予約や別App、注文変更など適用条件を調べます。承認日を予定で入力したまま実績へ更新していない可能性もあるため、仮の値には仮と分かる表示を付けておきます。

発送期限に間に合わない見通しが出たら、まずどの注文が対象かを抽出し、購入者へ状況を連絡します。公式は自動キャンセルまでの期間を延長できないと案内しています。商品説明の予定日を書き換えたり、購入者から了承を得たりすることを、システムの期限延長と同じ意味で扱わないようにします。

購入者から取消・返品・返金の相談が来たら、まず支払状況と発送状況を確認し、ショップとして受け付ける対応を伝えます。購入者向けの公式案内でも、相談先は注文したショップとされています。受付可否の判断と、管理画面で取消操作ができるかは別です。了承しただけで注文状態や請求が自動的に変わるとは限りません。

カード決済は発送処理前なら注文詳細から取消できますが、一部でも発送処理を済ませた注文では同じ操作ができません。キャリア決済も発送待ちの未発送注文が対象で、一部の商品だけの取消には対応していません。一方、コンビニ・Pay-easyと銀行振込は管理画面から取消できず、入金済みで返金する場合はショップが購入者へ直接返金する扱いです。注文状態の取消と実際の返金を同じ完了欄にせず、該当する決済の手順で確認します。

PAY ID あと払いでは、「未対応」の注文は注文詳細から全体を取消できますが、一部商品だけの取消はできません。「対応済」の場合はショップ登録メールから所定のキャンセル依頼が必要で、依頼しなければ購入者への請求が続きます。売上残高が当該注文の売上金額を下回る場合は取消できないという条件もあります。支払方法によって取消後の請求・返金の扱いが違うため、購入者へ即時返金を約束する前に公式案内を確認してください。

一部発送と虚偽の発送処理を避ける

カード決済では、一部の商品だけを発送済みにしていても、期限までに未発送の商品が残ると注文全体がキャンセルされると案内されています。キャリア決済にも同様の注意があります。「一個は送ったから注文を維持できる」と判断せず、注文に含まれる商品の状態をすべて確認します。

P-01と別の予約商品を同時に受け、片方だけ完成している場合は、注文番号の下に商品ごとの進捗を並べます。一部発送という現物の動きと、注文全体の決済がどうなるかは別です。期限を避けるためだけに、まだ渡していない商品を発送済みにする運用は行わないでください。

すでに一部を送ってから期限の問題が分かった場合は、送り状番号、実際に送った商品、残っている商品、注文状態をそろえて公式サポートへ相談できる形にします。新しい注文を作れば元の決済問題も解消する、と自己判断で進めないことが重要です。現物とお金の処理を別々に追い、二重請求や未回収を避ける対応を確認します。

予約受付の終了と発送後の記録を整理する

通常商品への切替と予約受付の終了を区別する

通常予約で発送開始予定日だけを設定した商品は、その開始日から通常商品に切り替わると公式に案内されています。発送完了予定日も設定した場合は、その完了予定日から通常商品となります。「完了予定日の翌日から」と読み替えないようにします。長期予約も発送開始予定日を過ぎると通常商品になる扱いです。

この切替は、商品の販売そのものが終了するという意味ではありません。P-01を予約分だけ売り切って追加注文を受けない方針なら、受付終了日時や商品状態を別に管理します。「予約」の表示が消えたことを、注文を受けなくなった証拠にしないでください。

Aの例では完了予定日が11月5日なので、商品設定を変えずにその日を迎える場合は、通常商品への切替も見込んで準備します。10月20日に商品設定を変えたシナリオでは、変更後の設定で改めて確認が必要です。注文Aの元の予定、現在の商品設定、実際の受付状態という三つを区別して記録します。

受付を終えるときは、販売期間設定Appで決めた日時、商品ページの案内、告知している締切を照合します。「予定数に達したので終了」と「予定の時刻になったので終了」も違う理由です。終了した理由が分かれば、次回の予約で期間を見直すのか、受注できる数量を見直すのか判断しやすくなります。

発送後は予定ではなく実績で注文を閉じる

注文を発送したら、予定日の欄を実績へ上書きして消すのではなく、実際に発送した日を別に残します。通常予約Aでは、11月1〜5日という注文時の予定、11月10日以降という連絡内容、実発送日を比べられます。遅れの原因を振り返るためにも、最初の予定が分かる形が役立ちます。

長期予約Bは、変更後の予定と実発送日に加え、承認日、追加利用料、売上明細の確認を結び付けます。試算45円と実際の明細を比較し、対象の注文金額や送料に違いがないかを見ます。数字が合わない場合、手数料全体を一括して「長期予約の一パーセント」と説明せず、費目を分けて確認してください。

購入者への発送案内には、実際に発送した内容と、利用する配送方法に応じた追跡情報を使います。通常は実際に発送してから管理画面で発送処理を行い、「対応済」への変更によって発送完了メールが送られます。操作は受注後の発送手順の公式案内で確認してください。前章の入金済み注文が六十日経過で自動的に対応済となる処理とは異なります。予定日に処理するためだけの架空の送り状情報は使わず、別注文の追跡番号を送らないようにします。

同じ記録を次回の予約設定へつなげる

表は横にスクロールできます。

この最終表は、発送できたかどうかだけを丸で付けるものではありません。Aで個別連絡が遅れたなら連絡の起点を早め、Bで承認待ちを見落としたなら注文状態の確認を発送前へ追加します。問題が起きた工程を特定し、次回に必要な変更だけを予約の準備表へ戻します。

数量の見直しでは、予約で確保した数、制作中の数、完成後に追加販売できる数を区別します。予約受付を終えたからといって、すべてが自由に販売できる完成在庫になるわけではありません。物の数の管理はハンドメイドの在庫管理を使い、今回の注文ごとの期限表とは役割を分けて続けられます。

たとえばBを前倒しできた理由が材料の早着なら、次回も必ず同じ早さで届くとは限りません。一度うまくいった最短日程へ予約期間を縮めるより、実際の入荷・制作・検品の日を比較して、安定して説明できる期間を選びます。販売機会を増やすことと、約束できる発送日程を守ることの両方を見てください。

問い合わせには注文の種類と現在地を添える

公式サポートへ確認するときは、「予約商品が発送できない」だけでなく、通常予約か長期予約か、元の予定日、変更した日、注文の現在の表示を伝えられるようにします。長期予約なら、カード承認の結果と、発送開始予定日を前倒ししたかも重要です。購入者のカード番号や不要な個人情報を資料に含める必要はありません。

相談内容は、商品設定、注文変更、承認、期限のうち、どこで想定と違ったかを一つずつ整理します。変更前と後の情報が残っていれば、同じ設定を何度も上書きする前に原因を調べられます。操作を繰り返して表示が変わるのを待つより、どの注文へ何が反映されたかを確認するほうが、購入者への説明も一貫します。

BASEの予約販売は、発送予定を登録したあとも、通常予約の個別連絡と長期予約の注文操作を使い分けることが大切です。受注時の条件を残し、承認・期限・実発送を注文単位で照合して、次の予約でも使える記録に整えましょう。