ECサイトで商品をカートに入れ、購入完了の画面まで進めても、公開前の確認は終わりではありません。注文が届いたことに担当者が気付けるか、正しい商品を取り出せるか、出荷したことを購入者へ知らせられるかまで、注文後の仕事が続きます。

テスト注文では、一件の注文を購入者側と運営側の両方からたどります。画面の動作に加え、通知、管理画面、在庫、決済状態、出荷に使うデータを、実際に担当する方と確認しましょう。

最初に、確認環境と止める範囲を決める

テストに使う環境、決済方法、商品、連絡先を制作会社と運営担当者で決めます。利用するECや決済サービスの公式手順に従い、テスト機能で確認できる範囲を把握します。通常販売中のサイトへ、担当者に知らせず注文を入れる方法は避けます。

Shopifyでは、テスト用の決済方法を使って注文を確認できます。一方、Shopifyペイメントの公式案内は、配送ラベルの購入には請求が発生し、自動出荷するアプリにも事前の対応が必要だと説明しています。テスト決済だから、外部への処理もすべて止まるとは限りません。

倉庫への出荷指示、送り状の購入、会計への転送など、つながっている先を確認します。テスト環境で受け渡すのか、データを出力して内容を見るところまでにするのか、確認の終点を決めます。実決済や実出荷が必要な検査は、費用と処理方法を含め、関係者が合意した別の手順で行います。

一件の注文に、現場で使う条件を入れる

ここでは、タオルを販売する小さな通販店の架空例を考えます。色違いの商品と、届け先、配送希望を使って、受注から出荷の準備まで確認するとします。扱っていないギフト機能や配送指定を、検査のためだけに追加する必要はありません。

注文を始める前に、選ぶ商品と数量、入力する条件、予想する合計金額や送料を記録します。購入後は注文番号を控え、購入者への通知と管理画面、出荷用の資料で同じ注文を追えるようにします。

実際に使っていない人のメールアドレスや電話番号は入力せず、確認用として管理できる連絡先を使います。受信確認の方法も利用サービスに合わせ、通知の送信先が意図した範囲に収まっているかを確かめます。

通知が届いた後、担当者が仕事を始められるか

購入者向けの注文確認メールでは、選んだ商品、色やサイズ、数量、送料、届け先などを注文内容と照合します。支払い待ちの注文なら、支払いが済んだように読める文面になっていないかも見ます。

運営側の通知は、担当者が普段確認する宛先へ届くかを確かめます。制作担当者にだけ届いていても、公開後の受注担当者が注文を把握できなければ仕事が止まります。

メールが届くことに加えて、受注担当者が管理画面で対象の注文を見つけ、次の作業を判断できるかを確認します。注文番号、日時、購入者、商品が一致し、同じ注文を重ねて処理しそうな表示や通知がないかも見ておきます。

テスト注文を購入者の通知、受注担当の管理画面、出荷担当のデータへ同じ注文番号でたどる流れ
購入完了後も、同じ注文を担当者の仕事へつなげて確認します。

決済の状態と、在庫の変化を照合する

注文が作成されたことと、決済が完了したことは分けて確認します。支払い待ち、決済済み、取消などの状態が、利用する決済方法と運用に合っているかを制作会社と見ます。受注担当者がどの状態で出荷準備へ進めるかも、社内の手順と合わせます。

在庫は、注文前に記録した数量と注文後の状態を比べます。タオルの例なら、選んだ色の在庫が対象になっているか、別の色の数量が変わっていないかを確認します。在庫を減らすタイミングや、注文の取消時に戻す扱いは仕組みによって異なるため、期待する動作を先に決めて照合します。

通常の購入だけでなく、採用する決済方法の失敗や取消をテストできる場合は、そのときの注文状態も確認します。成功した注文と同じように出荷対象へ入らないかを、公式のテスト方法と担当者の判断手順に沿って見ます。

出荷に使うデータで、商品と届け先が分かるか

出荷担当者が使う一覧や帳票、データファイルで、商品名だけでなく色、サイズ、数量を判別できるかを確認します。購入画面では選べていても、出荷用の一覧では選択内容が抜けると、商品を取り違える原因になります。

届け先の氏名や住所、建物名、配送方法なども、実際に使う形式で確認します。備考や配送希望を受け付けるなら、担当者がその情報をどこで読むかまでたどります。注文管理から別の画面へ手作業で写す場合は、その工程も確認に含めます。

倉庫や配送サービスへ自動で送る仕組みは、準備したテスト環境と範囲で検査します。実際の出荷を起こさず確認した部分と、未確認の部分を分けて残します。「画面で見えた」だけで外部への受け渡しも確認済みにはしません。

出荷連絡と、テスト後の片付けまで記録する

出荷完了の連絡は、用意した確認方法で文面と送信先を見ます。出荷した商品、配送方法、問い合わせ先が分かるか、追跡情報を載せる場合は正しい注文の情報かを確認します。実出荷を伴わない試験では、試験用の通知やプレビューなど、利用できる方法と限界を記録します。

最後に、テスト注文と在庫をどう扱ったか、停止した連携や変更した設定を戻したかを担当者同士で確認します。公開前の確認が終わっても、テスト用の決済状態が残っていると通常の販売へ進めません。未確認の項目には、次に確認する担当と方法を残します。

テスト結果を確認済み、修正後に再確認、別環境で確認の三つに分け、注文と設定の終了処理も残す図
確認できたことと、別の手段で確かめることを分けて引き継ぎます。

Bämの通販・ECサイト制作では、商品を選ぶ画面と、受注・出荷・通知の流れを一緒に整理します。テスト注文も、購入できるかだけでなく、運営する方が注文後の仕事を進められるかを確認する機会として準備します。

参考資料