注文通知メールに何を入れておくべきか｜店側が受け取る通知の項目設計

ネットショップに注文が入ると、店側にも通知メールが届きます。ところがこの通知、初期設定のままだと「注文が入った」という事実しか分かりません。

お客様に確認の連絡をしたいのに、通知メールのどこにもメールアドレスが書かれていない。お届け日を指定してもらったはずなのに、通知には商品名と金額しか出ていない。結局、毎回管理画面にログインして注文詳細を開くことになります。

この記事では、店側が受け取る注文通知メールに何を入れておくべきかを、結論から示します。あわせて、項目を追加するときに実際に起こりやすい落とし穴と、その防ぎ方までを、ホテル系ギフトECの実運用から整理します。

結論：「受け取った人が管理画面を開かずに次の作業へ進めるか」で決める

先に正解を書きます。通知メールに入れる項目は、次の基準で決めます。

通知メールを受け取った人が、管理画面を一度も開かずに、次の作業へ進めるか。

この基準で見ると、初期設定の通知メールに足りない項目は、たいてい次の4つです。

項目	なぜ必要か
お客様のメールアドレス	注文内容に不明点があったとき、店側からすぐ返信するため
お届け日・配送希望日	仕入れ・製作・配送手配の起点になる日付。通知の中で最も業務上重要
注文フォームの入力内容すべて	依頼者名・電話番号・希望時間・メッセージ内容など、カスタマイズ商品の中身
注文者名と商品の対応	複数商品の注文で「どの商品にどの指定が付いているか」を紐づけるため

逆に、標準の通知メールに最初から入っているのは「商品名・数量・金額・配送先住所」あたりです。つまり足りないのは「お金の情報」ではなく「動くための情報」です。決済はプラットフォームが完結させてくれますが、そのあとの仕入れ・製作・連絡は人が動きます。その人が見る画面が通知メールなら、そこに全部書いてあるのが正しい状態です。

「管理画面を見ればいい」が通用しない現場は普通にある

ここで「管理画面を見れば全部載っているのだから、通知は簡易でいい」という考え方があります。運営者がひとりで回している店舗なら、それでも成立します。

しかし実際の受注業務には、管理画面にログインできない人・しない人が関わることが多くあります。

実例を挙げます。都内ホテルのフラワーギフトECでは、1件の注文に対して動く関係者が3者います。ホテルの予約担当、提携している花屋、そして運営を支援する制作会社です。このうちホテルの予約担当は、ECの管理アカウントを持っていません。通知メールに付いている「注文を表示する」ボタンを押しても、ログイン画面で止まってしまい、その先が見られない。つまり通知メールの本文に書かれていない情報は、この担当者にとって存在しないのと同じでした。

このECからの要望は「お客様に届く内容と同じものを、こちらの通知でも見られるようにしてほしい」というものでした。要望の本質は、メールの見た目を揃えることではありません。通知メールを印刷すれば、そのまま当日の作業指示書として使える状態にしたいということです。実際、項目を追加したあとの運用では、通知メールが花屋とホテルの共有書類として機能しています。

管理画面へのログインを関係者全員に配る方法もありますが、アカウント管理の手間と権限の問題が増えるだけです。情報を人に取りに行かせるのではなく、情報を人に届く形にする。通知メールの項目設計は、この方針で考えるのが正解です。

お客様のメールアドレスは「空のときの挙動」まで決めて入れる

4項目の中で最初に効くのが、お客様のメールアドレスです。

注文内容に確認したい点があったとき、通知メールに連絡先がなければ、管理画面を開いて注文を探し、顧客情報を開いてコピーする、という手順が毎回発生します。通知メール本文にアドレスが1行入っていれば、そのまま返信用のメールを書き始められます。

ただし、追加するときは値が空だった場合の挙動まで決めておくことをおすすめします。ゲスト購入や電話番号のみの注文など、メールアドレスが取得できていないケースは実際にあります。そのとき「メールアドレス：」という空欄の行が印刷物に残ると、「記載漏れではないか」という確認がかえって増えます。

正しい設計はこうです。

• メールアドレスがあれば表示する
• 別の場所（顧客情報側）にあればそちらを代わりに表示する
• どちらも空なら、行ごと表示しない

「空欄を出すくらいなら行を消す」。小さな判断ですが、通知メールを印刷して現場で使う運用では、この差が効きます。

注文フォームの入力内容は「表示されない仕様」を前提に設計する

ギフトECや受注生産の店舗では、注文フォームでお届け日・依頼者名・メッセージ内容などを入力してもらいます。この入力内容（カスタム項目）を通知メールに出すのが、項目設計の本丸です。そして、ここには知らないと気づけない落とし穴が2つあります。

落とし穴1：非表示扱いのカスタム項目

Shopifyをはじめ多くのカートには、カスタム項目を「顧客に見せない内部データ」として扱う命名規則があります。Shopifyの場合、項目名の先頭にアンダースコア（_）が付いていると、メールにも画面にも表示されません。オプション入力用のアプリを使っていると、アプリが自動的にこの形式で保存していることがあります。

つまり「フォームで入力してもらっているのに、どのメールにも出てこない」という状態は、故障ではなく仕様です。通知メールに出すには、テンプレート側でこの項目を明示的に拾って、表示用に整形する必要があります。

