ECサイト制作では、商品を見せる画面と、受注から出荷・返品までの業務を一緒に設計します。見た目や機能数だけでは、購入できるか、運営を続けられるかを判断できません。販売する商品と対応できる条件を明確にし、公開前に実際の流れを試します。
最初に決める五つの要件
| 要件 | 決める内容 | 確認する担当 |
|---|---|---|
| 商品 | SKU、選択肢、価格、在庫、説明と写真 | 商品・販売担当 |
| 配送 | 地域、温度帯、梱包、送料、出荷日 | 倉庫・発送担当 |
| 決済 | 利用方法、売上確定、返金、失敗時の案内 | 経理・運営担当 |
| 顧客対応 | 注文変更、取消、返品、問い合わせ | サポート担当 |
| 更新 | 価格改定、販売終了、権限、障害対応 | 管理責任者 |
未定の条件は、公開までに決める項目として残します。初回公開に必要な機能と、利用状況を確認してから追加する機能を分けると、予算と試験範囲を整理できます。
商品へ辿り着ける構造を作る
GoogleのECサイト構造資料に沿い、メニュー、カテゴリ、商品へ通常のリンクで移動できる状態を確認します。サイト内検索だけに商品発見を依存させません。利用者向けの絞り込みと、検索エンジンに見せるURLの整理は両方設計します。
商品ページには選ぶための情報を置きます。寸法、素材、対応条件、同梱品、発送と返品の案内は、写真だけに埋め込まず本文でも確認できるようにします。構造化データの価格・在庫と実際の表示が一致するかも点検します。
公開前の購入試験
- 代表商品と選択肢を選び、在庫あり・なしの表示を確認する。
- カートで数量を変更し、割引や送料の境界条件を試す。
- 配送先の地域や条件を変え、意図した配送方法が出るか確認する。
- テスト決済で注文・通知・在庫の変化を確認する。
- 取消・返金・一部返品の記録と、顧客への案内を試す。
- スマートフォンで入力エラー、戻る操作、通信中断後の状態を確認する。
決済の試験方法は利用サービスの案内に従い、実課金の有無を区別します。試験で作った注文や計測イベントを、公開後の実績へ混ぜないよう記録します。リンク切れや二重注文、通知が届かない状態は公開前に解消します。
計測と受注台帳を照合する
商品閲覧、カート、購入までのどこで変化があるか確認します。アクセス解析と受注データは同意設定や端末差などで一致しないことがあるため、売上の正本を明確にします。集計期間、返品、税・送料の扱いも揃えます。
売上だけでなく、粗利、返品理由、欠品、問い合わせ、発送の遅れを見ます。購入率が高くても利益や対応負担が悪化していないかを確認します。期間や広告が異なる比較で、デザイン変更だけの成果と決めないようにします。
AIや追加アプリは運用できる範囲で使う
商品説明の下書きは仕様と照合して公開し、サポートは回答できない質問を人へ引き継ぎます。在庫予測をそのまま発注へつなげず、保管・資金・納期の条件を確認します。便利な機能でも、料金、権限、速度、終了時のデータ移行を検討します。
制作会社と引き継ぐもの
アカウント、契約、更新手順、バックアップ、障害連絡先、URL対応表、計測設定を一覧にします。自社担当者が商品変更や販売停止を実行できるかを確認し、保守に含まれる作業と追加費用の条件を残します。
よくある疑問
機能を多く入れるほど売れますか?
機能は課題を解決するために選びます。利用されず保守負担だけ増える場合もあるため、購入に必要な基盤から始めます。
公開したらSEO対策は完了ですか?
登録状況、商品変更、リンク、検索される内容を継続して確認します。公開やサイトマップ送信は登録・順位を保証しません。























コメント