Shopifyの注文メモ(備考)がスタッフ通知メールに出ないときの直し方|条件付きで1ブロック足す方法と、モール側で変えられないときの拾い方
Shopifyの注文メモ(備考)がスタッフ通知メールに出ないときの直し方|条件付きで1ブロック足す方法と、モール側で変えられないときの拾い方
お客様が注文時に入れた備考、あるいは受注後にスタッフが書き足した申し送り。管理画面の注文詳細には「メモ」としてちゃんと入っているのに、店側に届く受注メールにはその一行がない——これは設定ミスでも、メモの入れ方が間違っているわけでもありません。
先に結論を書きます。
Shopifyのスタッフ通知「新規注文」テンプレートには、注文メモ(note)が最初から入っていません。仕様です。出したいなら、テンプレートに条件付きのブロックを1つ自分で足します。作業そのものは5分で終わります。
ただし、足す場所と足し方を適当に決めると、あとで面倒なことになります。この記事で扱うのは主にそこです。具体的には次の3点です。
- 「メモがある注文のときだけ」出す書き方(空の見出しを毎回出さない)
- 挿入位置を、そのメールを誰が読むかで決める
- 顧客向けメールには絶対に同じブロックを入れない
弊社graciautoは名古屋でホームページ制作とLINE公式アカウント構築を手掛けており、支援先のECでは受注メールを機械で読み取って受注台帳と製造指示書に自動反映する仕組みを運用しています。この記事は、その本番環境で実際に行った設定と、そこで決めた判断基準をもとに書いています。
—
なぜ「納品書には出るのにメールには出ない」のか
先に混乱のもとを片付けておきます。Shopifyで注文メモを扱う場所は2つあり、編集画面も変数の書き方も別系統です。
| スタッフ通知メール | 納品書(仕様表テンプレート) | |
|---|---|---|
| 編集場所 | 設定 → 通知 → スタッフ通知 → 新規注文 | 設定 → 発送と配達 → 仕様表テンプレート |
| 注文メモ | 既定では出ない(自分で足す) | {{ order.note }} が既定で出る |
| メモの変数 | note |
order.note |
| 明細のループ変数 | 複数ルートに分かれる | line_items_in_shipment の1本 |
「納品書には出ているのだから、メールに出ないのはおかしい」と感じるのはこの差が理由です。片方で動いた書き方をもう片方にそのまま貼っても動きません。メール側は order. を付けずに note と書きます。
なお納品書側のカスタマイズについては別記事「Shopifyの納品書に注文メモや納品情報を載せる方法」で扱っています。この記事はメール側の話です。
—
実際に足すコードと、挿入位置の決め方
スタッフ通知「新規注文」のテンプレートに、次のブロックを入れます。
{% if note != blank %}
<table class="row" style="width: 100%;">
<tr><td class="empty-line"> </td></tr>
<tr><td><strong>メモ:</strong> {{ note }}</td></tr>
</table>
{% endif %}
要点は2つです。
{% if note != blank %} で囲む。 これを省くと、メモが無い注文でも「メモ:」という空の見出しが毎回出ます。受注メールは毎日届くものなので、中身のない行が常に出ていると、読む側がその行を見なくなります。実際にメモが入った注文が来たときに気づかれない——という事態を未然に防ぐための条件分岐です。機械で読み取っている場合も同じで、空行が常時混ざると「メモがあるかどうか」を行の有無で判定できなくなります。
既存テンプレートの構造に合わせて table で入れる。 メール本文は各社のメールソフトで崩れないようテーブル組みで作られています。素の <p> や <div> を差し込むと、特定の環境だけレイアウトが崩れることがあります。周囲のコードと同じ形で入れるのが安全です。
挿入位置は、「注文内容を確認する」ボタンのテーブル直後が扱いやすい位置です。理由は次の項で説明します。
—
置き場所は「誰がそのメールを読むか」で決める
挿入位置に唯一の正解はありません。判断は「そのメールの読み手」で分かれます。
人だけが読む場合は、目に入りやすい上のほう——注文番号や合計金額の近くに置きます。メモは出荷前に見落とすと事故になる情報なので、スクロールしないと見えない位置は避けます。
受注メールを機械で読み取っている場合は、話が逆になります。既存の項目の並びを壊さない位置に置きます。受注メールを解析して台帳に転記するプログラムは、「この見出しの次の行に品番がある」といった本文の並びを手がかりにしています。明細の途中にブロックを差し込むと、その手がかりがずれて品番やSKUの読み取りが崩れます。既存の描画ブロックの後ろ、区切りのはっきりした位置に足すのが安全です。
弊社が支援している革製品ブランドのECでは、Shopify・楽天・Yahoo!・Amazonの4チャネルの受注メールを毎朝の自動処理で読み取り、受注台帳のスプレッドシートと製造指示書に反映しています。この構成ではメールの本文が事実上のデータ入力欄なので、通知テンプレートの改修は「見やすさ」ではなく「後工程が読めるか」で決めます。メモ欄が空のままだと、現場が結局は管理画面を開き直すことになり、自動化した意味が薄れます。
—
顧客向けメールには同じブロックを入れない
ここは強調しておきます。同じコードを顧客向けの「注文確認」テンプレートに入れてはいけません。
注文メモ(note)は、お客様が入れた備考だけが入るとは限りません。受注後にスタッフが「在庫確認済み」「クレーム対応中」「値引き了承済み」といった社内の申し送りを書き足す運用は珍しくありません。顧客向けテンプレートにメモを出すと、その社内メモがそのままお客様に届きます。
編集するのはスタッフ通知だけ。Shopifyの通知設定は「お客様への通知」と「スタッフへの通知」が別セクションに分かれているので、作業前にどちらのセクションを開いているかを必ず確認してください。
—
作業前に決めておく4つの安全策
本番のテンプレートを直接編集する作業です。次の4つを先に押さえておくと、手戻りが起きません。
1. 編集前に現行テンプレートを丸ごと保存する。 エディタ内をクリック → 全選択 → コピーして、テキストファイルに落としておきます。Shopifyには初期テンプレートへ戻す機能がありますが、それは既定の状態に戻るものです。過去に別のカスタマイズを入れていた場合、それも一緒に消えます。自分の直前の保存状態に戻したいなら、手元のバックアップしかありません。
2. ログイン中のストアを確認する。 複数ストアを扱っているアカウントでは、ブラウザが別ストアでログインしたままということが起こります。編集画面には入れるのに保存で権限エラーになる、あるいは意図しないストアを編集してしまう——どちらも着手前のストア名確認で防げます。管理画面左上のストア名を見てから作業に入ってください。
3. 貼り付け後に「保存」バーが出たか見る。 テンプレートのエディタはコードエディタ部品で動いており、貼り付け方によっては変更が検知されず、未保存バーが出ないことがあります。エディタ内をクリック → 全選択 → 貼り付け、という手順で入れると確実に検知されます。バーが出ないまま画面を離れると、変更は消えます。
4. 既存の表示に手を入れない。 品番・SKU・数量など既にある行は触らないこと。後工程で読み取りをしている場合、既存行のラベルを1文字変えるだけで解析が止まります。足すだけ。書き換えない。
—
検証は「プレビュー」ではなく「実注文」と「受信者」で行う
保存後の確認で、2つ間違いやすい点があります。
プレビューにメモが出なくても、それは正常な可能性が高い。 プレビューはサンプル注文で描画され、そのサンプルにメモが入っていないことがあります。条件分岐を入れた以上、メモが無ければブロックが出ないのが正しい動作です。「プレビューに出ない=壊れている」ではありません。最終確認は、メモを入れた実注文(テスト注文でも構いません)で行います。
そのテンプレートのメールが、本当に見たい宛先に届いているかを確認する。 スタッフ通知は複数のテンプレートがあり、それぞれ受信者が別に設定されています。編集したテンプレートと、実際に業務で使っているメールが別物だったという行き違いは起こり得ます。設定画面で受信者アドレスを確認し、自動処理で読んでいる場合は「そのアドレスのメールボックスを読んでいるか」まで突き合わせてください。
—
楽天・Yahoo!・Amazonはテンプレを変えられない。「本文にあれば拾う」に切り替える
Shopifyや自社ECは通知テンプレートを自由に編集できますが、モールは店舗側でメール本文のレイアウトを編集できません。備考やギフトメッセージが本文に出るか出ないかは、モールの仕様で決まっています。
ここで「全チャネルで同じ形式に揃えよう」と考えると詰まります。揃えられないからです。現実的な線引きはこうなります。
| チャネル | 通知テンプレの編集 | メモ・備考の取り方 |
|---|---|---|
| Shopify・自社EC | 可能 | 条件付きブロックを足して確実に出す |
| 楽天・Yahoo!・Amazon | 不可 | 本文の決まった見出しを手がかりにあれば拾う |
「必ず出す」チャネルと「あれば拾う」チャネルを分けて設計するのが要点です。モール側は、備考の見出し行をアンカーにして次の行を取る、という読み方になります。そして出ないケースは自動化をあきらめて、管理画面で確認する運用に落とす——ここを無理に自動化しようとすると、取りこぼしに気づけない仕組みができあがります。
自動化の判断としては、「取れないものがある」こと自体は問題ではありません。問題は、取れなかったことが分からないまま次の工程に進むことです。モール側の備考は台帳上で「要確認」として残し、人が見る前提にするほうが安全です。
—
手順のまとめ(チェックリスト)
- 設定 → 通知 → スタッフ通知の「新規注文」を開く(お客様への通知ではない)
- 現行テンプレートを全文コピーしてファイルに保存する
- 管理画面左上でストア名を確認する
{% if note != blank %}で囲んだブロックを、既存の描画を壊さない位置に足す- 未保存バーが出たことを確認して保存する
- メモを入れた実注文で本文を確認する
- そのテンプレートの受信者アドレスを確認する
- モール側は「本文にあれば拾う・無ければ要確認」に線を引く
—
まとめ
注文メモがスタッフ通知メールに出ないのは仕様であり、条件付きのブロックを1つ足せば解決します。作業自体は短時間で終わりますが、足す位置は「そのメールを誰がどう読むか」で決める——人が読むなら目立つ位置、機械が読むなら既存の並びを壊さない位置。この一点を先に決めておくと、あとから受注処理が崩れるような手戻りが起きません。
そして、顧客向けテンプレートには入れない。社内の申し送りがお客様に届く事故は、通知設定のセクションを取り違えるだけで起こります。
受注メールを起点に台帳や指示書まで自動で流す構成では、通知テンプレートは「メールの体裁」ではなく業務システムの入力画面として設計する対象になります。ネットショップの受注を1枚のスプレッドシートに集約する設計や、複数モールの品番ルールを統一する話は別記事で扱っていますので、あわせてご覧ください。
弊社graciautoでは、ホームページ制作・LINE公式アカウント構築とあわせて、受注から製造指示までの業務の仕組み化もお手伝いしています。「同じデータを何度も転記している」という状態に心当たりがあれば、お気軽にご相談ください。