落とし穴2：セット商品は別の処理経路で描画される

より厄介なのがこちらです。メールテンプレートの明細部分は「注文商品を1件ずつ処理するループ」でできています。ここに表示を追加すれば全商品に効くように見えますが、セット商品（グループ化された商品）は別のループで描画されることがあります。

この構造を知らずに明細ループの中へ表示を追加すると、どうなるか。単品商品では表示されるのに、セット商品では何も表示されません。しかもエラーは一切出ないため、テスト注文が単品だけだと問題に気づかないまま本番運用に入ってしまいます。実注文で「納品日がどこにも出ていない」と発覚して初めて分かる、という事態が起こり得ます。

これを防ぐ設計は明快です。明細ループの中に表示を差し込むのではなく、メール冒頭に独立した「納品情報」ブロックを新設する。そのブロックの中で、商品データが通る可能性のある経路をすべて走査し、商品IDで重複を除いて一覧表示します。知らない分岐の中に表示を潜り込ませない。これだけで「特定の商品タイプだけ静かに表示されない」というリスクが構造的に消えます。

前述のホテル系ギフトECでも、この方式で通知メールの冒頭にお届け日を大きく整形して表示し、その下に商品ごとの入力内容（依頼者名・時間・メッセージ等）を並べる形に落ち着いています。受け取った担当者は、メールを開いた瞬間に「いつの、何の注文か」が分かります。

検証は「プレビュー」ではなく「実注文」で行う

もうひとつ、検証の話です。メールテンプレートのプレビュー機能は、サンプル注文データで描画されます。このサンプルには、あなたの店のカスタム項目が入っていません。つまり追加した表示がプレビューに出ないのは正常で、「プレビューに出ない＝壊れている」でも「プレビューに出た＝完成」でもありません。

確認の手順はこう組みます。

1. テンプレート保存後、編集画面を開き直して変更が残っているかを確認する（保存したつもりで反映されていないケースを潰す）
2. プレビューではエラーが出ていないことと既存部分が崩れていないことだけを確認する
3. カスタム項目の表示は、テスト購入か次の実注文で最終確認する。テスト購入は必ず通常の商品ページからフォームを全部入力して行う（管理画面から作る手動注文ではカスタム項目が入らず、検証になりません)

変更・キャンセルの案内は「顧客向けメール」に書く。店側通知には不要

冒頭の課題ともうひとつセットで聞かれるのが、「注文の変更・キャンセルの案内文はどこに書いておくべきか」です。

答えは、お客様に届く注文確認メールの中、キャンセル導線のすぐ近くです。「キャンセルはいつまで受け付けるか」「変更したい場合はどうするか」の2点を、注文直後に届くメールの中で示しておくと、変更系の問い合わせはそこで大きく減ります。文面の作り方と期限の決め方は、別記事で詳しく整理しています。

一方、店側の通知メールにこの案内文を入れる必要はありません。店側通知の役割は「作業に必要な情報を全部渡すこと」であって、案内ではないからです。顧客向けメールと店側通知は、同じ注文から生まれる別の書類だと考えると、それぞれに何を書くべきかが整理しやすくなります。

• 顧客向け（注文確認メール）：注文内容の控え＋変更・キャンセルの案内＋問い合わせ先
• 店側向け（注文通知メール）：お届け日・連絡先・フォーム入力内容を含む、作業に必要な全情報

項目を整えても「届かない」なら意味がない

最後に、項目設計の外側にある前提をひとつ。通知メールの中身をどれだけ整えても、そのメールが迷惑メール扱いされていては意味がありません。独自ドメインで送信するメールのドメイン認証（SPF・DKIM）が未設定だと、到達率そのものが下がります。通知メールの改善に手を付けるタイミングで、送信ドメイン認証の状態も一度確認しておくことをおすすめします。

なお、通知メール内の商品画像が「×」で表示されないという相談もよくありますが、これは多くの場合、受信側メールソフトの外部画像ブロックが原因です。特に企業の受信環境では組織のポリシーで一律ブロックされていることがあり、送信側では解決できません。作業に使う情報を画像に依存させず、テキストで本文に書いておくべき理由のひとつでもあります。

まとめ：通知メールは「もうひとつの業務システム」として設計する

店側が受け取る注文通知メールの項目設計を整理します。

• 判断基準は「受け取った人が管理画面を開かずに次の作業へ進めるか」
• 追加すべきはお客様のメールアドレス・お届け日・フォーム入力内容・商品との対応関係。足りないのは「動くための情報」
• 管理画面にログインできない関係者（外部パートナー・他部署）がいるなら、通知メール本文への集約が唯一の共有手段になる
• メールアドレスは空のときは行ごと消すところまで設計する
• カスタム項目には「非表示扱いの命名規則」と「セット商品の別経路描画」という2つの落とし穴がある。明細ループに差し込まず、冒頭に独立ブロックを新設するのが安全
• 検証はプレビューではなく実注文またはフォーム入力込みのテスト購入で行う
• 変更・キャンセルの案内は顧客向けメールに、作業情報は店側通知に。役割を分ける

通知メールは「システムからのお知らせ」ではなく、受注のたびに関係者へ自動配布される業務書類です。そこに何を載せるかは、立派な業務設計です。印刷してそのまま現場が動ける通知メールになっているか、一度ご自身の店の通知を見直してみてください。