果物のギフトを三か所へ送る注文が届いたものの、どの箱を誰へ送るか、送り状に誰の名前を載せるかを電話で確かめ直している。注文画面に住所欄があっても、商品や数量との対応が曖昧なままでは、受注担当者が情報を組み直すことになります。
農園・生産者直販の経営者やWeb担当者が見直したいのは、複数の住所を入力できるかだけではありません。購入者が確認する注文全体と、各受取人へ届ける商品・情報を分けることです。この記事では架空のF農園を例に、注文画面、確認表、通知や同梱書類の改修範囲を整理します。
ギフト対応を、包装の選択だけで終わらせない
商品ページに「ギフト対応」と書いてあると、購入者は包装のほかにも、別住所への配送や送り主名の変更を期待するかもしれません。実際に何ができるかを分けて案内します。包装を選べることと、一回の注文で複数の宛先へ送れることは別の機能です。
まず受注担当者と、現在受けている注文を確認します。同じ商品を何軒にも送る注文が多いのか、宛先ごとに品物が違うのか。注文者本人の名前で送るのか、会社名など別の表示を希望されるのかによって、必要な画面が変わります。過去の注文を共有するときは、実際の氏名や住所を除いた例に置き換えます。
複数配送を受けない運用なら、一注文で指定できる宛先の範囲を、購入手続きに入る前から示します。備考欄へ住所を追加すれば対応できるような案内にせず、宛先ごとに注文するのか、別の受付方法を使うのかを説明します。実際に受けていない一括注文の窓口を、便宜的に作る必要はありません。
複数宛先に対応する場合も、すべての商品や組み合わせで使えるとは限りません。受付時期や発送元などによって扱いが変わるなら、商品を選ぶ画面と配送先を指定する画面の両方で条件を確認できるようにします。最後の確定画面だけで対象外と分かる構成は、見直しの候補です。
数量は、振り分けるのか、同じ一式を複製するのか
「三箱を三か所へ」と「三箱ずつ三か所へ」では、必要な総数が違います。複数配送の設計では、カートに入れた数量を宛先へ割り当てるのか、選んだ一式を宛先数だけ増やすのかを先に決めます。同じ「配送先を追加」というボタンでも、数量がどう変わるかを説明しなければ、利用者は判断できません。
コウ農園の案内は、送り先を選んだ後に商品と数量を指定し、配送先リストへ追加する流れを説明しています。指定を終えた後は、送り先ごとの商品と送料を確認する構成です。参考にするのは、住所だけでなく、商品・数量との組み合わせを一件ずつ確認できる点です。コウ農園の複数配送先の案内
F農園では、説明用に「りんご箱Aを三箱選び、宛先Aへ二箱、宛先Bへ一箱を割り当てる」例を考えます。画面には選択済み三箱、割当済み三箱、未割当てなしと表示する設計です。宛先を増やすだけでは商品数が増えないことも、数量欄の近くで伝えます。この数は実際の販売単位や商品仕様ではありません。
宛先Bの数量を二箱へ変えた場合は、合計四箱になるため、カート側の数量を増やすのか、割当てを修正するのかを利用者が選べる必要があります。入力後に無言で数量や金額を変えず、何が不足しているかを対象商品と一緒に示します。自社のカートで実現できる方法を制作会社と確かめます。
同じ一式を複製する方式を使うなら、「この内容を別の宛先にも追加」のように動作が分かる名前を検討します。追加前後の合計数量と金額を確認できることが大切です。異なる商品を宛先別に振り分ける機能がない場合は、その制約と利用できる注文方法を先に案内します。
購入者・送り主・受取人を、別の役割として扱う
購入する人、贈り主として表示する人、商品を受け取る人が同じとは限りません。家族が代理で注文する場合や、会社の担当者が手続きをする場合があります。「氏名」という入力欄だけで済ませず、「購入者のお名前」「送り状に表示する送り主」「お届け先のお名前」と役割が分かる見出しを付けます。
JAタウンの会員向け複数配送の案内では、注文主とは別に送り主を指定する欄を説明しています。一方で、一回の注文に複数の送り主名は指定できず、送り主名を分ける場合は注文を分ける案内があります。複数配送先に対応していても、送り主まで宛先ごとに変更できるとは限らない例です。JAタウンの複数箇所への注文案内
F農園の例では、送り主を注文全体で共通にする前提を置きます。確認画面にも「以下の全配送先に共通の送り主」と表示し、変更したらすべての宛先へ反映されることを伝えます。宛先ごとに送り主を変えたい注文を受けるかどうかは別に決め、未対応なのに備考欄だけで指定できるようにはしません。
送り主の情報を購入者情報からコピーする場合も、どの項目がコピーされるかを確認します。名前だけなのか、住所や電話番号も含むのかで、出力される送り状の内容が変わります。画面の説明を作る前に、発送時に使う仕組みと、実際に表示できる範囲を受注・出荷担当者へ確かめます。
のしの名入れも、送り状の送り主とは別の表示です。同じ名前になることが多くても、一方を変更すれば他方も変わる設計でよいかを確認します。自動で転記する場合は、その関係が分かる説明と、転記後の内容を確認する場所を用意します。表示先が違う項目を、見た目が似ているだけで統合しないことが大切です。
注文全体と、宛先ごとの確認表を作る
制作会社へ「複数配送を付けたい」と伝えるだけでは、商品、送り主、通知のどこまで個別に扱うかが分かりません。先に一件の架空注文を作り、注文全体で持つ情報と、宛先ごとに持つ情報を並べます。次の表は、F農園が数量を割り当て、送り主を共通にする設計例です。
| 確認する対象 | 注文全体の情報 | 宛先ごとの情報 | 画面・出力で確かめる点 |
|---|---|---|---|
| 商品と数量 | 箱Aを三箱選択 | Aへ二箱、Bへ一箱 | 合計と割当数が一致する |
| 購入者と連絡先 | 手続きする人と連絡先 | 受取人の名前と住所 | 購入者欄へ受取人を上書きしない |
| 送り主の表示 | 全宛先で共通の表示 | 各送り状で同じ表示 | 共通項目の変更範囲が分かる |
| 同梱する案内 | 同梱方針と対象書類 | 各箱へ入れる内容案内 | 別宛先の情報を混ぜない |
| 金額入りの明細 | 購入者向けの確認先 | ギフト箱には入れない例 | 通知・帳票の宛先を照合する |
この表では、宛先AとBは説明用の記号です。実際の確認画面では、宛先を識別できる表示と商品名・数量を同じ区画へ置きます。長い画面の上にだけ住所を表示して、下の数量欄がどの宛先か分からなくなる状態を避けます。スマホでは区画ごとに対象名を繰り返す方法もあります。
確認表を作る段階で、実現できない項目や手作業が残る箇所も記録します。たとえば購入者への明細を自動で送れないなら、確認できる画面へ案内するのか、希望に応じて担当者が対応するのかを決めます。使っていない機能を前提に「自動送信されます」と原稿へ書かないようにします。
金額入りの明細と、商品に添える案内を分ける
ギフト注文で「明細なし」と案内する場合、何を入れないのかを明確にします。金額入りの購入明細を同梱しないことと、商品内容の案内や保存方法の説明まで入れないことは別です。書類の名前だけで判断せず、誰にどの情報を渡すものかを確認します。
山下フルーツ農園のFAQでは、希望がない限り、納品書など金額が分かるものは添付しないと案内しています。参考になるのは、同梱の扱いを購入前に確認できる点です。他店と同じ条件にする必要はなく、自園の方針と実際の帳票出力が一致するように説明します。山下フルーツ農園のギフトに関するFAQ
F農園の架空例では、金額入りの明細は購入者が確認する情報とし、各ギフト箱には入れない設計を置きます。購入者の確認画面には注文全体の内容を表示し、箱に入れる案内にはその箱の商品情報を載せます。これは書類発行の義務や会計上の扱いを示すものではなく、情報の届け先を考えるための例です。
購入者への注文メールを、そのまま受取人向けの発送通知に流用しないことも確認します。全宛先の住所や購入金額など、別の受取人に見せる必要がない情報が含まれる可能性があるためです。受取人へ通知する運用がないなら、通知を追加する前提で進めず、現在の連絡方法を基に対象を決めます。
受取人向けの通知を用意する場合は、どの注文からどの宛先分を取り出すかを確認します。宛先Aの箱に、宛先Bの商品や住所が記載された案内が入らないよう、画面だけでなく出力される書類まで照合します。同梱しない設定を選べても、別の出力経路で金額が印刷されるなら、改修の範囲に含めます。
収穫や出荷の都合で一部の宛先だけ発送が遅れる場合も、購入者へ知らせる対象を絞れるかを確認します。注文全体を一括で「発送済み」と表示すると、まだ出していない箱まで完了したように見えます。宛先別の状況を持てる場合は、その単位で通知と表示をそろえ、全体の表示と食い違わないようにします。
一方、同じ宛先でも商品ごとに分かれて届く運用なら、宛先の数と発送する荷物の数は一致しません。送料や到着案内を宛先だけでまとめてよいかを出荷担当者へ確認します。複数便の管理が今回の改修範囲に入らない場合も、その注文をどう受け付けるかは案内に残します。
一件を直したとき、ほかの宛先への影響を見せる
購入手続きの途中で宛先Aの住所を直したとき、宛先Bまで同じ住所になっていないかを確認します。共通の送り主を直す操作と、一つの配送先を直す操作は、異なる名前のボタンにします。変更後は、何が変わったかを確認画面で読み取れるようにします。
宛先を削除する場合は、その宛先へ割り当てた商品をどうするかも必要です。未割当てへ戻すのか、カートの数量も減らすのかを、自社の注文方式に合わせて決めます。住所だけが消えて商品数は残る状態と、商品数まで減る状態を、同じ「削除しました」の表示で済ませないようにします。
登録済みの住所を使う場合は、今回の注文だけ直すのか、次回も使う住所録を更新するのかを区別します。また、会員情報を後から変更しても、受付済み注文の送り主や送り先がどの状態で残るかを確認します。現行の住所録を見れば、注文時の指定も分かるとは限りません。
確定後の変更は、変更を申し出た段階と、担当者が反映した段階を分けて案内します。注文番号だけでなく、どの宛先・商品についての連絡かが分かる入口を用意します。問い合わせを送ると必ず出荷前に変更できるような表現にせず、実際の受付方法に合わせます。
架空注文を、画面から通知・出力まで通して確認する
公開前には、自宅向け一件、同じ商品を二宛先へ振り分ける注文、購入者と送り主が異なる注文などを検証環境で試します。実際の決済・出荷・購入者への通知が動かない手順を決め、架空の情報を使って確認します。今回作る説明資料と、本番の注文機能の検査は別の作業です。
確認するのは、注文が送信できることだけではありません。商品数と割当数、送料などの表示、送り主の適用先、明細の届け先が、入力画面、確認画面、受注控え、通知、出力物でつながっているかを見ます。宛先Aだけの修正や削除も行い、残る宛先の指定を照合します。
最後に受注担当者が、どの箱を誰へ送り、どの名前を表示し、どの情報を購入者だけへ渡すかを説明できるか確認します。そこで迷う箇所があれば、入力欄だけでなく見出し、案内文、確認画面、通知や帳票も改修対象です。対応する注文の範囲を決めたうえで、利用者と担当者が同じ内容を確認できる設計へ整えます。
参照資料：コウ農園の複数配送先案内、JAタウンの注文案内、山下フルーツ農園のFAQ。2026年9月21日確認。公開ページの注文案内の構成を参照しています。各店の個別条件を一般化せず、自園の運用と利用機能の確認が必要です。
